The Outer Loop Is Still Run by Hand

Last month a PM I work with watched a coding agent rebuild a settings flow her team had deliberately split in two. The agent had the whole codebase. It saw the duplication, decided it was a mistake, and merged the two paths back together. Clean diff, passing tests, and it quietly broke the one enterprise customer who needed those paths separate for an audit requirement nobody had written down in the repo.

The code was never the problem. The agent read the code fine. What it could not read was the reason the code existed.

There is a lot of good writing right now about making agents better at the inner loop. Andrew Ng framed it well in June: building software runs as nested loops at different speeds. There is the agentic coding loop, seconds to minutes, run by the agent. There is the developer feedback loop, minutes to hours, run by you. And there is the external feedback loop, hours to weeks, run by the world. Most of the tooling and most of the excitement lives in the first loop. Context engineering, loop engineering, spec-driven development, evals in CI. All of it sharpens how the agent writes, runs, and checks code.

The outer loop is the one still run by hand.

What the outer loop actually is

The external feedback loop is the product loop. A customer hits a problem on a call. A support ticket names it a different way. Someone in sales flags the revenue at risk. A PM reads three of those threads, checks who is affected, decides a problem is worth solving, and writes it down. The team builds. The world responds, and that response becomes the next signal.

That loop has always existed. What changed is the speed of everything downstream of it. When code was expensive, the outer loop had time to be sloppy, because the inner loop took weeks and absorbed the slack. Now the inner loop takes minutes, and the slack is gone. A vague decision reaches a coding agent in an afternoon, and the agent turns vagueness into a confident, plausible, generic feature faster than anyone can review it.

So the bottleneck moved. It is no longer typing the code. It is stating, precisely, what to build and why, and keeping that reasoning attached to the work as it moves.

The context the codebase does not hold

Gregory Muryn-Mukha made a version of this point in UX Collective recently. His agent had full access to the codebase, and that access was not the problem. The gap was a different shape of knowledge: what the product is, and why. His estimate was that code carries maybe forty percent of what matters and the rest lives in design files, in decisions, in things nobody encoded.

His fix was to hand-write that context into a skill file the agent could load. That works, and it is a good habit. It also has a shelf life. A hand-written context file is a snapshot taken on the day someone had time to write it. The reasons behind a product keep moving. You talk to ten more customers, one segment grows, a constraint that mattered stops mattering, and the file that was accurate in April is subtly wrong by July. Nobody notices until an agent builds on the stale part.

Code context can be regenerated from the repo. Product context cannot, because its source is not in the repo. Its source is the pile of calls, tickets, and decisions that never made it into a file.

What actually helps

The teams shipping real work with agents are not the ones with the best prompts. They are the ones who can say what they want before they start, and who keep the "why" traveling with the work.

Three things make the difference, with or without any tool:

Write the origin, not just the task. A ticket that says "split the settings flow" is an instruction. A ticket that says "split the settings flow because enterprise audit requires a separate path, flagged by two accounts worth this much" is context. The agent uses the second one and skips the merge that breaks the audit.

Define done before you generate. The stop condition is a product decision, not a technical one. Acceptance criteria and success metrics are what turn a vibe into something an agent can be checked against. Paweł Huryn put it plainly in his loop writing: a loop is only as good as the thing that tells it to stop.

Keep the reasoning linked to its source. When a PM can trace a spec back to the exact customer sentence that motivated it, the review is fast and the agent handoff is grounded. When the reasoning lives only in someone's memory, every handoff loses a little more of it.

None of this requires buying anything. You can do it with a text file and discipline. The discipline is the hard part, because the outer loop runs across calls, tickets, docs, and three tools that do not talk to each other, and keeping it coherent by hand is a job nobody has time for.

Where I am biased

I build Zentrik, so I have skin in this. We keep the product context linked to the customer signal it came from, and generate it into the coding agent instead of asking someone to retype a file that goes stale. A human still owns the decision. The system proposes and organizes; product leadership decides what to build. That last part matters to me: the goal is not an autonomous roadmap machine, it is a loop that stays inspectable while it moves fast.

You do not have to use any of that to take the point. The inner loop is getting most of the attention because it is the flashy part. The outer loop is where the wrong thing gets decided, and it is still run by hand. Whoever tightens it will get more out of their coding agents than whoever writes the cleverest prompt.

The agent reads your code. Give it the reason the code exists.