Software creation is no longer a pipeline. It is three bodies in equilibrium.

For four decades the binding constraint on software was the cost of producing it. People gathered requirements, drew designs, wrote code, ran tests, and shipped releases, and every one of those steps consumed scarce human hours. AI has now removed most of that cost from the producing steps. That does not make the work easy. It moves the constraint to a different place, and most organizations are still optimizing the part that is no longer scarce.

The relocated constraint sits in the part Fred Brooks called essential. Writing the code was always accident; knowing what to build and how it should hold together was always essence, and essence is exactly what a model cannot infer from a thin prompt (Brooks, 1987). When production becomes cheap, ambiguity becomes expensive. A vague requirement that once slowed a single developer can now generate a complete, plausible, and wrong system in minutes.

So the central question of AI-native engineering is not whether the agent can build the feature. It is whether the organization can preserve intent, respect structure, govern execution, learn from reality, and adapt without losing the thread. That is an alignment problem before it is a productivity problem.

This paper proposes a model for that problem. It treats software creation as a system of three interacting bodies, Intent, Structure, and Execution, held together by connective fields: memory across time, governance across risk, adaptation across change, and, as the AI era forces into view, comprehension across the minds that have to hold the system in common. The bodies are not stages in a line. They are centers of gravity that pull on each other continuously, and the work is keeping them in equilibrium rather than passing a baton between them.

The Three-Body System was developed by Surendra Reddy at 451 Labs, and it did not begin as a theory. It began as a pattern noticed across three decades of building software and watching ventures live or die, a path that ran from Bell Labs and Xerox PARC through Oracle and Yahoo to the founding and operating of Quantiply. Models built from failure tend to be more honest than models built from success, because failure is specific where success is often lucky. This one was assembled from the wreckage of products and companies that did not make it, and the first thing the wreckage taught was that the autopsies were usually filed under the wrong cause of death.

The pattern was then sharpened from the opposite direction by 451 Labs’ research into designing and governing autonomous agentic systems. Building an agent that acts, rather than one that merely assists, brings the same three forces into the open: an agent given no clear intent optimizes the wrong thing, an agent given no coherent structure amplifies whatever it is handed, and an agent allowed execution without governance turns speed into risk. The venture failures looked backward and the agentic work looked forward, and both arrived at the same three centers of gravity. A model that two unrelated lines of evidence keep rediscovering is usually pointing at something real.

The accepted verdict on why ventures fail points at the market, not the codebase. CB Insights, analyzing hundreds of post-mortems, puts “no market need” or poor product-market fit at the top at roughly forty-two to forty-three percent, with running out of cash a frequent second that the same analysts now describe as a symptom rather than a root cause (CB Insights, 2024). Read at face value, this says the killer is the market, and that engineering is a sideshow to the only question that matters, which is whether anyone wanted the thing. That reading is popular, it is partly correct, and it sits upstream of an expensive mistake.

The mistake is treating “no market need” as a verdict on the idea rather than on the search for fit. Product-market fit is rarely found by insight. It is found by iteration, by building, shipping, measuring, learning, and adapting until the product converges on a need that was there the whole time. How many of those cycles a venture gets, and how coherent each one is, is not a marketing property. It is a property of the engineering system, and that is the property most post-mortems never name.

The research that looks directly at software startups finds failure exactly there. Giardino, Wang, and Abrahamsson studied early-stage software companies and located the failure at the seam between strategy and execution: teams rush to build before they have validated the problem, accumulate the wrong product, and exhaust their room to pivot before the market is ever truly tested (Giardino et al., 2014). The label on the death certificate said market. The cause of death was an engineering system that could not search fast enough, or cleanly enough, to find it.

For software ventures in particular, the build is not a solved problem that merely needs aiming. It fails on its own terms, at rates that ought to be more alarming than they are. Across decades of the Standish CHAOS research, only about a third of software projects are delivered as intended, roughly half are challenged, and the rest are abandoned, with the single strongest predictor of failure being size and the most durable predictors of success being user involvement and a clear statement of requirements (Standish Group, 2020). Those success factors are not engineering trivia. They are intent and structure wearing a project manager’s vocabulary, and their absence resurfaces years later as technical debt that drags velocity while getting mislabeled as “we just move slower now” rather than the architectural failure it actually is. The Consortium for Information and Software Quality has put the annual cost of poor software quality and failed projects in the United States in the trillions of dollars (CISQ, 2022).

Even the empty bank account, the proximate cause in most post-mortems, is engineering-mediated. A venture runs out of runway because each learning cycle cost too much and took too long, and the price and pace of a learning cycle is set by how well its engineering system converts capital and time into validated learning. So the honest reframe is not that engineering replaces the market as the cause of failure. It is that the engineering system is the substrate on which the search for the market is run, and a venture’s odds are largely fixed by how fast and how coherently that substrate moves from intent to shipped, measured, adapted product.

Product-market fit is the verdict. The engineering system is the trial, and most trials are lost before the market is ever really put on the stand.

Seen enough times, that pattern forces a model. The failures that filed under “market” almost always decomposed into three deeper ones: a loss of intent, where the team slowly stopped building what mattered; a loss of structure, where the system grew too tangled to change at the speed the search demanded; and a loss of learning, where execution produced signal that never found its way back into the next decision. Those three losses are the three bodies of this paper, named from failure long before AI made them urgent. 451 Labs built the Three-Body System to make that substrate explicit, so that the part of venture-building that actually decides the outcome stops being invisible until the post-mortem.

AI is what turns this from a useful lens into a necessary one. By removing most of the cost of producing code, AI strips away the work that was never the real constraint and leaves the real one fully exposed: the discipline of holding intent, structure, and governed execution in coherence while learning fast enough to find fit before the money runs out. The rest of this paper develops that model in full, and it begins where the change begins, with the constraint that has now, finally and unmistakably, moved.

The traditional lifecycle was an answer to a production problem. Waterfall and agile disagreed about cadence and feedback, but both assumed the same scarce resource: humans typing the artifacts. Requirements, designs, code, and tests all flowed from people, so the obvious way to go faster was to help people produce faster.

AI breaks that assumption at the root. Agents now generate code, write tests, summarize documents, analyze logs, refactor modules, and propose architecture, which means the producing steps are no longer the bottleneck. The interesting consequence is not speed. It is that the bottleneck has not vanished, it has relocated, and the evidence is already visible in the field.

Consider three independent signals from 2024 and 2025. A randomized controlled trial by METR found that experienced developers working in repositories they knew well took roughly nineteen percent longer with AI assistance, while believing they had been sped up by twenty percent, with much of the lost time spent reviewing and repairing generated code (Becker et al., 2025). GitClear’s analysis of more than two hundred million changed lines found refactoring collapsing from about a quarter of changes in 2021 to under ten percent in 2024, while copy-pasted code rose sharply, a maintainability signal pointing the wrong way (GitClear, 2025). And Google’s DORA program found that AI adoption correlated with reduced delivery stability even as individual throughput rose, concluding that AI behaves as an amplifier: it strengthens disciplined systems and magnifies weak ones (DORA, 2024, 2025).

None of these findings says AI is bad at writing code. They say something more precise and more useful. The work that determines whether software is good was never the typing, and the typing is the part AI has automated. The constraint moved downstream into review, integration, validation, and coherence, and a model of AI-native engineering has to put that relocated constraint at its center.

The old pipeline asks one question. Did we deliver? The richer model has to ask a harder one: did we preserve intent, maintain structure, govern execution, learn from reality, and adapt correctly? Those are not the same question, and conflating them is how teams ship fast and drift far.

Every meaningful software system is shaped by three forces. Intent is what should exist and why it matters. Structure is how the system must be organized so it can be built and sustained. Execution is how the system is created, validated, operated, governed, and improved. These are not departments and they are not phases. They are gravitational centers, and the health of the work depends on the relationship among them rather than the strength of any one.

When one body dominates, a recognizable failure follows. Intent without structure becomes aspiration that never compiles. Structure without intent becomes architecture in search of a purpose. Execution without either becomes automation without judgment, which is precisely the failure mode the field has started calling vibe coding: plausible output that drifts from anything anyone actually wanted.

The name is deliberate, and it is worth being honest about why. In celestial mechanics, the three-body problem describes three masses pulling on each other under gravity, and its defining property is that it has no general closed-form solution. Poincaré proved in 1890 that you cannot write a tidy formula predicting where the bodies will be, because the system is chaotic and sensitively dependent on its starting conditions (Poincaré, 1890). The only way forward is continuous numerical integration, step by step, forever.

That is the analogy that matters, and it is not decoration. You cannot solve the relationship between intent, structure, and execution once and hand off the answer. There is no closed form, no clean specification that survives contact with production, no architecture that absorbs every future requirement. The system has to be re-integrated continuously, which is another way of saying that coherence is a practice, not an artifact. The model exists to make that practice legible.

The Intent Body holds the gravity of purpose. It carries the questions that come before any artifact: what are we trying to create, who is it for, what need does it serve, what behavior should change, and, just as important, what should not be built. Intent is not the same as requirements. Requirements tend to describe what a system should do; intent explains why the system should exist at all, and that difference is the one a model cannot reconstruct on its own.

This matters more under AI than it ever did under human production. An agent does not understand organizational purpose. It infers from prompts, examples, and surrounding context, and when intent is thin it fills the gap with reasonable defaults that rarely match what the team actually meant. The industry discovered this the hard way and named the result intent drift, the slow divergence between what was asked and what was wanted (Thoughtworks, 2025).

The response now reshaping practice is spec-driven development, in which a versioned, structured specification rather than the code becomes the source of truth, and agents generate against it. Sean Grove put the underlying point sharply at the 2025 AI Engineer World’s Fair: keeping the generated code while discarding the prompt is like version-controlling the binary and shredding the source, because the specification is where human intent actually lives (Grove, 2025). Spec-driven development is, in the vocabulary of this paper, an attempt to give the Intent Body a durable form.

The Intent Body produces the things that give software direction: a stated purpose, a real understanding of the user, defined outcomes, experience principles, explicit success criteria, the boundaries of scope, and the rationale behind the decisions that shaped them. Without that, agents optimize for completion rather than meaning, and completion is a poor proxy for value. A finished system that solves the wrong problem is not a partial success. It is a faster way to be wrong.

The Structure Body holds the gravity of coherence. It asks how the system should be organized, what architecture serves the intent, what constraints must guide implementation, how the work should be decomposed, which dependencies matter, and which risks must be made visible before anyone writes a line. Structure is the bridge between human purpose and machine execution. It defines the shape of the system before implementation begins and keeps generation from collapsing into a pile of locally correct, globally incoherent parts.

Brooks named the reason this body cannot be automated away. The essence of a software entity is a construct of interlocking concepts, and the hard, irreducible work is getting those concepts right; tools mostly attack the accidental difficulty of expressing them (Brooks, 1987). AI is a remarkable accident-reducer. It has done almost nothing to reduce essence, which means structure remains a human responsibility even when the code is machine-written.

There is a second reason structure resists delegation, and Conway saw it in 1968. Organizations produce systems whose structure mirrors their own communication structure, so an incoherent or invisible architecture tends to reproduce an incoherent organization in code (Conway, 1968). When agents enter the picture, this law does not weaken; it accelerates, because the agent will faithfully amplify whatever structural assumptions it is handed, sound or not.

The Structure Body produces the system’s skeleton: its architecture and boundaries, component and data models, interfaces, constraints, the decomposition into epics and stories with acceptance criteria, and the dependency and risk maps that sequence the work. The GitClear data is, read correctly, a portrait of this body failing. Refactoring fell and duplication rose because generation outran structural discipline, and the structure body, left untended, lost the argument to raw output (GitClear, 2025).

The Execution Body holds the gravity of reality. It is where intent and structure stop being theoretical and meet the resistance of running systems. In traditional development, execution mostly meant coding and delivery. In AI-native development it is wider, taking in context assembly, agentic implementation, testing, review, governance, deployment, observation, and the learning that follows. The defining question of this body is not only “what should be built now” but “what did production reveal, and what should change next.”

Execution is also where the relocated constraint actually bites. The METR result is an execution-body finding: the time AI saved on producing code was more than spent on reviewing, correcting, and integrating it, because validation does not get cheaper just because generation does (Becker et al., 2025). DORA’s stability finding is the same story at organizational scale, where larger AI-assisted change sets raised the failure rate even as throughput climbed (DORA, 2024). The lesson is consistent. Output without evidence is not progress, it is unverified risk wearing the costume of progress.

The Execution Body produces implementation plans and code changes, tests and review findings, security checks and governance decisions, deployment records and runtime telemetry, the signals of real user behavior, and the operational lessons that feed back into memory. This is the body that gives software its truth, in the plain sense that nothing is known to work until it has been observed working. Intent and structure can be elegant and still be wrong, and only execution can tell you which.

The model does not deny sequence. A new initiative still usually begins with intent, moves into structure, and then enters execution, and that ordering is correct at the start. The mistake is believing the ordering is the whole story. Sequence describes how work begins; it does not describe how a living system behaves.

Mature AI-native development closes the loop. Execution produces observation, observation produces learning, and learning reshapes both structure and intent, so the line bends back on itself and keeps moving. The system is sequential at the beginning and recursive during operation, and the goal is not a perfect handoff between stages but continuous coherence across them.

This is where the physics earns its keep again. A three-body system has no closed-form solution precisely because the bodies keep influencing each other, so its future can only be computed by integrating the interactions forward in small steps (Poincaré, 1890). Software under AI behaves the same way. There is no one-time specification that settles the relationship between purpose, design, and reality, and any process that assumes there is will drift the moment conditions change. Coherence has to be recomputed, which is unglamorous and unavoidable.

Each body maintains a different kind of truth, and the discipline is keeping the three connected rather than letting any one calcify. The Intent Body holds product and purpose truth, the answer to what matters and why. The Structure Body holds engineering and system truth, the answer to how the thing is built and sustained. The Execution Body holds operational and learning truth, the answer to what actually happened when the system met the world.

A healthy organization treats these as a circuit, not three separate filing cabinets. When product truth changes, structure must adapt; when structure changes, execution must follow; when execution reveals reality, both product and structure must learn. The alternative is the familiar pathology of documents that were true once, contradict each other now, and are trusted by no one. The aim is a living system of truth rather than a chain of stale artifacts, and the difference between the two is whether the truths still talk to each other.

The value of a model is partly in the failures it lets you see early. AI-native engineering fails along six surfaces, and each one shows up in two forms: a slow form, drift, where the system gradually loses alignment, and an acute form, collapse, where it loses alignment all at once. Naming both forms matters, because the slow version is the one that hides until it is expensive.

Intent. Drift is the system slowly ceasing to solve the original problem as defaults accrete; collapse is shipping something polished that solves the wrong problem entirely. This is the surface spec-driven development was invented to defend (Thoughtworks, 2025).

Structure. Drift is the steady erosion of architecture into hidden coupling and duplication; collapse is a generation spree that produces features with no coherent shape. The falling-refactoring, rising-duplication pattern is exactly this surface deteriorating in the wild (GitClear, 2025).

Execution. Drift is agents optimizing for task completion with thinning validation; collapse is output shipped without adequate tests, review, or observability. The productivity-perception gap in the METR trial is drift made measurable: people felt faster while the system got slower (Becker et al., 2025).

Governance. Drift is autonomy quietly expanding past safe boundaries; collapse is an agent acting well outside them. The OWASP agentic risk catalog, with goal hijacking, privilege abuse, and rogue agents, is a map of this surface failing acutely (OWASP GenAI Security Project, 2025).

Memory. Drift is the organization gradually forgetting why decisions were made; collapse is repeating a known mistake because the lesson was never preserved. Spec-driven practice calls the underlying mechanism context decay, the agent contradicting older decisions it can no longer see (Thoughtworks, 2025).

Learning. Drift is feedback that is captured but never changes behavior; collapse is a culture that mistakes reporting for learning and is therefore surprised by the same failure twice. This is the most expensive surface because it disables correction on all the others.

These failures are predictable rather than mysterious, which is the entire point. A model that lets you name them before they become systemic is worth more than one that explains them after the incident review.

The bodies are held together by connective fields, and the first is memory. Memory is not itself a body. It is the connective tissue that lets the bodies influence each other across time, carrying the why that no single artifact preserves: why an intent was defined, why an architecture was chosen, why work was decomposed a certain way, why a story changed, why a test failed, why a release was blocked, why users behaved unexpectedly, and why the system adapted.

Without memory, every cycle starts partially blind and the organization relearns its own history at full cost. The context-decay failure that spec-driven development fights is memory failing at the level of a single project, where an agent contradicts decisions it can no longer see (Thoughtworks, 2025). The organizational version is worse and slower, and it is the reason teams rebuild the same wrong thing in successive quarters. Memory is what turns delivery experience into reusable knowledge, and it is the difference between a system that compounds intelligence and one that merely accumulates code.

The second field is governance, which defines the boundaries of autonomy. It asks what agents may do alone, what requires human review, what risk class applies, what evidence is required, what policies constrain an action, what must be logged, and when execution should stop or escalate. The defining shift under AI is that these questions can no longer live at the end of the process as an approval gate. By the time an autonomous agent reaches an approval gate, it has already acted, so governance has to be embedded in the flow of work rather than bolted to its exit.

The field has formalized quickly because the risks turned out to be concrete. In December 2025, the OWASP GenAI Security Project published the first risk framework specific to autonomous applications, cataloging failures that traditional application security does not cover: goal hijacking, identity and privilege abuse, memory poisoning, excessive agency, and rogue agents (OWASP GenAI Security Project, 2025). The NIST AI Risk Management Framework gives the complementary governance scaffolding, organizing the work into governing, mapping, measuring, and managing risk across a system’s life (NIST, 2023). Read against the three bodies, both are arguments that control belongs inside design, planning, implementation, and deployment at once. Governance is what keeps autonomy from becoming uncontrolled acceleration, and the cost of learning that lesson late is paid in production.

The third field is adaptation, the system’s ability to revise itself based on what it learns. It asks what should change because of an experience: whether intent should be clarified, architecture revised, a pattern promoted to standard, a policy updated, a story template changed, an agent behavior corrected, or a memory strengthened or pruned. Adaptation is the field that turns the loop in Section 6 from a diagram into a habit.

This field is what separates AI-native engineering from AI-assisted delivery, and the distinction is not pedantic. AI-assisted delivery uses agents to perform tasks faster, which is valuable and also limited, because it leaves the system of delivery unchanged. AI-native engineering uses agents, memory, governance, and learning to improve the system of delivery itself, so the organization gets better at getting better rather than merely faster at the same work. The DORA program’s decade-long refrain, that improvement is a capability and not an event, is the same claim from a different direction (DORA, 2024).

The model as first drawn had three fields, and for most of the history of software that was enough. Memory, governance, and adaptation were the connective tissue, and a fourth force could stay implicit because the people building a system carried it without being asked to. AI is what pulled that fourth force into the open, and once seen it does not go back into hiding.

The force is shared understanding, the live theory of the system that a team holds in common. Peter Naur named it in 1985, arguing that a program is not the text but the theory in the minds of the people who built it, and that when the theory dies the program becomes unmaintainable no matter how clean the code still reads (Naur, 1985). For forty years that theory was a free byproduct of the work. You could not write code you did not understand, so understanding accumulated as a side effect of typing. That bargain is now broken.

When an agent writes the code, the understanding no longer comes for free. A developer can accept a correct, well-structured implementation without ever building the mental model that authorship used to force, and across a team and a year this compounds into what Margaret-Anne Storey calls cognitive debt, the quiet erosion of shared understanding even while the artifacts stay healthy (Storey, 2026). The danger is that it is invisible. Storey observes that the same surrender of scrutiny that lets the debt accumulate also inflates confidence, so a team feels it understands the system better exactly as it understands it less, which is the human mechanism beneath the METR result this paper opened with.

This is why comprehension is a field and not a fourth body. A body produces a truth and an artifact of its own: intent produces purpose, structure produces form, execution produces operational reality. Comprehension produces neither, because it is always comprehension of intent, of structure, of execution, never a separate thing being built. It runs across all three bodies at once, and its failure mode is precisely loss of equilibrium: when shared understanding fragments, the three bodies drift apart in the team’s collective mind while every document still looks correct. A body is what gets balanced. A field is what does the balancing, and comprehension balances along the one axis the other fields do not touch, distribution across the minds that have to hold the system in common.

It is worth naming, for readers who know the source, exactly where this parts company with it. Storey arrives at a parallel model of three layers, intent, code and structure, and shared understanding, and gives the third equal standing with the first two, in effect placing understanding where this paper places execution. We keep execution as a body, because the Three-Body System is an end-to-end operating model and not only a diagnosis of system health, and we treat her concern as a field that crosses all three bodies rather than as a body of its own. The convergence runs deep on two pillars and the divergence is real on the third, which is a more honest thing to report than a borrowed endorsement.

The distinction from memory is worth being exact about, because the two blur easily. Memory runs across time and lives largely in artifacts and records, answering whether anyone will still know why next year. Comprehension runs across people and lives in minds, answering whether everyone who needs to know why knows it now. They decay at different rates and they are repaired by different means, a captured decision record on one side and a walkthrough, a review, or a rebuilt mental model on the other, which is the same line Storey draws between intent debt that lives in artifacts and cognitive debt that lives in people (Storey, 2026). Distributed cognition gives the pairing its grounding, since understanding is a property of people, artifacts, and the traffic between them rather than of any one alone (Hutchins, 1995).

The field also adds a failure surface the earlier taxonomy could not name. To the six surfaces of Section 8, comprehension adds a seventh. Its drift is the slow concentration of understanding into fewer and fewer heads until the bus factor approaches one. Its collapse is the moment a team can no longer say why the system does what it does and freezes, afraid to change what it cannot explain. Storey’s opening case is this surface failing in miniature, a student team that stalled not because the code was bad but because no one could reconstruct why it had been built that way (Storey, 2026).

Naming comprehension as a field is, in our own canon, sensemaking brought down to the engineering altitude. The same human capability that 451 Labs names in leadership and in decisioning appears here in its narrowest and most concrete form, the work of keeping a system understood in common while humans and agents change it at a speed neither could reach alone. We chose the plainer word deliberately, to bind the field to one axis rather than to the whole sensemaking loop, and to keep the claim honest about exactly what it covers.

A word on symmetry, since the model now carries three bodies and four fields rather than a tidy three and three. We considered forcing the balance and decided against it. The asymmetry is the truth: the AI era added a dimension the older lifecycle could leave unspoken, and a model that adds a field when reality demands one is doing exactly what the Three-Body System says systems must do. The imbalance is not a flaw in the model. It is the model taking its own medicine.

The model can be drawn as three bodies in a feedback relationship, wrapped by the four fields that give it continuity, control, evolution, and shared understanding.

Memory connects the three bodies across time. Governance constrains the three bodies across risk. Adaptation evolves the three bodies through learning. Comprehension keeps the three bodies understood across minds.

The bodies form the operating system. The fields keep that operating system coherent as it runs, which is the part a static pipeline diagram has never been able to show.

The model resolves into a small set of principles, each one a defense of a body or a field against its characteristic failure.

Intent before generation. An agent should not produce before the organization has clarified what matters, because cheap generation against thin intent is just a faster route to the wrong system.

Structure before scale. Implementation should not be scaled before architecture and decomposition are coherent, since agents amplify whatever structure they are given, including its flaws (Conway, 1968).

Execution with evidence. No autonomous action earns trust without tests, reviews, logs, or observable proof, because output and verified output are not the same thing (Becker et al., 2025).

Governance inside the flow. Control belongs in design, planning, implementation, and deployment, not in a final approval that an autonomous system has already outrun (OWASP GenAI Security Project, 2025).

Memory is a system asset. Decisions, failures, patterns, and outcomes have to be captured as reusable knowledge, or the organization pays repeatedly to relearn what it already knew.

Understanding is held in common. Shared understanding has to be rebuilt as deliberately as code is written, because when an agent authors what no one comprehends, the team keeps the system and loses the theory of it (Naur, 1985; Storey, 2026).

Learning must change behavior. Feedback that does not alter future design, structure, or execution is not learning, it is reporting, and the two are easy to confuse and expensive to mistake.

Humans remain accountable. Agents can act, but responsibility for intent, judgment, ethics, tradeoffs, and outcomes stays with people, because accountability is not a thing that can be delegated to a system that cannot be held responsible.

The model runs as a repeatable cycle rather than a rigid methodology, and any number of tools can implement it. The cycle begins by clarifying intent, defining purpose, users, outcomes, experience, and boundaries. It then forms structure, creating architecture, constraints, decomposition, sequencing, and acceptance criteria. From there it executes the work, building, testing, reviewing, governing, deploying, and observing.

The back half of the cycle is the part the old lifecycle never had. The work captures evidence, collecting test results, review findings, telemetry, incidents, user behavior, and policy outcomes. It updates memory, recording decisions, lessons, patterns, and exceptions as reusable knowledge. And it adapts the system, revising intent, structure, execution patterns, policies, and future plans in light of what the evidence showed. The cycle is a pattern, not a prescription, and its discipline is that it does not end at deployment.

The model changes how an organization should arrange itself. Traditional shops separate product, architecture, engineering, quality, security, and operations into functional silos and pass work between them. AI-native development needs those disciplines to stay distinct in expertise while becoming continuously connected in practice, because the failure surfaces in Section 8 all live in the seams between functions.

In concrete terms, product intent has to be visible to engineering, architecture has to be visible to the agents doing execution, and execution evidence has to flow back to product and architecture rather than dying in a dashboard. Governance has to be visible across all three bodies, memory has to be shared rather than hoarded by individuals, and adaptation has to be a deliberate act rather than an accident that occasionally happens to a lucky team. The shape that results looks less like an assembly line and more like a living intelligence system, which is a higher bar than most reorganizations aim for and a more honest description of what the work now requires.

Organizations tend to move through five stages, and the destination is not the one the vendor pitch implies. In the first stage, assisted delivery, AI helps individuals write code, tests, and documents, and the gains are real but local. In the second, structured delivery, AI operates within clearer specifications, architecture, and story structures, so the output starts to compose. In the third, governed execution, agents work under policy, review, testing, and deployment controls, and autonomy becomes something the organization can trust rather than fear.

The last two stages are where the model’s argument concentrates. In the fourth stage, memory-driven development, the organization captures and reuses decisions, lessons, and execution history, so it stops relearning its own past. In the fifth, adaptive engineering, the system continuously improves intent, structure, execution, governance, memory, and the understanding it holds in common on the basis of evidence. The mature organization treats shared understanding as a deliverable rather than a byproduct, which is the discipline the AI era quietly removed and the one this stage exists to restore. The highest maturity is not full automation, which is the destination most roadmaps assume. The highest maturity is governed adaptation, a system that changes itself deliberately and within bounds, and the distance between those two destinations is the whole point of the model.

This paper has named no products and endorsed no platforms, and the omission is deliberate. The Three-Body System is a conceptual foundation, and it should be possible to implement with different design methods, planning methods, agent runtimes, memory systems, governance layers, and adaptation engines. Specific frameworks can then be mapped into it, and that mapping is a separate piece of work that comes later.

What the foundation insists on is structural rather than technological. There must be a body that preserves intent, a body that creates structure, and a body that executes and learns. There must be a memory field that connects them across time, a governance field that constrains them across risk, an adaptation field that evolves them through learning, and a comprehension field that keeps them understood across the minds that build them. A team can satisfy these requirements with many different tool choices and still be doing the same essential thing, which is the test of whether a model is a foundation or merely a fashion. Foundations outlive the tools that implement them, and that is the ambition here.

AI-native software engineering needs a new foundation because its binding constraint has moved. The old lifecycle was built for a world in which humans were the scarce producers of software artifacts, and that world is ending. In the new one, humans and agents cooperate, production is cheap, and the expensive work is the alignment between what should exist, how it is organized, and what actually happens when it runs.

The Three-Body System offers a way to hold that work. It says software creation is no longer a pipeline but a dynamic equilibrium among three forces: intent, which is what should exist and why it matters; structure, which is how it is organized so it can be built and sustained; and execution, which is how it is built, governed, observed, learned from, and improved. Around those bodies sit the connective fields of memory, governance, adaptation, and comprehension, the last of which the AI era pushed from a quiet assumption into a discipline that has to be maintained on purpose. Together they form the operating model.

The goal was never just to build faster. The goal is to build systems that preserve purpose, respect structure, operate safely, learn continuously, and improve over time. A three-body system has no closed-form solution, and neither does this one. It has to be integrated forward, continuously, with judgment, and that is not a limitation of the model. It is the honest shape of the work.

These notes record why the Comprehension field was added, so the reasoning is recoverable later rather than reconstructed from memory. They are kept in the spirit of the paper’s own argument, that intent and rationale should be externalized rather than left in people’s heads.

Origin. The field was added after a close reading of Storey (2026), “From Technical Debt to Cognitive and Intent Debt.” The question put to that paper was direct: which parts support the Three-Body System, and which parts weaken it.

What converged. Storey reaches the same relocation-of-constraint thesis independently, and two of her three layers map onto two of the bodies, goals-and-intent onto the Intent Body and code-and-structure onto the Structure Body. Her intent-debt concept reinforces both the Intent Body and the Memory field, her cognitive-surrender mechanism supplies the psychology beneath the METR result the paper cites, and her treatment of accountability matches the principle that humans remain accountable. This convergence from a credentialed, independent source is strong external validation and is used as such.

What diverged. Storey’s third layer is not execution. It is human shared understanding, which she argues is the risk that matters most in the AI era. That is a serious and well-defended alternative to the third body, and it exposed a real gap: the model had no first-class home for shared understanding as a living property of people, and the Memory field was quietly carrying two different things at once.

The decision. Execution was not moved. It remains a body, because the Three-Body System is an end-to-end operating model that must include build, test, govern, deploy, and observe, which is a wider scope than Storey’s health diagnostic. Shared understanding was added instead as a fourth field, named Comprehension, rather than as a fourth body.

Why a field and not a body. A body produces a truth and an artifact of its own. Comprehension produces neither, since it is always comprehension of intent, structure, or execution, never a separate thing being built. It spans all three bodies, and its failure mode is loss of equilibrium, the bodies drifting apart in the team’s collective mind while the artifacts still look correct. A body is what gets balanced. A field is what does the balancing, and comprehension balances along an axis the other fields do not touch, distribution across minds.

The axis, bound precisely. Comprehension is bound to Naur’s theory of the system (Naur, 1985), so the field has a concrete object rather than a vague mandate, and its failure mode is bound to Storey’s cognitive debt (Storey, 2026). Memory and Comprehension are kept as distinct siblings rather than merged: Memory runs across time and lives in artifacts, Comprehension runs across people and lives in minds, and the two decay and are repaired differently. Distributed cognition (Hutchins, 1995) grounds the pairing.

Naming. Comprehension was chosen over Sensemaking deliberately. Sensemaking already carries a larger meaning in the 451 canon, the full sense-decide-act-learn loop in decisioning and the leadership posture in Level 6, and reusing it here at a narrower altitude would dilute it in all three places. Comprehension names the one axis the field needs, distribution across minds, without dragging in the whole loop. Sensemaking is retained as a single lineage line in the field section, marking Comprehension as sensemaking at the engineering altitude, so the canonical link stays visible without the takeover.

A noted grammar tension. Memory, Governance, and Adaptation read as capabilities, while Comprehension tilts toward the state it produces. This is accepted, and the field is kept active in the prose, treated as the ongoing work of comprehending rather than the achieved fact of having understood.

On symmetry. The model now carries three bodies and four fields rather than a tidy three and three. The asymmetry is deliberate and is stated openly in the paper. The AI era added a dimension the older lifecycle could leave implicit, and adding a field when reality demands one is the behavior the model itself prescribes.

Enactment. Comprehension is introduced late in the arc, as the field the AI era forces into view, rather than asserted alongside the others from the top. This lets the paper enact the same discovery Storey describes instead of merely stating it, and it is why the failure taxonomy in Section 8 still lists six surfaces, with the seventh revealed only when the field arrives.

Citation discipline. Storey is cited as independent convergence on the thesis and on two pillars, with a productive divergence on the third, which Section 12 now names in the main text rather than leaving only to this appendix. She is not cited as endorsing the Three-Body System, which would be an overclaim, since she proposes her own overlapping framework.

Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity (arXiv:2507.09089). arXiv. https://arxiv.org/abs/2507.09089

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19.

CB Insights. (2024). The top reasons startups fail. CB Insights Research. https://www.cbinsights.com/research/report/startup-failure-reasons-top/

CISQ. (2022). The cost of poor software quality in the US: A 2022 report (H. Krasner). Consortium for Information & Software Quality. https://www.it-cisq.org/

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

DORA. (2024). Accelerate state of DevOps report 2024. Google Cloud / DevOps Research and Assessment. https://dora.dev/research/2024/dora-report/

DORA. (2025). State of AI-assisted software development report 2025. Google Cloud / DevOps Research and Assessment. https://dora.dev/

Giardino, C., Wang, X., & Abrahamsson, P. (2014). Why early-stage software startups fail: A behavioral framework. In C. Lassenius & K. Smolander (Eds.), Software business: Towards continuous value delivery (Lecture Notes in Business Information Processing, Vol. 182, pp. 27–41). Springer. https://doi.org/10.1007/978-3-319-08738-2_3

GitClear. (2025). AI Copilot code quality: 2025 research report (W. Harding & M. Kloster). https://www.gitclear.com/ai_assistant_code_quality_2025_research

Grove, S. (2025, June). The new code \[Conference talk\]. AI Engineer World’s Fair, San Francisco, CA.

Hutchins, E. (1995). Cognition in the wild. MIT Press.

Naur, P. (1985). Programming as theory building. Microprocessing and Microprogramming, 15(5), 253–261.

NIST. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1

OWASP GenAI Security Project. (2025). OWASP top 10 for agentic applications (2026). https://genai.owasp.org/

Poincaré, H. (1890). Sur le problème des trois corps et les équations de la dynamique. Acta Mathematica, 13, 1–270.

Standish Group. (2020). CHAOS report 2020: Beyond infinity. The Standish Group International.

Storey, M.-A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI (arXiv:2603.22106). arXiv. https://arxiv.org/abs/2603.22106

Thoughtworks. (2025). Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices. https://www.thoughtworks.com/