The Wrong Race
I spent part of last week at Boston Tech Week, sitting in on technical sessions with founders building in the agentic AI space. One presentation stopped me cold — not because of the product, but because of the framing. The CTO walked through why the entire field is racing toward a solution that is, information-theoretically, the wrong one. This is my attempt to share that framing.
Everyone building AI coding tools is racing to make context windows bigger.
They're solving the wrong problem.
I was at Boston Tech Week last week and heard a technical presentation that reframed how I think about agentic coding infrastructure. The core insight has stayed with me.
The problem isn't that agents aren't smart enough. The problem is that context has two constraints that are in direct tension with each other.
The first is exhaustiveness. If an agent misses a symbol, a dependency, a cross-file relationship, that signal is gone. Information theory is unambiguous about this: signal lost in a processing chain cannot be recovered downstream. RAG is a sampling technique. It misses things. Those misses are permanent.
The second is signal-to-noise ratio. Here's where it gets counterintuitive. If you solve exhaustiveness by dumping an entire codebase into context, you've maximally destroyed SNR. Shannon-Hartley tells us that as irrelevant context grows, the channel capacity for transmitting useful information collapses. A bigger context window makes this worse, not better.
These two problems are in direct conflict. Every tool on the market resolves one at the expense of the other.
The correct architecture separates them.
Handle exhaustiveness ahead of time: parse every symbol, every dependency, every file, deterministically. Build a structured context base that is complete by construction.
Handle SNR at runtime: from that exhaustive base, resolve and assemble only what is relevant to the specific task. Progressive refinement. Broad orientation first, targeted detail second.
The teams getting this right are becoming non-negotiable infrastructure for enterprise engineering organizations. Not a tool. Infrastructure.
We don't even have the right word for this layer yet. "Compiler" is close but carries the wrong connotation. "Context engine" is too generic. Whatever we call it, the architecture is clear.
The race to build bigger context windows will continue. But the teams who figure out that exhaustiveness and relevance are separate problems, requiring separate solutions, are the ones building the foundation that everything else runs on.
What would you call this infrastructure layer?
If you're thinking about agentic coding infrastructure or seeing this context problem in your own engineering organization, I'd be curious to hear from you. Get in touch: arif@faris-capital.com
This thesis was originally published on LinkedIn. Join the discussion, add your thoughts, and follow for regular updates.
View on LinkedIn