Nobody Opposed the Delay - Arman Fatemi
Arman Fatemi
SubscribeSign in
Nobody Opposed the Delay<br>When a model does something it knows better than, where did the objection go?
Arman Fatemi<br>Aug 19, 2026
Share
A frontier model, the best in the world by its operator’s own description, inserted a nonsensical 700-millisecond delay to settle something. Challenged, it folded instantly: “you’re right, I was cargo-culting.”
Guillermo Rauch shared that anecdote recently, and I haven’t been able to put it down. His broader point: if you’re not reading AI-generated code (yourself, or through agents doing the reading for you), then one of a short list of things is true: you’re a beginner, the software is throwaway, you’re prototyping, you have no users or revenue, you’re knowingly taking on debt and risk, your problems are basic.<br>All of which, he adds, is fine. Models still make rookie mistakes and go down bad architectural paths; they’re not at full autonomy yet.<br>I agree with the conclusion. Review is necessary, and anyone shipping agent-written code to real users without it is running an experiment on their customers.<br>I want to argue with the autopsy.<br>“Rookie mistake” is a capability diagnosis. It locates the failure in the weights, and it implies a capability remedy: wait for better models, review harder in the meantime. But there’s a cheap experiment that breaks that diagnosis. Open a fresh session with the same model: no history, no project, no pressure. Ask it: ”I have a race between two services. Should I add a 700ms sleep to settle it?”<br>It will refuse. Not ambiguously; it will lecture you. Sleeps mask timing bugs instead of fixing them; the problem returns under load; here is what a real fix looks like. The knowledge that a 700ms delay is cargo-culting is emphatically in the model: the word it used to confess is proof it knew the pattern by name. And remember: this was already the best model available. Even at the frontier, having the knowledge isn’t the same as using it.<br>So whatever went wrong that day happened somewhere between the weights and the transcript, and it wasn’t a shortage of knowledge.<br>01 — The wrong autopsy
I don’t know what happened inside that session. But I run an agent pipeline every day against a codebase of my own, I read the transcripts, and I can tell you what this failure shape looks like from the inside. When an agent of mine does something it demonstrably knows better than, the transcript almost always shows one of a few conditions upstream:<br>The context was crowded. The reasoning that would have caught the mistake was competing with a whole session’s worth of accumulated survey results, tool output, and half-finished threads. Attention starts failing long before the window does.
The fix was nested inside another task. The agent set out to implement feature A, hit a surprise, hit a surprise inside the surprise, and the timing bug was three levels down a detour. Nobody, human or agent, scoped that fix. It inherited the momentum of the parent task instead of getting the skepticism a fresh task would have received.
The agent inferred urgency. Somewhere in the accumulated context was a signal (a tone, a deadline mention, a string of quick confirmations) that it read as settle this fast and move on. I’ve found models exquisitely sensitive to what they think you want. Sycophancy is the loud version of that sensitivity; the quiet version is an agent deciding you’d rather have it fast than right.
These aren’t hypotheticals; they’re what the run records show. One case: a review flagged a vacuous test: an absence assertion on an element id with no positive anchor anywhere in the suite, so a rename would leave the test green while the feature it guarded went dark. Inside the very fix round for that finding, the agent applying it wrote a fresh absence assertion on an id that doesn’t exist in production at all. The run record’s own words:<br>reintroduced the identical bug while fixing it
Caught before commit, that time. Rauch’s session I can’t inspect; this one is on my disk. The rule wasn’t merely in the weights. It was in the context window, freshly stated, and it still didn’t fire on an edit nested one level inside the fix.<br>Before calling any of that a malfunction, notice that the same conditions bend human judgment too, and there we don’t call it a rookie mistake, we call it a judgment call. A strong engineer at a two-person startup, coding at midnight with demo day at nine, adds the 700ms sleep, writes TODO: real fix, and ships. In that context the delay isn’t even wrong.<br>Which exposes what the capability framing hides: whether the delay is a mistake at all is decided by the context, not by the code. An agent’s judgment isn’t merely degraded by what it arrives with; it’s constituted by it. The difference between the demo-day engineer and Rauch’s model is that the engineer knew what they were trading. The model made the trade without knowing a trade existed: the context handed it the...