Section: data-ai
Kind: Editorial
Reading time: 4 min
Updated: 8 September 2026

Where smart coding assistants speed up your team, and where they should not go

Coding assistants boost productivity and reduce time spent in code review. The risks lie in letting assistants generate or green-light the very code that needs human scrutiny.

Assistants deeply improve productivity for low-context, low-risk code

Where GitHub Copilot's impact has been strongest is in routine, repetitive, and low-risk code. Functionality, readability, and quality all rose. Junior developers' productivity grew the most. [1, 2]

Acceptance rate of the assistant's suggestions is a valid measure. This captures actual perceived productivity, not just those things that are easy to measure.

This improvement isn't just about developer mindset. In their highest-usage weeks, Copilot users averaged 40.5% more pull requests than in weeks with zero usage. Even after a year, this was a consistent pattern.

Copilot primarily helps with small, incremental changes. It hardens a team's most common and least risky code. During repetitive tasks, it frees up 87% of developers' mental effort. It helps 73% of developers stay in the flow.

For droves of context-free, low-risk code, an assistant can write faster than most of us can review. Testing the assistant's output rigorously is the trickiest part - but it allows even the brightest teams to push low-risk changes through review faster.

Where assistants' impact flatlines - and creates big risks

For code that matters, none of these productivity measures are a reliable guide. The assistant has no real understanding of the specific project. Code review's value is concentrated in the furthest reaches of the assistant's reach - and that is where reviewers must be most vigilant. Assistant reviews have made no material improvements in the core risk areas:

Threading and concurrency. All of C/C++ threading, blocking and mutex code. Async/await and callback-based implementations in Java.
Async safety and security in JS/TS.
Authentication, session handling, and authorization changes.
Payment, billing, and subscription changes.
Data migrations, schema changes, and schema translation.
Cryptography, key management, and certificate handling.
User data exports and external data transfers.

These are a real bottleneck. Beyond these gates, assistants are often a tumour - generating far more review cost than they save, risking much more than they safeguard, lowering standards rather than lifting them.

Deserving of our attention: the review backlog

The real risk for most teams is review backlog, not assistants. Assistants may make code review faster. But they push far more pull requests to review. Even if the average review speed is faster, the volume wins.

A good assistant is like a forward-thinking developer. It creates fewer review comments. It pushes smaller pull requests, each with a tighter focus. It changes the sidelines themselves, not the foundations.

So why aren't we faster still?

The assistant raises its pitch, but it does not drown out the roll of the incoming tide. More pull requests prove more than just more assistants; norms that vary from project to project set all fundamentals in motion. Number, not velocity, is the governing rule.

Increased review load calls for even stricter discretion. A pull request is a return to first principles, not the crowning moment of a virtuous cycle.

For most teams, the assistant requires less review and enables more deployment practice. On average, it preserves more stable code.

But this is a temporary spur: a powerful effect, but synchronous rather than generative. Over time, it becomes a drag. An assistant that influences final outcomes damages trust and compromises quality over efficiency.

These tools cast a net that meets us in the midstream of the review process. They support the flow of the team, while limiting oversight. The challenges lie deeper, at the platforms' source.

Minimizing AI-generated pull requests

Every codebase is distinct, with its own risks. The policy must match the locus of knowledge held by the organization. The underlying documents and game matrix are experiential, assisting only in recreating the felt world.

So every organization should canonize a code contribution policy - a clear set of explicit rules and expectations for code generation and contribution. The rules vary by domain:

Authentication: senior engineering approval required.
Authorization: approve before merge.
Session: senior approval then merge.
Payment: validate then merge.
Billing: senior reviewer needed.
Subscriptions: requiring senior review.
Data migrations: special prior approval for merge.
Schema changes: senior required before merge.
Cryptography: policy-based criteria for senior approval.
Key management: policy requiring senior approval
Certificates: review requirements
User data exports: added scrutiny
Data transfers: special approval for cross-border transfers

These might seem exhausting. But so is managing a critical hit in production that a full audit would have caught. It's an engineering organization's duty to contain what it cannot prevent. An AI resource is valuable. But code is precious.

So ensure that each pull request holds AI authorship disclosures. Ensure reviewers can spot assisted code instantly.

The takeaway

On everything else, force your assistant to fly. Leave no review page unturned. Your codebase is keystone, your engineering reputation - and your product reliability - depends on sticking to this principle:

Coding assistants, in general, write faster than they review. Generating all of a team's code is a special-danger risk. Assistants are great for boilerplate, tests for existing behaviour, translations between languages. But the code an assistant generates - with less forethought and 100% of its loss - must never be the same as code that goes to production.

So use assistants liberally. But when an assistant tags along, no silent attendant, a human intervention has been performed. A senior reviewer adds an impartial reading. Let an approved senior engineer merge everything that the assistant touches. And let the assistant do the bulk of the routine code.

Only then can AI-assisted coding become a true boon - not a performance accelerator that props, but a companion, that doesn't lower the bar.