When good engineering becomes hard to see

There is a peculiar difficulty in recognizing work whose result is that something did not happen. A service was not built, a dependency was not introduced, a team did not spend the next six months maintaining an abstraction that seemed reasonable on a Tuesday. The consequences can be substantial, but the evidence is slight. There is no artifact corresponding to the trouble avoided, and the person who avoided it may have little to show beyond a conversation in which the plan changed.

Engineering has always depended on this kind of work. It is part of what we mean when we say someone is senior: not merely that they can implement a difficult thing, but that they can see enough of its consequences to judge whether it should be implemented at all. We have never been especially good at accounting for that contribution. For a long time, though, it was bundled with enough visible production that we could recognize the person's value without having to distinguish its sources very carefully.

Agents are making that distinction harder to avoid.

On teams using them seriously, an implementation can arrive faster than the team can develop a considered view of it. An engineer asks for a service, receives something coherent and well-tested, and then realizes that the requirement belonged in an existing service rather than a new one. The generated code may be perfectly competent. What it cannot establish by being competent is whether the additional service is worth owning. An afternoon's implementation can create years of maintenance, and neither the speed of its arrival nor the tests it passes resolve that question.

As implementation becomes less expensive, more of the work comes to rest on decisions of this kind. Someone has to understand what was requested, what was produced, and how both relate to the system the team will still be responsible for next year. Senior engineers have always done this; what changes is how much of their day it occupies, and how much other activity now waits on it. A team can produce substantially more code without becoming proportionately better able to decide what to accept.

This creates a widening distance between the work people do and the evidence organizations use to recognize it. An engineer may spend a productive week reviewing, redirecting, and preventing commitments that would have been expensive to unwind, then struggle to describe that week in the familiar language of delivery. The implementation that survived is visible, but alternatives that made it good by being refused are not. Where advancement and recognition remain closely tied to personal output, a larger share of the engineer's contribution becomes difficult to explain.

The old accounting reads a day of good judgment as an empty day.

That mismatch has practical consequences beyond the performance review. If engineers still need a full slate of implementation work to demonstrate that they are contributing, judgment gets fitted around it. Review becomes something to catch up on; architectural questions become interruptions; decisions that would have been inexpensive before implementation become a queue of finished work awaiting approval. The organization rewards people for adding to the queue while asking them to clear it in the time left over.

Some of the disappointment around agents may be easier to understand in those terms. The team has acquired a real capability, yet the experience of work has become more congested. There is more to read, more to reconcile, and more that appears nearly finished but still needs someone to take responsibility for it. The gain in production is visible immediately. The need to organize differently around it is less obvious, particularly when the people absorbing that need have always been relied upon to make the system work.

A useful response begins by treating judgment as planned work rather than incidental overhead. Review is the work, not a tax on the work, when deciding what to accept is what limits the team's progress. That means leaving experienced engineers time to shape requests before they become implementations, budgeting attention for the decisions a project will require, and recognizing that preventing an unnecessary commitment can be as consequential as delivering a necessary one.

It does not mean making senior engineers the approval desk for everything. Their judgment is valuable partly because it can change the conditions under which other people work: a clearer boundary, a well-chosen example, a test that captures a previously tacit requirement. These allow good decisions to happen without repeatedly summoning the same person. A team that depends on continuous senior intervention has not fully benefited from senior judgment, however carefully that intervention is scheduled.

Recognizing this work requires more care than replacing one output metric with another. Counting rejections would reward obstruction just as readily as counting code rewards volume. What matters is whether a decision made the team's subsequent work better: whether a boundary reduced confusion, an early question prevented rework, or a simpler design left people able to proceed without asking permission at every turn. Those consequences can be discussed and documented, even if they cannot be reduced to a convenient number.

The underlying contribution is familiar. Engineers have been making it for a long time, often alongside the implementation work through which it received its credit. As agents change that balance, organizations will need to become more deliberate about seeing what was there all along.

The service that never needed to exist will not appear in a release note. Recognizing the engineer who understood that is becoming a more important part of knowing whether the team had a good week.