Agentic Development

The phrase "AI-assisted development" has a precise implication embedded in it: human development assisted by AI. The human is the actor; the AI is the tool. The human proposes; the AI helps implement. The human reviews; the AI explains. This is a valuable paradigm — it makes human developers faster — but it is not the paradigm that is collapsing the existing model of software engineering governance.

Agentic development is. It is the paradigm where the AI is the actor: proposing, implementing, committing — with the human designing constraints and reviewing outcomes rather than generating at each step. That inversion is not a marginal change. It makes the entire architecture of existing governance systems structurally inadequate.

What agentic development actually means

The operational definition: AI agents operate autonomously across files, services, and architectural boundaries without asking permission at each step. An agentic coder doesn't suggest a function and wait for approval — it reads the codebase, understands the context, writes the feature, updates the tests, and commits the changes. The human's involvement is bounded: they specify requirements at the start and review outcomes at the end.

This autonomy across architectural boundaries is the critical element. An agent writing a feature might:

• Choose which database driver to use based on what it sees in existing code — right or wrong.
• Select an error handling pattern from the codebase without knowing which patterns are deprecated.
• Import a library that has been organizationally banned because of a security decision made six months ago.
• Structure a new service in a way that violates an ADR about service boundaries — an ADR the agent was never told about.

Each of these choices is locally plausible — the agent is making reasonable inferences from what it sees. Each is potentially a serious architectural violation — made by an actor that has no intrinsic knowledge of the decisions that humans made and documented.

Why this problem exists structurally

The structural problem is that human oversight models don't scale to agent output velocity. This is the central incompatibility between agentic development and existing engineering governance.

In human-only software development, the oversight model is: (1) human proposes, (2) PR review approves or rejects. This model works because human proposal speed is the bottleneck — there are roughly as many proposals as reviewers can meaningfully evaluate. The oversight cost is proportional to the generation cost.

In agentic development, the proposal speed increases by 10–100x. The review model doesn't scale: reviewers have the same bandwidth they always had, but are now receiving 10–100x the throughput. One of three things happens:

1. Review quality degrades. Reviewers rubber-stamp to keep pace. Governance becomes nominal — the process exists but the enforcement doesn't.
2. Throughput throttles. The team constrains agent velocity to match review capacity, losing the productivity gain. Governance survives at the cost of the benefit.
3. Governance moves upstream. Architectural decisions are encoded, distributed, and enforced before generation completes — eliminating violations rather than reviewing them after the fact.

Agentic development names the paradigm that makes option (3) necessary. Teams that adopt agentic workflows without moving governance upstream discover options (1) and (2) empirically — usually through accumulated architectural violations that surface months later.

The common misread: AI as productivity tool

The most widespread failure mode is treating AI coding agents as productivity tools for human developers and applying the same governance model. This misread is understandable — for the first generation of AI coding tools, it was accurate. GitHub Copilot, early Claude Code, early Cursor — these were genuinely AI-assisted development: humans still drove the generation loop, and existing governance models applied with minor adjustments.

The misread becomes structural when teams adopt agentic workflows — autonomous agents operating without human proposal at each step — but don't redesign the governance model. The symptoms:

• PR review volume increases without a corresponding increase in review depth. Reviewers approve faster, not better.
• Architectural violations accumulate in merged code — each locally plausible, collectively incoherent.
• Teams invest in better CLAUDE.md files, longer context windows, more comprehensive prompt engineering — improvements that help within a session but don't address the cross-session, cross-agent governance problem.
• Senior engineers spend increasing time on architectural debt remediation rather than new development — the opposite of the productivity promise.

The diagnosis is that the governance model was designed for human-speed development and has been applied unchanged to agent-speed development. It was designed for a different bottleneck.

How this fits the AI SDLC

Agentic development is the paradigm that makes architectural governance infrastructure necessary rather than optional. In human-only development, cultural norms and code review are sufficient governance. In AI-assisted development, they are still mostly sufficient — the human is still in the generation loop. In agentic development, they are structurally insufficient — there is no human in the generation loop to apply cultural norms.

The consequence: architectural decisions must be encoded, distributed, and enforced mechanically. "Encoded" means the decision lives in a version-controlled, machine-readable corpus — not only in a document or a team wiki. "Distributed" means every agent that operates on the codebase receives the relevant decisions at generation time — not just the agents whose users remembered to configure governance. "Enforced" means the governance system produces a binary verdict before generation completes — not a suggestion, not a style warning, but a blocking check.

This is the transition from governance as a team practice to governance as engineering infrastructure. It is the same transition that happened with security (from "developers should write secure code" to "security testing in CI"), with reliability (from "developers should handle errors" to "error handling linting"), and with performance (from "developers should profile their code" to "performance benchmarks in CI"). Each time, a practice that worked at human scale became infrastructure at machine scale.

The multi-agent context

Agentic development frequently involves not one autonomous agent but multiple agents acting on the same codebase in a coordinated pipeline: a planner agent that decomposes requirements, a coder agent that implements features, a reviewer agent that checks for obvious issues, a CI agent that runs governance gates. Each agent has its own LLM instance, its own context window, its own session lifecycle, its own failure modes.

The multi-agent context is where existing governance models fail most visibly. A CLAUDE.md file configured for the coder agent doesn't automatically propagate to the reviewer agent. A governance configuration set up for one engineer's Claude Code session doesn't apply to another engineer's Cursor session operating on the same codebase. Each agent is an independent actor with independent context — and without shared governance infrastructure, they receive inconsistent architectural constraints.

Consistent governance across heterogeneous agents requires the governance to live in a shared external corpus, not in any agent's configuration. Every agent queries the same corpus; every agent receives the same constraints. The architectural decisions are not owned by any single agent's session — they are owned by the corpus, which is the shared architectural authority for the entire codebase regardless of who or what is operating on it.