Core Thesis: Multi-agent coding systems can satisfy every local contract while the program, the evolving conception that makes separate changes belong to one system, erodes. The loss begins upstream, in plans whose divisions acquire authority while the conception that justified them becomes optional. Software factories automate doing and knowing; the program lives in the thinking between them. Coherence holds when the people responsible for the system steer, and the production process gives their conception authority over the plan.
Highlights
- The program is the evolving conception of a system’s identities, relationships, constraints, and behavior. A healthy program stays compressible: a compact conception explains a much larger implementation.
- Architecture must survive ordinary compliance with the process that produces it. Effort spent working against that process belongs in its cost.
- A specification refines execution inside a partition someone has already chosen. The partition itself is the question that should stay open.
- Boundaries set up to coordinate work harden into the product: duplicated evaluators, parallel pipelines, and screens that mirror delivery handoffs.
- Local completion rewards replication. Architects absorb the repair as mitigation load, work that sustains coherence and stays off the productivity account.
- Software factories automate doing and knowing. The program lives in the thinking between them.
- Steering is the work of the people responsible for the system. The production process gives their conception authority to reopen plans, merge tasks, and move ownership.
Multi-agent coordination and the disappearance of the program
A multi-agent coding system can satisfy every local delivery contract while gradually losing the program. Each task closes, each test passes, and each agent acts as directed. The artifacts remain individually defensible. The conception that makes them parts of one system becomes harder to locate and harder to revise.
By the program, I mean the evolving conception of a system’s identities, relationships, constraints, and behavior: the understanding that makes separate changes belong to one system.
The loss shows up as several structures named Tenant, overlapping policy evaluators, parallel command pipelines, and pages whose distinctions make sense once someone explains the order in which they were built.
The repository is where the loss becomes visible. It starts upstream, in how the work is divided and in what those divisions are allowed to reconsider.
Architecture Must Survive Ordinary Compliance
Exceptional individuals can make a strained process appear stable. A capable architect refines language. A seasoned team maintains shared frameworks. Such effort merits recognition, and its need reveals something about the process.
The useful question is what happens when people follow the process’s normal rules under ordinary delivery pressure.
Consider a process built around independent units of work, bounded ownership, minimal coordination, parallel execution, and progress measured by completion. It has a slope. Adding something within a boundary follows it. Reconsidering something across boundaries climbs it, especially when that reopens work already counted as done.
Discovering that three tasks express one underlying change improves the system and makes the plan look worse.
Architecture must survive ordinary compliance with the process that produces it.
When coherence depends on people repeatedly working against that process, their corrective effort belongs in its cost.
The Specification Is Already Downstream
Before an agent receives a task, someone has interpreted a larger intention and decided how to partition it. Each translation, from intention to feature to specification to tasks, makes the work easier to execute. Each also decides which relationships stay relevant.
Take a single task: add invitation revocation. The specification can be excellent. It can cover who can revoke, what happens after acceptance, how repeated requests behave, and what the audit trail records.
System-oriented attention asks other questions. What is an invitation across its lifecycle? How does its authority relate to membership? Does this operation change the model of other operations?
A task-oriented view starts with the assigned operation and expands far enough to complete it. A system-oriented view starts with identities, relationships, and dynamics, then works toward the intervention. Both are necessary, and both are open to humans and agents alike.
The difficulty arises when the workflow supports the first and relies on someone outside it to maintain the second.
More detail makes the chosen decomposition clearer. Whether that decomposition is right is a separate question. A better specification improves the execution of a decision that should still be open to revision.
Coordination Becomes Architecture
Decomposition creates boundaries. Recomposition revisits what those boundaries mean.
Much of that revisiting happens through attention crossing assigned work: while investigating a failure, recalling an adjacent feature, or noticing that two things look a little too alike.
Agent orchestration can close off those crossings. The scheduler decides context. Ownership decides what can be edited. Acceptance criteria decide success. The completion protocol decides when to stop.
As those boundaries harden, the coordination topology starts to decide what can be thought about together.
Implementing invitation revocation requires validation, idempotency, policy evaluation, a state change, audit, and event publication. A similar setup already supports tenants and memberships. Reusing a nearby pattern keeps the work within its scope. Identifying shared structure involves reviewing several operations together and perhaps reopening finished tasks. Under a workflow that favors independent completion, replication is the most practical route.
The copies serve as the message bus. Each copy gathers tests, schemas, audit codes, and migration history. What started as a convenience turns into part of the product, and rethinking it shifts from refactoring to migration.
Multiple representations can be valid; the key question is whether differences stem from the domain or development.
The Process Generates Distinctions
Once coordination boundaries enter the implementation, they become hard to tell apart from domain boundaries.
A module exists because an agent required a distinct workspace. Separate screens indicate different delivery dates where the user encounters one activity. The architecture begins tracking two elements simultaneously: the system under construction and the method used to create it.
The process generates distinctions. The repository keeps them, the interface shows them, and users inherit them.
Validation strengthens the arrangement, and the system responds to the questions it can pose. Each scenario includes a test, and every schema validates. The dependency rules remain intact. Whether revocation requires its own execution structure is a question beyond every gate.
A map can trace every alley and leave the city illegible.
The next agent discovers several valid artifacts, each accompanied by proof of function. Adding another aligns with the pattern. Consolidating them disrupts finished work. Mechanical assurance makes accidental differences endure.
The Program as a Compressible Conception
A healthy program stays compressible: a manageable conception continues to explain a much larger implementation.
An agent can describe the domain beautifully while the repository stays fragmented. The test is operational. Can the conception locate behavior, explain why representations differ, and predict what a change affects? Can someone explain a boundary in terms of the domain? When the answer weakens, knowledge stays local. Each region needs its own explanation, and the repository becomes its own explanation.
Some reconsideration is intrinsic to engineering. Implementation teaches us about the domain, and earlier decisions give way to better understanding. That is learning through realization. A second cost emerges when the process hides familiar connections, encourages their local repetition, or makes them costly to maintain. This can be called mitigation load: the effort needed to prevent locally rewarded behavior from solidifying into a global pattern.
An architect spends part of each week revisiting completed work to remove task-boundary distinctions. This yields coherent software, partly from corrective efforts omitted from productivity metrics. When coherence depends on such persons restoring relationships outside the normal process, essential engineering has become their vigilance.
The Thinking Between
A common response is to build better workflows: software factories that plan, execute, and verify with greater reliability. That response treats the condition with more of its cause.
Every loop runs on three arrows. Doing produces knowing, knowing informs doing, and thinking runs between them, turning traces into models and signals into signs. Thinking is where the conception forms and where it is revised.
A software factory automates doing and knowing. Execution produces artifacts, and gates report on them. The loop closes on completion and becomes a pipeline. Reasoning happens inside each task and ends with it. The artifact persists, the path that produced it is gone, and understanding stays where it started.
The thinking that spans tasks happens in a person’s head, outside the process. Human-in-the-loop places that person at a gate, verifying one artifact at a time inside the frame the task defined. Their conception enters the system as a rejected change. That is mitigation load in its purest form.
A better factory strengthens doing and knowing. The program lives in the thinking between them.
From Instruction to Steering
Instruction works when understanding is stable: specify, assign, verify. Development keeps moving understanding. Building reveals the domain, and a distinction that explained the system yesterday can lose that power today.
Conception and realization grow together, each reshaping the other.
Steering is the work of the people responsible for the system: holding its conception and revising it as building teaches them. The production process gives that work standing. The conception persists across tasks, and the process reads from it. The reasoning behind each decision stays reconstructable, so a position can be traced to its origin and revised when conditions change. And the conception holds authority over the decomposition: when understanding changes, the plan reopens, tasks merge, ownership moves, distinctions retire, and the process counts that as progress.
Those people decide what things are, what counts as the same, and which distinctions the domain supports. Every instrument, from a semantic graph to an agent, serves that thinking: keeping it reconstructable and bringing it what implementation reveals. An instrument that generates its own conception and checks it against its own gates adds one more stage to the pipeline. The conception can be partial and distributed. It must be shared enough to guide action, explicit enough to be questioned, and provisional enough to change.
Death by a Thousand Plans
The parallel pipelines, scattered evaluators, and fractured identities are late-stage symptoms.
Before the repository fragmented, the work was divided. Division is ordinary and necessary. The failure lies in what came next: the divisions acquired authority while the conception that justified them became optional.
Agentic coding amplifies outcomes: weak decomposition is fully realized and harder to challenge.
Local work is executable, measurable, and protected. The evolving conception that should organize it needs equivalent standing: somewhere to be shared, reconsidered, and given authority to change the work.
So the last and most important question comes before the files, before the agents, and before the plans: Where, in our system of software production, is the program still allowed to exist as a living conception?