For most of my career the question was how do I build this.
Now the question is how do I design a system that builds this reliably, with verification, without me in the loop.
That is not a small shift. It changes what I spend my days doing, what I'm good for, and what I'm on the hook for when something breaks.
The job used to be shipping features
Ship a feature. Review a PR. Debug a production issue. Linear work. A ticket opens, you do the thing, the ticket closes.
That was most of my job for a long time and I liked it. The feedback loop was tight. You could see the thing you built running in production. You knew what you owned.
Agents broke that. Not all at once. Slowly, over the last couple of years, until I looked up and realized most of my day wasn't writing code anymore. It was writing specs, scoping boundaries, defining what "done" means precisely enough that an agent could execute against it, and building the verification layers that catch the places where it won't.
The unit of work changed. I don't ship features now. I ship loops.
What a loop actually is
A loop is a closed system that takes a goal in and produces a verified outcome out, without a human sitting in the middle of every step.
Spec. Plan. Execute. Verify. Feed back.
Writing that down makes it sound like a framework someone invented for a conference talk. It isn't. It's what the work actually looks like now when you stop and watch yourself do it. The parts of the job that used to be implicit, the "I'll just look at it and know if it's right," have to become explicit because something other than me is producing the output.
The plan step is where I decide scope and shape. The execute step is mostly the agent. The verify step is where most teams fail, and where most of my real time goes now.
Verification is the whole game
At Fast Protocol, the verification problem is hard in a way that clarifies the point.
When a user swaps on the DEX, the settlement involves MEV capture and return. The math has to be right. If an agent writes code that miscalculates the user's share of the returned MEV by half a basis point, nobody notices in testing. They notice three weeks later when the numbers don't reconcile and a user who made a large swap realizes they got less than they were owed.
You can't ship an agent's guess on that. You can't even ship an agent's careful work on that without a verification layer that proves the settlement math matches the protocol specification across every path the swap can take.
So the verification layer isn't a test suite. It's a parallel implementation that independently computes what the answer should be, and fails loudly when the two disagree. It's property-based tests that fuzz the edge cases the agent would never think to try. It's post-deployment monitoring that watches settlements in production and alarms on anomalies the pre-deployment checks missed.
Building that verification layer is now 40% of my job. Not writing it. Designing what it has to prove, which invariants matter, which failures are catastrophic versus recoverable, which checks go pre-deploy versus post-deploy. The agent can implement it. I have to decide what it's implementing.
That decision is the work. That's architecture. That's taste. Both are now the bottleneck.
Closer to founder than manager
The instinct is to call this engineering management. It isn't. A manager owns a team and a roadmap. This role owns a closed system and its outcomes.
It's closer to what running Elements Software was, actually. When I was bootstrapping that company I owned every decision that mattered, from what we built to how we shipped it to whether customers would pay for it. I made the decisions. Other people (or in that case, me wearing other hats) did the execution.
The modern version is the same shape with different execution. I make the decisions about what the system has to do, what correctness means, what boundaries it runs inside. Agents do a large portion of the execution. Human engineers on the team handle the parts agents can't, and own the parts where human judgment is the product.
The hard part isn't the agents. The hard part is that the decisions I'm making now are bigger than the decisions I used to make, and I'm making more of them per day, and I don't get to punt by saying "I'll figure it out when I'm writing the code." There's no writing the code phase anymore where the details resolve themselves. The details have to be resolved in the spec. In the architecture. In the verification strategy. Before the agent starts.
That pressure compresses taste and architecture into the same job. They used to be different skills you could develop separately. Now they're the same skill applied at different altitudes.
What this means for what you're good for
If you're an engineering leader and you're still evaluating yourself on "how much did I ship this week," you're measuring the wrong thing. Shipping is cheap now. Designing something that ships correctly, at speed, without human review of every line, is not.
The uncomfortable version of this is that your value is now entirely in the parts of the work agents can't do. Judgment calls that require context agents don't have. Taste about what good looks like. Architecture decisions that ripple through a system in ways a short-horizon agent won't predict. The questions nobody thought to ask.
If any of those feel weak to you, now is the time to notice. Nobody's going to pay a premium for a leader who's fast at prompting. They'll pay a premium for a leader whose systems run reliably, whose verification catches what matters, whose architectural bets pay off two years out. That's what's left when agents handle the rest.
The takeaway
You're not managing engineers anymore. Not primarily. You're designing the system the engineers, human and otherwise, execute inside.
That system either works or it doesn't. Your architecture, your verification, your judgment about what matters. Those are the load-bearing decisions now. Everything else is execution, and execution is increasingly not the bottleneck.
Decide what the loop has to prove. Decide where it can fail safely and where it can't. Decide what verification looks like before you write a line of code.
Then let the loop run.