Context blindness is the defining failure of 2026

We spent three years bracing for hallucination. Made-up functions, invented citations, confident nonsense. Reviewers learned to check whether the thing being called exists.

That is not the failure that is costing teams money now. The one that is costing money is a pull request where every function exists, every type checks, the tests pass, the naming is idiomatic, the error handling is thorough, and the whole thing is wrong for this codebase. It uses the HTTP client we deprecated. It adds a second retry mechanism next to the one in the platform library. It handles auth in a way that is entirely reasonable and bypasses the middleware every other route goes through.

This is context blindness, and my position is that it is the defining failure mode of this era. Not because it is the most dramatic, but because it is the only one that gets worse as models get better.

Why better models make it worse, not better

Hallucination is a capability problem. More capable model, less hallucination. That relationship has held.

Context blindness is not a capability problem. It is an information problem. The model produced the best possible answer to the question it was actually asked, and the question it was actually asked did not include the fact that this organisation banned that pattern after an incident in March.

Increase the model’s capability and you do not close that gap. You make the wrong answer more polished. The code becomes better structured, better named, better tested, more convincingly a thing a good engineer would write. Every increment of fluency makes the defect harder to spot, because the signal reviewers were using was never correctness, it was strangeness.

The cost lands entirely on review, and review is already failing

If the defect cannot be caught by types, tests or lint, there is exactly one place left for it to be caught, and that place is a human reading a diff.

The LinearB 2026 benchmarks describe what is happening there. Agentic pull requests wait 5.3 times longer to be picked up. Median review duration is up 441.5 percent. The share merged with zero review is up 31.3 percent.

Read those three together and the story is not that reviewers got worse. It is that the work arriving is longer, more plausible, and more numerous, and the reviewing capacity did not change. When a queue exceeds capacity and every item in it looks fine, the rational individual behaviour is to approve. That is how 31.3 percent more zero-review merges happens without a single person deciding to lower their standards.

Meanwhile the Stack Overflow Developer Survey 2025 recorded trust in AI output falling from around 40 percent to 29 percent. That is not developers becoming reactionary. That is developers correctly updating on this exact experience: output that reads well and turns out to have been written for a different repository.

The repository is the missing input, and yours cannot be read

Here is the part that is uncomfortable, because it puts the problem on our side of the line.

A new engineer joining your team acquires context by osmosis over months: code review comments, an incident, a senior engineer saying “we don’t do that here, ask me why”. None of that is written anywhere. It exists as tribal knowledge held in five heads.

An agent gets none of it. It gets whatever your retrieval puts in front of it, plus whatever it can infer from the code it can see. And what it can see is a codebase containing three eras of convention living side by side, because you never deleted the old one. It reads the deprecated pattern and the current pattern with equal weight, because nothing in the repository says which is which.

So it picks. Sometimes it picks the pattern with more occurrences, which in a large old codebase is reliably the one you are trying to kill.

What the repo shows:
  147 call sites using LegacyHttpClient
   12 call sites using PlatformClient
What the team knows:
LegacyHttpClient is frozen. New code
uses PlatformClient. Migration is
a background task with no deadline.
What is written down:
nothing

Two responses, and only one of them works

The common response is more instruction. Longer system prompts, a growing document of rules, a CONTRIBUTING file that swells to three thousand lines. This helps at the margin and then stops, because instruction is advisory. It competes for attention with everything else in the window, it is not enforced, and nobody notices when it is ignored until review.

The response that works is making the constraint checkable rather than stated. If new code must not import the legacy client, that is a lint rule, not a paragraph. If a route must go through the auth middleware, that is a test or an architectural fitness check. The distinction is not that one is more polite. It is that one produces a failure at the point of authorship and the other produces a disappointment in review, and the whole problem is that review is saturated.

This is where our own product sits, and I want to be honest about its edge. GroundTruth checks a diff against the acceptance criteria attached to the work, which catches the class of context blindness where the change does not do what was asked. It does not catch the class where the change does exactly what was asked using a pattern the team abandoned, unless somebody wrote that down as a criterion. Nothing reads your unwritten conventions. That remains a repository legibility problem and it is yours.

Where this breaks down

Retrieval is improving fast, and this may be a two-year problem. Agents that index the repository, read git history, and notice that a pattern’s most recent commits all move away from it would close a lot of this gap without anyone writing anything down. If that lands well, my argument dates badly. My hedge is that history tells you what changed and not why, and the why is the part that matters when the two patterns are both defensible.

Humans do this too, constantly. Every new joiner writes code in the style of their last job for their first two months. We have always had context blindness. The honest claim is not that it is new, it is that it now arrives at a volume review cannot absorb, and that the perpetrator does not learn from the correction.

“Make it checkable” is easy to say and expensive to do. Turning a convention into a fitness function is real engineering work, and the set of conventions that can be expressed mechanically is smaller than the set of conventions that matter. Some things genuinely can only be explained by a person.

I may be blaming the tool for a codebase problem. A repository with one clear pattern per concern, dead code deleted, and boundaries that are actually enforced produces far less of this. Some of what gets called context blindness is a mess being reflected back accurately, and the diagnosis “our repository is illegible” is less flattering than “the agent got confused”.

Zero-review merges are not automatically bad. A trivial dependency bump merging without review may be entirely correct, and the 31.3 percent figure does not separate the trivial from the consequential. It signals a shift in behaviour. It does not by itself prove harm.

The takeaway

Hallucination is a shrinking problem with an obvious detector. Context blindness is a growing one with no detector except a human who already knows the codebase, and it becomes better disguised as models improve. That combination is why I think it is the defining failure of this period rather than merely one of several.

The fix is not a longer instruction document. It is moving constraints from conversation into things that fail loudly at authorship time, and accepting that the parts you cannot mechanise are the parts you must staff for.

If you take one thing into next week: pick one convention your team enforces only in review comments, and make it fail in CI instead. You will find out quickly whether it was a real rule or a preference, and either answer is worth having.