Context-driven development (CDD)

A named discipline for AI-assisted coding, introduced by Google’s Conductor launch post (Developers Blog; Keith Ballinger, Jay Kornder, Sherzat Aitbayev). Its core move: treat project context as a managed artifact alongside your code — a persistent, reviewable single source of truth that “drives every agent interaction” — rather than letting intent live in ephemeral chat sessions.

The positioning (a third point on a spectrum)

The post frames CDD against two alternatives:

Vibe coding — jump straight to code, intent improvised in chat and lost when the session ends.
spec-driven-development — agree a written spec before generating code (the reviewable-artifact discipline this wiki already tracks).
Context-driven development — go further: not just a spec for this change, but the whole context (product definition, tech stack, workflow standards) kept as durable Markdown next to the code, so every future agent interaction inherits it. The pitch: “plan before you build, review plans before code is written, and keep the human developer firmly in the driver’s seat.”

So CDD is spec-driven-development widened from spec-before-code to context + spec before code, with the context persisting across tracks, sessions, and team members.

How Conductor operationalizes it

Conductor is the reference implementation: /conductor:setup captures the durable context; /conductor:newTrack produces a spec + a plan.md (Phases → Tasks → Sub-tasks) with a mandatory plan-review gate; /conductor:implement executes with file-persisted state so work resumes across sessions. The context is the artifact; the tool is the executor — the same “capability and process encoded as markdown an agent executes” pattern the spoke keeps seeing (cf. spec-driven-development, get-shit-done).

Why it matters

It names the far end of the structure-before-code trend: as agents do more of the typing, the durable human contribution shifts to curated context, versioned and reviewed like code. That it comes from Google/Gemini CLI shows the Gemini side converging on the same governance patterns as the Claude side — the harness competition is increasingly about planning/context discipline, not raw code generation.

The premise is now contested (added 2026-08-03)

CDD’s whole argument is that durable project context, kept as reviewable Markdown next to the code, makes every agent interaction better. context-files-ablation-paper tested the nearest available proxy for that claim — AGENTS.md-style project context, delivered three ways — and found no measurable effect on correctness on either Claude Code or Codex across 288 evaluated runs.

The fit is not exact and the difference cuts both ways. What the paper ablated was naturalistic style-guide context (conventions, architecture notes, error-handling rules) and the channel it arrives through, not CDD’s fuller artifact of product definition plus tech stack plus workflow standards, and its own recommendation carves out “purpose-built, task-specific context” as untested. So CDD is not refuted. But the burden has moved: the belief that a well-maintained context artifact raises output quality is the thing that was measured and did not appear, and Google’s post offers no measurement of its own.

The one effect the paper did find is worth CDD’s attention because it is so specific. Context reduced wasted work — blind full-suite test runs, and wall-clock with them — on the single repository whose file warned about a cost the agent could not observe. That is context earning its place on operational grounds, which is a narrower and better-evidenced claim than the one CDD makes.

Tier

T1 — first-party Google Developers Blog (the methodology’s own articulation). freshness: volatile — Conductor is a preview extension and the framing is new; the term’s adoption beyond Google is unproven.

conductor · spec-driven-development · agentic-coding-harness · agent-skills · get-shit-done · google · context-files-ablation-paper · agents-md