Own the Loop

I don't think AI makes the engineer unnecessary. I believe it makes a much bigger job available to us, and we get into trouble when our idea of engineering stays smaller than the work we can now own.

The change for me hasn't been typing code faster. It's looking at ideas or product problems that once felt too large, too slow, or outside my scope, and realising I can just attempt them now.

The job just got bigger.

For years, this was the whole job: implementation. Building the thing.
Around it, coordination: sequencing the work and the people.
Then evaluation: actually judging whether what comes out is any good.
Then the product calls: deciding what we're building in the first place and what comes next.
And the outcome: owning whether it actually solves the problem.

So the job didn't shrink. It grew, and the opportunity is to operate across all of it.

You've all seen versions of these five. So be honest with yourself: where does most of your time still go today? For most of us, it's still right down here, in implementation. That's the gap I want to talk about.

The loop was always there, long before AI.
At the centre, the implementation loop: this is where we build, test, fix.
That sits inside an engineering loop: you design it, hand it off, review what comes back.
And that sits inside a product loop: decide, ship, measure. Each one takes its direction from the loop outside it.

None of this is new. AI didn't invent any of it.

At every level, part of this can now be handed to AI, and the deeper in you go, the more of it. The whole inner loop (build, test, fix) is becoming AI's. But the outer calls (what to build, what to ship, how to delegate) are still yours.

Let's focus on one such loop. You don't have to do every step yourself.

You own the objective.
You decide what to delegate to AI.
You own the evidence that it worked.
And you decide when a human steps in.

That's what it means to own the loop.

Engineer A refuses to delegate anything: hand-owns every line, never moves up the loop. Engineer B delegates everything, including judgement. Both are avoiding the new responsibility. The real move is in between: understand it deeply enough to delegate it, and still own the outcome. That's why the engineer who understands the loop doesn't get fired.

Six ways to get left behind:

Stay buried in implementation, never move up.
Delegate work you can't evaluate.
Let the agent set its own permissions. That's the blast radius nobody's watching.
Confuse output with evidence: “it ran” is not “it worked.”
Measure activity instead of outcomes: lines of code written, PRs opened, tokens spent; none of that means the problem got solved.
Protect the old job instead of expanding what you can own.

A while back I caught my agent reaching for data it shouldn't touch in production. My first fix was a Claude Code rule pinned to that path. It worked, until long sessions, where conflicting instructions made it forget. So I moved the agent into a container and blocked those calls at the network. I don't want everything deterministic. Lock it all down and you lose the point. Most of the time I just guide the behaviour; what changes that is how hard the damage is to reverse.

Code gets easier. But judgement gets scarcer. And confidence has to be earned, not assumed.

Understanding of the inner loops. You still have to know how the thing works.
Judgement at the outer loops. What's worth doing, and whether it's any good.
Responsibility across all of them. The outcome is still yours.

The engineer doesn't disappear. They get more valuable, because they understand the work deeply enough to delegate it, evaluate it, and own a bigger outcome.

This is bigger than developer productivity. The same shift is reaching research, product, operations, decision-making. Once systems can act, observe and improve, knowledge work itself starts to reorganise.

Code is getting easier, but easier isn't doing less. The radical part isn't doing less; it's being able to own more. So I'll leave you with one question: how much more are you willing and able to own?

1 /