The full-loop engineer: what comes after full-stack

As loop engineering gives engineers time back from writing code, full-loop engineering answers what that time is for: carrying work from problem to outcome and back again.

A couple of months ago, I made it through the first paragraph of Addy Osmani's article “Loop Engineering” before I got annoyed.

He opened with this:

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

The idea is incredibly useful. You build a system that finds work, hands it to agents, checks the result, records what happened and goes around again. I do versions of this myself every day. There is real craft in a coding loop that runs without a human holding its hand.

It was one word that annoyed me.

Loop.

Getting annoyed at a single word in an otherwise excellent article was the most engineer thing I’d done all week. Anyway.

It’s talking about a coding loop.

And solving that problem is good and important. Over the next year or so, I expect engineers to spend much less time writing code and supervising agents. The inner loop will become faster and more autonomous.

Then what? Where do we spend the time we get back?

We could produce more tickets, pull requests and software nobody asked for. Somebody is already preparing the dashboard, a vendor is working out how much to charge you for it. Per seat. Per month.

Or, here’s an idea, we could spend that time deciding whether our work actually fucking helps anyone.

This was always the answer. But code was expensive to produce and measurable, so it consumed the job. Pull requests merged. Everyone got their productivity sticker. Engineers got a pat on the back, managers got promoted and executives got their bonuses.

For twenty years I have watched us draw a box around writing code and call it engineering. Then we act surprised when the excellent software we create is valuable to no one.

A coding loop can run perfectly inside a broken value chain. Give it the wrong problem and it solves the wrong problem faster. Stop at passing tests and it may never discover that customers ignored the result.

Coding is one part of the loop. It is not the loop. The loop is not the code. The loop is the value chain.

To be fair to Addy, he returned with “Own the Outer Loop”, keeping quality, the final verdict and answerability with engineers. I agree. But the loop I am talking about starts before there is a task and continues after the pull request goes green.

It starts with an uncertain problem, runs through a trustworthy implementation, asks whether it worked and feeds the evidence into the next turn.

The loop is the value chain

Often, our end-to-end loops look something like this:

Define a problem → Define a solution → Slice that problem up → Defining the slice → Code it → Code quality → QA → Security / stability → Did it work? → Define problem ….

It is not nine equal boxes. It is definitely not waterfall wearing a circular hat and hoping nobody notices. It’s not even SAFe.

Before code, someone has to understand the problem, choose a solution, find the smallest useful slice and define its intent, risks and evidence.

A customer says something, sales paraphrases it, product turns it into acceptance criteria, and engineering receives a specification handed down on a stone Jira ticket.

Then we build something trustworthy. Coding matters. So does code quality, QA, security and stability. Those are not four genies you summon before release by rubbing the Buildkite lamp. They shape the work and force us to prove it will not set fire to production.

We run a retro on the sprint, talk about how Jessica took all the fun cards and John turned every stand up into a seminar on why we should be using functional programming.

Then comes the question teams forget.

Did it work?

Not “did it hit production?” Did it solve the problem? What changed for the customer? What should that evidence change next?

Shipping closes a sprint. It does not close the loop.

AI can work almost anywhere inside the loop. Good. Let it. But it cannot own the thread connecting those decisions. It does not get embarrassed when we build the wrong thing. We do.

Coding looked like the whole job because it was visible: tickets, commits, pull requests, deployments. Problem framing, avoided risk and uncomfortable evidence hid in meetings.

We made one part of the loop visible and gave it the name "engineering".

Six months of excellent engineering. Hardly anyone used it.

I once joined a company as a team was about to launch something it had spent six months building.

The engineering was genuinely difficult. The product served millions of users and hundreds of millions of page views every day. The team built something that survived that scale. They had every right to be proud of it.

It launched.

Hardly anyone used it.

The result barely registered on any metric the business or its customers cared about. Roughly 99.99 percent of the user base carried on as if those six months had never happened.

Both things are true. The engineering accomplishment was real. The outcome was almost meaningless.

That does not make the engineers incompetent. It makes me ask what allowed six months of excellent work to continue without enough evidence that the result would matter. What problem were we solving? What smaller slice might have exposed weak demand sooner?

At some point, “what the fuck are we doing?” is not cynicism. It is the most important engineering question in the room.

Coding, code quality, QA and stability can all succeed while the value chain fails. You can build a magnificent bridge to a place nobody wants to visit.

Engineering used to throw software over the wall to Operations: “We built it. Now you host it.” We worked out that was terrible. So naturally, we kept the wall and moved it.

Now we tell Product Managers: “We built what you asked for. Your turn. Find out whether it worked.”

AI might have turned those six months into six weeks. Brilliant. We could have arrived at irrelevance before the end of the quarter instead of the year.

Despite how proud those engineers were, and should have been, was it meaningful work?

AI is not going to solve that problem.

Shock horror: you have to talk to PMs and customers

You can't understand a customer problem from an acceptance criterion.

A Jira ticket is a fossil. I don’t just mean the software should have gone the way of the dinosaurs. I mean it only proves a conversation happened, but most of its useful tissue disappeared before it reached you. After customer, sales, product, design and refinement, the engineer reconstructs a living problem from three bullets and a Figma link.

That interface has to change.

The PM and engineer should shape the problem, solution and slice together. The PM brings customer and strategic context. The engineer brings system knowledge and an instinct for where reality will punch the plan in the mouth. Neither should use the other as an API.

Senior engineers need contact with customer reality every week: a conversation, support tickets, metrics, session recordings, sales calls or an incident review. Not every engineer on every call. Just something more alive than Linear.

Talking to customers doesn't mean promising features because somebody sounded annoyed and you got scared (I’ve been there). It means observing, asking better questions and carrying what you learned into the build.

Regulated products need guardrails. Fine. “Engineers never meet customers” is still an organisational defect not a line in your ISO 27001 audit.

AI makes this more important, not less. When implementation is expensive, a bad problem model wastes months, sure. When it gets cheap, we produce the wrong shit at industrial speed. A cow with a mechanical rectum.

If you never meet the person with the problem, you are not owning the loop. You are owning a ticket.

The PM is not the customer. The ticket is not the problem.

No, this does not make every engineer a one-person product department

There are two objections to this idea I want to cover off. The first comes from engineers: “So I keep the coding workload, but add discovery, customers, product decisions, QA, security, operations and analytics? Please quietly fuck off.”

Fair.

If full-loop means the same sprint commitments plus fitting several more jobs into the narrow gap between stand-up and burnout, it is a terrible idea. Engineers should not replace every specialist or work a second shift around the code.

I expect less time spent writing code and supervising agents. The work around the code should occupy that released time. It should not come with increased coding targets like a consultant announcing “efficiency” five minutes before the redundancies.

The second comes from PMs: “If engineers define problems, talk to customers and inspect outcomes, what the hell is left for me?”

Quite a lot.

PMs bring skills most engineers don't have: strategy, research, market context and hearing five contradictory customer requests without promising all of them by Friday. I don't think PMs are going away.

The relationship changes from handoff to partnership. Engineers stop waiting for a finished brief. PMs stop routing tickets. They shape the problem and evidence together.

The PM is not being replaced. The handoff is.

Specialists own parts. Engineers keep sight of consequences rather than becoming mediocre versions of everyone else.

You can't ask engineers to own a loop you keep them out of

This part is for leaders who tell engineers to “show more ownership” while excluding them from discovery, customer contact, business context, early decisions and outcome data.

What exactly would you like them to own?

You have put them in the engine room, welded the door shut and then told them off for not commenting on the destination. Once a quarter, someone shouts the strategy down a pipe and calls it “an alignment session”.

full-loop work requires access. Engineers need customer evidence, the reasoning behind priorities, production signals, cross-functional collaborators and permission to challenge a bet when the evidence changes. Autonomy still needs boundaries, but those boundaries should be explicit constraints, not a pre-decided solution with “use your judgement” stapled to the bottom.

The engineers in that six-month build from earlier might not have failed at ownership. They may never have been given enough of the loop to own. The organisation allowed technical excellence to proceed without a tight enough connection to customer outcome.

Leadership owns every decision until it fails, at which point engineering apparently owned it all along.

You can't ask engineers to own a loop you keep them out of.

The valuable work leaves terrible GitHub statistics

Code is legible. Judgement is often invisible.

“I stopped us building the wrong thing” produces no impressive diff. Neither does narrowing a risky slice, changing the solution after a customer call, preventing an incident or killing a project before it becomes a six-month monument to sunk cost.

This is inconvenient if your management system thinks engineering value should look like a GitHub contribution graph. Green squares are a Fitbit for people with mechanical keyboards. They tell you activity happened. They don't tell you whether any of it mattered to anyone other than you.

The market is already signalling the shift. Anthropic describes human work as the judgement layer. Canva asks senior engineers to set technical direction, not merely execute against a brief. The valuable engineer is increasingly the person who can make a good call when the ticket runs out.

Carrying the full-loop takes four muscles.

Craft is building things well and understanding how they work. AI does not remove the need to recognise technically impressive nonsense.

Judgement is deciding when there is no best answer, including when a sound solution is still the wrong thing to build.

Agency is acting without waiting for somebody to decide that uncertainty into an acceptance criterion. Ask the question. Find the evidence. Start the awkward conversation.

Ownership is responsibility for the problem, not merely the requested solution. It holds through delivery, evidence and what happens next.

These are not four kanban cards. You do not complete Judgement on Wednesday and move Agency to Done. 

Craft verifies. Judgement carries trade-offs. Agency crosses gaps. Ownership stops the work ending at “merged”.

It’s hard to make that work visible without turning it into theatre. Keep short problem briefs. Record consequential decisions. Write down the evidence that changed the plan. Review outcomes against the problem you started with.

Show the disaster that did not happen. Write the record before you need it.

What do we do with the time?

I'm still annoyed by the first paragraph.

The boundary still bothers me because we spent decades mistaking writing code for the whole job. We built incentives around the part we could count. Then we wondered why engineers waited for tickets, PMs became human message queues and excellent software landed with the impact of the damp sock you dropped when hanging out your washing.

Now the options are moving.

We can fill the released time with more code, more queues and better dashboards. We are completely capable of using powerful technology to automate the least useful version of our current behaviour. We have form.

Or we can spend it understanding the problem, working with customers and PMs, building responsibly and finding out whether it helped.

Loop engineering improves the inner loop. full-loop engineering answers what engineers do with the time it gives back.

For once, we might get to spend engineering time on the thing that actually fucking matters: helping people.

Please, be a full-loop engineer.