AI Coding Assistants in Production: 2026 Field Notes

What does “production-grade” really mean for an AI coding assistant?

Two years into the AI-assistant rollout, the conversation has stopped being about whether developers should use them and started being about whether the work that ships is any good. The honest answer in 2026 is “sometimes, with discipline.” This is the field-note version of what we have measured on our own production codebases over the last six months.

By “production-grade” we mean three concrete properties, all measurable. One: the merge rate of AI-authored PRs is above the team overall merge rate, not below it. Two: the defect-escape rate on AI-touched code is statistically indistinguishable from human-authored code. Three: the review-bandwidth cost (the time senior engineers spend cleaning up AI suggestions) does not eat the productivity gain that the tool is supposed to deliver.

Almost everything else (vibes, vendor benchmarks, internal Slack enthusiasm) is noise. The three numbers above either look right or they do not.

Copilot in 2026: where it shines and where it still stalls

GitHub Copilot is the assistant we have the most data on, mostly because most teams started there. Its strengths after two years of model upgrades are the boring ones: completing boilerplate, generating tests from existing function signatures, scaffolding new endpoints in well-known frameworks. We measured a real time-saving on these tasks. None of it is glamorous.

Where Copilot still stalls in production is anywhere the surrounding context is not in the file. Cross-file refactors. New-pattern code in an existing codebase. Anything where the right answer requires reading three other files first. The model fills in plausible-looking code without checking the rest of the repo, and the result compiles and passes basic tests while quietly being wrong.

The 2022 “Asleep at the Keyboard” study from NYU documented that about 40% of Copilot completions in security-sensitive scenarios contained vulnerabilities. The 2024 follow-up work from Veracode and academic groups put the number lower for general code (closer to 22%) but still measurable. Our internal data sits between those numbers, which is reassuring only if you know which side of the chart you are on.

Cursor and Claude Code on real PRs

Cursor and Claude Code read more of the repository before generating. That cost shows up two ways: a longer first response, and a meaningfully higher rate of suggestions that actually work in context.

On our cross-file refactors, the merge-unchanged rate for both Cursor and Claude Code sits between 26% and 31%, roughly two to three times Copilot rate on the same class of work. The trade-off is that the cognitive cost of reviewing those suggestions is higher: the diff touches more files, and the reviewer has to validate a larger surface area.

For migration work (the kind of bulk pattern-translation that comes up during framework upgrades or platform consolidation), Cursor and Claude Code are the tools we lean on most often. Copilot is still our default for in-line tab completion on routine work. None of the three replaces a human reviewer.

What is the four-step quality gate for AI-generated code in production?

Every AI-authored or AI-touched PR runs through the same four-step gate before merge. The gate is not optional; it is enforced by branch protection rules in GitHub branch rulesets, not by Slack agreements.

1. Step 1: Human review with a specific question

   The reviewer is not asked “does this look good.” They are asked: “what does this code assume about the repository that the model could not have seen?” The framing changes what reviewers catch.

2. Step 2: Static analysis with type-strict settings

   TypeScript strict, PHPStan level 8, mypy strict. The floor is “every type is explicit.” AI suggestions that pass loose linting often fail under strict types, and the failure is where most of the silent bugs live.

3. Step 3: Test coverage on touched lines, not the file

   We require coverage on the lines the AI changed, not the file overall coverage. This catches the “added a clever new branch with no tests” pattern that ships otherwise.

4. Step 4: Security review for sensitive areas

   Anything touching authentication, payments, user data, or cryptography goes through a separate security reviewer regardless of who wrote it. CODEOWNERS enforces this, not goodwill.

The four-step gate is the part of the system that makes the rest of the productivity claim honest. Without it, AI assistants shift the cost of bugs from the writing stage to the review stage to production. Our AI-driven web development tools work always ships the gate alongside the assistant. We covered the team-shape and governance side in our earlier piece on AI co-pilots for engineering teams.

How do AI coding assistants quietly tax engineering review bandwidth?

The most uncomfortable finding from our six months of data is that AI assistants quietly shift labour from the IDE to the review queue. Productivity in code-writing went up. Time spent in review went up roughly the same amount. The net was close to flat for senior engineers.

This is not a reason to pull AI assistants. The juniors saved real time, and the work was better-shaped on entry. But it is a reason to track review-bandwidth as a first-class metric, not an afterthought.

Six months of internal data

What we measured, what we kept, what we changed.

The underlying point we keep coming back to is that AI assistants are productivity tools when the surrounding system is built for them, and noise generators when it is not. Codebases with strict typing, real test coverage, and CODEOWNERS files behave very differently from codebases without them. The first hour of any AI-assistant rollout should be spent on the gate, not the seat purchase. The same operating discipline runs through our development practice and through how we measure success on the AI-platform side (we wrote about that in our note on human-centred moderation at scale and in the broader AI-driven web tools overview).