Context Engineering at Scale: Why Shared Context Beats Token Counts

AI coding tools finally have a sense of direction. Prompts led to specifications, specifications to context engineering, context to harnesses and loops. But while the technology stack is settling, most organizations haven't changed shape to match it. That gap between technical maturity and organizational maturity was the core of a fascinating conversation on The AI Native Dev podcast, recorded at AI Engineer in San Francisco with Patrick Debois, the godfather of DevOps.

Debois has spent his career studying what new technology does to organizations, from cloud to DevOps to mobile. His view of the current moment: the pieces are stabilizing, but the org charts aren't. His new research project, an auto-generated patterns site at Tessl.io/patterns, is an attempt to map that shift as it happens.

From Prompt Engineering to Context Engineering: A Stack That Compounds

A common worry among developers is that the ground keeps moving: first prompts, then context engineering, then harnesses, then loop engineering. Debois pushed back on the idea that this is churn. "Prompts and specifications will be a keeper. Harnesses and context will make sense," he explained. Each layer adds on top of the previous one rather than replacing it.

To make sense of where a team sits, Debois finds it helpful to plot work across three modes: solo, shared, and multiplayer. A developer refining their own setup is in solo mode. The unlock comes when context moves to shared mode: skills in the repo, reusable harnesses, centralized evals. "If one team kind of optimizes it, everybody has an optimization," he noted. That compounding effect is what separates AI agent context management as an individual craft from context engineering as an organizational capability.

What Is AI Agent Context Management at the Platform Level?

AI agent context management is the practice of maintaining the shared context, rules, skills, and harnesses that steer coding agents, treating them as versioned, tested platform components rather than personal settings. Done well, it lets one team's improvement propagate to every team using the same components.

In practice, Debois expects platform and developer experience teams to own this layer, much as they own CI/CD today. They already run MCP proxies and registries; centralized evals and shared harnesses are the natural next additions. This suggests the platform team, often overlooked in AI conversations, may be the piece that unlocks large organizations.

Measuring Adoption: AI Agent Evals and the Trouble with Token Counts

Most organizations measure AI adoption in stages: first license counts, then token usage. Debois argued both are proxy metrics that reward enthusiasm over efficiency. Heavy users "might not be using this quite efficiently," he observed, running the biggest model on repetitive tasks that a context change or harness change would solve permanently.

His alternative measurement is pointed: track how much people contribute to shared components, and "how many touches does the human still need to do for an agent to do the right thing." Fix the system once and the numbers improve across every team. The budget conversation follows the same logic. Rather than capping spend when costs spike, he recommends observability first, then habits, echoing the FinOps playbook from the cloud era, when every workload started as an expensive VM until teams learned to consolidate.

Verification is evolving in parallel. Beyond LLM-as-judge evals, Debois sees mature teams building custom review tools, and he expects the agent itself to take on the job of convincing you the work is correct, with screenshots and recordings rather than just a pull request. That, he argued, is why the IDE is returning as the review interface even as code writing moves to the CLI.

The Organizational Shift: Skeptics, Success Stories, and New Roles

For engineering leaders driving adoption, Debois offered a transformation playbook straight from the DevOps years. Find the success story first and resist the urge to convert resisters early: "Do not spend time on the negatives in the beginning. If you can't make that work, the rest will not work." Team leads set the cadence of learning, deciding when the whole team jumps from prompting to shared context to harnesses.

His most practical tip inverts the usual dynamic with skeptics: get them to write the context and build the harness. The complaint that the tool "isn't good enough" often means nobody has invested in making it better.

Hiring changes too. The profile Debois looks for now is the system thinker: someone who cares about improving the whole pipeline, collaborates on shared components, and switches languages without complaint. Elegant code matters less; taste still matters. And for developers who signed up to code rather than to write specifications, harness and loop engineering offer a deeply technical path forward.

The through-line is speed of learning. In a world where generation is cheap, the organizations that win appear to be the ones that compound knowledge fastest, even if that means rewriting a codebase along the way. Where is your organization on that curve, and what's holding it back? The full conversation is worth a listen.