# The Thing That Made Me a Good Engineer Was the Thing I Had to Unlearn

_I caught an agent about to make a mistake and felt good about it, and I was wrong to feel good about it. What I was best at just got cheap, and the job that's left is the one I didn't see coming._

July 2, 2026

A few weeks ago I caught an agent about to make a mistake, felt good about it, and was wrong to feel good about it.

I was working through a plan with it. About two-thirds down the list I saw the gap: it was going to mishandle a boundary case on an input, the kind of thing that would blow up the first time the code ran against a real example. I stopped it. "You missed this one. That input will break it." It agreed, folded in the fix, and moved on. And I felt the small, specific hit of satisfaction. I caught that. If I had not been paying attention, that would have gone in wrong.

Some version of that feeling has been with me for twenty-five years, long before any agent existed. Anticipating the blind corner is the thing I was good at. I could read a design and feel where it would fail, name the case nobody else had thought through, write the spec so complete that the failure never got a chance to happen. It made me a good engineer, and later it made me a good leader, because I could look at a plan and tell you where the bodies were going to turn up. Every time I caught one, the belief hardened: without me, it stays broken.

Here is what took me a long time to admit. I was lying to myself, thinking I was saving work by catching that mistake early. That is not how these agents work. They do not one-shot it. They get it roughly right, then closer, each pass using what the last one revealed. The plan I was reading already had the agent writing tests and running that path against real inputs, and the first time it did, the boundary case I "saved" it from is exactly the kind that trips on the next run. Not every bug surfaces that way, but this kind does. I was treating an iterative experimentalist as a one-shot oracle, reacting to its first draft as if it were the final answer. So when I jumped in by hand, I was not saving the run. I was interrupting a process built to correct itself, and feeling proud of the interruption.

The thing I was good at, catching the blind corner, just got cheap. Everything that follows is one argument about that.

It did not get cheap because the machine got better than me. It got cheap for a narrower reason. The edge cases that come from a checklist, the ones I was thorough about, an agent now enumerates at least as well as I do, and it never tires of it, never skips the boring ones. The edge cases that come from knowing this system's particular scars, the history nobody wrote down, it cannot see at all. What got cheap was the thoroughness. What got expensive was the judgment. So the honest frame is not that experience is being devalued. It is repriced. The part of my experience that was really just diligence is worth less now.

So if I am not the catcher anymore, what is the job?

Build the gate. The discipline does not disappear, it moves. "Let the agent iterate and stop checking its work" is exactly the kind of advice that ships a bug. The fix is not to keep checking by hand forever. Stop being the gate. Build the gate, so you do not have to be it. The rigor I used to spend nitpicking a plan in real time goes up front now. I say once, clearly, what "valid" means in this domain, so the agent inherits it on every task, and I build the validation that runs whether or not I am watching.

Where you put the gate matters as much as building it. The inner loop is only free when failing is cheap and you can tell, fast, whether it failed. Reversible is not the same as verifiable. A financial calculation can be trivial to rerun and still take a domain expert a day to confirm is right. A concurrency bug can be cheap to undo and effectively invisible to the inner loop until it hits production load. So let the experiment run free in the reversible, verifiable inner loop, and put the gate at the boundary that is expensive or irreversible to cross. Inside, let it run. At the boundary, hold the line. The cross-team dependency that breaks something three teams away is not a thing you catch by hovering over the plan. That is exactly what the gate is for.

The gate is not something you build once and walk away from. It encodes my current understanding of what "good" means, so it can be wrong, and it can quietly rot as the system moves. The check that mattered last quarter can keep passing long after the thing it was protecting has changed shape underneath it. And an agent will happily learn to satisfy it without satisfying me, hitting the letter of the rule while the thing I actually cared about slips through. It is something you own and keep honest on purpose. The single point of failure does not disappear when you stop inspecting every change by hand. It moves to the gate, the one thing now running unwatched unless you decide to watch it.

When I look back at that moment with the boundary case, what I see is two old habits dressed up as diligence. Fear of the rework drove me to over-specify before the agent ever started, when the truth is the agent does better with a clear statement of what I actually want than with my best attempt to pre-chew every step. Pride drove me to jump in the second it wobbled. And under that pride was the thing I like least to admit. I was trying to stay relevant, and I reached for it in the one place the machine had already taken: the thoroughness, not the judgment. Both were trying to make me the gate, and being the gate, standing in the path of every change to inspect it by hand, is exactly the job that does not scale and exactly the job I should not want.

The work that is left when I stop being the gate is leadership work, and what caught me off guard is where it lives now: in the hands-on building itself, not just in running a team. It is deciding what "good" means here, building the validation that lets a team move fast without flying blind, and knowing which boundaries are the expensive ones so you guard those instead of everything.

And this is not only my story. An agent is a tireless junior engineer that iterates until the thing works but cannot tell you whether it built the right thing. Someone has to supply that, and supplying it used to be the back half of a career, the part you grew into after years of watching systems break in ways no checklist predicted. The demand for it has not gotten any smaller. It has just moved to the front. Ready or not, every engineer directing agents is being handed the judgment call before they have earned it. The gap between the judgment the job needs and the judgment you have is real, and it does not close on its own. It is the new thing to grow into, and it starts on day one.

I spent a long time proud of being the person who caught the mistake. The job now is to build the thing that catches it and keep it honest, spending the scarce judgment where no gate can reach.