AI writes the code. Who signs for it?

AI has changed how quickly software can be written. It has not changed who is accountable when that software reaches production.

A generated change still needs an engineering decision. Someone must understand its impact, validate its behavior, review its security implications, and decide whether it is ready to release.

The productivity conversation often starts with how much code AI can generate. The more important question is how much verified software an engineering team can put into production.

That is where the real engineering challenge begins.

The numbers behind the feeling

AI-assisted development is changing the economics of implementation. But faster implementation is only one part of software delivery.

The work does not end when code is generated. Changes still need to be reviewed, tested, integrated, secured, and operated.

The relevant measure is not how much code an AI tool produces. It is how much additional, verified functionality reaches users without increasing the cost of maintaining it.

Here is what the research measures, and what it does not.

How much code AI writes. Across more than 500 companies measured this year, over half of new code is AI-generated (DX, 2026).¹ Google says three-quarters of its new code is (Semafor, 2026).² Both figures count code written. Neither says how much of it was reviewed, worked as intended, or reached users. Google's is one company's figure, given by its chief executive.

Output is up. Incidents per change are up faster. A telemetry study of 22,000 developers (Faros AI, 2026) found tasks completed per developer up about a third under heavy AI use. In the same population, incidents per pull request were up about 240%, median review time was five times longer, and 31% more pull requests were merged with no review at all.³ It measures what happened in those teams' tools. It counts tasks and pull requests, not features released. On its own, it does not show that AI caused the incidents.

The issues stay in the code. Researchers traced 302,600 AI-authored commits across 6,299 open-source repositories (Liu et al., 2026). More than 15% of commits from every assistant tested introduced at least one issue, and nearly a quarter of those issues were still present in the latest revision.⁴ It measures issues in public open-source code. It does not measure what those issues cost in production, or how company codebases compare.

Better models did not mean safer samples. Across 100+ models, roughly 45% of AI-generated code samples contained a known security weakness (Veracode, 2025). Newer, larger models did not improve the rate.⁵ These are samples, not production systems. That is the point: nothing stops a sample from becoming production except a check.

Engineers know. Of 1,149 developers surveyed (Sonar, 2026), 96% said they don't fully trust AI code to be functionally correct, and only 48% said they always check it before committing.⁶ It measures what developers say about their trust and their habits, not how often AI code is wrong.

None of this is an argument against AI. The researchers who measured slower task completion under AI in early 2025 now say developers are probably faster with AI, though they call their own data weak evidence (METR, 2026).⁷ Both come from timing developers on tasks; neither measures how fast verified changes reach users.

The pattern is older than software. The printing press made a copy of a book about 340 times cheaper than a scribe's (Clark via AI Impacts, 2008).⁸ It also made a mistake 340 times cheaper to repeat: in 1631 the king's printers dropped the word not from the seventh commandment, the whole run was destroyed, and they were fined £300 (Wikipedia, Wicked Bible).⁹ So print invented the corrector, a named person who checked the set type before the press ran (Grafton, 2020).¹⁰ Cheap reproduction made checking the master the job that mattered.

The gain never comes from the tool alone. Electricity was commercial by 1881; factory productivity did not move for 40 years, until factories were rebuilt around the flow of work instead of around the old steam engine (David, 1990).¹¹ Both are history, not measurements of software teams: they show a pattern, not what AI will do.

The AI-native companies have noticed. Ramp built an agent that watches one of its apps in production and proposes its own fixes. It still holds one rule: "no code is merged without engineer review" (Ramp Labs, 2026).¹² It is one company's rule for one agent, not a measure of how teams work.

Productivity claims need context. Faster task completion does not automatically translate into faster releases. Nor does a higher volume of generated code establish that engineering quality has improved.

The distinction matters when teams make decisions about engineering capacity, delivery commitments, and AI investment.

The bottleneck moves. It always has.

Every improvement in software development moves pressure somewhere else.

Faster implementation increases the volume of changes entering the engineering lifecycle. That creates more demand for review, integration, testing, and architectural judgment.

AI does not remove the engineering bottleneck. It changes where the bottleneck appears.

Teams that optimize only for code generation can end up moving work downstream rather than eliminating it.

A developer may complete an implementation faster, but the change still needs to fit the architecture, satisfy the specification, pass verification, and operate reliably.

If those activities cannot keep pace, the apparent productivity gain becomes additional work waiting in the delivery pipeline.

The objective should be to improve the entire path from specification to production release.

Four questions that separate speed from borrowed speed

When a team reports productivity gains from AI, four questions help determine whether those gains are real.

1. What actually reached production? Distinguish generated code, completed tasks, and merged pull requests from functionality released to users. Measure the work that completed the delivery lifecycle.

2. Who reviewed and approved it? Identify the engineer accountable for technical decisions. Generated code does not remove the need for architectural review, ownership, and documented reasoning.

3. What did verification catch? Examine defects, failed tests, rework, security issues, and integration problems. Faster implementation is not an improvement if it creates disproportionate downstream correction.

4. What did delivery actually cost? Include implementation, engineering review, correction, infrastructure, AI usage, and ongoing maintenance. Token cost alone is not the cost of delivering software.

These questions move the discussion from AI activity to engineering outcomes.

How we hold the line at Olensys

At Olensys, AI participates throughout the engineering lifecycle. It can analyze requirements, propose implementations, generate tests, and assist with verification.

But AI does not own engineering decisions.

A named engineer reviews proposed changes, evaluates alternatives, and records the reasoning behind important decisions.

We apply this principle through six engineering gates.

• G0 — Repo-ready: The repository, dependencies, and working environment are ready.
• G1 — Spec approved: Requirements and acceptance criteria are agreed.
• G2 — Plan approved: The implementation approach and trade-offs are reviewed.
• G3 — Verified: Changes pass the required engineering checks.
• G4 — Production-ready: The release meets deployment and operational requirements.
• G5 — Released and measured: The functionality is released and its performance is measured.

Each gate establishes what must be true before work progresses.

AI can propose a change. A named engineer decides whether it is acceptable. Verification provides evidence. Production measurement establishes what happened after release.

A gate that always passes is not a gate.

The objective is not to slow down AI-assisted development with unnecessary approvals. It is to put engineering judgment where it has the greatest impact.

The real point

AI changes the economics of writing software. It does not transfer responsibility for the software being written.

Engineering leaders still own architecture, quality, security, reliability, and production outcomes.

The advantage will not belong to teams that generate the most code. It will belong to teams that turn AI-assisted work into verified software, release it responsibly, and measure what happens afterward.

AI writes the code. Engineering owns the decision.

That is the distinction between faster development and better engineering.

Sources

1. DX, Q2 2026 State of AI Impact in Engineering (Jul 2026, more than 500 organizations): AI-generated share of code 52.7%. getdx.com
2. Semafor, Google CEO: ~75% of new code is AI-generated (Apr 2026). semafor.com
3. Faros AI, Acceleration Whiplash: 2026 AI Engineering Report (Apr 2026, 22,000 developers). faros.ai
4. Liu et al., Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild (arXiv 2603.28592, 2026). arxiv.org
5. Veracode, 2025 GenAI Code Security Report. veracode.com
6. Sonar, 2026 State of Code Developer Survey (1,149 developers, Oct 2025). sonarsource.com
7. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Jul 2025), metr.org, 2025; and We are Changing our Developer Productivity Experiment Design (24 Feb 2026), metr.org, 2026.
8. AI Impacts, Historic trends in book production, citing Clark (2008) and Eisenstein for the 1483 Ripoli Press comparison (~341× cheaper per copy). aiimpacts.org
9. Wicked Bible (1631): Robert Barker and Martin Lucas; "not" omitted from Exodus 20:14; run called in and destroyed; fined £300 by the Star Chamber. en.wikipedia.org
10. Anthony Grafton, Inky Fingers: The Making of Books in Early Modern Europe (2020): correctors as a new social type created by print. reviews.history.ac.uk
11. Paul David, The Dynamo and the Computer (1990), via History News Network. historynewsnetwork.org
12. Alex Levinson and Ramp Labs, How we made Ramp Sheets self-maintaining (24 Mar 2026): "no code is merged without engineer review." ramplabs.substack.com