AI Is Writing Code Faster. Who Is Checking It?

For years, software teams have tried to make development faster. Better frameworks, CI/CD pipelines, cloud infrastructure, automation and reusable components have all reduced some of the friction around building software.

Now AI has changed the speed of creating code much more directly. A developer can describe a feature, ask an agent to investigate a codebase, generate an implementation, write tests and prepare a pull request.

GitHub says Copilot code review has already processed tens of millions of reviews. OpenAI describes coding agents that can write features, fix bugs and propose pull requests, while other AI companies are increasingly positioning coding agents as part of real production workflows.

That is impressive. But I keep coming back to one question:

If we make code much faster to produce, who is checking all of it?

The bottleneck may simply be moving

Imagine a factory where the production line makes 100 products per hour and five people inspect them. Then somebody installs a new machine and the factory can suddenly produce 1,000 products per hour.

Great. But the inspection area still has five people.

Did the factory become ten times more efficient, or did the bottleneck simply move ten metres further down the building?

I think software may be entering a similar stage.

DORA's recent AI research describes AI as an amplifier. Strong delivery systems can benefit from it, but existing weaknesses can also become larger. Individual coding gains may disappear into downstream problems around testing, security review and deployment.

Charity Majors has made a similar argument: when code becomes much cheaper to create, stronger engineering discipline becomes more important rather than less.

That makes sense to me. When producing another implementation takes a prompt and a few minutes, creating more becomes easy.

But more code is still more behaviour, more states, more interactions, more assumptions and more things somebody may eventually need to maintain.

We may be confusing code generation with software development

This is probably the controversial part: I do not think writing code and building software are the same thing.

Code is part of the product, but a real product also contains business rules, user expectations, old decisions, integrations, strange edge cases and years of accumulated context.

An AI model may create a perfectly reasonable implementation of the wrong behaviour.

Imagine the requirement says: A user can cancel a contract before completion.

The AI creates the endpoint, validates the user, updates the status and returns the expected response. The unit tests pass and technically everything looks clean.

But what happens if money has already arrived? What if the other party already completed their action? Should the cancellation questionnaire still appear? Does a refund process start? Which message does each user see?

Those answers are not always sitting neatly inside one function. Sometimes the real business rule is spread across product discussions, support tickets, previous defects and somebody's understanding of why the feature was designed that way in the first place.

AI is very good at generating from the context it receives. The uncomfortable question is whether we gave it the right context.

“It passes the tests” may become a weaker argument

AI can write the code. AI can also write the tests.

At first, that sounds perfect. But imagine I misunderstand a requirement and write both the implementation and the test based on the same misunderstanding.

The test passes. Have I proved the product is correct?

No. I have proved that my implementation agrees with my assumption.

AI can create the same problem at a much larger scale.

Two mirrors facing each other do not suddenly give you another point of view.

This is why I think independent verification matters.

Research into AI-generated code is still developing and the findings are not one-sided. Some large-scale studies have found AI-authored changes both introducing and removing technical issues. Other comparisons have identified different defect or security profiles between human and AI-generated code.

That nuance matters. AI code is not automatically bad and human code is definitely not automatically good.

The problem is unquestioned code.

Developers are using AI more while trusting it less

The 2025 Stack Overflow Developer Survey found widespread use or planned use of AI tools in development, while distrust in the accuracy of AI output remained significant. Highly experienced developers were also among the more cautious groups.

I find that interesting because usage can increase at the same time as trust decreases.

It sounds contradictory, but maybe it is a sign that people are learning how these tools actually work.

The first time AI creates a working feature in a few minutes, it feels almost magical. Then you use it for six months and start noticing the code that is almost right, the duplicated logic, the fallback that makes no sense, the test that mocks away the actual problem and the parameter that is accepted but never used.

You also start recognising the confident explanation of behaviour that the system does not actually have.

AI does not need to be completely wrong to cost time. Sometimes 90% correct is the most expensive type of wrong.

A completely broken feature is obvious. A feature that works in nine scenarios and silently corrupts the tenth can survive much longer.

The verification tax is real

DORA has used the phrase verification tax to describe part of this trade-off. Time saved during creation can return as time spent auditing and validating the result.

That does not mean AI provides no benefit. It means we should be careful about how we measure the benefit.

Imagine a developer normally spends eight hours implementing a change. With AI, the initial implementation takes three hours.

That looks like five hours saved. But then the team spends two hours reviewing generated logic, one hour fixing duplicated behaviour, another investigating a failed edge case and another correcting the tests.

Did AI save five hours, or did it move the work into another part of the process?

The answer will vary enormously between developers, tasks, models and codebases.

METR's 2025 randomized research produced one particularly surprising result: experienced open-source developers working in repositories they already knew took longer with the AI tools tested, even though they expected the tools to make them faster. Other research, including work associated with GitHub and broader AI productivity studies, has reported positive productivity and code-quality effects.

So which side is correct?

Probably both.

Different developer. Different task. Different codebase. Different model. Different amount of context. Different review process.

“Does AI make developers faster?” may simply be too broad a question.

Fast developers can generate slow teams

One developer becoming faster does not automatically make the whole delivery process faster.

Imagine a developer previously created three pull requests per week and now creates twelve. The same two people still review the code, the same QA engineer tests the release, the same security checks run and the same deployment process still exists.

You have not necessarily improved the system. You may have created a traffic jam.

This is where I think companies need to look beyond individual productivity.

A developer producing twice as much code looks productive on a dashboard. But what happens if review time increases, QA scope doubles, releases become larger, technical debt grows or nobody fully understands the new code?

The customer does not care how quickly the code was written. They experience the final product.

AI can produce code that works and is still unsafe

Security makes the discussion even more uncomfortable.

Veracode's 2025 GenAI Code Security Report found risky security flaws across a substantial portion of the AI-generated solutions it evaluated. That does not mean the same percentage of all AI-written production code is vulnerable; the research used defined security tasks and the result needs to be understood in that context.

But the finding still matters because code can function correctly and fail security expectations.

Other research comparing functional benchmark success with code quality and security analysis has also shown that passing the functional task does not necessarily prove the implementation is good.

That should sound familiar to QA engineers.

A login flow can work and still expose information. A payment request can succeed and still allow duplicate processing. An administrator endpoint can return the correct data and still return it to the wrong user.

Functionality is one layer of quality. AI does not change that.

The maintenance cost may appear much later

The first release is not the full cost of software. Somebody eventually needs to change it.

GitClear has analysed large volumes of changed code and reported increases in duplicated code alongside declining reuse and refactoring patterns during the period in which AI-assisted coding became more common.

Its methodology and conclusions have generated debate, and correlation should not automatically be treated as proof that AI caused every observed change. But the concern itself is reasonable.

AI is very good at giving you a solution. That does not always mean it understands how much similar logic already exists elsewhere in a large organisation.

Imagine asking five people to solve the same problem without allowing them to speak to each other. You may receive five working solutions.

That does not mean you wanted five implementations in the product.

This is where architecture and codebase context become increasingly important. Simple applications can be generated very quickly, but product history becomes harder to reason about as complexity grows.

AI can read a lot of code. Understanding why the code became that way is a different challenge.

Maybe QA becomes more important, not less

I obviously have some bias here, but I think there is a reasonable argument that faster code generation increases the need for stronger quality thinking.

That does not necessarily mean more people manually clicking every button. If AI can generate fifty changes, QA cannot respond by writing fifty manual happy-path test cases and asking everybody to wait.

The quality process needs to become smarter.

That can mean:

• Stronger API regression coverage
• Automated contract and schema validation
• Better observability
• Risk-based testing
• Feature flags
• Smaller releases
• Production monitoring
• Improved test data
• Exploratory testing around changed behaviour
• Clearer and better documented business rules

The QA role may move even further away from “check whether the button works” and closer to a more important question:

What should we be worried about?

That is a much more interesting quality problem.

AI should absolutely be used by QA

I do not think QA should stand on the side complaining about AI-generated code. Use the same tools.

AI can help create test ideas, compare API responses, investigate logs, generate test data, explain unfamiliar code, identify boundary values, draft automation and analyse differences between releases.

It can also help a tester understand a technical flow much faster before deciding where deeper investigation is needed.

Anthropic has shown examples of AI combined with property-based testing to find defects in major Python projects, with findings manually validated before being reported. GitHub and OpenAI are also investing heavily in AI-assisted code review and automated validation.

AI can help check AI. That is not as ridiculous as it sounds.

Compilers check human code. Static analysis checks human code. Automated tests check human code.

The important question is not whether the checker is human or AI. The important questions are independence, coverage and whether the team understands the limitations of the check.

But AI checking AI can become a circular problem

This is where I remain cautious.

Imagine one AI agent writes a feature based on an incomplete requirement. A second AI agent reviews the code and a third generates the tests.

All three receive the same documentation.

The documentation forgot to mention one business rule.

How many agents does it take before the missing requirement magically appears?

Probably more than we can afford.

This is why product knowledge matters. It is why customer feedback matters and why exploratory testing still matters.

Sometimes the defect is not that the code fails to match the specification.

Sometimes the specification itself did not understand the user.

No automated test can validate a business expectation nobody defined.

The biggest risk may be false confidence

I am less worried about obviously bad AI code because people usually notice obviously bad code.

I am more interested in software that looks finished before it has actually been understood.

A polished interface. Clean tests. Good naming. A passing build. A detailed AI-generated pull request description.

Everything looks professional, but one assumption underneath it is wrong.

Simon Willison has highlighted examples where AI-generated descriptions explained visible code details while missing the higher-level context reviewers actually needed.

That is a small example of a much larger problem.

AI can produce the shape of professional work extremely well: the structure, explanation, documentation and confidence.

Humans can mistake polish for understanding.

We do this with people too. A confident presentation often feels more trustworthy than an uncertain one.

Software does not care about confidence.

The bug works either way.

The answer is not to slow down AI

I do not think companies should respond by banning AI coding tools. The capability is moving quickly and the benefits are already obvious in many areas.

AI companies themselves are showing increasingly agent-heavy engineering workflows where agents contribute product code, tests, CI configuration, release tooling, documentation and review work.

These companies are building the technology, so their workflows are not automatically representative of an ordinary software team. But they show how far this direction can go.

The lesson I take from those examples is not let AI write everything.

The interesting part is the systems around the agents.

Guidance for long-running coding agents increasingly talks about feature lists, progress files, clear verification states and repeatable ways to understand what has been completed and what still fails.

That sounds a lot like engineering discipline.

Clear expectations. Repeatable checks. Visible state. Good context.

The better AI becomes, the less glamorous this foundation sounds and probably the more important it becomes.

AI is making software creation cheaper. Quality may become the expensive part.

This is my current view.

The cost of creating a first version of software is falling. More people can build, developers can move faster and small teams can attempt projects that previously required much larger groups.

That is genuinely exciting.

But when creation becomes easier, selection and verification become more valuable.

A camera made taking photographs easier. It did not make every photograph good. Word processors made writing easier. They did not make every article worth reading.

AI makes creating code easier.

It does not automatically decide which software should exist, how it should behave or whether users can trust it.

The bottleneck may move from Can we build this? to Did we build the right thing?

And then to:

Can we prove it works?

Faster code needs faster feedback

I do not think the teams that benefit most from AI will necessarily be the teams generating the most code.

They will probably be the teams that can learn the fastest without losing control of the product.

Generate faster. Review faster. Test smarter. Release smaller changes. Watch production. Listen to users. Feed what you learn back into the next change.

DORA's AI research places capabilities such as small batches, strong version control, internal data access and good platforms around AI adoption for a reason: AI works inside a delivery system.

Put a faster engine into a good car and you may go faster.

Put the same engine into a car with poor brakes and loose steering and you have created a different kind of performance problem.

AI is writing code faster. I think that part is already obvious.

The more important question for software teams is whether verification, testing and product judgement are improving at the same speed.

Because somebody still has to check what we are shipping.

And “the AI said it passed” is probably not the quality strategy I would bet the company on.