Skip to content

Knowledge base

Architecture work in the agentic era

When agents write most of the code, the engineer's job moves to architecture: placing boundaries, stating intent and constraints, and judging quality. Cheap implementation raises the value of design, because an agent without a sound design model only produces a mess faster.

Written by

Updated:

Agentic Engineering 5

Our position. We hold that code generation is solved (opens in a new tab) and what remains is the cost of being wrong about the design. Depth is a property an agent will not optimize for unless a human names it, asks for it and reviews for it (opens in a new tab), because that judgment is taste and does not compress.

Why does architecture matter more when agents write code?

Anthropic’s 2026 trends report predicts that most tactical work of writing, debugging, and maintaining code moves to AI while engineers focus on architecture, system design, and strategic decisions about what to build; the value of an engineer’s contribution shifts to system architecture design, agent coordination, quality evaluation, and problem decomposition (2026 Agentic Coding Trends Report). Field evidence points the same way: a 2025 study surveying 99 experienced developers, with field observations of 13, found professionals delegate boilerplate and scaffolding but retain control over complex business logic, security-critical code, and architectural design (Professional Software Developers Don’t Vibe, They Control (opens in a new tab)), and code review is shifting from line-by-line reading toward pattern and architecture review (Vibe Coding vs. Agentic Engineering).

The discipline is starting to codify itself in pattern language. The linked article introduces Agentic Engineering Patterns as a chapter-based guide, loosely modeled on the 1994 Design Patterns book, opening with the observation that the cost of producing initial working code has dropped to almost nothing, which breaks existing intuitions about how individuals and teams work (Writing about Agentic Engineering Patterns (opens in a new tab)). A parallel community catalog collects 51 patterns, 10 anti-patterns, and 15 obstacles for AI-augmented development, with explicit relationships between them (Augmented Coding Patterns (opens in a new tab)).

New structural proposals are appearing as well. Capability-Centric Architecture argues that layered, hexagonal, and clean architectures fail when systems span the embedded-to-enterprise spectrum or absorb AI components, which have their own infrastructure, versioning, and inference characteristics; it proposes composing systems from capabilities, each a nucleus of essence, realization, and adaptation, connected through contracts that declare provisions, requirements, and protocols so capabilities can evolve independently (Capability-Centric Architecture (opens in a new tab)). A capability registry enforces this mechanically, rejecting any binding that would create a circular dependency and forcing a restructuring that yields cleaner boundaries; evolution envelopes make versioning, deprecation, and migration a first-class mechanism per capability; and efficiency gradients let one capability run a bare-metal critical path and a fully abstracted storage path inside the same boundary (Capability-Centric Architecture (opens in a new tab)).

For products that embed agents, The agent-native architecture guide sets parity (whatever the user can do through the UI, the agent can do through tools) and granularity (tools are atomic primitives, features are outcomes described in prompts) as the foundational principles, and distills a general design rule: design for what agents can reason about, which in practice means structures a human could understand by looking at them (Every - Agent-native Architectures (opens in a new tab)).

The human’s job in this arrangement is architecture, not typing. The Modern Software Engineering talk frames the real constraint as cognitive rather than mechanical: the limit on how fast agentic development can go is how quickly one learns the problem and manages the complexity, not how fast the model emits valid syntax, and without a sound design mental model the agent mostly helps you make a mess faster (Modern Software Engineering (YouTube) (opens in a new tab)). Some teams make the division of labor absolute. The System Initiative team ships an open-source CLI where humans own only the design decisions, constraints, and invariants while agents write every line, enforced by deleting any pull request a human wrote; their one-line summary is that intent is the new architecture and context is the new code (If humans architect the system, the AI writes the code (YouTube) (opens in a new tab)).

A blog series on regenerative software pushes that inversion further than we would, to a definition: the architecture of a system whose implementations get regenerated rather than maintained is defined entirely by what cannot be deleted, which leaves four irreducible primitives (The Phoenix Primitives (opens in a new tab), April 2026). Behavioral specifications come first, and the argument distinguishes them from documentation by direction of travel: conventional docs describe code that already exists, while a regenerative specification is a generative input the implementation derives from, which is what keeps the two from drifting. Evaluations are the second primitive, runnable contracts any implementation has to satisfy. Context boundaries, the API contracts and event schemas where regeneration units meet, are the third, and the practical consequence is where the craft goes: once internal code structure is disposable, architectural skill is the placement of boundaries between independently regenerating parts rather than the arrangement of code inside them. Provenance records are the fourth, on the reasoning that line-level diffs mean little when the lines were generated, so what is worth tracking is causation, which specification version produced an implementation, which evaluation cleared it, and what triggered the regeneration (The Phoenix Primitives (opens in a new tab), April 2026).

The wider series works the same thesis into design heuristics, among them a deletion test for evaluating a system and a restatement of “keep things small” as “safe to delete”, and it supplies its own counterweight: mature implementations accumulate hard-won lessons in their validations and error handling that no organization has written down anywhere, which is exactly what a regeneration discards (The Phoenix Architecture (opens in a new tab), December 2025 to August 2026).

Resources

Articles

Posts

Talks and videos