{"slug": "we-build-faster-than-we-decide", "title": "We Build Faster Than We Decide", "summary": "AI has made building software faster, but the bottleneck has shifted from delivery to decision-making. Teams must now focus on understanding problems and running experiments rather than just shipping features, as speed without learning creates noise. The discipline of 'Software Science'—treating code as an instrument, the market as a lab, and user behavior as data—becomes critical.", "body_md": "AI has made it easier to produce working software.\n\nThat part is real.\n\nIt can write code, draft documents, research a topic, scaffold a prototype, and debug a problem faster than most teams can finish writing a decent ticket.\n\nBut faster building doesn't automatically mean better product decisions.\n\nThat's the part I keep coming back to.\n\nFor decades, software teams optimized around delivery. Requirements, design, development, QA, release. Waterfall softened into Agile. Agile grew into DevOps. The practices changed, but the assumption underneath stayed pretty stable:\n\nbuilding software is expensive, so plan carefully before you start.\n\nThat made sense because, for a long time, it was true.\n\nNow that assumption is breaking.\n\nAI is doing to software what calculators did to accounting. It isn't eliminating the job. It's moving the job up a level. The syntax, boilerplate, first draft, and some of the debugging are getting offloaded.\n\nThe work doesn't disappear.\n\nThe bottleneck moves.\n\nHere's what didn't get cheaper:\n\nThe old question was:\n\nCan we build it fast enough?\n\nThe new question is:\n\nDo we understand the problem well enough?\n\nThat sounds like a small shift, but it changes the work.\n\nIt changes what strong engineers spend time on. It changes what product people need from engineering. It changes how teams should define \"done.\"\n\nIf the code ships but nobody learns anything, did the team actually move forward?\n\nSometimes yes.\n\nOften no.\n\nPeople are not great at specifying requirements up front.\n\nNot because they're difficult.\n\nBecause they're human.\n\nMost of us don't know how we feel about something until we can react to a version of it. A mockup. A prototype. A rough slice. A real workflow with sharp edges.\n\nSo the fastest path to learning usually isn't a better requirements document.\n\nIt's getting working software in front of people sooner.\n\nBut only if you know what you're trying to learn.\n\nThat's the step teams skip.\n\nWe jump from problem to implementation:\n\nUsers need X, so build X.\n\nA product engineering loop adds the missing middle:\n\nWe believe doing X will cause Y because Z.\n\nNow the work has a hypothesis. Now feedback has something to test against. Now shipping becomes part of a learning loop instead of just the end of a delivery pipeline.\n\nProblem.\n\nHypothesis.\n\nWorking software.\n\nUser feedback.\n\nThen back around again.\n\nThe question for a modern software team is not just how fast you can ship.\n\nIt's how fast you can run that loop without losing the evidence.\n\nThis is already happening.\n\nPostHog has engineers talking to users, digging into metrics, and shipping experiments without always waiting for a product manager to translate the work.\n\nAmazon runs thousands of experiments.\n\nNetflix's advantage was never just the recommendation algorithm. It was the system for learning what to put in front of people.\n\nFeature flags, A/B tests, canary deploys, and audience segmentation are not exotic anymore. There are open source tools and commercial tools for all of it.\n\nThe gap is usually not tooling.\n\nThe gap is the habit of thinking in experiments instead of features.\n\nThat habit matters more as AI makes implementation cheaper.\n\nBecause if you get very fast at shipping without getting better at learning, you create a new problem: noise.\n\nToo many changes in flight. Too many overlapping experiments. Users hit six new things in a week, and no one can tell what actually moved the outcome.\n\nSpeed without experimental discipline just gives you more noise faster.\n\nThis is why I like the phrase Product Engineering.\n\nEngineering starts with technology and learns empathy.\n\nProduct starts with empathy and learns how things get built.\n\nAI makes the overlap more valuable because the scarce person is increasingly the one who can hold both sides together:\n\nI've started thinking of this person as a Software Scientist.\n\nNot a job title.\n\nA discipline.\n\nCode is the instrument.\n\nThe market is the lab.\n\nUser behavior is the data.\n\nIf a hypothesis is wrong, the code wasn't wasted. It did its job. It answered the question.\n\nThat is a hard mindset shift for teams trained to treat shipped code as the primary output.\n\nBut in a product engineering world, speed-to-data matters more than speed-to-code.\n\nThere is one more piece that I think teams underestimate.\n\nIf software development is becoming more experimental, where does the experiment get recorded?\n\nMost teams have places for pieces of it:\n\nThat works until it doesn't.\n\nSomeone goes on vacation. The thread disappears. The AI chat is gone. The next person picks up the ticket and has to reconstruct the experiment from fragments.\n\nScientists don't just run experiments.\n\nThey keep lab notebooks.\n\nNot because the notebook is the point.\n\nBecause the notebook lets the next experiment build on the last one.\n\nThat's how I think about imdone.\n\nJira and GitHub track work.\n\nA lab notebook tracks hypotheses, decisions, evidence, and learnings.\n\nFor product engineering teams, those things need to live close to the work. Close enough that a human can pick them up later. Close enough that an AI agent can use them without guessing. Close enough that the team doesn't start from zero every time.\n\nIf you want to see how imdone keeps Jira or GitHub work in a local markdown workspace, the CLI docs are here: [imdone.io/docs/imdone-cli](https://imdone.io/docs/imdone-cli?utm_source=dev.to)\n\nYou don't need a new title or a new process to start.\n\nOn your next piece of work, ask one question:\n\nHow can we run the loop a little faster?\n\nMaybe that means writing a real hypothesis before you build.\n\nMaybe it means putting a rough version in front of a user this week instead of next month.\n\nMaybe it means adding a feature flag, a PostHog event, or a simple way to capture what happened.\n\nMaybe it means keeping better notes so the next person doesn't have to rediscover what you already learned.\n\nAI is making it easier to build.\n\nThe teams that win will be the ones that get better at learning.\n\nThat is the work now.", "url": "https://wpnews.pro/news/we-build-faster-than-we-decide", "canonical_source": "https://dev.to/imdone/we-build-faster-than-we-decide-253k", "published_at": "2026-06-24 12:58:58+00:00", "updated_at": "2026-06-24 13:11:49.178095+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "ai-products"], "entities": ["PostHog", "Amazon", "Netflix"], "alternates": {"html": "https://wpnews.pro/news/we-build-faster-than-we-decide", "markdown": "https://wpnews.pro/news/we-build-faster-than-we-decide.md", "text": "https://wpnews.pro/news/we-build-faster-than-we-decide.txt", "jsonld": "https://wpnews.pro/news/we-build-faster-than-we-decide.jsonld"}}