The Context Problem Moved From People to Agents

Engineering teams have always had a context problem. A new hire joins and spends weeks, sometimes months, absorbing tribal knowledge before they're productive. The senior engineer who built the billing system carries decisions in their head that never made it into documentation. A Jira ticket from 2023 contradicts the Confluence page from 2024, and no one remembers which is authoritative.

Teams built workarounds for this. Onboarding buddies. Architecture decision records. "Ask Sarah, she'll know." Those workarounds assumed the consumer of context was a human who would learn over time. A human who asks once, remembers the answer, and gradually builds a mental model of the organization.

AI agents are not that consumer. According to the Stack Overflow Developer Survey 2025, 82% of professional developers now use AI coding tools weekly (Stack Overflow Developer Survey, 2025). Every one of those sessions starts from zero. The context problem didn't go away when we adopted AI tools. It moved. It moved from people to agents, and with that move, every workaround the profession built over three decades stopped working.

---

What was the original context problem?#

McKinsey's 2025 research on developer productivity found that AI tools boost raw code output by up to 30%, but developer time spent on context gathering hasn't decreased (McKinsey, 2025). The original context problem, getting the right knowledge to the right person, predates AI entirely.

The context problem in engineering is the gap between what someone needs to know to do the work and what's readily available to them. McKinsey's 2025 research found that AI tools boost raw code output by up to 30%, but context-gathering overhead hasn't decreased (McKinsey, 2025). The problem predates AI entirely, but AI amplified it.

For decades, this problem was a people problem. A junior engineer didn't know which auth pattern to use. A mid-level engineer transferring between teams didn't know why the billing service avoided the standard ORM. A contractor didn't know that the team tried and rejected exactly the approach they were about to propose.

How teams used to cope#

The workarounds were social, not technical. Pair programming transmitted context in real time. Code review caught violations after the fact. Architecture decision records attempted to write things down. Onboarding docs tried to compress months of context into a week of reading.

These strategies shared a core assumption: the recipient is a human who will learn. Ask a new hire the same question twice, and the second time they'll remember. Correct a junior engineer's approach once, and next time they'll check the convention before writing code. Human context absorption is slow but cumulative. The overhead of context transfer amortizes over tenure.

Before AI coding tools became widespread, the most expensive form of the context problem was onboarding. Teams we've spoken with consistently estimated 3-6 months before a new engineer was fully productive. That investment paid off because the engineer retained what they learned.

---

How did the context problem move to agents?#

GitHub's 2025 research found that 97% of developers have used AI coding tools at work, yet most organizations lack infrastructure to feed those tools organizational knowledge (GitHub, 2025). The context problem moved because the consumer changed from humans who learn to agents who don't.

The context problem moved to agents because the profession adopted AI coding tools faster than it built infrastructure to support them. GitHub's 2025 research found that 97% of developers have used AI coding tools at work (GitHub, 2025). Those tools shipped generation capabilities before they shipped understanding.

The shift happened in three stages.

Stage 1: autocomplete didn't need context#

Early AI coding tools (Copilot's first release, Tabnine, Codeium) worked at the line or function level. They predicted the next token based on the current file. At that granularity, organizational context barely mattered. The tool didn't need to know why your retry logic exists. It just needed to complete the line you were typing. The context problem was still a people problem.

Stage 2: chat-based agents exposed the gap#

When AI tools moved from autocomplete to chat-based coding (ChatGPT, Claude, early Copilot Chat), the context gap became visible. Engineers started asking the model to implement features, refactor modules, and debug cross-service issues. Those tasks require organizational knowledge the model doesn't have. The Stack Overflow 2025 survey captured the result: 66% of developers said "AI solutions that are almost right, but not quite" was their top AI pain point (Stack Overflow, 2025).

Stage 3: autonomous agents made it structural#

The current wave, Claude Code, Devin, Codex, and other autonomous agents, turned the gap into a structural bottleneck. These agents run for extended periods, make multi-step decisions, and produce complete pull requests. Every decision they make without organizational context is a decision the reviewer has to check, correct, or reject.

The context problem's shift from people to agents is not just a change in degree. It's a change in kind. Humans learn and accumulate context over time. Agents start from zero on every session. The workarounds built for a learning consumer don't work for a stateless one. This is why "better documentation" is necessary but not sufficient. The agent will read the docs, but it won't remember them tomorrow.

---

Why don't the old workarounds work for agents?#

Anthropic's 2025 research on agentic coding documented how agents "get stuck in loops, repeating the same failed approach" when they lack sufficient context (Anthropic Engineering, 2025). Old workarounds assumed a consumer who would learn from corrections. Agents don't learn between sessions.

The old workarounds fail because they assumed context absorption is cumulative. Anthropic documented agents repeating failed approaches in loops when context is missing (Anthropic Engineering, 2025). That repetition is the proof that the old model broke.

Documentation helps but doesn't solve it#

Architecture decision records, runbooks, and README files are valuable. But they have three limitations for agents. First, they go stale. A doc written six months ago may contradict last week's PR. Second, they're incomplete. No team documents every convention, especially the ones that feel obvious to insiders. Third, agents don't know what they don't know. An agent won't search for a doc about retry patterns unless it already suspects retry patterns are relevant to the current task.

Onboarding assumes retention#

The human onboarding model works because the human retains what they learn. Teach a new hire the auth pattern once, and they apply it going forward. An agent gets "taught" the auth pattern via prompt injection, uses it for one session, and forgets it entirely the next time. You're onboarding the same agent to the same organization every single session. That's not a scalable model.

Code review catches problems too late#

Code review is the profession's safety net. But when agents produce code without organizational context, review becomes rework. The reviewer isn't checking for quality. They're re-teaching the organization's conventions to a tool that will forget them by the next PR.

The JetBrains 2025 Developer Ecosystem Survey found that 77% of developers using AI assistants still manually correct outputs for project-specific conventions (JetBrains Developer Ecosystem Survey, 2025). That 77% is the old context problem wearing a new face.

---

What does the new context problem actually look like?#

Google's DORA 2024 State of DevOps research found that AI adoption among developers reached 90%, but AI use correlated with declining software delivery throughput and stability (DORA State of DevOps, 2024). The new context problem manifests as more code generated but less code shipped successfully.

The new context problem looks like high generation volume with low acceptance rates. DORA's 2024 research found AI adoption at 90% among developers but correlated AI use with declining delivery stability (DORA, 2024). More code, worse outcomes. That's the context problem in aggregate.

In practice, the new problem has three shapes.

Repeated mistakes across sessions. The agent makes a convention violation. A developer corrects it. The next session, a different developer (or the same developer on a different task) hits the same violation. The correction never persists. This is what we've described elsewhere as the AI agent doom loop.

Confident wrong answers. The agent produces code that looks right, compiles, passes lint, and violates an unwritten rule the team agreed on in Slack four months ago. The confidence is the problem. A junior engineer who was unsure would ask. The agent that's confident doesn't ask.

Invisible overhead. Engineers spend 10-20 minutes per agent session assembling context that the tool should already have. A Forrester report on AI-augmented development estimated that developers spend an average of 45 minutes per day on prompt preparation and context assembly (Forrester, 2025). That overhead doesn't show up in any productivity metric, but it consumes real hours.

The most telling signal we've seen is this: teams that measure "time from task assignment to merged PR" often find that AI tools haven't shortened that window as much as expected. The generation is faster. The context work, review, and rework fill the gap.

---

How should teams think about solving the new context problem?#

Stanford HAI's 2025 AI Index reported that AI adoption in software development grew faster than in any other professional domain, but productivity gains remain "inconsistent and context-dependent" (Stanford HAI AI Index, 2025). Making those gains consistent requires treating context delivery as infrastructure, not an afterthought.

The new context problem requires a new category of solution. Stanford HAI's 2025 AI Index found developer productivity gains from AI are "inconsistent and context-dependent" (Stanford HAI, 2025). Making them consistent means treating context as infrastructure.

Three principles should guide the approach.

Principle 1: context delivery must be automated#

If a human has to assemble context for every agent session, the cost of context delivery scales linearly with agent usage. That's the model that's failing today. Automated context delivery means connecting agents to organizational knowledge systems, code, PRs, chat, tickets, docs, incidents, and surfacing the relevant slice at task time without human intervention.

Principle 2: context must be task-aware#

Dumping everything into the prompt doesn't work. Chroma Research tested 18 frontier models and found that reasoning degrades as context length grows, often well before the window is full (Chroma, Context Rot, 2025). The right context for a feature implementation is different from the right context for a bug fix. Task-aware retrieval means the system understands what the agent is doing and selects context accordingly.

Principle 3: context must be conflict-resolved#

Organizational knowledge is contradictory. The wiki says one thing. The last PR says another. A Slack thread from last week says a third. Handing an agent three conflicting signals doesn't help. It needs a system that weighs sources, identifies conflicts, and surfaces the most authoritative answer.

These three principles, automation, task-awareness, and conflict resolution, describe the function of what we've called elsewhere a context engine. The label matters less than the function. What matters is that the context problem moved, and the solution has to move with it.

Teams that have moved from manual context injection to automated context delivery report a measurable shift: review cycles shorten because the agent's first attempt more closely matches organizational expectations. The gap between "compiles" and "mergeable" narrows.

---

Frequently Asked Questions#

What is the context problem in software engineering?#

The context problem is the gap between what someone (or something) needs to know to do the work correctly and what's readily available to them. For humans, this gap closes over time through experience. For AI agents, it reopens every session. The Stack Overflow 2025 survey found only 33% of developers trust AI tool accuracy (Stack Overflow, 2025), and missing context is a primary driver.

Why can't better documentation solve the agent context problem?#

Documentation helps but doesn't solve it for three reasons. Docs go stale, no team documents every convention, and agents don't know what they don't know. An agent won't search for a doc about retry patterns unless it suspects retry patterns are relevant. The JetBrains 2025 survey found 77% of developers still manually correct AI outputs for project conventions (JetBrains, 2025).

How is the context problem different for agents versus new hires?#

New hires learn and accumulate context over time. Teach them a convention once, and they retain it. Agents start from zero on every session. You're effectively onboarding the same "new hire" to your organization hundreds of times a day. The old onboarding model assumed retention. Agents don't retain between sessions.

What is a context engine and how does it help?#

A context engine retrieves, ranks, and synthesizes institutional knowledge from across an engineering organization, including code, PRs, chat, tickets, and docs, and delivers decision-grade answers at task time. It automates the context work that engineers currently do by hand. For a detailed explanation, see what is a context engine.

---

This post is part of the Context Engineering series. For the full framework, read the context engineering guide for engineering leaders. For the working definition, see what is context engineering.