The Context Tax: Your Developers Are Doing Unpaid Platform Work Every Session

An essay published on dev.to under the handle vscarpenter argues that the ritual developers perform before every agent session - paste the deployment standard, link the runbook, explain what the criticality tiers mean - is not developer work but unclaimed platform work ^[1][2]. It matters because the author's central observation is a cost curve, not a complaint: the better an AI rollout goes, the more hand assembly the organization performs, so success makes the problem bigger ^[10].

The ritual has a second act. After the gathering comes the correction, where the developer talks the agent out of a confident guess about a naming convention the team retired two years ago, and then does the whole thing again tomorrow because the agent will not remember ^[3]. Meanwhile every guide to working with AI keeps repeating the same instruction to give the model good context, which pushes developers to hunt for it one session at a time, across systems that were never built to answer an agent's questions ^[4].

Compare the accounting. A new engineer pays the onboarding cost once and amortizes it over years of context, hallway conversations, and scar tissue ^[7]. Agents may hold instructions, memory, or project state, but none of that tells them which standard is authoritative, which exception still applies, or which decision was reversed six months ago ^[6]. So the per-hire cost becomes a per-session cost, repeated across hundreds of engineers who rediscover the same standards, fork the same repo, re-paste the same runbooks, and retype the same corrections ^[8][1].

The output quality is stratified, too. Strong engineers assemble excellent context and get excellent output; everyone else gets whatever the search index returns first, which is often the three-year-old wiki page that still outranks the current standard ^[9].

The evidence that this is platform work is already sitting in the repos. Every CLAUDE.md, every AGENTS.md, every set of AI rules is a developer hand-building a context layer one repository at a time, and the author's read is that when many teams independently build the same scaffolding, a platform capability is waiting to be claimed - the same pattern that produced shared build scripts, deploy tooling, and observability config ^[11]. That is a plausible definition of the platform team's job: absorb work that every delivery team would otherwise repeat ^[15].

The inventory is not small. An agent doing real enterprise work needs service ownership and dependencies, approved architectural patterns, tier-specific deployment requirements, API definitions, security classifications, observability conventions, naming standards, environment details, coding conventions, runbooks, and enough operational history to know which integration test has always been flaky ^[13]. It lives in Git, the developer portal, Confluence, tickets, Slack, and people's heads; the scatter is old, but the price of the scatter changed, because an agent cannot walk over to your desk and ask ^[14].

The author's warning about the fix is the useful part. A crawler, a vector database, and a chat window demo well on a Friday and solve discovery, but discovery is not authority, and the scarce resource in an enterprise drowning in context is trusted context ^[17][18].

Watch two things. First, whether platform teams ship a context surface that carries authority markers - current versus superseded, exception still live, decision reversed - rather than a search box ^[6][18]. Second, count the hand-built AGENTS.md files in your own estate; that number is the size of the capability you have not claimed ^[11]. The version of the essay published on dev.to breaks off mid-sentence at "Retrieval without an authority mo", so the proposed authority model itself is not visible in the text ^[19].