Your AI Editor Doesn't Actually Know What You're Doing

Any developer who has spent weeks with Claude Code, Cursor or Copilot knows the problem well: the assistant solves the function you ask for, but has no idea why that function exists, what architectural decision surrounds it, or what business constraint conditions it. An article published on May 5th on hashino's personal blog, which circulated on Hacker News that same day, articulates it precisely: your AI editor doesn't know what you're doing.

The thesis isn't new, but the framing is useful because it shifts the focus. The problem isn't that the model makes mistakes—we already accept that—but that it operates without a mental model of the project. It can read the files you give it, it can infer patterns from visible code, but it doesn't access the intention behind each decision, the history of why a previous approach was abandoned, or the organizational context that makes certain constraints meaningful.

The Limit Isn't Capacity, It's Context

It's tempting to think this problem will disappear with larger context windows. Claude Opus 4.7 already works with up to 1 million tokens, which allows loading entire repositories in a single session. And yet the problem persists because most of the relevant knowledge isn't in the files: it's in team members' heads, in Slack conversations from six months ago, in a decision made in a meeting nobody documented.

What the article describes is, at its core, the difference between syntactic context and semantic context. The former—what you can put in a prompt—is what LLMs process well. The latter—what makes technical choices meaningful—remains human territory.

This doesn't mean assistants are useless. It means their usefulness has a specific geography: they excel at self-contained tasks, at bounded refactorings, at generating tests for well-defined functions. They falter when the work requires reasoning about the system as a whole or about decisions that aren't written anywhere.

What Tools Can and Can't Do

Some of the mechanisms Anthropic has built into Claude Code are designed precisely to mitigate this gap. Skills allow packaging reusable instructions and context that the agent can invoke on demand, helping transfer tacit knowledge in structured form. Hooks allow injecting information at specific points in a task's lifecycle. MCP servers open the door to connecting the agent with external sources of truth—internal documentation, wikis, ticketing systems—that expand context beyond the repository.

But all these solutions require that someone, at some point, has externalized the tacit knowledge into a machine-readable format. If the team doesn't document its architectural decisions, no MCP server will recover them.

Who This Problem Matters Most For

The article resonates especially with three profiles:

• Developers working on legacy projects: code accumulates undocumented decisions over years. Asking an AI editor to touch that code without context is an invitation to subtle regressions.
• Distributed teams: where knowledge is more fragmented and documentation typically lags behind what the code actually does.
• Junior engineers who delegate too early: they may generate functionally correct code but architecturally misaligned, without realizing it.

Conversely, those who get the most from these editors are developers with enough judgment of their own to review suggestions from a global understanding of the system. The assistant amplifies the capacity of someone who already knows what they're doing; it doesn't replace it.

Our Take

The article doesn't offer a new solution, but the diagnosis is honest and worth circulating. While the industry sells AI editors as universal accelerators, it's worth remembering that their performance is bounded by the quality of context the developer is able to provide—and for now, that remains a human problem.