---
title: ['Tunnel', 'Vision']
description: "A support document for a half-built feature came back with \"not implemented yet\" scattered through it. Claude and Codex both prop drill, write tests for 1+1 and over-disclose, and most of it is tunnel vision: the task in hand feels like the most important thing in the world. My partial fix is separate steps in separate contexts."
---

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.

### FOOTNOTES

[^1]: Tests that add build minutes without adding confidence are the same waste [Don't Run It Twice](/dont-run-it-twice/) went after from the other end.

[^2]: This looks like it contradicts [No agents, no plan, ship it](/no-agents-no-plan/), but it doesn't quite: each run is still a single prompt, there are just two of them, in different contexts, at different times.

[^3]: Same reasoning as [Start With One](/start-with-one/): a small, bounded set of changes is a far better thing to look at, for a human or an agent, than the whole feature at once.

[^4]: Cognition's [Don't Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents) makes the one-agent-one-context case, and their 2026 follow-up, [Multi-Agents: What's Actually Working](https://cognition.com/blog/multi-agents-working), concedes that a clean-context reviewer "catches bugs the coder can't see" as long as only one agent writes, which is this setup.