AI & Engineering

AI doesn’t write bad code. It writes more of the code you already had.

Neil Sherman ·

AI doesn’t write bad code. It writes more of the code you already had.

There’s a specific breed of regret I’ve watched settle over engineering leaders this past year. It usually shows up about six months after they’ve rolled out AI coding tools across the team. The initial dashboards looked brilliant. PR counts doubled. Developer satisfaction surveys glowed. Someone in finance got a line to put in a slide.

Then the incidents started.

Not big, dramatic ones. Just a creeping accumulation of bugs that were difficult to trace, regressions in places nobody had touched, code that worked but that nobody on the team fully understood. One architect described his codebase as “suddenly full of strangers.”

Meanwhile, in a quieter corner of the industry, other teams were having a very different experience. One enterprise client migrating 687,600 lines of .NET code achieved an 80% automation rate and cut their original fifteen-sprint plan to eight. That’s a rigorously measured 47% productivity gain. Other teams are reporting similar stories, from framework migrations that finished in months rather than years, to cycle times falling by a quarter as AI adoption matured.

Same technology. Same tools. Vastly different outcomes.

This isn’t a paradox. It’s a straightforward consequence of a principle the research has now established beyond reasonable doubt, and it’s the most important thing an engineering leader needs to understand before signing the next round of AI licences.

AI is an amplifier.

Drop a brilliant tool into a well-run engineering organisation and you’ll see the curve bend sharply upwards. Drop the same tool into a codebase held together with duct tape and good intentions, and you’ll generate technical debt at machine speed. The tool isn’t the variable. The system it’s dropped into is.

For engineering leaders who’ve spent years making the case for unglamorous foundational work, this is the moment that investment starts paying off.

The opportunity, stated plainly

For the first time in a generation, three historically intractable problems have become economically solvable.

Legacy modernisation is viable again. Anthropic recently described legacy code modernisation as “one of the highest-demand enterprise workloads” and committed $100M to a partner network focused on exactly this problem. The Experian example above delivered a 47% productivity gain on a real .NET estate with rigorous measurement behind the number. Modernisation programmes that would have been ten-year, eight-figure commitments can now be done in quarters. For any organisation carrying a decade or more of technical debt, AI-assisted modernisation is the first honest shot at paying it down that the industry has had.

Onboarding and comprehension stop being bottlenecks. New engineers joining complex codebases have historically needed six months to be productive and eighteen to be genuinely fluent. A capable AI agent can explain why a function exists, trace business logic embedded in a twenty-year-old module, and answer the questions a new hire would previously have had to interrupt a senior engineer to ask. For any organisation struggling with knowledge silos, retiring engineers, or the long tail of “we’d fix that but only Dave knows how it works”, this is a genuine step change.

Senior engineers can finally do senior engineering. The work that actually needs seniority — architectural judgement, system design, tradeoff analysis, mentorship — has been chronically displaced by the work seniors end up doing because nobody else can: reviewing routine PRs, debugging edge cases, writing the same CRUD endpoints they wrote last year. AI doesn’t replace senior engineers. It gives them back the hours they’ve been losing to work that never deserved them.

Brownfield refactoring at speed. Most interesting engineering work happens on codebases that already exist. For the first time, there are genuine tools for reasoning about a large existing codebase, proposing safe refactors across dozens of files, and executing them with human review at every step. The cost of improving a working system has collapsed.

These aren’t theoretical benefits. They’re happening right now in organisations that have done the foundational work. The rest of this post is about what that work looks like, because the research is equally clear on what happens to organisations that try to capture these benefits without it.

What the research keeps finding

Start with the 2025 DORA report,[1] drawing on survey responses from nearly 5,000 technology professionals. Its central finding lands the amplifier thesis directly: AI adoption now correlates positively with throughput and with instability, and the differentiator between those outcomes is the strength of the engineering foundations the tools are dropped into.

The shadow side of that amplification has been quantified in detail. An analysis from GitClear,[2] spanning over 211 million changed lines of code, found a 60% decline in refactored code, an eightfold increase in duplicated code blocks, and code churn that has doubled. For the first time in recorded history, copy-paste patterns have exceeded moved-code patterns in large-scale repositories. Developers have been generating new code faster than they tidy up the old.

Where DORA measured outcomes, OX Security[3] went looking for causes. Their 2025 report (memorably titled Army of Juniors: The AI Code Security Crisis) analysed more than 300 repositories and found ten recurring anti-patterns present in 80 to 100% of AI-generated code. Incomplete error handling, weak concurrency management, inconsistent architecture. Their framing is worth sitting with: unsupervised AI behaves like an enormously productive junior developer who has never met your codebase before and has no memory of what you decided last Tuesday. Veracode’s 2025 GenAI Code Security Report[4] reinforced the security angle, finding that 45% of AI-generated code introduces vulnerabilities when developers don’t provide explicit security guidance.

The telemetry picture is consistent with the survey and security findings. Faros AI[5] tracked two years of data across 22,000 developers. LinearB’s 2026 benchmarks[6] drew on 8.1 million pull requests. Both found the same pattern: high-AI-adoption teams generate 98% more pull requests, review times increase by 91%, and any correlation between AI adoption and company-level performance evaporates. Acceptance rates for AI-generated PRs sit at 32.7% against 84.4% for human-written ones.

CircleCI’s analysis[7] of this pattern captures the economics in one memorable line. If fifty senior engineers spend four hours daily reviewing AI-generated code, that’s 50,000 hours annually — the equivalent of 25 full-time senior engineers — spent on validation rather than building. You’re not getting 25 free senior engineers by adopting AI. You’re getting 25 senior engineers reassigned to reviewing the output.

The rework metric matters more than ever in this context. DORA added deployment rework rate to its five-metric model in 2024, and the 2025 DORA report[14] established the first official benchmarks for it. The headline number: only 7.3% of teams achieve a rework rate below 2%, while more than a quarter (26.1%) sit in the 8 to 16% range. Rework rate measures the proportion of deployments that are unplanned fixes for production issues rather than planned feature work, so the figure is essentially saying that the typical engineering team is losing somewhere between one in ten and one in five deployments to firefighting. That loss compounds quickly when AI accelerates the rate at which changes enter the system.

Six findings, multiple methodologies, all pointing the same way. The differentiator is never the AI. It’s always the system around it.

A quick note on tools

People often ask me which AI assistant I’d recommend. The honest answer is that the tool choice matters less than most vendors would like you to believe, and the conversation has moved fast enough that anything I write here will be half-stale by the time you read it.

That said, the state of play in 2026 is roughly this. GitHub Copilot is still the most broadly adopted tool and the strongest option for inline IDE completions and teams deeply tied to the GitHub ecosystem. Claude Code is the most capable autonomous agent for repository-scale tasks (refactors, migrations, multi-file reasoning) and has been gaining ground fast through early 2026. Cursor is the standalone AI-native IDE, popular with developers who want the full editor experience rebuilt around AI. Most teams I speak to who are serious about this use more than one, typically Copilot or Cursor for daily editing and Claude Code for bigger autonomous tasks.

But this choice is downstream of the question that actually matters, which is whether your engineering system — and the business it sits inside — are ready to amplify productivity rather than chaos.

How to tell if you’re ready

Before you buy anyone another licence, the honest diagnostic. Four questions I’d ask any team asking for advice on this.

Can your developers get signal on a change in under ten minutes? Test suite speed, CI reliability, static analysis, automated checks. If a developer can get meaningful feedback in five minutes, AI amplification is safe. If signal takes forty minutes or an overnight build, you’re automating the production of surprises.

Does every PR get at least one substantive review comment from a senior reviewer? AI-generated PRs need more review, not less, because the author has no memory of previous decisions and no stake in the codebase’s long-term health. If your current review culture is “merge to unblock,” AI will merge chaos to unblock.

Do you have architecture decision records, coding standards, and agreed patterns that are actually enforced? The OX Security finding about inconsistent architecture in 80 to 100% of AI-generated code is a symptom of AI filling in the gaps where your standards should be. If your standards exist only in the heads of two senior engineers, AI will produce code that quietly disagrees with them.

Can you trace a defect back to the change that caused it within an hour? If the answer involves grep, prayer, and a Slack message to someone on holiday, you have an observability problem that AI-accelerated delivery will expose.

If you’re answering “no” or “sort of” to more than one of these, the honest conversation is that you need to do the readiness work alongside the adoption, not after it.

The bit nobody’s talking about: the rest of the business

There’s one more readiness question, and it’s the one I rarely see asked in AI adoption conversations. It might be the most important one.

If your engineering team could genuinely double their output tomorrow, is the rest of your business ready to receive it?

Engineering doesn’t ship in isolation. Every feature that makes it to production passes through product, design, client stakeholders, legal or compliance review, release management, customer success, sales enablement, documentation, and support. If you 2x the rate at which code gets written but product takes three weeks to clarify requirements, design takes two weeks to deliver UX, and client sign-off takes a fortnight on a good day, you haven’t accelerated your business. You’ve just moved the queue.

This is a pattern that’s played out across the industry in the last eighteen months. An engineering team enthusiastically adopts AI tooling. Throughput visibly improves. A few weeks later, the team is half-idle because product can’t feed them requirements fast enough, and the features that do get built are stuck in a client review cycle that wasn’t designed to process this volume. Developers are frustrated, the backlog looks artificially healthy, and the capacity gain has quietly evaporated into waiting.

This is the broader version of DORA’s Value Stream Management finding: local engineering optimisations don’t translate into business outcomes unless the whole value stream can handle the new pace. AI that accelerates the middle of a pipeline whose front and back ends move at yesterday’s speed isn’t really accelerating anything. It’s just creating pressure points at the handoffs.

Three honest questions to put to your leadership team:

Can product and design keep up? If your engineering team doubles capacity, can the people feeding them requirements actually produce twice as many well-specified tickets? If the answer involves product managers already working evenings, the answer is no.

How fast can clients make decisions? For anyone doing B2B software or bespoke work, client approvals are often the biggest latency in the value stream. AI doesn’t speed up a customer who takes three weeks to sign off on a change. It just means you’ve now got more developers staring at the same email chain.

What happens in the release and compliance pipeline? In regulated industries, every feature might go through security review, change advisory board, regulatory approval, or customer UAT before it ships. If those processes assume the historical rate of change, doubling the input will just lengthen each stage.

The uncomfortable truth is that many organisations will find their engineering team isn’t the tightest constraint on their throughput. It’s just the most measured. AI adoption without a corresponding look at product velocity, design capacity, client processes, and release management will simply expose where the real bottlenecks have been hiding all along.

This isn’t a reason not to adopt AI. It’s a reason to adopt it with your eyes open about where the gains will actually materialise.

How to get ready (the actual playbook)

If you read nothing else in this post, read this part.

If you do only one thing, shorten your feedback loops.

Before the platform work, before the architecture documents, before the review discipline, get the time between “developer makes a change” and “developer knows whether it broke something” down under ten minutes. Ideally under five.

This one investment does more to make AI adoption safe than anything else on the list. Fast feedback loops turn AI mistakes into caught mistakes. Slow feedback loops turn AI mistakes into production incidents. Every other item in this playbook matters, but if you can only fund one, fund this one. It’s the single most important investment an engineering organisation can make in the AI era, and every other improvement gets easier once it’s in place.

If you have bandwidth for more, here’s the rest of the list in priority order.

1. Treat code review as the bottleneck it’s about to become.

Not more reviewers. Better ones, with better tools. Invest in static analysis, architectural linting, and automated policy enforcement that catches the issues humans shouldn’t have to think about. The review queue is where your AI productivity either materialises or evaporates.

2. Write down your architecture — for the AI, not the board.

If your standards, patterns, and constraints exist as documents that can be fed into the AI’s context, it will generate code that matches them. If they exist only as tribal knowledge, the AI will make up its own patterns. Architecture decision records, prompt templates, internal style guides, API design documents. These were always good ideas. Now they’re load-bearing.

3. Invest in your internal platform.

DORA’s data is unambiguous on this: organisations with high-quality internal platforms convert AI adoption into measurable outcomes. Organisations without them don’t. A platform doesn’t need to be glamorous. Consistent deployment pipelines, shared libraries, golden paths for common tasks, sensible defaults. The boring infrastructure that makes it harder for anyone, human or machine, to do the wrong thing.

4. Build an AI-specific review discipline.

Every AI-generated PR should answer three questions before it merges. Does the human submitting it understand what it does? Does it match our architectural patterns? Have we run the checks that would have caught the issues we know AI tends to introduce? The last question requires you to actually have those checks.

5. Align the rest of the business before you scale.

Product, design, client services, release management. Make sure they know the engineering team is about to go faster, and find out whether they can meet the new pace. Run the value stream mapping exercise. Identify the handoffs that will become bottlenecks. Get commitment from leadership that when engineering capacity doubles, the upstream and downstream functions are resourced to match. Without this step, the productivity gains will evaporate into waiting, and someone in finance will eventually ask a very awkward question.

6. Measure what matters, not what’s easy.

Licence adoption is not a success metric. Lines of code generated is not a success metric. Measure change failure rate, rework rate, cycle time, and the rate at which post-deployment incidents trace back to AI-generated changes. If those numbers are going in the right direction, you’re winning.

If you want a starting point that the rest of the industry is now using, the DORA Quick Check[15] was updated in April 2026 to include deployment rework rate alongside the other delivery metrics. It’s free, takes a few minutes, and produces a benchmark against current industry data. Worth running across teams as a baseline before you scale AI adoption further.

The window

The teams getting this right are genuinely excited about their work. Legacy modernisation projects that were a perpetual “next year” item are actually moving. Senior engineers are spending time on architecture and mentorship rather than routine reviews. Onboarding is faster. DORA’s data on high-performing teams validates this pattern, and CodeRabbit’s 2026 outlook[13] captures the industry shift succinctly: 2025 was the year of AI speed; 2026 is the year of AI quality. The teams who invested in the foundations are now seeing the payoff.

The gap between disciplined adopters and everyone else is going to widen fast. Not because AI is magic, but because the organisations with strong foundations will pull further ahead each quarter, while the organisations without them will be doing increasingly expensive triage on the debt they’ve been generating.

This is the best news engineering leaders have had in years. For the first time, the unglamorous work — test suite speed, review discipline, architectural documentation, platform investment — has a clear, measurable, near-term payoff. The boring investments that used to be a hard sell to the board are now among the highest-value moves available to any technology organisation. And because the research has surfaced exactly which disciplines matter most, the roadmap is clearer than it’s ever been.

If you’re reading this with a slightly queasy feeling of recognition, the work is doable, it’s cheaper than the damage it prevents, and it’s the same work your best engineers have been quietly asking for anyway.

This piece focuses on engineering readiness specifically. The harder organisational question is what happens to the rest of the business when engineering accelerates. I’ve been developing a framework called Flow Readiness that extends this thinking into the value stream and the upstream and downstream functions that have to absorb the new pace. I’ll publish it in a few weeks.

The research is clear, the roadmap is clear, and the returns start the day you begin. Start this quarter.

  1. Announcing the 2025 DORA Report: State of AI-Assisted Software Development — Google Cloud
  2. AI Copilot Code Quality 2025: Look Back at 12 Months of Data — GitClear
  3. AI-Generated Code Creates New Wave of Technical Debt, Report Finds — InfoQ (on OX Security’s Army of Juniors report)
  4. When AI-Generated Code Becomes Your Technical Debt — Crossbridge (citing Veracode 2025 GenAI Code Security Report)
  5. The AI Productivity Paradox Report — Faros AI
  6. 2026 Software Engineering Benchmarks Report — LinearB
  7. DORA is right: AI is an amplifier, for better or worse — CircleCI
  8. GitHub Copilot — GitHub
  9. Claude Code — Anthropic
  10. Cursor
  11. Mastering the AI Code Revolution in 2026 — Baytech Consulting (citing Jellyfish AI adoption cycle time analysis)
  12. The AI-Powered Legacy Modernization Playbook — Altimi, March 2026
  13. 2025 was the year of AI speed. 2026 will be the year of AI quality. — CodeRabbit
  14. What are the 2025 benchmarks for the DORA five-metric model? — Research-Driven Engineering Leadership
  15. DORA Quick Check — free assessment tool, dora.dev