A relay of identical blindfolded figures along a long corridor, each passing forward a carefully built wooden scaffold. The scaffold carries tags and guide rails that steer each new pair of hands, while the footprints behind them fade away. Editorial illustration in a risograph print style: confident ink linework, two muted inks (deep slate blue and warm ochre) on an off-white paper ground, visible grain, generous negative space. No text, no letters, no numbers, no logos.
Most of what gets said about coding is about the one-shot: describe an app, get an app. It's an impressive moment, and an easy one to judge. The thing runs or it doesn't. But software doesn't stop at its first version. Every change after that is a second, third or fiftieth pass, made by an agent that remembers none of the passes before it. That's where quality is actually decided, and it's where almost nobody is looking.
The one-shot is the easy part
A first version is judged against the request. Did it build the thing? A fiftieth version is judged against everything the first forty-nine were supposed to keep true, and most of that was never written down. The agent making pass fifty can't see the intent behind pass twelve. It sees code, and whatever fits in its window.
So the hard question isn't “can an agent write this?” It can. The question is what the code looks like after an agent has changed it fifty times, and whether pass fifty-one can still be made safely.
How slop forms
Nobody sets out to write slop. It accumulates. Each pass solves its own task in the nearest place that works: a new branch in the function that's already open, another flag on a class that already does too much, a helper copied rather than found. Each change is reasonable on its own. Nothing in the task pays for structure, so structure doesn't get built.
After enough unsteered passes, you get what “working” looks like without anyone deciding the shape: god files, functions that do four things, the same rule enforced in three places with three slightly different answers. It still runs. It's held together with duct tape, and the duct tape is load-bearing.
This is measurable at scale. After repositories adopted coding agents, static-analysis warnings rose about 18% and cognitive complexity about 39% (Agarwal, He and Vasilescu, 2026). A 2026 study of 302,600 AI-authored commits across 6,299 GitHub repositories found that most of the issues they introduce are code smells rather than outright bugs (89%), and that about 23% of them were still there at the latest revision (Liu et al., 2026). Slop doesn't break the build. It stays.
An agent holds a window, not the codebase
Slop matters more with agents than it did with people, because of how an agent knows things. A developer who has worked on a codebase for a year carries a map of it in their head. An agent carries a . Sessions end and the next one starts empty. Long sessions get : the history is replaced with a summary that guesses what mattered, plus a few recently touched files. Some add memory across sessions, and it helps, but it's memory you don't own, in a shape you didn't choose. And a full window isn't a reliable one either: missed a coding agent's dangerous actions 2 to 30 times more often when those actions came after 800,000 of harmless activity (Martin and Roger, 2026).
We measured where our own usage goes. Over one day in a project of ours, 95% of agent usage ran with more than 150,000 tokens of context, and 89% came from sessions that had been active for eight hours or more. The long sessions are where the cost is, and most of what they spend is re-sending their own history. That history is the continuity. When it's compacted, the continuity is whatever the summary kept.
A messy codebase makes this worse in a specific way. An agent working in tangled code spends its window finding its way: reading the god file to locate the one branch that matters, tracing which of the three rules is the live one. That's window not spent on the change. The messier the code, the less of the task fits, and the more the agent has to guess.
Structure is the memory that survives
If the agent's memory resets, something else has to hold what it
would have remembered. In code, that's structure. Separated
concerns, small modules, named helpers and tests are what a fresh
agent can rebuild its understanding from in a few reads. A function
called parse_retry_after tells the next agent what
it's for without the conversation that wrote it. A test that pins a
behavior tells it what must not change. Good structure is a
codebase explaining itself to someone with no memory, which
describes every agent you'll ever run.
The same holds for the work, not just the code. State kept in the conversation dies with the conversation. State kept outside the agent survives: an ordered list of what's being done and why, notes on each item, plans with their decisions written down, a feed of what happened. After a compaction we stopped trusting the summary to know what was in flight. A now prints the live state from the system itself (what's running, what's waiting on a person) into the fresh context. And at natural boundaries we start a fresh agent rather than carry a summarized one forward. A new agent that reads the record is more reliable than an old one that half-remembers it.
Steer upstream
Structure doesn't appear by asking for it at the end. It comes from steering before and around each pass. Three habits do most of the work for us: decide before building, so the questions a change raises are answered and written down before code exists; review with a second agent that starts clean and didn't write the change; and measure what each failure cost, so the next fix goes where the cost is.
Two examples from the same project show why the steering matters more than the model. Implementer agents there were asked to hand back a structured report at the end of each run. Six times in two days, a run returned the report in a shape of its own invention, and each one needed fixing by hand. It looked like a model problem. It was an instruction problem: the example in the instructions showed only part of the shape, and the agents filled in the rest differently each time. We fixed the example, and the invented shapes stopped.
The other was a gap nobody had steered: a launch that waited for a busy slot instead of moving to a free one. It was met about ten times in one day before its fix landed, each time costing minutes to hours. No single meeting looked like much. Counted, it was the most expensive thing in the system that day.
Where it gets real
On a demo, slop is cosmetic. Nobody depends on it, and when it breaks you start over. With live users, it's someone else's outage. In open source, it's someone else's afternoon spent working out why a function does four things. That's the point where “it works” stops being enough, and it arrives sooner than you'd expect, because agents make the passes cheap and so there are a lot of them.
The memory you own
This site's argument is about the gap between what something is meant to be and what it measurably does. Iteration is where that gap opens in code. Each pass is checked against what it can see, which is the : the tests that exist, the in front of it. The intent is somewhere else, and the only reliable way to carry it from one forgetful agent to the next is to write it into the structure, both of the code and of the work. It's the one memory that survives a reset, and the one you own.