Human Engineers as Context Engines at Organizational Scale

Writing code has stopped being the scarce skill inside a software organization. The scarce skill now is supplying the organizational context that confirms whether what an AI agent just wrote is actually correct.

AI coding agents today handle multi-file refactors, run long background tasks, and in some organizations carry a change from first commit to production, though most teams still keep a human review gate in that last step rather than letting the flow run fully on its own. That capability is no longer the frontier. The frontier is what surrounds the agent: whether it has the context, permissions, and up-to-date information a real codebase demands before its output can be trusted. Engineers who use these tools report real gains in individual output, but they still delegate only a small share of tasks all the way through, because getting useful work out of an agent takes active steering, not a human simply waiting on the result. That pattern will not resolve itself as models get better, because a model can read every line of a codebase and still have no way to read production: the years of request patterns, load-bearing code paths, and near-misses that never made it into a comment or a commit message are facts about the organization, not facts about the model.

The two-layer architecture underneath every AI coding agent

Every AI coding agent in production today is really two systems stacked on top of each other, and the confusion between them is why so many organizations end up with agents that are fully authorized to act and frequently wrong when they do.

The first system is the harness: sandboxing, approval workflows, role-based access control, audit logging. The harness answers one question, whether an agent is allowed to touch a given system, file, or environment. For the four leading coding agents on the market, this problem is largely solved; vendors have spent real engineering effort making sure an agent can be safely contained, monitored, and rolled back. The second system is the context layer: the business vocabulary, data ownership, lineage, and policy that decide whether the action the agent takes, once permitted, is the right one. A harness alone cannot tell an agent what a given metric means or who signed off on its definition, who owns a given table or pipeline and who an approval should route to, what broke the last time someone touched a particular service, or whether the policy the agent is operating under actually reflects how the company runs today. Those are governance and institutional questions, and no sandbox configuration answers them.

Consider a concrete failure: an agent asked to modify a shared API field makes a technically valid, fully-approved, properly logged change, and breaks three downstream consumers in another repository it never had reason to look at, because nothing in its context told it which schema was authoritative or who depended on the one it touched. The harness did its job perfectly. The change still shipped wrong. Cross-repo consumer mapping, field-level usage, and change-impact analysis are exactly the questions an agent needs answered before it can safely touch shared infrastructure it did not write, and they sit outside what any harness is built to provide. An organization can get every permission, every approval chain, and every audit log exactly right and still ship confident, fully-sanctioned, incorrect changes, because being allowed to act and being right about the action are two different problems solved by two different layers.

What organizational context actually consists of

Context, in the sense that matters here, is not something a model can derive by reading the repository more carefully. It lives in human heads, in meeting notes nobody wrote down formally, and in institutional memory that the codebase was never built to carry.

Five categories make up the context an agent needs before its work can be trusted at organizational scale. Business knowledge covers how the company defines terms like "customer" or "revenue" and which tables are the authoritative source for each; without it, an agent might compute "revenue" off a staging table that looked plausible and was wrong in a way no test would catch. Team expertise covers how a given team actually tests, reviews, deploys, monitors, and rolls back changes, since the same action can be safe on one team's pipeline and dangerous on another's. Policy norms cover who owns an affected system, which changes require a named approval, and what data cannot cross a given environment boundary, so a compliant change and a quiet violation nobody notices until an audit depend on them. Shared context means every agent across every tool in the organization works from the same approved definitions rather than each inventing its own understanding of what "active user" means this quarter. Portable context means all of this lives outside any one harness, reachable through an interface like MCP or an API, so it survives a change in tooling.

None of this can be inferred from source code, because code encodes what the system does, not why it was built that way, who is accountable for it, or what happened the last time someone got it wrong. A reasonable objection is that an agent could learn this over time, from past pull requests and old conversations, the way a human engineer gradually absorbs a team's norms. That approach rebuilds the same understanding probabilistically, inside a single agent's session memory, and it evaporates the moment an engineer leaves, a project changes hands, or the organization adopts a new agent harness. Context that lives only inside one agent's accumulated history is a private guess that has to be rebuilt from scratch the next time around, not organizational knowledge.

How MCP turns context into shared infrastructure

A standardized protocol for sharing context between tools, introduced in late 2024 and adopted widely through 2025 and 2026, gives organizations a way to hand governed context to any agent harness without rebuilding that context separately for each tool. An agent running inside Cursor can draw on the same servers as an agent running inside Claude Code or Codex. The fragmentation that used to lock context to one specific tool is closing.

That matters most at scale. On a monorepo too large for any one developer to check out in full, or across an estate running into the thousands of microservices, nobody can hold the full picture of ownership and dependency in their head, so context has to be gathered centrally and served out on demand. An MCP server fetches the relevant slice from a central catalog and hands it to the agent exactly when it needs it, rather than asking every engineer to reconstruct that map by hand each time they start a task. The alternative, asking every team to rebuild the same organizational understanding from scratch for every new agent harness it adopts, does not hold up as the organization grows, and it disappears entirely whenever the people who built that understanding move on.

Coding workflows already lean on a cluster of MCP servers for operational context: Filesystem MCP, GitHub MCP for issues, pull requests, code search, and repository state, Git MCP, Linear MCP, Sentry MCP, and widely used servers like Context7 and Playwright MCP. What they do not solve is governed business context: who owns a given table, what a metric means, which approvals a change requires. A context layer delivered through MCP needs to carry the same vocabulary, ownership, and lineage with a team no matter which harness that team adopts next, and that portability is the real test any model-agnostic context layer has to pass. Retrieving documents from a wiki through a retrieval system and serving governed context through MCP both involve fetching content, but a context layer also resolves who owns a piece of data, what policy governs it, and where it came from. A stale wiki page that nobody has updated in two years and a governed, certified data definition are not interchangeable inputs, even if both can technically be retrieved by the same kind of query.

Individual Engineers in the New Division of Labor

The contribution an engineer cannot be replaced for is no longer the code they type. It is the organizational context they hold, the history of what broke, what the team's actual norms are, why a given system was built the way it was. Most organizations today are putting that contribution in exactly the wrong place.

Software engineering, under this shift, increasingly means directing agents that write the code, checking their output, setting strategic direction, and making sure the system as a whole is solving the right problem, rather than spending most of the day writing code directly. The common mistake organizations make is handing AI tool licenses first to senior engineers, including during pairing sessions with new hires. The senior engineer gets faster at producing answers. The new engineer still waits in a queue for those answers, because the license sat with the wrong person.

The better arrangement runs the opposite direction. The new engineer holds the tool for codebase questions, tracing dependencies, and generating hypotheses about how something works, and the senior engineer is pulled in only for the questions an AI genuinely cannot answer well: product strategy, organizational history, decisions that were made in a meeting three years ago and never written down anywhere an agent could read. Anthropic's own engineering organization offers a concrete signal that this division works: pull request throughput grew even as headcount doubled, the reverse of what normally happens when a team hires fast and spends a quarter absorbing new people before output recovers. At TELUS, teams built thousands of custom AI solutions, shipped engineering code faster, and saved hundreds of thousands of hours, a scale that is only reachable when context is built and maintained as shared infrastructure rather than something each senior engineer re-explains by hand every time someone asks. Where an organization routes its senior engineers' time is a decision about where the organization's scarcest resource, context, actually gets used, not just a scheduling detail.

Why individual gains aren't yet becoming project-level velocity

A randomized controlled trial found that developers using AI tools took meaningfully longer to finish their tasks while believing they had worked meaningfully faster. That gap between what engineers felt and what actually happened points to where the real cost of missing context is accumulating: not in the moment of writing code, but downstream, where someone else has to catch what the agent got wrong.

Review time increases substantially, pull requests grow larger, and review cycles slow down on teams with high AI adoption, and incremental delivery and review turnaround slow in the same way across engineering organizations more broadly. That cost lands squarely on senior engineers, who end up being the ones who supply, after the fact, the organizational context the agent never had before it wrote the code. DX's Developer Experience Index fell from 67 to 65 over four quarters, even as documentation quality, code maintainability, and onboarding speed all improved in the same period. The gains appear in documentation and maintainability while the losses appear in review burden and cycle time, and the net effect on developer experience is currently negative.

This has a direct consequence for how organizations should read their own metrics. Individual-output numbers, lines of code shipped, pull requests opened, will look good, while project-level numbers, cycle time, review throughput, incident rate, will keep degrading, and the distance between those two sets of numbers is itself evidence of a context problem rather than a tooling problem. None of this argues against using AI coding agents. It argues that the context layer is not an optional add-on to be installed after the fact; it is the infrastructure individual gains must pass through to reach the project level.

What Onboarding Shows About Context

Onboarding a new engineer is the cleanest test available of whether an organization's context is genuinely transferable, because a new hire arrives with real technical skill and zero institutional history, which is precisely the position an AI agent is in on every single task, every single time.

The gain from giving that new engineer a capable agent is large when the agent is used for codebase questions, tracing dependencies, and forming hypotheses, and the senior engineer's calendar correspondingly opens up for only the questions that genuinely require seniority. The gain is small when the license instead sits with the senior engineer and the new hire keeps waiting. What an early pull request from a new hire actually measures is not how fast they can produce code. It measures whether the organization's context has been made legible enough that someone with no institutional memory can act on it correctly. A new hire paired with a powerful agent but no access to governed business context will produce answers faster, and those answers will be wrong: the pull request is merged in week one, and the revert follows in week two. The organizations seeing durable onboarding gains, by contrast, are the ones investing in what Anthropic Engineering calls codebase setup, layering CLAUDE.md files and skills so an agent like Claude has enough grounding to navigate the codebase well from the start. That investment is a direct, practical instance of the same argument running through the rest of this piece: context that has been made explicit and shared outlasts context that lives only in one person's head.

The security perimeter expands with the context layer

As business vocabulary, data ownership, policy, and lineage move into AI infrastructure, where that infrastructure physically runs starts to determine the attack surface around the most sensitive knowledge a company has.

A cloud-hosted agent processes prompts on a vendor's external servers and uploads codebases to remote vector databases, meaning proprietary source code travels across the public internet to get indexed and queried. A self-hosted agent runs entirely on-premises or inside the company's own virtual private cloud, indexing code on internal network storage that never leaves the organization's perimeter. Choosing between these two models used to be treated mostly as a compliance checkbox, something legal or security signed off on once and rarely revisited. Once the context layer carries not just source code but the organization's full map of data ownership, policy, and lineage, that choice becomes an architectural decision about where the company's most sensitive institutional knowledge is allowed to live, and it deserves exactly that level of scrutiny going forward.