Book a Free Call
No commitment required
TL;DR: AI can get you something that runs, but writing code was never the expensive part. The research all points one way: AI speeds up output while delivery gets less stable and technical debt piles up, because it amplifies whatever a team already is instead of fixing it. The hard part of building software didn’t disappear. It moved to the work AI can’t own. That means production discipline, senior judgment, and someone accountable when it breaks. Which means you need senior engineers embedded in your workflow, owning what ships.
The question we hear most from founders and CTOs lately, usually phrased a little nervously: if AI can spin up an MVP over a weekend, does building software still take an engineering team in 2026, or can a company just point it at the problem and ship?
It’s a fair question. Anyone who has spent a weekend with a coding agent has seen it produce something that runs — a working UI, a database, an API, auth that mostly behaves. A year ago that took a small team a week or two. Now one person does it before lunch. Pretending the question doesn’t deserve a serious answer would be dishonest.
The honest answer is yes — it probably could get you something that runs. That’s exactly why the rest of the work matters more, not less.
There’s a gap between “it runs on my laptop” and “it runs for ten thousand people who are angry when it doesn’t.” Almost everything expensive about software lives in that gap, and almost none of it is typing code.
A demo doesn’t have to stay correct when the same webhook fires twice and the naive version bills the customer twice. It doesn’t have to migrate a table with forty million rows to a new schema without taking the product offline to do it. It doesn’t have a deploy where the old version and the new one run side by side for ten minutes, so every change has to be backward-compatible with the code it’s replacing. It doesn’t hit the third-party dataset where the field you actually need is missing in most rows, forcing a fallback path nobody scoped. It doesn’t get woken up at 3 a.m. when an upstream API quietly changes a response shape and your “working” code starts dropping records without raising a single error.
None of that shows up in the demo. All of it shows up in production. And the AI that wrote the happy path didn’t account for any of it, because it was never asked to live with the consequences.
That’s the part worth sitting with. A coding agent optimizes for “make this run.” Production optimizes for “keep this running while reality attacks it.” Those are different jobs, and the second one is where almost all the cost, risk, and engineering judgment actually live.
This isn’t a vibe. Over the last two years the data has gotten specific, and it’s more interesting than either the hype or the backlash.
Writing code faster doesn’t mean shipping software faster. Google’s DORA program, a decade of research into what actually predicts software delivery performance, has measured this directly. Its 2024 report found AI adoption dragging both throughput and stability down, by roughly 1.5% and 7.2% respectively for every 25% increase in AI use [1]. The 2025 report, with AI now near-universal at 90% of developers, sharpens the picture rather than softening it: teams have learned to convert AI into a throughput gain, but stability still moves the wrong way. AI adoption continues to correlate with less stable delivery [2].
DORA’s own conclusion is blunt: AI is an amplifier, not a cure. It magnifies whatever a team already is, and pushing more change through a system that lacks strong testing, mature version control, and fast feedback just produces instability faster. The teams that come out ahead are the ones that already treat code as a long-term asset, with tests, review, and documentation they actually maintain, and use AI to amplify that discipline instead of papering over its absence. The bottleneck was never how fast you could type. It was everything downstream of that: integration, the blast radius of a bad deploy, all the work a demo never has to survive.
Even expert self-assessment is unreliable. In a 2025 randomized controlled trial, METR had experienced open-source developers work on their own repositories with and without AI tools. The developers expected to be about 20% faster with AI. They were measured as 19% slower [3]. To be fair, METR itself revisited this in early 2026 and said newer tools and self-selection make the current number genuinely uncertain — so don’t anchor on the figure. The durable finding is the other half of the study: skilled people are bad at knowing whether the tool actually helped.
Feeling productive and being productive are not the same measurement, and the gap between them is exactly where bad staffing decisions get made.
The maintenance bill is real, and it’s deferred. GitClear analyzed 211 million changed lines of code from 2020 to 2024. Over that window, copy-pasted code rose from 8.3% to 12.3% and, for the first time, exceeded refactored code, while the share of “moved” lines, the signature of someone reshaping a system instead of bolting more onto it, collapsed from around 25% to under 10% [4]. Short-term churn, code rewritten within two weeks of being written, climbed alongside it.
The honest caveat: this is correlation, not a controlled experiment, and they say so. But the direction is consistent everywhere you look. AI is very good at adding code and indifferent to whether the codebase stays comprehensible. Duplication is cheap to generate and expensive to own, and that bill doesn’t arrive in the sprint that created it. It arrives six months later, when a change that should take an hour takes three days because the same logic was pasted into eleven places.
Put those three together and a pattern shows up. AI didn’t remove the hard part of building software. It moved it.
The work that’s left is the work AI can’t take ownership of, because it isn’t really about producing code.
It’s deciding what to build and what to deliberately not build. It’s knowing that this feature will fall over at scale and that one won’t, before you’ve shipped either. It’s the architecture call that’s cheap to make on day one and ruinous to reverse on day two hundred.
Take a concrete one: reviewing an AI-generated pull request. The code is clean, it’s commented, the tests pass, and it’s confidently doing a subtly wrong thing: handling a currency conversion in a way that’s fine for the demo and quietly lossy at volume, or fetching inside a loop in a way that works for ten records and melts at ten thousand. Nothing in the output flags it. The only thing standing between that PR and a production incident is an engineer who has seen this failure before and knows where to look. And more often than not, it’s someone who has lived in the codebase for months, who remembers why that currency logic was written the way it was, not a contractor three weeks into a rotation. That’s not a typing problem. It’s an experience problem, and experience is the one thing you can’t prompt your way into.
The same goes for owning the incident. When the system is down, you don’t need the tool that generated the line that broke. You need the team who is accountable for fixing it, who understands why the decision was made, and who stays to clean up if it was the wrong one. AI can draft a migration. It can’t be the one who decided the migration was worth the risk.
This kind of work scales with judgment and context, not with tokens per second. More AI doesn’t produce more of it. If anything, more AI produces more code that needs that judgment applied to it.
The need didn’t shrink, it shifted. The kind of capability that matters has changed. An engineer with good tools covers far more ground than before, and a lot of mechanical work has evaporated, so the shape of a software team is genuinely different now. But anyone claiming the team itself became optional is selling something.
The leverage moved toward the senior end, not away from it. An AI coding assistant makes a senior engineer more effective, because they know what to ask for, what to throw away, and what’s about to bite. Handed to someone who can’t tell good output from plausible-looking output, the same tool produces technical debt faster than anyone can review it, exactly what the churn and duplication numbers describe. AI raised the floor on raw output and raised the ceiling on what experience is worth.
The work that’s left is the scarcest and most expensive kind: senior judgment, production discipline, and someone accountable when it’s live. It doesn’t come bundled with the tool, and it’s slow and costly to assemble from scratch. So the real question isn’t “AI or engineers.” It’s whether the company has access to engineering capability that can own what the AI produces, scale it, debug it, deploy it, and stand behind it in production. That capability can be built in-house. But for most companies, partnering with a team that already has it is faster and lower-risk than spending a year hiring and hoping the bench comes together before the next release.
DORA gave the trap a name: the Vacuum Hypothesis. AI gives you time back, and then that reclaimed time gets quietly swallowed by other low-value work, so the productivity gain never actually reaches the product [1]. You go faster and somehow ship the same.
Our answer is to spend the reclaimed time on purpose. We let AI take the laborious, mechanical load: the scaffolding, the boilerplate, the first pass at a test suite, the repetitive migration. That’s real work, and it used to eat hours. But the hours it frees don’t disappear into busywork. They go straight to the things that quietly got skipped or left half-finished every time a deadline got close: the test that covers the ugly edge case, the observability you add before the incident instead of during it, the refactor that keeps the codebase legible for the next person, the architecture decision someone actually sat down and thought through.
That’s the shift, and it’s why our model is what it is. We embed full-time, US timezone-aligned senior engineers directly into your standups, your Slack, and your Product, and we hold them accountable for what they ship, not just what they generate. AI handles the heavy lifting; the engineer owns the outcome. And when something won’t work, you hear it early, the honest version, not the padded estimate. That’s the part a subscription can’t give you.
The code was never the expensive part. Running it for real always was. The companies that win in 2026 won’t be the ones that replaced engineering with a tool — they’ll be the ones that put senior engineering behind the tool, and finally did the parts everyone used to leave for later.
We build and embed senior engineering teams for companies past the prototype and serious about production. We own what we ship, and stay long enough to know why the product works the way it does. If AI got you to an MVP and now you need the part that keeps it alive at scale, that’s the work we take ownership of.
Where does senior engineering fit in your roadmap? Book a call with our team and we’ll walk through what that would actually look like.
[1] DORA / Google Cloud — 2024 Accelerate State of DevOps Report (Oct 2024). Source of the −1.5% throughput / −7.2% stability figures and the Vacuum Hypothesis. https://dora.dev/research/2024/dora-report/
[2] DORA / Google Cloud — 2025 DORA Report: State of AI-assisted Software Development (Sep 2025). ~5,000 professionals; AI as “amplifier”; throughput now positive but stability still negatively affected; 90% adoption, 30% distrust. https://dora.dev/dora-report-2025/
[3] Becker, Rush, Barnes, Rein — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, arXiv:2507.09089 (Jul 2025). Methodology update Feb 2026. https://arxiv.org/abs/2507.09089
[4] GitClear — AI Copilot Code Quality: 2025 Research (211M lines of code, 2020–2024). https://www.gitclear.com/ai_assistant_code_quality_2025_research