I opened a support document the other day for a feature that was still being built and found "not implemented yet" scattered through it. Not once, as a note at the top, but next to every button and setting the agent hadn't got to. It was accurate, but (obviously) it had missed the point.
Claude and Codex are both moving up the developer curve, and for the most part they write code I'm happy to merge. But there are a few things they both do that I keep hitting:.
(1) "Prop drilling". The agent needs a piece of data at location X, so it threads that data through every layer between here and there, clobbering interfaces on the way. The case that stuck with me was expanding our error logging to return specific codes rather than a generic error. The agent drilled every fact the codes needed down through the stack, when at the point the error left the system all of those facts were already sitting there.
(2) Unit tests for 1+1. The frontend ended up with a pile of tsx tests checking that string concatenation works. They're cumbersome, they cost build minutes[1], and they were written by the same context that wrote the code, so their value as an independent check is arguable at best.
(3) Over-disclosure. Ten-line comments on three-line functions, and over-sharing in anything user-facing. That's where "not implemented yet" came from. It was true, but a support document isn't the place to say it a dozen times.
Most of this, I think, is tunnel vision. The task in hand is the only thing in the context, so it feels like the most important thing in the world. The ten-line comment is obviously necessary (it isn't), and the concatenation test feels like diligence, because nothing in that context is looking at the whole.
Model or harness? Probably both.
My partial fix is to separate the steps and give them different contexts. Subagents would do it, but I prefer a separate agent altogether -- one that never saw the original task and has no stake in it. For support docs it's a separate runner on a schedule[2]. It takes a small bundle of recent changes[3], looks at the feature as a whole, and only then touches the document. The context isn't "do this thing" it's "maintain the support site as a whole with a batch of changes." This modifies the outcome in a meaningful way.
Cognition argued against this a while back: split the work across contexts and you lose the implicit decisions the writer made along the way[4]. I disagree. If those decisions lie only in the context then I think you have a problem - the code and supporting materials aren't self-evident. Also it cuts the other way. The same context has all the twists and turns that are better left in the tunnel.