Skip to content
All articles

AI Made Your Team Faster at Writing Code. Not at Shipping Product.

Almost every team codes with AI, yet few ship product faster. Why complex codebases stall without written intent, and how PRDs and specs fix it.

Filipe Abreu12 min read

Everyone adopted AI. Delivery did not get faster.

Almost every engineering team now codes with AI, and almost none of them ship product meaningfully faster. That gap is the most important number in software right now.

The adoption side is settled. The 2025 DORA report found 95% of developers using AI tools, with over 80% reporting productivity gains.

The delivery side tells another story. Faros analyzed two years of telemetry from 22,000 developers in 4,000 teams for its 2026 report, The Acceleration Whiplash. Task throughput rose 33.7% and epics completed rose 66.2%. Deployments per week fell 11.7%, median review time grew 5x, and incidents per pull request tripled.

More code is going in. Less value is coming out the other end, and it arrives with more defects.

Even the perception is unreliable. In METR's 2025 randomized trial, experienced developers were 19% slower with AI while believing they were 20% faster. METR's February 2026 update says developers are likely faster now, but that its data can no longer measure by how much.

I do not read this as "AI doesn't work". I use agents every day and would not go back. I read it as: typing code was never the bottleneck, and we just made the non-bottleneck ten times cheaper.

Where AI is spectacular: the small, new and low-risk

AI can take a small MVP from idea to market in days, and that is real. A greenfield project has no legacy, no hidden business rules, no customers to break and a codebase that fits in the agent's head.

The trouble is that most of the public evidence comes from exactly this kind of work. The demo on stage is a to-do app. The viral thread is a weekend project. The experiment that "proves" a 10x gain is a self-contained task with a clear finish line.

Benchmarks have the same bias. The authors of SWE-Bench Pro noted that 161 of the 500 problems in SWE-bench Verified need only a one or two line change. Their harder benchmark averages 107 lines across 4 files per task.

The scores moved accordingly. Models scoring above 70% on the easier benchmark landed around 43% on the public Pro set at the time of the paper. On private commercial codebases, which no model had seen in training, the best result was 17.8%.

Newer models score higher, but the shape of the result holds. The closer the task gets to a real company's codebase, the less the headline number applies. We are extrapolating from the easy case to the hard one.

Complexity changes the math

In a complex application, unmanaged code growth costs more than the speed it bought. Generating code is nearly free now, so codebases grow faster than anyone's ability to shape them. I see three compounding costs.

Time to market for the next feature gets worse. GitClear's 2026 analysis of 623 million code changes found duplicated blocks up 81%. Refactoring fell from 21% of changed lines in 2022 to 3.8%. Agents add; they rarely consolidate. Every new feature now has to be threaded through several near-copies of the same logic.

The agents themselves get worse. This is the part most teams miss. Chroma's context rot research, summarized here, found every model tested degrades as input length grows, well before the context window is full. A bloated, duplicated, inconsistent codebase is bad context. The agent reads three versions of the same function, picks one, and extends the wrong pattern. The mess you generated last quarter becomes the prompt for this quarter.

The product drifts from its intent. An agent optimizes for the task in front of it. It does not know your roadmap, your pricing strategy or the customer segment you decided to stop serving. Hundreds of locally reasonable changes add up to a product nobody actually decided to build.

These three feed each other. More code means worse agent output, which means more rework, which means more code. The curve that looked exponential in month one flattens, then bends down.

Fire, forget, and the fading memory of the codebase

A team that prompts, merges and moves on stops understanding its own product within months. I call this the fire-and-forget workflow: describe the task, accept the diff, close the ticket, never write down why.

The industry now has names for the result. Addy Osmani calls it comprehension debt: the growing gap between how much code exists and how much of it any human understands. Margaret-Anne Storey calls it cognitive debt, building on Peter Naur's old idea that a program is a theory living in its developers' minds.

Storey describes a student team that could no longer make simple changes without breaking things. They blamed messy code. The real cause was that nobody could explain why design decisions had been made or how the parts fit together.

The effect is measurable in individuals too. In Anthropic's study of 52 engineers learning a new library, the AI-assisted group scored 50% on a comprehension quiz against 67% for the hand-coding group. The largest gap was in debugging. They were not significantly faster either.

This matters because the human is still the control system. Without a working mental model of the codebase and the business rules, an engineer cannot:

  • Steer the agent, because a good instruction requires knowing where the change belongs and what it must not touch.
  • Detect a hallucination, because plausible and correct look identical to someone who does not know the domain.
  • Predict side effects, because the billing rule that breaks is three modules away from the diff.

Unlike technical debt, this one is silent. Tests pass, the build is green, velocity charts look great. The cost only shows up on the day someone needs to change something important and nobody knows how it works.

The same Anthropic study offers the way out. Engineers who asked the AI for explanations and concepts kept their understanding. The ones who delegated passively lost it. The tool is the same; the workflow decides the outcome.

Why better prompts, context and harnesses are not enough

Prompt, context and harness engineering improve how the agent works. None of them decides what the company should build or keeps the team's understanding alive. That is why the fix is harder than the tooling conversation suggests.

The industry's answer has moved in three steps. First we tuned the prompt. Then we curated the context: rules files, retrieval, memory. In 2026 the term is harness engineering: the instructions, guards, tools, evals and feedback loops around the model.

All three are necessary, and I invest in all three. But look at the state of practice. Marmelab's State of AI Harness Engineering 2026 found 63% of major open-source projects now ship agent instruction files, yet 60% of harnesses have no tests or evals. Only 4.4% of security rules were backed by a real control. Machine-generated context files reduced agent success compared to no context at all.

The same survey lists as an open problem the one I care most about: there is no consensus on how to translate high-level product goals into rules a harness can enforce.

That is the limit. A harness can make the agent follow your conventions. It cannot tell the agent which feature matters this quarter, why the refund rule has an exception for enterprise accounts, or what you decided not to build. That knowledge sits in people's heads, in old Slack threads and in meetings nobody recorded.

So the problem is only partly technical. It is about how an organization captures decisions, who owns them, and how they reach the place where the work happens. That is workflow and culture, and no config file ships it.

PRDs and specs: where intent gets written down

PRDs and spec-driven development are the most effective tools we have today for building with agents, because they put intent in writing before code exists. They only work if the team's workflow changes around them.

The division of labor is simple. The PRD holds the why and the what: the problem, the user, the requirements, the acceptance criteria, what is out of scope. The spec holds the how: the design, the plan, the tasks. The agent implements against both, and both stay in the repository next to the code.

The tooling matured fast. GitHub Spec Kit, AWS Kiro, OpenSpec and BMAD all follow a similar pipeline of specify, clarify, plan, break into tasks, implement and verify, with a human gate at each step. A good 2026 overview sums up the shift in one line: the spec is now where the thinking happens.

This answers the problems above directly. A spec gives the agent a small, precise context instead of a sprawling codebase to guess from. It gives the reviewer something to check the diff against. It leaves a record of why, which is the memory fire-and-forget destroys.

But installing a spec tool changes nothing by itself. In a Thoughtworks conversation from May 2026, Birgitta Böckeler and Laura Tacho stressed that the workflow matters more than the spec format. They also named the traps I see teams fall into:

  • Waterfall by another name. Planning everything upfront because the agent can build it all at once. Keep increments small and the feedback loop short.
  • Specs nobody reads. The agent generates 2,000 lines of markdown and the human approves without reading. That is fire-and-forget with extra steps.
  • Spec drift. The code changes, the spec does not. The next feature is then built on a false description of the system.
  • A spec team and a build team. Splitting who writes from who implements recreates the handoff the method was meant to remove.

So the adaptation is in the habits. Engineers spend more time on clarifying and reviewing intent than on typing. Product people write requirements precise enough to be testable. Specs are reviewed like code and updated in the same pull request as the code. "Done" means the spec is true again.

Osmani adds one caution I agree with: a spec cannot capture every implicit decision, and two implementations of the same spec will behave differently. Specs reduce the need for human understanding of the system. They do not remove it.

The same problem, one level up

Engineering is only one of the departments now working with AI, and if each one accelerates alone, the company produces misalignment faster. Product drafts PRDs with AI. Design generates flows and prototypes. Marketing produces campaigns and positioning. Strategy teams model scenarios.

Each of them is running its own fire-and-forget loop, with its own context and its own version of what the company is trying to do.

The data matches what I see. In WRITER's 2026 enterprise AI survey of 2,400 executives and employees, 79% said AI applications are being built in silos. 55% described AI use at their company as a chaotic free-for-all. 75% of executives admitted their AI strategy is more for show than real guidance.

Now connect that to the engineering problem. The agent writing your code depends on the spec. The spec depends on the PRD. The PRD depends on positioning, research and strategy. If those upstream documents were each generated in isolation, the coding agent is executing precisely against a confused intent.

The drift I described inside the codebase happens across the whole company. Marketing promises a feature the roadmap dropped. Design prototypes a flow that contradicts the pricing model. Engineering ships it all, quickly.

The fix has the same shape as the engineering one, applied to the organization:

  • One written source of intent. Strategy, priorities and product decisions live in documents that people and agents in every department can read.
  • Traceability between layers. A campaign points to the feature, the feature to the requirement, the requirement to the goal.
  • Shared vocabulary. A glossary sounds trivial until three departments' agents use the same word for three different things.
  • One loop, not a relay. Product, design and engineering work on the same increment together instead of handing artifacts over a wall.

Böckeler and Tacho make a similar point: the next step is shared context that everyone in the team can read and contribute to, developers or not. The companies that get there will have AI pulling in one direction. The others will have several fast teams pulling apart.

The bottleneck moved

AI removed the cost of writing code and exposed what was always the hard part: knowing what to build, why, and how it fits with everything already there. Teams that treat AI as a faster keyboard get more code. Teams that treat it as a reason to get disciplined about intent get more product.

If I had to reduce this to a starting point for an engineering leader, it would be four questions:

  1. For the last feature you shipped, is the why written anywhere an agent or a new hire could find it?
  2. Could someone on the team explain how that feature works without opening the code?
  3. Is your codebase getting easier or harder for an agent to work in, and are you measuring it?
  4. Do product, design, marketing and engineering feed their AI tools the same priorities?

None of these is about which model or tool you use. That is the point.

How is your team handling this? I would like to hear what is working in codebases that are past the MVP stage.

Sources