Domain-Driven Agents

TEXT START: I've been using LLMs heavily in the last years in coding, or more generally, in software engineering.

The Dissection

This piece is not really about DDD. It is a workflow manifesto for converting software engineers from typists into supervisors of machine-produced changes. It correctly identifies the bottleneck: when implementation becomes cheap, system interpretation, boundary decisions, and semantic consistency become the scarce inputs. The manifests, glossaries, context maps, skills, sub-agents, issues, and review loops attempt to externalize that scarce context into machine-readable control surfaces.

It is also a transition-management document. It tells engineers they can remain useful by moving upward from code production into specification, ownership, verification, and coordination. That is a real adaptation, but the article quietly treats adaptation as durable economic protection.

The Core Fallacy

It confuses making a codebase legible to agents with preserving human economic indispensability.

DDD metadata can reduce hallucination, expose contradictions, and make brownfield change safer. It can improve the throughput and reliability of agents. That is precisely the danger under the Discontinuity Thesis: this framework accelerates P1 rather than escaping it. Once the domain map, glossary, ownership rules, edge contracts, tests, and review procedures are explicit, the engineer's tacit system knowledge has been packaged into an executable asset. The engineer is no longer the scarce repository of meaning; they are helping manufacture the artifact that displaces them.

The remaining “strategic half” is not a permanent moat. It is a target for the next wave of agentic automation: repository analysis, change planning, architectural proposals, conflict detection, issue creation, review, and eventually approval under policy. “I coordinate, I plan, and I create a path” describes a control layer that can itself be formalized. The article lowers the cost of crossing that layer.

Hidden Assumptions

• Human judgment about domain boundaries remains too ambiguous to automate at economically relevant quality.
• A human must continue reviewing every generated PR rather than sampling, delegating, or being removed as verification improves.
• The engineer who authors the language retains authority over it. In practice, authority can shift to whoever controls the platform, capital, deployment pipeline, and organizational mandate.
• Semantic clarity is a stable achievement. It is not; business requirements mutate, contexts collide, and machines can maintain the resulting artifacts once the rules are encoded.
• Reducing technical debt creates more engineering work for humans. Under competitive pressure, it may instead make neglected brownfield systems tractable to machines and destroy the justification for a large engineering workforce.
• A superior internal workflow translates into individual bargaining power. It may only make the firm's software output cheaper and its labor demand smaller.
• The project's discipline generalizes across institutions without changing the underlying power structure. Even if it does, generalization strengthens the agentic production stack rather than rescuing labor.

Social Function

Transition management with a strong dose of elite self-exoneration and ideological anesthetic.

It gives skilled engineers a plausible role after implementation collapses: become the person who defines meaning, controls boundaries, and audits machine output. That role may be valuable during the lag phase. But the article presents the ladder upward as if there were enough upper rungs for the displaced population. There will not be. The workflow concentrates leverage in those who own the domain models, agent infrastructure, repositories, compute, and distribution. It does not solve mass productive participation; it improves the machinery that makes participation unnecessary.

The Verdict

This is a technically serious brownfield-enablement strategy and a strategically misleading labor story. Its diagnosis of legacy-code ambiguity is accurate. Its proposed cure—formalized domain language plus agent orchestration—will likely make cognitive automation more capable, not less.

Under P1, the tactical layer is already being absorbed and the article deliberately feeds it structured context. Under P2, its hope that human-only strategic judgment remains protected is unstable once that judgment is represented as manifests, glossaries, policies, tests, and repeatable skills. Under P3, the result is fewer people required to maintain and evolve more software.

For the individual, this is a temporary Servitor position at best: valuable while they uniquely own the living domain model or control the verification boundary. It becomes Sovereign only if they own the agent stack, the software asset, the operational bottleneck, or the distribution channel. Otherwise, the article is not a refuge from obsolescence. It is a field manual for making the refuge automatable.