Your team tried Copilot, or Cursor, or Claude Code. Some of your engineers swear it doubled their output. Others produced the same volume of churn, just faster, with a worse paper trail. You’ve probably concluded the difference is the tool, or the model, or how good the prompt was.
It’s none of those.
A 2025 randomized trial found experienced developers were 19% slower completing real coding tasks with AI tools than without — and rated themselves 20% faster afterward. Meanwhile McKinsey’s own adoption data shows a top quintile of engineering organizations seeing 16–30% productivity gains, while the rest see far less, because only about 13% of them are using generative AI systematically at all. Same tools. Same models, mostly. Wildly different outcomes. MIT Sloan Management Review reaches the same split from a different angle: the raw speedups are real, but validation time, review burden, and cognitive load rarely show up in the metrics orgs track — which is exactly the gap between believing you’re faster and being faster.
If the average result is this murky, the interesting question isn’t “does AI make engineers faster.” It’s: what separates the cases where it clearly does?
Vibe coding was never going to average out
I’ve written here before about what happens when you ship agentic AI on top of first-generation integration architecture — the root tokens, the god-mode service accounts, the audit trail that lives in a chat window and dies with the session. The same failure mode shows up in delivery, not just in the data plane. Unmanaged prompting — an LLM as a supercharged autocomplete, no workflow structure around it — produces exactly the bimodal result the research shows, because there’s nothing standing between “the model can technically do this” and “this shipped.”
Google’s DORA team said it plainly in their 2025 report: AI adoption is now positively correlated with delivery throughput — and negatively correlated with delivery stability. AI doesn’t level anyone up. It amplifies whatever process it’s dropped into, weaknesses included. Drop it into a disciplined workflow and you get the top quintile. Drop it into vibe coding and you get the 19%-slower result with extra confidence.
What amplification actually looked like, in my own delivery
I pulled two years of my own git history to see which side of that line I was actually on. Not a highlight reel — every number below comes straight out of git log and the GitHub API, across everything I own, contribute to, or can access through client and collaborator organizations. The full breakdown, charts included, is in Two Years of AI-Amplified Delivery: The Telemetry; here’s the headline.
426 repositories in scope. 2,503 commits in the trailing 24 months. 8 concurrent client and organizational contexts. 142 repositories with real activity in the window.
Here’s the line that actually matters, from that report: AI-assisted delivery didn’t make me type faster. It raised the number of engagements I could carry at full depth, at the same time.
The shape of that data is worth showing plainly, because a smooth upward curve would actually be a less credible story. It isn’t smooth. Some months show almost nothing — April 2025 was a flat zero, and there are more near-zero stretches through late 2025 and mid-2026. Then a peak: 265 commits in July 2025, 250 in January 2026, 398 in June 2026, each one bigger than the last. That’s not steady productivity. That’s engagement-driven delivery, in bursts, at a ceiling that kept rising.
The inflection point is July 2025 — the month AI-agent tooling first shows up in that same commit history. Every peak since has exceeded every peak before it.
And it wasn’t volume for its own sake. In that window I was running a production SMS gateway fleet, live-debugging incidents over SSH at 2am; shipping firmware for a fall-detection device that’s now fielded in production in Colombia; carrying a 20-plus-repo enterprise .NET modernization for an automotive engineering client through a real legacy migration; and building the AI-agent tooling itself, concurrently, with the same discipline it now runs under. Different stakes, different codebases, same standard applied to all of them at once. That’s the part raw commit velocity doesn’t capture on its own.
The discipline has a name now
The reason that worked isn’t a secret technique. It’s a framework — we call it Ignition, and it’s what we build for clients at Code Éxitos, enforced by the Athanor Suite underneath it. Five rules, and none of them are exotic:
Specifications replace prompts. Nothing is buildable until a human marks it Approved. Chat messages, meeting notes, drafts — those are inputs to be distilled into a spec, never instructions an agent executes directly.
The workflow enforces itself. Deterministic orchestration means the system decides what happens next and blocks unauthorized moves — not the discipline of whoever happens to be driving that day.
No one grades their own homework. If an agent wrote the code, a human approves it. If a human wrote it, a different human approves it. That rule doesn’t bend for solo work.
Verification runs before a human is asked to look. Layered review — deterministic checks, then a critic pass, then a human — means the human gate is the last one in the chain, not the only one.
The audit trail is a byproduct, not a chore. Signed commits and structured PR history are the record. Nobody writes documentation about the work after the fact.
The part people usually push back on is whether that much verification slows everything down. It doesn’t, and the reason is architectural: under Ignition, specification and verification run as two independent tracks starting from the same moment, not sequentially — one team drafts the feature while another independently drafts how it’ll be tested and accepted, and they only meet at a human checkpoint before a line of implementation code exists. The throughput in that commit history wasn’t purchased by skipping verification. It was gated by verification running in parallel the whole time.
This is a staffing question too
There’s a newer skill hiding in all of this that most engineering orgs haven’t named yet, and it isn’t “AI fluency.” It’s judgment about when to hand something to a model, when to do it by hand, and when to stop and check the output before it compounds into something worse. That’s a coachable, observable competency — not a personality trait — and it’s going to separate engineers a lot more than which tool they prefer. More on that soon.
The organizations that will get this right
…are not the ones who moved fastest into agentic tooling. They’re the ones who designed the discipline layer in before it became urgent — before the top-quintile numbers became the exception instead of a repeatable outcome. The 19%-slower result and the 30%-faster result aren’t contradictory studies. They’re the same intervention, measured with and without that layer.
The agent code was always going to be the easy part. The multiplier was never the model.
This is a companion piece to Two Years of AI-Amplified Delivery: The Telemetry — the raw telemetry behind the argument above.