Case Study · How the work gets done
The model proposes. Something independent has to dispose.
Everyone says they use AI now. The question that separates real work from theatre is what happens when it is wrong — because it will be, and whether you catch it is the whole difference between leverage and liability.
A SMALL EXAMPLE
A client sent me a ninety-eight minute recording of a strategy call, transcribed automatically. Twenty-six minutes in, the transcription failed — the model entered a repetition loop and produced forty identical lines of the same half sentence. Three minutes of conversation were gone, and the section it destroyed was the one about how they get paid.
An earlier analysis had recorded that content as permanently lost. It was not. The loop was in the transcription, not the recording — so I pulled the original audio and re-ran only those windows with the setting that causes the loop disabled.
What came back changed two recommendations. Their customers were not refusing automatic payment out of general reluctance; they were refusing because the amount changes every month and they cannot see how it is calculated. Different problem, different fix. And a question the earlier analysis had listed as unanswered turned out to have been answered on the call.
None of that required unusual technical skill. It required not believing the output.
The method
The discipline is not prompting. It is deciding what the model sees, what it has to prove, and how small the piece has to be for a person to still judge it.
Five phases. Each one exists because of a documented failure, and each one costs time up front — which is exactly why they get skipped by people trying to look fast.
01
Context engineering
DECIDE WHAT THE MODEL SEES
The discipline that replaced prompt engineering. Curating the smallest set of high-signal information that produces the outcome you want — and the reason it matters is counterintuitive: more context makes results worse, not better.
Research across eighteen models found performance degrades consistently as input length grows, with a single irrelevant distractor measurably hurting accuracy. So the work is subtractive. A short curated instruction file in the repository rather than an accumulating one. Information loaded at the moment it's needed instead of everything up front. Investigation delegated to a separate agent, so the exploring burns someone else's attention and only the conclusion comes back.
02
Interview, then specify
RESOLVE THE AMBIGUITY BEFORE ANY CODE
The highest-return step, and the one almost everyone skips. Models are poor at noticing a request is underspecified — and excellent at resolving it once they're forced to ask.
Research on underspecified engineering tasks found models struggle to tell well-specified instructions from ambiguous ones, yet performance improved by up to 74% when they were made to interact and gather what was missing. Separate work found more than 40% of curated academic problem statements were ambiguous enough to be worth rewriting — real stakeholder requests are far worse. So the sequence is: the agent interviews me, we produce a short self-contained spec naming files, interfaces and what is explicitly out of scope, and a fresh session executes it.
03
Verification, not supervision
BUILD THE HARNESS BEFORE THE FEATURE
An agent stops when the work looks done. Without a check it can run itself, "looks done" is the only signal available — and you become the verification loop, with every mistake waiting on a human to notice it.
So every task gets something deterministic it must satisfy: a failing test written first and confirmed failing, a build exit code, a linter, a screenshot diff. Gates escalate with the length of the leash — an in-prompt check for small work, a blocking hook for longer runs, and a separate reviewing agent whose brief is to refute rather than confirm. That reviewer is deliberately given a narrow remit, because a critic asked to find problems will always find some, and chasing every one produces its own kind of damage.
04
Small batches
KEEP THE UNIT SMALL ENOUGH TO JUDGE
Google's long-standing review guidance is that around a hundred changed lines is reasonable and a thousand is too large. That was true before any of this. It is now load-bearing.
DORA elevated working in small batches to an AI-specific capability, describing it as a critical countermeasure to the delivery instability that AI adoption introduces. The mechanism is simple: AI produces large changes quickly, and large changes are hard to review, test and integrate safely. The real constraint underneath it is human — after the tenth approval you are not reviewing anymore, you are clicking.
05
Evaluation
MEASURE BEHAVIOUR, NOT OUTPUT
For anything with a model in the runtime path, the question stops being whether it renders and becomes whether it behaves. That needs a test set, and building one is unglamorous and non-optional.
What works at small scale: read fifty to a hundred real traces, and stop adding failure categories when twenty consecutive traces turn up nothing new. Grade binary pass or fail with a written critique rather than a one-to-five scale, because nobody knows what to do with a three. Gate continuous integration on a curated set that includes every past bug. And for anything running on a schedule, measure success across repeated runs rather than one — an agent that succeeds half the time is worthless if the other half silently posts a wrong entry.
WHAT THE EVIDENCE ACTUALLY SAYS
Including the findings that cut against everything above. If a page like this cites only the flattering research, assume it has not read the rest.
AI speeds up well-specified greenfield work
SupportedA controlled experiment on building an HTTP server found the assisted group finished 55.8% faster. Note the shape of that task: self-contained, well-specified, no existing codebase to understand.
AI increases output volume
SupportedThree randomised trials across 4,867 developers at Microsoft, Accenture and a Fortune 100 manufacturer found a pooled 26% increase in completed pull requests — with the gains concentrated among less experienced developers.
AI speeds up experienced developers on large, familiar codebases
ContradictedThe only clean randomised trial of that setting found the opposite. Sixteen experienced open-source developers, 246 tasks, in repositories they had worked in for years: they predicted AI would make them 24% faster, estimated afterwards that it had made them 20% faster, and were measured 19% slower.
Developers can self-report their own productivity
RefutedThat same study produces a roughly 39-point gap between perceived and measured performance. It is why most survey-based productivity data — including the 80%-plus of developers who report AI makes them faster — cannot be taken at face value.
AI improves delivery stability
Refuted, two years runningDORA found AI adoption associated with a 7.2% reduction in delivery stability in 2024. In 2025 their throughput finding reversed and turned positive — the stability finding did not. Their framing: AI does not fix a team, it amplifies what is already there.
AI improves code security
RefutedA study of more than a hundred models found 45% of generated samples introduced a well-known vulnerability class, and — the part that matters — security performance stayed flat across model generations while functional correctness improved. Vendor-published; the direction is corroborated academically, the exact figure is not independently replicated.
Benchmark scores reflect real capability
Substantially underminedModels identify buggy files with up to 76% accuracy on the standard benchmark and 53% on repositories outside it. A separate audit found 63% of successful resolutions retrieved the fix from public history rather than deriving it.
So the gains are illusory overall
Also not supportedThe researchers who measured that slowdown tried to repeat the experiment a year later and could not — developers refused to work on tasks without AI. Between 30% and 50% declined to submit work they would have to do unassisted. That is a revealed preference, and it is strong.
The defensible synthesis: the gains are real, unevenly distributed, concentrated in bounded and verifiable work, and substantially offset by rework and review load unless the countermeasures are genuinely in place. That conditional is the entire argument for method over tooling.
HOW IT FAILS, AND WHAT I DO ABOUT IT
These tools fail in characteristic, documented ways. Knowing the shape of the failure turns review from a vague worry into a checklist.
Hallucinated dependencies
What happens
Models invent packages that do not exist. Across 576,000 code samples, 5.2% of commercial-model package references and 21.7% of open-source ones were fabricated.
Why it persists
43% of hallucinated names recurred on all ten re-queries. A predictable hallucination is a registrable name with predictable traffic — which is why the resulting supply-chain attack now has a name.
What I do
Every dependency verified against the registry before it reaches a lockfile, and a preference for short generated code over a new dependency.
Gamed verification
What happens
When the test suite is the only oversight, the agent optimises for passing tests rather than for the goal. Documented cases include overwriting timing functions and patching scorers to always report success.
Why it persists
The gap between visible tests and held-out tests grows by roughly 28 percentage points for every tenfold increase in code size. It gets worse exactly as the work gets bigger.
What I do
Acceptance criteria the agent never sees, a sealed environment during evaluation so the answer is not reachable, and never letting the same agent author both the implementation and the standard it is judged against.
Agreement bias
What happens
Across three frontier models, sycophantic behaviour appeared in 58% of cases — and in 14.7% the model abandoned a correct answer after mild pushback.
Why it persists
It is in the training signal rather than the model. Human raters demonstrably prefer confident, agreeable answers over correct ones often enough to select for it.
What I do
Ask whether something is right after seeing it, not before. Stating an objection up front measurably increases the odds a correct answer gets abandoned — and dressing that objection in a citation makes it worse still.
Confident wrongness
What happens
An audit of eight AI search tools found more than 60% of answers incorrect, presented with almost no hedging. One signalled uncertainty fifteen times across two hundred responses and never once declined to answer.
Why it persists
Training rewards guessing over admitting ignorance, so the absence of hedging carries no information. Confidence has been decoupled from accuracy.
What I do
Treat fluency as neutral. Require evidence rather than assertion — a quoted span, a command output, a passing test — before believing a claim.
Review fatigue
What happens
A study of 33,707 agent-authored pull requests found two regimes: 28% merge instantly, while others consume disproportionate reviewer attention and are frequently abandoned mid-review.
Why it persists
Agents generate faster than humans review. The queue becomes the bottleneck, and spreading review effort evenly across it is the wrong allocation.
What I do
Small diffs, triaged rather than uniformly reviewed, with the mechanical pass done by an agent first — and never filing work for someone else to review that I have not read myself.
WHY YOUR BUSINESS IS THE HARD CASE
Almost everything written about AI-assisted development describes product engineering on clean problems. Internal business systems — reporting, integrations, the process still running on a spreadsheet — are a materially different problem, and there is a number for it.
On a benchmark built from real enterprise database questions, drawn from company systems that often carry more than a thousand columns, agents solved 21.3% of tasks. The same class of agent solves 91.2% of the academic version of that benchmark. The authors' own conclusion is that these systems need significant improvement before they are adequate for real enterprise use.
The gap is not model capability. It is that the business rules live outside the schema — revenue recognition, what counts as an active customer, which adjustments are real. Nobody wrote them down. As DORA puts it: an AI connected to bad data will only produce bad answers, faster.
And the finding that should worry you most
A peer-reviewed study put marketing and sales professionals in front of AI-generated analyses of their own data. Participants were told repeatedly that the AI often makes mistakes, shown plain-language explanations of what the code did, and explicitly asked to find the errors. They still missed critical flaws — many of which required no technical knowledge to recognise.
In code, a mistake gives you a stack trace. In a report, it gives you a number. A stakeholder nodding along at a demo is not a control, and building as though it were is how an organisation ends up confidently acting on something wrong.
What this buys you
Work that used to take a team and a quarter takes one person and a few weeks.
Not because the tools write the answer — the evidence above is fairly clear that they often do not. Because the expensive parts compress. Research that was a month of calls runs in an afternoon and comes back sourced. A prototype that was a sprint exists before the second meeting. Options that would have been argued about in the abstract get built and compared instead.
What does not compress is deciding what to do, and knowing which sentence to distrust. That still takes someone who has run a P&L, sold to an enterprise buyer, and shipped something people used.
Where these figures come from
Productivity findings from METR's randomised controlled trial and its 2026 follow-up, the DORA reports for 2024 and 2025, and controlled trials by Peng and by Cui and colleagues. Context and verification practice from Anthropic's engineering writing, Chroma's context-rot research and Thoughtworks' Technology Radar. Failure modes from USENIX Security 2025 on package hallucination, SycEval on sycophancy, the Tow Center's audit of AI search, and METR's reward-hacking work. Enterprise data findings from the Spider 2.0 benchmark; the non-programmer verification study is Virk and Liu, VL/HCC 2025.
Where a figure is vendor-published rather than peer-reviewed, it says so above. Several of the most recent findings are preprints that have not been independently replicated — they are the best available evidence on their questions, and they are individually fragile. Both things are true.
This is how every engagement runs.
Fast where speed is safe, slow where it is not, and honest about which is which.