Whose Code Counts: Context Engineering, Privilege, and the Ethics of AI-Assisted Development

The discipline of Context Engineering For Code is being sold as a productivity upgrade — a smarter way to feed information to an AI assistant so it produces better code. That framing is technically accurate and politically empty. The moment a method for shaping AI behavior costs ten times more for one developer than another, it stops being a workflow and starts being a filter. A filter on whose code reaches production, whose problems get solved cleanly, and whose work the next generation of models will learn from.

The Question We Are Quietly Avoiding

We celebrate every new context window expansion, every cleaner integration of Model Context Protocol into IDEs, every step toward Agentic Coding systems that can read entire repositories and make changes on their own. The conversation about whether the assistant can do the work is loud. The conversation about who gets to use the version that actually works is barely audible.

Context engineering — described by Anthropic Engineering as the discipline of curating the optimal set of tokens an LLM sees during inference — is not just a technique. It is the layer where an AI assistant either understands your codebase or hallucinates around it. Context is now treated as a finite “attention budget,” directional and load-bearing (Anthropic 2026 Agentic Coding Trends Report). The richer that budget, the more useful the assistant. And the richer that budget, the more expensive the tooling that maintains it.

So the question we are avoiding is not whether AI coding tools work. It is what happens when the quality of the assistant tracks the price of the seat.

What the Productivity Story Gets Right

The case for AI-assisted development is real, and it would be dishonest to pretend otherwise. A well-engineered context layer genuinely reduces tedium. It helps a developer move through unfamiliar code, plan an AI Code Migration, or draft boilerplate that would otherwise eat an afternoon. The thoughtful version of Vibe Coding — where an experienced developer uses an assistant to externalize working memory while keeping their own judgment in the loop — is not a regression. It is closer to the original hacker ethic of getting more done with the tools at hand.

Adoption confirms it. The Science paper by Hartley and colleagues estimates that contributions to AI-coded GitHub commits already range between twelve and twenty-four percent across major economies. Anthropic’s own framing positions context engineering as the natural progression of prompt engineering — a maturing discipline rather than a fad. And the Model Context Protocol, introduced by Anthropic in November 2024, has grown into a shared standard adopted by OpenAI and Google DeepMind, with MCP Roadmap 2026 reporting a 232 percent increase in available servers between August 2025 and February 2026.

This is the steelman. Context engineering is a real discipline, the tools are improving, and serious developers are getting serious work done. None of that is in dispute.

The Assumption Hidden in the Price Tag

What the productivity story quietly assumes is that everyone arrives at the assistant with comparable resources — a fast laptop, a stable connection, a paid subscription, and the time to learn how to engineer context properly. Strip those assumptions and the productivity narrative thins out fast.

The “Max” tier of leading AI coding tools sits in the one-hundred-to-two-hundred dollar per engineer per month range, while many companies — especially outside high-income markets — can stretch to only about twenty dollars per engineer per month (The Pragmatic Engineer). That is the visible inequality. The invisible inequality is what those tiers actually buy: longer context, better retrieval, more capable models, faster turns. Two developers with identical talent now sit at unequal interfaces to the same underlying intelligence.

The Hartley study makes the structural pattern explicit: the benefits of generative AI coding depend on users’ prior technical foundations. AI doesn’t lift everyone equally. It amplifies whoever was already positioned to ask good questions of it.

And the bias is not only economic. The Matthew Effect runs through the model itself. A 2026 arXiv preprint on the Matthew Effect of AI programming assistants shows mainstream languages and frameworks receiving significantly higher success rates than niche ones, creating a feedback loop where data-rich ecosystems get superior AI support — and where work in less popular stacks becomes harder, not easier, over time. A DEV Community analysis adds a quieter detail: AI coding tools default to Python for performance-critical tasks fifty-eight percent of the time, even when other languages might be objectively better. The assistant is not neutral. It has opinions about which code counts.

A Bureaucratic Parallel

There is a useful historical mirror for this. Twentieth-century bureaucracies promised universal access to public services, then quietly produced two different experiences of the same office: one for citizens who knew how to work the forms, hire intermediaries, and arrive prepared; another for everyone else. The forms were identical. The outcomes were not.

Context engineering is the bureaucratic form of the AI-assisted era. Two developers submit the same intent — “refactor this service,” “write tests for this module,” “explain this regression.” But one arrives with a curated context layer, a private MCP server pointing at internal documentation, a paid subscription that retains memory across sessions, and an organization that trained them on prompt patterns. The other arrives with a free tier and a generic chat box. The form is identical. The outcomes are not.

What makes this harder than the bureaucratic case is that the gap is invisible from the outside. The output looks like code. Code looks like code. The seams between a well-contextualized session and a thinly-contextualized one only show up later — in a CVE, in a production incident, in a junior developer who cannot debug what they pushed because they never understood it in the first place. Vibecoding.app’s debate roundup reports that forty percent of junior developers push AI-generated code without fully understanding it, and that sixty-three percent of developers spend more time debugging AI code than they would have spent writing it themselves. The gap leaks downstream.

The Thesis

Context engineering is becoming the access layer where AI development inequality compounds. It is not a neutral technique. It is the price-gated mechanism that decides whose intent gets translated into competent code and whose intent gets translated into a plausible-looking liability.

The evidence is converging. SQ Magazine’s 2026 statistics, drawing on AppSec Santa research, report that roughly one in four AI-generated code samples contains a confirmed security vulnerability mapped to the OWASP Top 10, with seventy-four CVEs as of March 2026 directly linked to AI-generated code — twenty-seven of them tied to Claude Code, four to GitHub Copilot, two to Devin. These are not exotic failures. They are the predictable consequence of asking systems to write code on behalf of users who lack the context, the tooling, or the training to verify what came back. Kenneth Reitz put it more bluntly in his 2026 essay on the hacker ethic and the vibe coder: “access has leapt ahead of understanding, and the gap is growing.”

When the cost of poor context falls on the developers least equipped to absorb it, the ethical question is not whether AI coding tools should exist. It is whether we should keep pretending they offer the same thing to everyone.

Questions to Sit With

What does informed consent look like for a developer pushing code they did not write and cannot fully read? Whose interests are served when the most reliable AI coding workflows require subscriptions priced for venture-backed companies, while the rest of the industry — and most of the world — is invited to settle for the cheaper version?

If the next generation of models is trained partly on the code we are generating now, what worldview is being encoded into the next decade of software when most of that code originates from a narrow band of well-resourced developers using premium tools? And what becomes of the engineering judgment we say we value when “convenience” is the loudest argument in the room?

Where This Argument Is Weakest

This thesis has a real soft spot. If tier pricing flattens — if free tiers improve quickly enough, if open-weight models close the capability gap, if the Model Context Protocol matures into a genuinely portable standard — much of the inequality I am describing becomes transitional rather than structural. Open-source agentic coding frameworks are moving fast. So is the regulatory conversation: the EU AI Act’s General-Purpose AI obligations begin to bite in August 2026, and they at least open a venue where access asymmetries can be discussed publicly. If those forces arrive in time, the privilege story softens. I would be glad of that outcome.

The Question That Remains

If software is the medium through which the digital world is built, and context is the medium through which AI assists in writing software, then context engineering is quietly becoming the layer where authorship, access, and accountability all converge. The question we owe ourselves is not how to optimize our prompts. It is whose code we are willing to live inside — and whose voice we are willing to lose along the way.