AI coding agents have changed the speed at which software can be produced. A developer can now describe a feature, let an agent inspect the codebase, generate changes across several files, write tests, run them, fix errors and prepare the result for review.
That is a huge productivity improvement. But it creates another problem.
If AI can produce code much faster than humans can properly review it, have we simply moved the bottleneck from coding to verification?
I think that question is becoming increasingly important.
Code generation is scaling very quickly
GitHub reported in October 2026 that one in three pull requests on GitHub now involves an AI agent, compared with fewer than one in ten a year earlier. That is an extraordinary change in a short period of time.
GitHub's concern was not that developers were suddenly becoming careless. The problem was that software production was increasing faster than traditional security and review processes could keep up.
The Stack Overflow Developer Survey 2026 tells a similar story. Among AI-related mistakes that had cost teams time, 69.3% of respondents reported plausible but wrong code. More than half, 54.2%, reported hard-to-review generated code, while 49.3% reported problems caused by missing context.
These numbers highlight an important issue. AI is becoming very good at producing code that looks reasonable. And that can sometimes be more dangerous than code that obviously fails.
Working code is not always correct software
Suppose an AI agent creates an API endpoint.
- The code compiles.
- The endpoint returns HTTP 200.
- The database update works.
- The generated tests pass.
Technically, everything may appear correct. But I would still not consider that endpoint ready.
When I review backend work, I normally test the endpoint directly using tools such as Postman or Insomnia. I check the parameters, headers, authentication requirements and expected output. Then I change the input and try different combinations based on how I know the application will actually be used.
But I also ask questions that are not purely technical.
- Who is supposed to use this endpoint?
- Why was it created?
- What should this user be allowed to access?
- What if somebody discovers the endpoint and intentionally changes the request?
- What if an authenticated user tries to access another user's information?
- What happens when an unexpected but technically valid value arrives?
- What safeguards should exist if someone attempts to misuse it?
Those questions come from understanding the business problem behind the code, not simply reading the implementation.
Once the backend passes those checks, I connect it to the frontend and test the complete user flow. If the feature behaves differently when seen in the real application, I adjust it before moving to the next part of the system. That process has taught me something important:
Code review is not only about finding bad code. It is about finding incorrect assumptions.
The most difficult bugs may look perfectly valid
Traditional bugs are often easier to notice.
- The application crashes.
- A query fails.
- A variable is undefined.
- A test turns red.
AI-generated mistakes can be more subtle. The code can be clean, readable and technically correct while implementing the wrong interpretation of the requirement.
For example, an endpoint may correctly return information for a logged-in user, but the authorization rule may have been interpreted too broadly. A calculation may be mathematically correct but based on the wrong business rule. A frontend flow may function perfectly while allowing an action the product owner never intended.
This is why I believe business-aware review becomes more valuable as code generation gets faster. The reviewer needs to understand not only how the code works, but why the software exists.
What if the same AI writes the code and the tests?
This creates another interesting problem. AI coding agents are now widely used to generate automated tests. According to Stack Overflow's 2026 survey, writing or improving tests is already one of the most common AI-assisted development activities.
That is useful, but there is a potential blind spot.
Suppose an AI agent misunderstands a requirement. It then writes the implementation according to that misunderstanding. After that, the same agent generates tests based on the same interpretation.
The tests may all pass. But what has actually been proven? Perhaps only that the implementation and its tests agree with each other. They may still both be wrong from the business perspective.
This leads to a principle I think software teams should take seriously:
Passing tests do not always prove that the software is correct. Sometimes they only prove that the code and the tests share the same misunderstanding.
Separate the requirement from the implementation
One practical way to reduce this problem is to keep test expectations independent from the generated code.
If AI is going to help create tests, give the testing agent the original business requirement, acceptance criteria and expected behaviour. Do not simply ask it to inspect the implementation and write tests around whatever it finds.
The difference is important. The first approach asks: Does this implementation satisfy the requirement?
The second approach may become: Can I write tests that confirm what this implementation already does?
Those are not the same question. For important workflows, I would still want a human who understands the business to perform independent validation.
Can AI review AI?
This is becoming another interesting development. GitHub launched ReviewBench in October 2026 to measure how well AI code-review agents perform against realistic pull requests.
One of GitHub's experiments combined several independent model runs into a multi-model review rather than relying on a single AI reviewer. In production testing, GitHub reported an 8% improvement in its precision-related measure and a 13.6% improvement in recall.
That suggests an independent AI reviewer can add real value.
I have not yet made a second AI reviewer a formal part of my own development workflow, but I can see where it fits.
- An implementation agent could generate the feature.
- A different AI model or review agent could inspect the change for bugs, missing edge cases, security issues and inconsistencies.
- Automated security and quality tools could perform another layer of checks.
- Then a human could concentrate on the questions that require business and architectural understanding.
This is important because AI review should not simply mean asking the same agent whether its own work looks good.
Independence matters.
AI review and human review solve different problems
I see a useful division emerging. An AI reviewer can be very good at asking:
- Is there a likely bug here?
- Is there repeated logic?
- Is this error case handled?
- Does this query create a security concern?
- Is a test missing?
- Does this change conflict with another part of the repository?
A human reviewer should increasingly focus on questions such as:
- Is this the behaviour the business actually needs?
- Does this permission model make sense?
- Could a real user misuse this flow?
- Does this change fit the architecture?
- What happens when this feature interacts with another workflow?
- Is the risk acceptable in production?
These are different kinds of review. Using AI for the first group can reduce human workload. Removing the second group would create a different problem.
Not every change needs the same level of review
Another consequence of faster code generation is that review effort needs to become more intelligent. A small visual adjustment should not receive the same scrutiny as:
- authentication
- payments
- user permissions
- database migrations
- financial calculations
- personal data access
- production deployment
- an integration with an external service
When generated code volume increases, treating every change exactly the same becomes expensive. A better approach is risk-based review.
Low-risk and easily reversible changes can rely more heavily on automated checks and AI review. High-risk features should receive deeper human inspection, explicit business validation and stronger testing.
The question should not simply be: "Did someone review this code?"
It should be:
"Was this change reviewed according to the risk it creates?"
A practical verification pipeline
If AI-generated implementation continues growing, I think a modern development workflow may increasingly look like this:
Business requirement → AI implementation → automated tests → independent AI review → human business-aware review → integration validation → production
Each layer solves a different problem.
- The business requirement defines what should happen.
- The implementation agent converts that requirement into software.
- Automated tests catch repeatable technical problems.
- An independent AI reviewer can scan more code than a human realistically can.
- The human reviewer challenges assumptions, architecture, permissions and business logic.
- Integration testing checks whether the feature still behaves correctly when placed inside the complete product.
No individual layer is perfect. Together they create stronger confidence.
Human review may become more valuable, not less
There is a popular assumption that AI-generated code will eventually reduce the need for experienced developers. I think the opposite may happen in some parts of software engineering.
If AI agents can produce implementation faster, experienced developers may spend less time manually typing every piece of code.
But somebody still needs to know when the generated solution is wrong. Somebody needs to recognize an insecure permission model. Somebody needs to notice that a technically elegant implementation does not match the business workflow. Somebody needs to decide whether a change is safe enough for production.
That requires judgment. And judgment usually comes from experience.
The bottleneck is moving again
A few years ago, producing the code itself consumed much of the engineering effort. Agentic coding is reducing that cost. Now verification, context, architecture and business understanding are becoming more important.
GitHub's data already shows the direction of travel. If one in three pull requests involves an AI agent today, the amount of generated software reaching review will continue to grow.
The question for engineering leaders is therefore not only: How much faster can our developers generate code with AI?
They should also be asking: How much faster can we establish that the generated code deserves to be trusted?
That is a different problem. And it may become one of the defining engineering challenges of the AI coding era.
AI has increased our capacity to produce code. Now we need to increase our capacity to verify it without lowering the standard of what reaches production.
