The more work AI creates, the less valuable it is to merely produce work. The scarce skill is knowing what deserves your name.
There is a comforting rule in software teams: someone should review the code before it ships.
The rule has always been imperfect. Reviewers miss things. Senior engineers skim. Pull requests get large. Deadlines make people optimistic.
But it expressed an important idea: somebody who understands the system should be able to see what changed and decide whether the change is safe enough.
Agent-written code puts pressure on the practical part of that rule.
An agent can produce a change faster than a person can read it carefully. Give it a large task, a repository, and enough time, and the output may include new files, changed dependencies, altered tests, configuration changes, and a plausible explanation of why it all works.
The obvious response is to insist that humans read every line anyway.
That preserves the rule. It also removes much of the speed advantage that made the agent attractive.
The opposite response is worse: the agent ran the tests, the diff looks tidy, ship it.
Neither is enough.
The question is not whether humans should read code.
The question is what human understanding is still necessary, and what the system should prove without asking a person to inspect every character.
Reading code is not the same as being accountable
Line-by-line review is one way to create confidence. It is not the only way.
In many cases, the more important question is whether the team can explain:
- what the change was meant to do;
- what it was not allowed to change;
- how the important behaviour was tested;
- what would reveal a failure;
- how the change can be undone;
- and who will respond if it goes wrong.
That is accountability.
A human can read every line of a small change and still miss that the requirement was wrong. A team can have a green test suite and still be testing the wrong behaviour. A code review can approve a clean implementation of a bad product decision.
This is why the agent question is not only a code question. It is a question about the quality system around the code.
If the system has no clear requirement, no meaningful test, no permission boundary, and no way to observe failure, asking a senior engineer to read more carefully is not a control. It is hope wearing a process label.
The harness becomes the review system
The word "harness" sounds technical. The idea is simple.
It is everything around the agent that makes a bad change harder to ship.
For code, that usually includes:
- a clear task and acceptance criteria;
- architecture rules and boundaries the agent should not cross;
- tests that would fail if the important behaviour broke;
- security, type, formatting, and dependency checks;
- limits on the files, systems, and actions the agent can touch;
- an independent check for the most important claims;
- a record of what changed and what checks ran;
- and a way to roll back when reality disagrees with the test suite.
None of this is novel. Good engineering teams have always used versions of it.
What changes with agents is the pressure to make these things explicit. When humans write most of the code, a lot of system knowledge lives in conversation, habit, and the fact that the person making the change has spent years being corrected by other people.
Agents do not have that apprenticeship. They need the constraints to be visible.
The harness is not a replacement for engineering judgment. It is the way engineering judgment becomes operational at a speed where no person can hold every detail in their head.
Tests are only as good as the question they answer
There is a predictable overreaction to this argument: write more tests.
More tests can help. They can also create a false sense of safety.
Tests are not a magic spell. They prove that the system behaved in the ways the test anticipated. They do not prove that the team anticipated the right failures, represented the customer correctly, or kept the change within the right product and architectural boundaries.
An agent can write a test that passes because the agent also changed the behaviour the test was supposed to protect. It can test an implementation detail rather than the promise made to the user. It can make the suite green while quietly making the system harder to understand, slower to operate, or more expensive to change.
So the review system needs different kinds of checks.
Some checks are deterministic: the types pass, the security scanner finds nothing known, the user flow still works, the performance budget holds, the deployment can be rolled back.
Some checks need an independent perspective: a separate reviewer, a different model, a test based on a real example, or a comparison against the previous behaviour.
Some checks are irreducibly human: is this the right problem, does the experience make sense, are we comfortable with the risk, and can this team live with the system after the agent leaves the room?
The important distinction is not human versus machine.
It is whether the check is independent enough to catch the thing that made the first attempt wrong.
Code review becomes more selective, not less serious
This does not mean code review disappears.
It means code review becomes a more deliberate use of expensive attention.
People should read the changes that establish a new pattern, cross an important boundary, alter security or permissions, change a data model, introduce a dependency, affect a customer experience, or create a system the team will have to maintain for years.
They should also read changes when the harness cannot give a credible answer.
That is different from treating every generated diff as an essay to be marked by hand.
The goal is not to eliminate human review. The goal is to reserve human attention for the places where it adds something tests and automated checks cannot.
There is a useful test here:
If a senior engineer had to understand this later, what would they need to know that is not captured by the code, the tests, and the trace?
If the answer is "almost everything," the team has a cognitive-debt problem. The system may run today, but it is becoming hard to change safely.
Accountability has an owner
The most dangerous sentence in an agentic workflow is: "the agent did it."
The agent did not choose the task. It did not decide the acceptable risk. It did not set its own permissions. It did not choose whether a passing test was enough to deploy.
Those were human decisions, even if they were made casually.
Someone owns the product outcome. Someone owns the technical boundary. Someone owns the decision to let the agent act. Those responsibilities can sit with different people. They cannot sit nowhere.
This is the version of AI governance that matters in practice. Not a large committee reviewing every tool. A clear answer to four questions:
- What was the system allowed to do?
- What was it required to prove before acting?
- Where would a failure be caught?
- Who responds when it is not?
If a team can answer those questions, it may be able to move quickly without becoming careless.
If it cannot, more manual review will only hide the problem for a little longer.
The future of code review is not blind trust in agents.
It is a stronger harness, more honest boundaries, and people who still understand enough to own the consequences.