Garbage in the Loop
Brian Kihoon Lee
Essays
Garbage in the Loop
2026-06-24
Tagged: llms
Since Opus 4.5 came out last November, my daily driving experience<br>with coding agents feels like it’s stagnated. It’s not that AI has<br>plateaued; it continues to accomplish feats that were not even in my<br>realm of possibilities a year ago: codebases<br>rewrites pinned to extensive unit tests, mathematical theorem proving,<br>security exploit<br>discovery, autoresearch, etc..<br>I am starting to believe that I am the bottleneck, not because I have to<br>sit there and prompt the agent, but because the agent needs to untangle<br>my sloppy prompting.
In this essay, I consider where we should focus our efforts now that<br>frontier models are no longer the dominant source of garbage.
A garbage loop example
“Garbage in the loop” is a fusion of two phrases: “garbage in,<br>garbage out”, and the agentic<br>loop.
A typical garbage loop (early-2026) might go as follows:
I ask the agent: “I’m seeing bug X on system Y. It’s coming from the<br>Z module, go investigate and fix.”
Agent greps the monorepo for Z and comes up with 4 search results,<br>only one of which is in system Y. But System Y’s name isn’t part of the<br>filepath, so the agent doesn’t know which one is correct. Plausibly, all<br>of the results might be different parts of system Y.
It wastes some time digging further before finding the right module<br>Z.
Along the way, the agent has learned some plausible concepts about<br>system Y’s doppelgangers that don’t actually exist in system Y.
It misdiagnoses the error, hallucinating some chain of causality<br>that would make sense if those other concepts actually existed – but<br>they don’t.
It invents a fix, tests it, and declares the task complete.
When I tell it that I’m still seeing the error, it starts inventing<br>new epicycles upon epicycles to explain away the discrepancy.
I give up, clearing the session and reprompting with the right<br>filepath.
The original garbage was my insufficiently precise reference to<br>system Y, and the agentic loop failed to recover.
Here are all the possible intervention points
Don’t even mention Y or Z; instead just reference the URL of the<br>page you saw the error on. Alternately, name the exact filepath to<br>system Y, or change directories into system Y so that the model’s search<br>returns the right results.
The harness could have indicated something about me and the systems<br>I usually work on, to help the agent disambiguate.
The environment could be cleaned up so that systems are better<br>documented - either self-documented through better naming, or with<br>AGENTS.md indicating common confusion.
Frontier labs train smarter models that, at higher reasoning levels,<br>spend more time digging into and figuring out the relationship (or<br>non-relationship) of the search results, and to be more thorough in<br>testing its hypothesis.
Division of Responsibilities
User, harness, environment, and model. Whose responsibility is it to<br>fix these garbage loops?
One extreme take is that as models get smarter, they’ll just figure<br>it out themselves, given sufficient tokens and a memory device of some<br>sort. Any attempt to short-circuit this process would be a violation of<br>The<br>Bitter Lesson, which warns us that building knowledge into our<br>agents is effective in the short run and actively harmful in the long<br>run.
The antipodal stance (call it the Babbage<br>take) is that models should restrain themselves to doing exactly<br>what they’re asked, and that it’s the user’s responsibility to input<br>their prompt exactly as they want it done.
The theory of risk<br>compensation says that we might take agents right up to the very<br>precipice of usefulness. Thus, we end up with a very rough equation:
User prompt quality + Harness quality + environment quality + model quality = Agent quality = Task scope
That’s the equation if we assume all four parties are working towards<br>improving their game. Otherwise, we might have something closer to the<br>following:
Harness quality + model quality = Agent quality = Task scope + tolerance to bad user prompt + tolerance to bad environment
You won’t be able to tackle more ambitious tasks if the user slurps<br>up all improvements in agent quality by being worse at prompting, or if<br>the codebase/information environment fills up with slop.
Garbage ontology
Stepping back, here’s a more complete list of garbage sources:
User
I told the agent to use a wrong approach (forgot about a constraint,<br>assumed a fix would be simple but it wasn’t, picked a bad<br>solution).
I prompted in the wrong environment (the wrong agent conversation,<br>the wrong SSH terminal, the wrong git branch/worktree/checkout.)
I gave an underspecified prompt which could quite reasonably be<br>interpreted differently.
I maintained one very long multi-topic session, which contained<br>instructions that were only correct with respect to previous<br>topics.
Unprocessed prompts are passed in (e.g. raw user feedback instead of<br>curated JIRA tickets).
Harness
System prompt was fixing...