The bottleneck in engineering has moved. It’s no longer writing code. It’s framing the problem so an intelligent system can solve it correctly.
The two-hour bug and the thirty-minute fix
Two engineers. Same codebase. Same bug: an intermittent null pointer in a payments webhook.
Jane opens the file. Runs the test. Reads the stack. Checks git blame. Scans related services. Pings a teammate. Two hours later she finds it: the retry policy was reversed in Q4 and the test harness still pretends it wasn’t.
Bob spends twenty minutes assembling context. He reads the ADR that reversed the retry policy. He pulls the last three commits that touched the webhook. He copies the relevant section of the runbook and the service’s context file into Claude Code. Then he hands the bug to the agent with one instruction: “Reconcile the actual retry behaviour with the stubs. Show me the fix and the test update.” Thirty minutes later, the PR is open.
Jane is faster at writing code. Bob won anyway. That’s the shift.
Context-Driven Development (CDD) is the paradigm underneath Bob’s workflow: treat context as a first-class primitive (composable, versioned, reusable), and the engineering craft stops being about typing and starts being about framing. This issue covers what that actually means, how it works, and what breaks when teams don’t take it seriously.
From code-first to context-first engineering
For sixty years we’ve built engineering primitives in the same direction. Functions. Objects. Services. Tests. Each one a new unit of abstraction the engineer could reason about, compose, and own.
Every one of those primitives assumes the human is the reasoning engine. You write the function. You compose the objects. You run the tests. The primitive exists to help a human think clearly.
LLMs changed the loop. There’s now a second reasoning engine in the room, and it reads your intent from the material you give it. Which means the primitive that matters isn’t code anymore. It’s context. The structured totality of information that shapes a model’s output: code, docs, constraints, conventions, intent, history. All of it.
Noah Gift caught this in January 2025, calling CDD:
CI/CD for AI-assisted programming.
Reach back further and you hit Peter Naur’s 1985 paper Programming as Theory Building, which argued programming was always about constructing shared understanding, not producing code. AI just made the cost of ignoring that thesis impossible to hide.
You no longer write software; you curate the conditions under which software gets written.
What “context as a primitive” actually means
“Primitive” has a specific meaning in computer science. It’s a foundational building block that other abstractions get built from. Integers are primitives. Pointers are primitives. Well-typed values are primitives.
Calling context a primitive means something real: it has the three properties that separate a primitive from an ad-hoc artifact.
Composable. Two context packs can be combined into a third. The service’s AGENTS.md + the ticket’s acceptance criteria + the relevant runbook section = a fresh context for this specific task. You don’t rewrite, you assemble.
Versioned. Context lives in git. Changes have diffs. You can roll back a bad edit the same way you roll back a bad commit. This is the move Pavel Buchnev made with CTX: context generated from a declarative context.yaml, reviewable in a pull request, reproducible across sessions.
Reusable. The same context artifact works across tasks, services, and (increasingly) across agents. The antigravity-awesome-skills library has 1,400+ skills running across Claude Code, Cursor, Codex, and Gemini CLI. Context written once; agent choice swappable.
If those three properties sound familiar, they should. They’re the properties that made code a primitive too. That’s the point. We’re building the same discipline around a different material.
It’s also why prompt engineering isn’t the same thing. Prompts are artifacts. Context is the underlying material. Prompt engineering is what you do per-turn; context engineering is what you maintain across turns, tasks, and teammates.
The four layers of engineering context
When you strip a real engineering task down to the context feeding the agent, you’ll find four layers stacked on top of each other.
Ambient context is what’s always true about the codebase: repo structure, naming conventions, style guide, dependency graph, the service topology. This is the background radiation. Most teams have it partially written down: in READMEs, in a CLAUDE.md, in tribal knowledge. CDD is the practice of making it explicit.
Task context is what this specific piece of work requires: the ticket, the acceptance criteria, the edge cases, the constraints. This layer is ephemeral and sharp. It changes per task.
Historical context is what you’ve already decided: ADRs, the last three commits that touched the file, past bugs, post-mortem notes. This is the layer that prevents re-litigating decisions and repeating mistakes. Patrick Debois calls the absence of this layer “cowboy coding of context.” He’s right.
Operational context is what’s true in production right now: current error rates, recent traces, live config, feature flag state. This layer is perishable in hours, not weeks. It’s also the one most teams never feed the agent at all, and then wonder why the suggestions feel disconnected from reality.
An AI-native engineer composes across all four. A traditional engineer usually only pulls from the first two, and wonders why the agent gets things half-right.
The practical techniques
Five techniques, in the rough order teams adopt them.
Context packing. Deciding what goes into the window vs. what gets retrieved on demand. Anthropic’s context-engineering paper from September is the cleanest statement of why this matters: models have a finite attention budget, transformers scale n² with context length, and past a threshold more tokens actively make the agent worse. Packing is the discipline of picking the smallest high-signal set.
Scoped retrieval over dumps. RAG, semantic search, well-crafted grep, repo-scoped MCP tools. The goal is the same: don’t dump the whole codebase; give the agent a search surface it can pull from. Birgitta Böckeler and Martin Fowler’s February 2026 piece on context engineering for coding agents walks through the concrete tactics. Their bluntest observation: “Almost all forms of AI coding context engineering ultimately involve a bunch of markdown files with prompts.” That’s the cleanest summary of where the discipline actually lives in 2026.
“Almost all forms of AI coding context engineering ultimately involve a bunch of markdown files with prompts.” - Birgitta Böckeler
Context files as versioned artifacts. CLAUDE.md, AGENTS.md, .cursorrules, spec files. Not ad-hoc scratch files. Not individual developer preferences. Team artifacts, reviewed via PR, owned by a named person. This is the simplest adoption step, and the one most teams haven’t taken.
Subagent delegation and context isolation. Big tasks split across specialised agents, each with a narrow context window. A reviewer agent doesn’t need the full codebase; it needs the diff and the style guide. A test-generator agent doesn’t need the product roadmap; it needs the function signature. Isolation prevents context poisoning. One stale file can otherwise corrupt every downstream call.
Context compaction and summarisation. Long-running sessions, long-lived projects. Context accumulates and eventually overflows. Compaction is the recurring practice of summarising older context into denser form, keeping the active window lean. Patrick Debois treats this as a first-class stage in his Context Development Lifecycle. It’s the most overlooked technique on this list and the one you’ll need earliest in a long engagement.
These are the moves. None of them are exotic. What’s new is treating them as primitives of the craft rather than clever hacks.
What’s below the subscribe wall
We’ve covered the paradigm shift, what makes context a primitive, the four layers, and the five techniques.
Below: the new skill set this demands, the team-level implications (including a role you probably don’t have yet but will), the failure modes I watch for, and where the tooling is going over the next 18 months. Plus the quarterly question every engineering leader should be asking themselves.
If this is landing, keep reading.
