The Engineer Becomes the Cross-Examiner

Software engineering is starting to look less like uninterrupted construction and more like a series of contested decisions. An agent proposes an interpretation. Another system checks it. A requirement supports one reading and a test supports another. The engineer has to decide what the words mean, which evidence counts, and whether the result has earned the right to move.

That can feel like engineering has been replaced by paperwork. It has not. The implementation work is moving into the factory, while the human work is moving toward intent, proof, and consequence. The documents matter because they define what the machinery is allowed to do. A vague acceptance rule is not administrative clutter. It is an open control surface.

Our prediction is that many engineering titles will remain long after the daily work underneath them changes. People who built their value around producing code will feel that shift first. People who can turn an ambiguous goal into a claim that can be tested, challenged, and enforced will gain leverage. The keyboard is getting cheaper. Judgment that survives argument is not.

An agent can produce a polished answer to the wrong question with astonishing efficiency. That is why a task cannot be just a request to build something. It needs a case: the behavior being claimed, the evidence required, the boundaries that must remain true, and the authority that will decide when those pieces conflict.

This is not a demand for longer tickets. Length is a poor substitute for precision. A useful specification names observable outcomes and the conditions under which they must hold. A useful test connects directly to one of those outcomes. A useful review identifies a mismatch that changes the release decision. Everything else risks becoming ceremony that agents learn to satisfy without protecting the product.

The engineer's job is to cross-examine the chain. What does this requirement actually commit us to? Which check proves that commitment? Who can change the check? What happens when two pieces of evidence disagree? If those questions have no mechanical answer, the factory is running on persuasion. The most confident agent wins, and confidence is not authority.

Agent-run work creates more disagreements, not fewer. One agent flags a defect. Another argues that the behavior is allowed. A policy blocks the submission. A reviewer asks for evidence the builder never collected. The wrong response is to keep the debate alive until every participant agrees. A factory needs a defined way to end the argument.

Some disagreements should resolve through deterministic proof: a schema, a contract test, a reproduced failure, or a policy check. Others need a named human authority because the answer depends on product intent or acceptable risk. The important part is that the route exists before the conflict arrives. Otherwise every exception becomes a meeting and every meeting becomes hidden production infrastructure.

A healthy escalation also writes back. If the same semantic fight appears twice, sharpen the specification. If a gate repeatedly rejects valid work, change the gate. If agents can route around a decision by rephrasing the claim, move the boundary closer to the consequence. Debate is useful while the factory is learning. Repeated debate is evidence that the factory refused to learn.

The danger in this shift is obvious: teams can generate an enormous legal-looking record and mistake it for control. More analysis, more scoring language, and more approvals do not automatically produce better software. If the record cannot stop a bad release, route an uncertain change, or alter the next run, it is commentary around the machine.

Treat every important document as an interface. Give it an owner, a consumer, and a consequence. Requirements should feed acceptance checks. Risk decisions should change permissions or review depth. Bug reports should create reproducible evidence. Production findings should update the rules the next agent encounters. The document earns its place by changing execution.

This is where software factories outperform coordination-heavy teams. Once a judgment becomes an executable rule, it applies at machine speed and survives the person who first argued for it. The factory does not forget the standard during a deadline, lose it in a channel, or reinterpret it because a different reviewer showed up. Human judgment sets the precedent. Machinery makes the precedent real.

Agents do not remove responsibility from engineering. They expose where it was hiding. When a person wrote and shipped the code, authorship, interpretation, and accountability were bundled together. As agents split those activities apart, the factory has to say who owns the requirement, who judges the evidence, who accepts the risk, and who can stop the line.

That will eliminate work and jobs built around moving information, producing routine implementation, and manually checking rules a machine can enforce. It will also make the remaining human role more demanding. You will need to read closely, notice contradictions, state a position, and own what happens when the system follows it. Being present is not enough. Your judgment has to change the machinery.

The engineer of the software-factory era is not a ceremonial approver standing beside an autonomous system. The engineer defines what must be true, challenges the evidence, and turns each durable decision into a control the factory can carry forward. Code was never the final product. Reliable consequences were. Now the job is being forced to admit it.