Almost every conversation about AI-assisted development runs on anecdote. Someone shipped a feature in a weekend; someone else spent three days untangling code an assistant confidently produced. Both stories are true, and neither is measurement. So we instrumented a single, real endeavour end to end — classifying every unit of work into a build stage — and read the ledger honestly. This is not a story about machines replacing engineers. It is a study of how a human-and-AI collaboration distributes its effort: where it races ahead, and where the work quietly piles up. The shape of that effort is more sobering, and more useful, than either the hype or the backlash.
The Setup: One Endeavour, Fully Measured
The subject was a single multi-day build across a web platform — a mix of subsystem refactoring and a new feature with its supporting content. We have deliberately kept it anonymous: the point of this article is the shape of the collaboration, not the product. Throughout, we use the generic term AI coding assistant, because the pattern we observed is not specific to any one vendor or model.
What makes the data trustworthy is the discipline of the recording. A human engineer directed the work through a sequence of instructions; the assistant responded with plans, edits, and verification runs. We captured the full transcript and then did one thing with it that most productivity claims never do: we classified every work-unit into a build stage and measured how effort distributed across them. The question we set out to answer was not “how fast” but “where does the work actually go.” Speed is what gets advertised; distribution is what tells you what the collaboration is really like.
What the Numbers Say
The engineer issued 74 human-directed work-units — discrete instructions, corrections, or approvals — and we sorted every one of them into three stages of the build: planning, the first working implementation, and iteration to completion. This classification is a documented heuristic rather than a stopwatch reading, so we treat the resulting split as indicative rather than exact. But its purpose is not precision to the decimal — it is to show the proportions, and those proportions tell a stark and consistent story.
The distribution overturns a comfortable assumption. Planning — the part people fear will bloat — was the cheapest phase at 13%. The first working implementation was an efficient burst at 39%. But iteration, the unglamorous last mile of getting a working thing to a shippable thing, was the single largest slice at 47%. The expensive part of building with AI is not starting; it is finishing.
The Shape of the Work: Fast to Functional, Slow to Done
If you plot cumulative effort against how complete the result feels, the collaboration traces a distinctive curve: a steep early climb, then a long, shallow tail. The completeness axis here is a modelled estimate, not a measurement — there is no meter for “how done is this.” We placed the points by mapping the project’s actual task milestones — first working draft, feature-complete, shippable — onto the effort spent to reach each. The effort behind each point is measured; the completeness value it maps to is a considered, reasoned reading of the task progression, not a statistically determined result. We label the curve as modelled precisely because that honesty is the point of the exercise.
The curve tells the same story as the stage split, from a different angle. The assistant is extraordinary at getting from nothing to a plausible, mostly-working draft — that early vertical rise is where the celebrated productivity gains live. But “mostly working” and “shippable” are separated by a long, flat tail of edge cases, visual polish, correctness under load, and the thousand small things that make software trustworthy. In our data, iteration consumed nearly as large a share of the effort as the first build did — it drew more work-units and the larger slice of the time-to-done. The last-mile polish roughly doubled the effort of the first working version — and that is the cost most AI productivity claims quietly omit.
This is not a new law, but a familiar one wearing new clothes. The wider industry has long described a “last-mile” or “70% problem” in AI-assisted work: the tool sprints you to roughly the two-thirds mark, and the remaining third is where human effort concentrates.[1] Fred Brooks made the structural argument decades ago — the hard part of software is not the code you can generate but the conceptual coherence you must maintain.[5] AI changes how fast you reach the hard part; it does not remove the hard part.
What fills that tail is not mystery — it is rework. The iteration phase has a signature you can see in the raw stream of work-units: a correction, a revision, a “that’s not quite right,” a re-explanation of context the assistant had already been given. Each loop is cheap on its own and expensive in aggregate, and together they are what turns a mostly-working draft into the shippable article.
Two failure modes drive the tail, and both are well documented beyond our single case. The first is confident-but-wrong output: a suggestion that reads perfectly and compiles cleanly but is subtly incorrect, which costs nothing to accept and a great deal to discover later. The second is quiet erosion of coherence: independent analysis of large AI-assisted codebases has found rising duplication and churn — more code that works in isolation but repeats itself and drifts from a clean structure.[3] Rigorous field data complicates the story further: one controlled study found that experienced open-source developers were actually slower with AI tools on familiar codebases even as they believed they were faster.[1] Left unmanaged, the review-and-rework tax can erase the first-draft speed it appears to grant.
Where AI-Assisted Development Genuinely Pays Off
None of this is an argument against the tools. Read the same data the other way and the upside is just as real — it simply lives in specific places, and each benefit arrives with a paired cost you have to plan for.
- Breadth in a single pass. The assistant moved fluidly across refactoring, a new feature, and its supporting content within one endeavour — work that would normally mean context-switching across specialisms. Paired cost: that same breadth is what makes the iteration tail so heavy, because coherence must be maintained across all of it.
- First-draft speed. Getting from nothing to a working scaffold was dramatically compressed — the steep part of the curve. Controlled experiments echo this, with the largest gains going to less-experienced practitioners on well-scoped tasks.[2] Paired cost: a fast first draft can lull a team into under-budgeting the iteration that follows.
- Tireless mechanical throughput. The assistant sustained a volume of edits, searches, and checks that no engineer keeps up by hand. Paired cost: volume without gates is just a faster way to accumulate defects.
- Lowered activation energy. The cheapness of planning (13%) meant more options were explored before committing. Paired cost: cheap exploration tempts scope creep if no one holds the line.
AI-assisted development is a genuine accelerant on breadth and first drafts — provided you price in the iteration and review it makes necessary, rather than pretending the first draft was the finish line.
What Makes the Ledger Net-Positive: PAAD
A tool that sprints to 70% and then demands disciplined finishing is only net-positive if the discipline is actually there. At WIS we run every AI-assisted engagement on a method we call PAAD — Pushback, Alignment, Architecture, Discipline. It is not an industry standard and we do not claim it as one; it is simply how we have chosen to work with these tools, refined against exactly the failure modes this case study exposes.
Pushback
The engineer’s job is not to accept output but to interrogate it. Pushback is the habit of challenging confident-but-wrong suggestions, rejecting the plausible-looking answer, and refusing to let a rework loop run unexamined. In our data, the difference between a healthy iteration phase and a runaway one is almost entirely how early and how firmly the human pushes back. The assistant proposes; the engineer disputes; and that friction is where correctness is bought.
Alignment
The most expensive code is code that works perfectly and solves the wrong problem. Alignment means spending the cheap planning phase — that 13% — making sure the thing being built is the thing that was needed, before the expensive 86% is spent building it. Getting alignment right up front is the single highest-leverage use of the phase AI makes cheapest.
Architecture
Breadth in a single session is a gift and a hazard: it is exactly the condition under which coherence quietly erodes.[3] Architecture is the human-held responsibility for keeping a large, fast-moving change structurally sound — deciding where things belong, resisting duplication, and preserving the conceptual integrity that no generator supplies on its own.[5] The assistant writes the code; the engineer owns the shape it takes.
Discipline
Discipline is the set of non-negotiable gates that turn a plausible draft into a shippable result: review every change, verify behaviour, run the build and the tests, and treat published identifiers as immutable so nothing downstream silently breaks. This is the machinery that governs the last mile — the 47% — and keeps the iteration tail from turning into an iteration spiral. Modern delivery research is blunt on the point: AI adoption without strong review and delivery practices tends to move problems downstream rather than remove them.[4] It also governs how the work is paced: shorter, well-scoped sessions produce better results than long-running ones — an assistant’s coherence and its cost both worsen the longer a single session runs, so the disciplined pattern is to work in focused phases, record decisions in durable documents, and begin each phase from a clean, re-hydrated context rather than an ever-growing one. Discipline is what converts raw output into something an organisation can actually rely on.
Read against the data, PAAD is not a slogan — it is a containment strategy. The iteration cost and the rework loops that fill the last mile are precisely the failure modes it exists to control. PAAD is how we keep the ledger positive: it does not make the last mile cheap, but it stops the last mile from becoming a bottomless one.
Choosing the Approach for the Work
The practical lesson for engineering leaders is not “use AI” or “avoid AI” — it is match the tool to the shape of the task, and budget for the whole curve, not just its steep beginning. The evidence in this study points to a few concrete calls:
- Lean in for greenfield and breadth. New features, scaffolding, exploratory drafts, and work that spans several specialisms are where the steep part of the curve pays off most.
- Budget iteration as the main event. Plan for the last mile to cost roughly as much as the first build — not as a rounding error. A schedule that assumes the working draft is nearly the finished product will overrun.
- Protect the deep-expertise path. On mature, well-understood codebases, the human may already be at the pace the tool promises; measure before assuming a speed-up.[1]
- Fund verification in proportion to generation. Every hour of generated breadth needs a matching investment in review, testing, and architectural oversight. That is not overhead on top of the productivity gain — it is the condition of the gain being real.
Chosen well and governed well, AI-assisted development shifts an engineer’s time away from typing and toward judgment — which is exactly where their time was always most valuable.
Conclusion
One measured endeavour cannot settle a debate this large, and we would not pretend otherwise. But it can replace two anecdotes with one honest ledger. Across the build, an AI coding assistant helped a single engineer plan cheaply, reach a working draft fast, and then spend the larger share of the effort dragging that draft across the line to shippable. Every one of those observations is a benefit and a cost at the same time.
We have been deliberate about what is measured — the stage distribution of effort across planning, first build, and iteration — and what is modelled, namely the completeness curve that plots that effort against how done the result feels. That distinction is not a caveat buried in a footnote; it is the whole ethic of the piece. The industry does not need more confident round numbers about AI productivity. It needs teams willing to instrument their own work, label what they actually know, and build the discipline to finish what the tools so quickly begin. AI-assisted development does not make software easy — it makes the easy part faster, and puts the hard part into sharper relief, which is exactly where good engineering has always earned its keep.