Coding agents are drowning in their own output

A prompt file hit 535 points on Hacker News trying to fix what retrieval broke. The structural fix: serve agents symbol-level answers instead of file lists.

Coding agents are drowning in their own output

A skill file called i-have-adhd topped Hacker News on September 8 with 535 points and 370 comments. Its entire purpose is to stop coding agents from burying the answer under their own output. The project describes its fix in one line: "Action first. Steps numbered."

A prompt file making the front page is the interesting part. Thousands of teams are running agents that retrieve badly, produce too much, and then read their own production back as input. The fix being passed around is behavioral. The cheaper fix is structural: change what the agent is fed in the first place.

Where the output problem comes from

The default retrieval move inside a coding agent is grep. Grep returns matches, not relevance. Search for a function name and you get every file that mentions it: call sites, comments, imports, test fixtures, a changelog entry for a function that got renamed twice. The agent receives a list of locations and has to read its way toward meaning.

Files are the unit grep works in, and files are big. The answer to "where does this input get validated" is usually a handful of symbols: one function, its callers, maybe a type definition. A few hundred lines of signal. The grep output that leads there can be ten times that, and the agent pays for all of it from the same context window it needs for reasoning.

Then there is the second-order problem the thread title points at. Agents generate their own output: plans, summaries, intermediate file listings. That output gets re-read and re-summarized back into context. The agent spends attention on its own voice instead of the codebase.

What symbol-precise context looks like

The alternative is to index the code once, then serve the agent structural answers instead of lists of files.

Cora Code, our CLI for AI code review and code intelligence, publishes numbers from its own repository: 1,864 symbols across 115 Rust files, a cold index of roughly 936 milliseconds, an incremental re-index of about 6 milliseconds, and hybrid search around 5 milliseconds. The binary is 10.4 MB with no runtime dependencies. The README marks these figures as indicative, not contractual, and that caveat is fair. The shape is the point: indexing is cheap enough to run continuously, so structure can come from a query instead of a grep.

The structural queries read like the questions a reviewer asks before touching code:

  • cora trace walks the call chain from an entry point
  • cora callers lists everything that invokes a symbol
  • cora impact estimates the blast radius of changing one
  • cora affected finds the tests that touch changed files
  • cora dead-code surfaces functions with zero callers

Each answer is measured in symbols. An agent that asks "what breaks if I change this function" gets a bounded answer instead of forty files to skim.

How it works under the hood

Cora Code is a Rust CLI under Apache-2.0, at version 0.15.0 as of this writing. Symbol indexing parses with tree-sitter across 13 languages, including Rust, Go, Python, TypeScript, and Svelte. Search fuses three signals with reciprocal rank fusion: SQLite full-text search, vector nearest neighbor, and a walk over the call graph. We covered the search design in an earlier post on Brain Mode.

Two properties matter specifically for agent use.

The non-LLM path is deterministic. Twelve built-in rules, 13 security patterns, and 15 secret detection patterns run without any model call. A CI job gets the same answer on every run, which is what a quality gate needs to be enforceable.

The agent path is MCP. Cora Code ships an MCP server with 18 tools, so agents in Claude Code, Cursor, or Windsurf call trace or impact directly instead of shelling out to grep. Installation is one command with cargo, or the curl installer for machines without a Rust toolchain.

Where grep still wins

The honest section. Grep survives several of these rounds.

Fresh code is invisible to an index until one gets built. If the agent wrote the function two minutes ago, grep on that symbol is exact and instant.

Known exact names need no ranking. If you already know the function is called validate_payment, grepping that string is the most precise retrieval available.

Small repositories may not justify the setup. A two-thousand-line project fits in context almost whole, and the index buys little there.

And Cora Code itself is young: 25 stars, v0.15.0 eleven days ago, a benchmark corpus of exactly one repository. Treat the millisecond figures as one data point from one codebase.

The behavioral fixes treat the symptom

i-have-adhd tells the agent what to do after retrieval has already gone wrong. Numbered steps and action-first formatting help an agent cope with a bloated context. They do not shrink it. The same goes for summarization tricks and "be concise" system prompts. All of them operate downstream of the bad retrieval, rationing attention that was wasted before the agent had a say.

We argued the same shape for long context windows earlier this month: a 524k context still needs an index. Bigger windows raise the ceiling. They do not change what gets served.

Fixing the supply side means fewer, smaller, structural answers in the first place. Symbol-level query tools are one way there. We build one, so read this post with that bias declared. The Hacker News thread shows the pain is common enough that a prompt file hit number one on the front page.

Try it

The repo is github.com/codecoradev/cora-code. Install with cargo install --git https://github.com/codecoradev/cora-code, run cora index, then run cora impact on a function you were about to change. Compare the answer to the grep output you would have waded through to get there.