Writing Code Got Cheap. Checking It Didn't.
- AI agents have made code production faster, but someone still has to check the result.
- A JetBrains survey reported that 90 percent of professional developers used AI agents weekly.
- I check rendered pages and server behavior against real project conditions.
- A second model from a different maker can spot problems the first one misses.
- Put the review process and a human decision-maker alongside the agents.
AI has changed which part of software work takes the effort. Producing code is getting cheaper. Checking whether it does the right thing is still hard, and that is where I would put more of the budget.
The tools have moved beyond one person asking a model for a snippet. An agent can plan work, send pieces to other agents and return the results for review. The person still has to decide whether those results are fit to use.
I have built for the web since 1994. In my consulting work, I see the gap between code that looks plausible and a result that works for the project. The check has to happen where the work will be used.
The takeaway
Spend less effort producing code and more effort testing the result against real conditions, with an independent review and a person responsible for the decision.
Why has checking become the expensive part?
Software from AI coding tools can arrive faster than people can check how it behaves. In a JetBrains survey released August 18, 2026, 39 percent of professional developers worldwide said they had used Claude Code between May and July 2026; 90 percent reported using AI agents weekly. These numbers measure adoption, not the correctness of the software produced. The survey details are available from JetBrains Research.
The gap matters because code can appear complete while failing in the setting it was meant for. Reading it can help, but it does not show what a visitor will see or whether a server keeps responding under repeated requests. A review that stops at the code leaves those results untested.
That changes where the work sits. If an agent produces the first version quickly, a person still needs time and a reliable way to assess it. The labor has shifted toward choosing checks that reveal failure, interpreting what they show and deciding what to do next.
What can coding agents do now?
Cursor released Projects on September 10, 2026. Its coordinator agent plans tasks, assigns them to other agents and returns their work for a person to review. The coordinator itself does not write code. OpenAI also announced its Agents API that day, a managed service for running the same Codex agent setup on OpenAI's servers. Details on both releases are in Cursor's changelog and OpenAI's announcement.
These tools change the shape of the work. A person can assign a plan and have agents carry out pieces of it, while another step gathers the work for review. The number of code-producing steps can grow without making the final decision automatic.
That can make an unchecked result travel farther before anyone notices a problem. If one agent's output becomes another agent's input, review needs to cover the combined result, not only each handoff. Before an agent touches production, I would define what it is allowed to change and how the result will be judged.
How do I check whether the work is right?
I check the result in the setting where it has to work. In my own work, that means a page rendered for a real project or a server hit repeatedly to see it hold. Those checks expose behavior that a code review alone cannot confirm.
A rendered page lets me inspect what the work actually produces for the project. Repeated server requests let me see whether it continues to respond. The specific check depends on the work; the point is to test what people will experience, rather than treating plausible-looking code as proof.
I also ask a second model from a different maker to review the work. It can catch what the first model is blind to. That review adds another view, but it does not establish that the result works in its intended setting. The models can help inspect the work; a human still owns the decision to accept it.
Where should the budget go?
Put time and money into checks that can reject bad work before it is relied on. That means testing with real project data, arranging a review from a different model and assigning a person to make the acceptance decision. The first two steps produce evidence. The person weighs that evidence and takes responsibility for the choice.
The split should follow the risk of the change. A result that affects a live page or server deserves a check in that environment, not a quick look at code alone. Decide what evidence would count as success before the agent starts, so review has a standard to apply instead of relying on confidence after the work is done.
A second model should come from a different maker because a second pass from the same model can share the first model's blind spots. I use multiple models as part of a review process, not as a vote that makes a result correct.
Common questions
Does a second AI review prove the code works?
No. A second model can find issues the first one misses, but the review is still another model's assessment. Test the result in the setting where it will be used, then have a person decide whether the evidence is enough to accept it.
What should I define before giving an agent work?
Write down what the agent may change and what result would count as acceptable. That gives the reviewer a boundary and a standard. For a production task, decide how you will test the result before the agent touches production.
Who should make the final decision?
A person should own acceptance, because the agents produce and review work without taking responsibility for whether it is fit for the project. The person making the decision needs to see the test result and the review, and be able to reject the work.
Sources
If you want to build an agent workflow with checks that fit your work, contact me.