Your coding agent got faster. Your feedback loop didn't.

On 2 June 2026, on the Acquired Unplugged / WorkOS appearance, Boris Cherny described how his own work had changed:

“Now it’s actually leveled up I think again to the next abstraction where I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and kind of figuring out what to do. My job is to write loops.”

The industry heard “write better inner loops.”

What followed was worktrees, sub-agents, skills, verification middleware, harness plumbing. All of it real, all of it useful, and all of it aimed at the loop that runs while you sit in front of the terminal. The loop that starts when a real person hits your real site got nothing.

The buzzword, handled honestly

The term is “loop engineering.” Addy Osmani named it on 7 June 2026. Cherny described the practice on 2 June; Peter Steinberger compressed it into a tweet on 7 June. Neither of them used the phrase. Andrew Ng called it a buzzphrase in The Batch #359 on 26 June, and he was not wrong to.

We are using the term because it is the word people search for. We are not going to build a taxonomy out of it.

Ng’s three loops

The useful part of that same Batch issue is the diagram. Ng lays out three nested loops rather than one: a coding agent iterating against a product spec and evals, that spec iterating against the developer’s vision, and the developer’s vision iterating against external feedback. He labels them roughly ~minutes, ~hours, ~days.

Read the chain right to left and it stops being a diagram of your tooling and becomes a diagram of how reality reaches your code. Reality lands on a user. The user reacts. That reaction has to travel back through the developer’s head, then into a spec, then into an agent, before a single character changes. Left to right is the direction work flows. Right to left is the direction truth flows, and it is the slow direction.

Ng puts the external feedback loop at ~days. That’s the optimistic case: it assumes the feedback reaches you already actionable. In practice, when the signal has to survive a screenshot in Slack, a triage call, and a ticket someone writes from memory, the loop runs in weeks.

Here is the part that should bother you. Making the inner loop faster does not shrink the outer loop. It makes the outer loop a larger share of everything. If the minutes loop is now genuinely ten times faster and the outer loop did not move, then the outer loop now owns almost all of your latency. Amdahl has an opinion about which loop deserves the next engineering hour, and it is not the one you have been optimizing.

The outer loop cannot close on machine signals

The obvious objection is that agents can verify their own work now. Tests, type checks, linters, screenshots diffed against baselines. Why does a human need to be in this loop at all?

Because none of those verify intent.

Qwen’s verification paper, The Verification Horizon: No Silver Bullet for Coding Agent Rewards (arXiv 2606.26300, June 2026), argues that verification is now harder than generation, and that tests cover only “a thin layer of intent.” The paper’s sharper claim is structural: every verifier we build is “a proxy for human intent rather than intent itself.” A green test suite tells you the code does what the test says. It says nothing about whether the test says the right thing. It is a position paper, not a refereed result, and it should be read that way. But the argument does not depend on new measurements to hold.

Nor can you route around it by asking the agent how confident it is. A February 2026 study (arXiv 2602.06948) measured predicted versus actual success rates across models:

Every model overestimates itself, and by a lot. The gap is not a quirk of one lab. Self-reported confidence is not a signal you can close a loop on.

So the outer loop needs a human. Which means the interesting question is not whether to have humans in it, but what condition the signal is in by the time it arrives.

Most feedback dies in transit

BugsRepo (EASE 2025) looked at 119,585 Mozilla bug reports and found that 10.5% met Bugzilla’s own reporting template. That is a template-compliance number, not a quality verdict, and it is a lower bound on the problem rather than a measure of it. But 10.5% is a striking floor for reports written by technically sophisticated people on a project that publishes the template. This is not new: Bettenburg (FSE 2008) and Chaparro (FSE 2019) both document that bug reports are chronically incomplete and ambiguous, missing exactly the reproduction steps and expected behavior that would make them actionable.

The instinct is to ask for more feedback. The evidence points at form instead of volume.

An Apple ML study at CHI 2026 (arXiv 2509.16779) compared two ways of collecting human input for a model. Asking people to revise an artifact in place recovered 76.1% of preferences. Asking them to rank alternatives recovered 49.2%, which the authors describe as close to random chance. That is peer-reviewed work, and it is adjacent-domain: it studies UI design tasks, not coding agents. Do not read it as a benchmark for our problem. Read it as the reason to be suspicious of every feedback mechanism that asks a person to choose between things instead of pointing at one.

Ranking is what a Slack thread is. Situated revision is what pointing at the actual broken element on the actual page is.

The steelman

The honest counterargument: this is not an unrecognized problem, and we should not pretend it is.

The same Verification Horizon paper that gives us “a thin layer of intent” explicitly names user-as-verifier as one of four reward constructions it considers. The researchers got there first. And the paper’s own subtitle is No Silver Bullet for Coding Agent Rewards, which is a fair warning aimed squarely at anyone about to claim they have one. We are not claiming one.

The gap is not conceptual. It is that the thing named in the research is absent from shipped harnesses. Open any agent harness today and count the interfaces for a human who is not the developer to hand structured signal back into the loop. You will struggle to find one. Recognized in research, absent in practice.

What closing it looks like

The Position: Humans are Missing from AI Coding Agent Research paper (CMU / Stanford / Princeton / UIUC, February 2026) argues that the bottleneck has shifted to human-agent interaction, and calls specifically for “visual previews and interactive summaries.” That paper comes from the SWE-bench authors, which is worth noting: the people who built the benchmark the field optimizes against are the ones saying the benchmark is not where the remaining problem lives. It is a position paper too.

PinAppAI is one implementation of that call, not the only possible one. A reviewer pins a comment on the actual element on the actual live page. The comment carries the selector, the page, the device and viewport. An agent reads it through the MCP server, applies it, and writes back the result. The developer still reviews the PR. We do not remove the human from the loop. We change the form the signal arrives in so that it survives the hops where the research says it dies.

We ran it on this site. One change, pin to applied to green marker, about 13 minutes wall clock. That was our own site, one change, and the recorded ramps are sped up. It is a demo, not a measurement.

What we don’t know

We have 3 real external users and 1 real external project. That is not a customer base, and nothing above should be read as a customer result.

We have not measured a loop-time reduction for anyone but ourselves, on one change, on a site we control. The claim that the outer loop compresses from weeks to hours is a stated prediction. It follows from the argument, and the argument may be wrong.

What we are confident about is the shape: the inner loop got fast, the outer loop did not, and the second one now dominates. When we have customers to measure, we will publish the numbers, including the ones that do not flatter us.