§7.3 Agentic Engineering Beyond Software
MAGE was developed through software engineering because that is where our engineering expertise lies. Its evidence in this book is correspondingly concentrated: the originating case, reconstructions of other software systems and organizations, and a theory developed to explain those observations. The subtitle of this book is deliberate. Software engineering is the first worked domain of Model-Based Agentic Engineering.
READING PATHInset — Reading this section on its own
This section is intended to stand on its own for readers interested in agentic engineering beyond software. If you have come directly here, the argument depends on a small set of ideas developed earlier in the book:
- MAGE asks how people retain informed control when capable agents perform consequential work.
- Modeling gives people and agents purposeful representations of the properties that matter, rather than requiring those properties to be reconstructed repeatedly from the artifact or work being produced.
- Alignment places selected obligations outside the producing agent, where the surrounding environment can evaluate and enforce them independently.
- A Governed Engineering Environment (GEE) combines these representations and enforcement mechanisms with evidence and allocated authority, so capable agents can work autonomously without being the sole judges of their own work.
- Governance conversion turns recurring human judgment into models, checks, mechanisms, and other engineering structure that later work can inherit.
- Not every judgment should or can become machinery. The determinization frontier separates properties that the environment can decide mechanically from those that continue to require situated judgment.
For example, consider an agent helping an organization evaluate suppliers for a major procurement. A model might represent the alternatives, requirements, costs, uncertainties, and dependencies that matter to the decision. Some obligations—such as spending authority, required disclosures, or minimum contractual terms—can be checked independently of the agent making the recommendation. The Governed Engineering Environment (GEE) connects those representations and checks with evidence about supplier performance and with the authority to make the decision. If the organization repeatedly discovers the same risk, it can turn that judgment into a required check or decision rule for future procurements. Other questions—whether a strategic dependency is acceptable, for example—may remain matters for accountable human judgment (i.e., they lie beyond the determinization frontier). The particular representations and controls differ from software; the governing pattern does not.
With that machinery in hand, this section asks whether MAGE describes something peculiar to software engineering or a more general way of governing consequential agentic work.
Chapter 5 contained one deliberate boundary case. This book reserves agentic software factory for a production system whose agents produce the software changes themselves and whose surrounding machinery decides which of those changes may be accepted. Zenseact's ZAP platform, a driver-assistance software company's internal agent platform reconstructed in §5.3, did not qualify: its agents performed knowledge work around software production rather than producing software themselves.11. Philip Dufwa and Thomas Luvö, “A Platform for Scalable Enterprise AI Agents,” Zenseact, May 29, 2026, https://zenseact.com/news/a-platform-for-scalable-enterprise-ai-agents/. Yet the engineering problem was already recognizable. Domain knowledge had to be represented for agents, capabilities had to be scoped, actions had to be governed, and responsibility remained with the surrounding organization. The boundary of the software factory was therefore not the boundary of the underlying problem.
But software is not fundamental to the theory. Remove source code from the account and its central problem remains. An agent has some capacity. It performs consequential work through an environment. Some of the knowledge needed for that work can be represented outside the agent. Some obligations can be evaluated independently of the agent's own judgment. Useful decisions made today can sometimes be preserved so that tomorrow's work inherits them rather than reconstructing them.
Nor does the work have to produce an autonomous system. Conventional engineering makes the theory particularly easy to see because engineering work often produces an artifact or system that can subsequently be inspected, tested, operated, and observed. But the more general object is a consequential outcome. In knowledge work, that outcome may instead be a decision or action: a recommendation, approval, plan, transaction, diagnosis, or other commitment whose consequences become observable through subsequent events.
In either case, the work forms a loop. People remain responsible for consequential outcomes while delegating portions of the work that produces them. The environment carries representations, evidence requirements, constraints, and enforcement. The resulting artifact can be inspected and observed; the resulting decision can be evaluated against what subsequently happens. Evidence from either kind of outcome informs later judgment and can change the environment inherited by the next round of work.
The particulars therefore change dramatically across domains without changing the control problem. Software offers requirements, architectures, dependency graphs, types, tests, permissions, telemetry, and executable admission gates. Conventional engineering offers geometry, tolerances, physical models, simulations, inspections, and certification. Knowledge work may instead represent alternatives, assumptions, objectives, evidence, uncertainty, authority, and expected consequences. The general question is not whether every profession can be made to resemble software engineering. It is what environment would let capable agents perform consequential work while people retain informed control of its outcomes?
Figure 7.3-1 holds the shape of that question. The governing loop remains constant even when what the work produces does not.
Before proceeding, let us review the definition of Engineering used throughout this book. Notice that the definition emphasizes the purpose and character of the work—exercising informed control over consequential systems and accepting responsibility for their outcomes—rather than a job title such as Engineer. An accountant, lawyer, manager, scientist, or other professional may therefore perform engineering work in this functional sense when they exercise this kind of control and responsibility:
Engineering. The discipline of exercising informed control over consequential systems and accepting responsibility for their outcomes. Control means retaining sufficient command of a system to understand and direct it, evaluate the evidence for its consequential properties, recognize when its assumptions fail, and intervene when necessary. Responsibility means remaining answerable for the consequential decisions made under one's authority and for the resulting system. Engineering does not require personally performing every act of implementation, and work may be delegated to other humans or to machine intelligence. Also, note that the term "engineering" is used here functionally rather than institutionally: engineering is defined by the kind of control, evidence, expertise, and responsibility being exercised, not by whether the work belongs to a conventionally named engineering discipline. Software engineering applies this discipline to software systems.
This distinction matters here because agentic engineering beyond software may occur inside professions that would never ordinarily describe themselves as engineering.
For the broader argument of this section, we can paraphrase that definition at a higher level of abstraction: engineering means exercising informed control over consequential work while remaining responsible for its outcomes. In conventional engineering, the outcome is commonly an artifact or system. In other forms of consequential knowledge work, the outcome may instead be a decision or action whose effects become observable over time. The particulars differ, but the questions of control, evidence, expertise, delegation, and responsibility remain.
This paraphrase does not imply that all knowledge work is engineering. It gives us a test for the narrower claim developed below: where consequential work has this structure, how much of the machinery of engineering can transfer?
7.3.1 What Must Transfer
The first requirement is representability. Some consequential knowledge about the work must admit a representation that preserves distinctions relevant to the decisions being made. The represented object need not be an engineered artifact. It might be a system, a proposed design, the state of a business, the alternatives in a decision, the evidence supporting a claim, or the expected consequences of an action. The representation need not contain everything known about that object. That would defeat much of its purpose. It must reduce the object while retaining what matters for the question at hand.
The same principle therefore applies beyond conventional engineering. A dependency graph can preserve the relationships needed to reason about change in software. A structural model can preserve the quantities needed to reason about a bridge. A decision model can preserve alternatives, objectives, assumptions, uncertainties, and predicted consequences needed to reason about a business choice. In each case, the representation earns its keep by making a consequential question easier to answer than reconstructing the relevant structure afresh.
Representation alone is insufficient. MAGE also depends on correspondence: some credible account of why the representation describes what it claims to describe. A beautifully structured model that has drifted from its object can make reasoning easier while making its conclusions worse.
Correspondence takes different forms for different outcomes. In software, a model may be extracted from, checked against, or even generate executable artifacts. In conventional engineering, drawings and models can be reconciled with measurements, inspections, and the realized artifact. In knowledge work, a representation may instead claim to describe the relevant state of the world, the evidence available when a decision was made, or the consequences expected to follow from it. Those claims can be checked against source data, independent evidence, and eventually observed outcomes. The mechanism changes; the need for trustworthy correspondence does not.
A third condition is governability. At least some consequential actions, outputs, or transitions must be susceptible to checks or controls outside the producing agent. The mechanism need not be a Boolean validator. Work may be constrained, routed, admitted, rejected, escalated for human judgment, or subjected to additional evidence requirements. A software change might be prevented from deployment; an engineering design might require certification; a financial commitment might require human approval above a threshold. The important distinction is between asking the producing agent to remember an obligation and engineering an environment in which the obligation has an independent path to consequence.
A fourth condition is economy. Models, controls, correspondence mechanisms, and accumulated engineering capital cost something to build and maintain. Their value lies in avoiding costs elsewhere: repeated reconstruction, repeated judgment, review, error, delay, or risk. The balance will differ sharply by domain and by task frequency. A representation worth maintaining for work performed ten thousand times may not be worth constructing for a singular judgment.
Finally, some consequential judgment must remain where representation and mechanism cannot responsibly carry it. A representation can expose alternatives without deciding which objective matters most. Evidence can reduce uncertainty without determining what risk is acceptable. Enforcement can bound delegated authority without deciding where that authority ought to be placed. MAGE moves judgment only where knowledge and mechanism justify the move.
These conditions also define a boundary around the claim. Some work may depend on state that cannot yet be represented without destroying distinctions essential to judgment. Correspondence may be weak or disputed. Consequences may resist useful bounding. Cases may depend primarily on situated human judgment rather than recurring structure. Such work is a poor candidate for strong MAGE-style governance. Better agents, richer human supervision, or simply leaving the judgment to people may be better interventions.
This boundary is not all-or-nothing. A domain may support strong Modeling and weak Alignment. Useful representations may extend an agent's reasoning horizon even when few consequential judgments can responsibly be moved into independent enforcement. MAGE governs what can usefully be governed; it does not turn judgment into machinery merely by naming it.
These requirements do not imply that every domain should acquire software-like models, tests, or workflows. They identify the functions that must somehow be served: represent what matters, maintain correspondence with what is represented, obtain evidence for consequential claims, constrain delegated authority, and preserve human judgment where the remaining decision cannot responsibly be mechanized. The forms that serve those functions are domain-specific.
7.3.2 Model-Based Engineering
Conventional engineering is the nearest transfer because the shape of the outcome changes least. Civil, mechanical, electrical, aerospace, and systems engineering commonly produce artifacts or systems whose consequential properties can be represented before realization and inspected or measured afterward. Their representational traditions therefore supply much of the machinery MAGE requires.
Software engineering is not the first engineering discipline to discover the value of working through models. Model-Based Systems Engineering (MBSE) formalizes the use of modeling to support requirements, design, analysis, verification, and validation across the system lifecycle.22. International Council on Systems Engineering, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 5th ed. (Wiley, 2023). Different engineering disciplines supply different models—of geometry, structure, behavior, loads, flows, controls, interfaces, or other properties—but the underlying move is familiar: engineers reason about a system through representations chosen to expose properties relevant to the decisions they must make.
MAGE does not replace this machinery. It asks what happens when agents begin to perform substantial work within it. An MBSE environment may already contain much of the engineering knowledge an agent would otherwise have to reconstruct from documents, realized artifacts, and prior conversations. Those models can become part of the agent's reasoning environment. They are context supplied to the agent, true, but for our purposes their more critical function is as maintained engineering representations through which the agent can inspect the system, evaluate candidate changes, invoke established analyses, and communicate its own decisions. The arrival of capable agents therefore gives existing investments in model-based engineering another purpose. Models built to help people engineer systems can also help govern the agents engineering them.
This does not mean that an MBSE environment is automatically a Governed Engineering Environment. Models address only part of the problem. Their correspondence with the engineered system must be established and maintained. Agents need appropriate capabilities and authority. Consequential obligations need evidence, and some need controls outside the producing agent. Proposed actions may need validation, admission, or escalation before they acquire consequence. MAGE places the agent inside the model-based engineering environment and asks how that environment must be engineered so that the resulting work remains governed.
Digital twins offer a familiar example of one part of this relationship. A digital twin maintains a computational representation in correspondence with a physical system, allowing observations of the physical system to inform the representation and the representation to support analysis of the physical system across its lifecycle.33. Michael Grieves and John Vickers, “Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems,” in Transdisciplinary Perspectives on Complex Systems: New Findings and Approaches, Transdisciplinary Perspectives on Complex Systems: New Findings and Approaches, ed. Franz-Josef Kahlen et al. (Springer, 2017), https://doi.org/10.1007/978-3-319-38756-7_4. For MAGE, the important idea is not simply that the model is detailed. It is that the representation participates in an ongoing correspondence relationship with the thing it describes. An agent working through such a representation need not reconstruct the relevant system state from scratch, while measurements and established engineering analyses can provide evidence independent of the agent's own reasoning.
These traditions suggest that the software case developed in this book may be unusual in one useful respect. In an engineering organization with mature MBSE practice, some of the representational infrastructure MAGE calls for may already exist. The question shifts from what models should we construct so that agents can reason about the engineered artifact and its consequential properties? toward how should agents use, maintain, and act through the models engineers already trust? This leads to a testable prediction: other things equal, organizations with mature and trustworthy model-based engineering environments should be better positioned to delegate consequential work to agents without requiring those agents to reconstruct the system from its realized artifacts.
There is a useful exchange in the other direction. Software engineering has much to learn from the model-centered traditions of systems engineering, but the software case also contributes something to the broader picture. Software engineering can be understood as the engineering discipline of controlled change: it creates and evolves software while preserving sufficient control over the properties and consequences that matter.44. James C. Davis, The Software Engineering Handbook: A Judgment and Decision-Making Approach, 1st ed. (2026), https://davisjam.github.io/model-based-agentic-software-engineering/book/se-handbook/index.html. Software is valuable partly because behavior remains revisable after construction. Its engineering problem includes keeping the artifact acceptable as both it and its environment change.
That emphasis has produced rich machinery for governing change: version control, automated analysis, tests, review, permissions, admission gates, deployment controls, and telemetry. These mechanisms help engineers understand the system and govern its evolution: what may change, what must remain true, what evidence is required, and whether a proposed change may acquire consequence.
The software case was therefore a fortuitous place to develop MAGE. Model-based systems engineering provides a mature account of how engineering knowledge can live in purposeful representations. Software engineering provides a mature account of how continual change can remain under engineering control. In MAGE's terms, the former illuminates Modeling especially clearly, while the latter illuminates Alignment. Neither division is exclusive: systems engineering has long traditions of verification and change control, and software engineering has long used models. But their different emphases expose complementary parts of the same problem.
Agentic engineering brings those traditions together. As agents perform more consequential work, models can provide representations through which they reason, while the surrounding environment determines what evidence is required and which actions or outputs may acquire consequence. Conventional engineering shows this arrangement most clearly when the outcome is an artifact. The harder test is whether the same control structure survives when the outcome is a decision or action instead.
7.3.3 Professional Knowledge Work
Other engineering disciplines are therefore the easiest place to see the transfer: the outcome is often still an artifact, and much of the representational machinery already exists. The harder question is what happens when MAGE moves into organized knowledge work where the work itself produces the consequential decision or action.
Consider an ordinary recurring business decision: how much inventory to carry, which market to enter, how to price a product, whether to approve an investment, or how to respond to a change in demand. There may be no autonomous artifact handed from a development team to a separate user. The people responsible for the outcome remain inside the loop. They represent the relevant state of the world, develop alternatives, gather evidence, make a decision, act, observe what happens, and decide again.
MAGE does not require pretending that this process is software development. It asks which parts of the process admit durable engineering structure. A representation can make alternatives, objectives, assumptions, dependencies, evidence, and uncertainty explicit. Evidence requirements can prevent a recommendation from proceeding without specified observations. Authority rules can determine which commitments an agent may make and which require human approval. Subsequent events provide evidence about the consequences of the decision. A recurring lesson can then alter the representations, rules, or review obligations inherited by the next iteration.
The transfer is therefore not a development lifecycle. It is a control loop. When consequential work recurs, ask what knowledge should be represented, what claims require evidence, what authority may be delegated, what decisions require human judgment, and what today's experience should cause tomorrow's work to inherit.
That loop is not only a prospect. The Zenseact platform this section opened on is already an instance of it. Its agents query the company's code-review, build, issue-tracking, and enterprise resource systems as data sources and synthesize answers for the engineers who ask.1 No agent writes a patch or merges one. The work is consequential knowledge work inside an engineering organization, arranged around a software factory rather than performed inside it.
Two of its choices bear directly on the conditions set out above.
Intent enters through domain-authored configuration. The platform team owns a runtime that, in the company's own words, "does not contain any business logic." A domain team's agent is a directory holding two text files: a configuration listing which skills the agent loads, and a markdown file encoding that domain's rules, formats, and tool-usage patterns.1 Creating an agent is something the domain writes down, not something the platform builds.
Admission operates per tool call. A permission table keyed on the tool and the caller's role resolves every call the agent attempts to one of three outcomes: execute immediately, stream the call and its arguments to a person and wait for approval, or refuse.1
That second granularity deserves a name, because it differs from the one software uses. A software factory admits a change: work is assembled, then accepted or refused as a unit at a merge point. Here the boundary sits one level down, inside the work itself, at each action the agent takes. Per-call admission is what remains available when the outcome is an answer rather than an artifact, because an answer offers no assembled unit at which to stand and decide. The same three-valued choice—proceed, escalate, refuse—arrives at a far finer grain, and arrives many times inside a single session.
Read the case for its architecture rather than its effect. It rests on one source, written by the platform's own authors, reporting no adoption count and no outcome measure. It shows that the arrangement this section describes is being built in an engineering organization. It does not show what that arrangement yields.
Whether these professions belong here at all turns on the book's definition of engineering, which is functional rather than institutional: what matters is the kind of control, evidence, expertise, and responsibility being exercised, not the name on the office door. In the tradition of my engineering forebears, I hesitate to assert that doctors and lawyers are "engineering" things. But given the definition used in this book, I must admit the possibility. The boundary here is not the name of the profession. It is whether specialized expertise is being used to exercise informed control over consequential outcomes for which someone remains answerable. Two professions make the range visible.
Accounting illustrates the easier end of knowledge work because both its intermediate representations and many of its consequential actions are already highly structured. Much of accounting's environment was engineered long before software existed. Double-entry bookkeeping is an old enforcement mechanism: every transaction must satisfy an invariant, and a violation surfaces arithmetically rather than through anyone's vigilance. Around that core the profession has built ledgers and charts of accounts, classification rules, reconciliations, separation of duties, approval thresholds, closing controls, and audit trails. These are purposeful representations of economic activity with maintained correspondence to it, and controls that give important obligations a path to consequence independent of the person doing the work. The profession learned early not to let consequential outcomes depend on the producing worker getting everything right.
The MAGE question in accounting is therefore not whether to build a governed environment. It is what happens when agents perform more of the work inside one that exists. An agent can reason over the accounting representations rather than reconstructing the rules from prose for each transaction. Reconciliations and variance checks can supply evidence independent of its reasoning. Approval limits and segregation-of-duties rules can determine which of its actions acquire consequence and which require escalation. Some judgments stay where they are. Materiality is a judgment about what matters to a reader of the statements; the environment can apply a chosen threshold but cannot choose it. Ambiguous classification and the reasonableness of an estimate likewise remain with the accountant. The environment can route those judgments, record them, and bound their consequences. It does not make them.
Legal analysis illustrates the opposite limit: representation can become rich while consequential judgment remains stubbornly semantic. Its representations are abundant: parties, claims, elements, facts, authorities, procedural posture, deadlines, and the relationships among precedents. An agent can organize those structures, trace a proposition to its authority, test whether a claim's elements have supporting evidence, or flag conflicts among authorities. Some obligations are as governable as anything in software. A filing deadline can be enforced; a citation format can be checked; a procedural rule can gate a submission.
Yet representation does not imply determinization. Interpretation, strategy, credibility, and the weight of competing authority are semantic and contested. Two lawyers holding the same represented facts and authorities can responsibly reach different conclusions, and the difference between them is argued, not computed. The environment can make an argument's structure explicit and check its supports; it cannot decide which reading of an authority should prevail. In legal work, Modeling can extend the reasoning surface substantially while the determinization frontier barely moves.
The contrast carries the lesson. Where accounting's obligations were settled by the profession in advance and equipped with evidence, the frontier already sits far from the individual worker, and agents test how much further it can move. Where law's obligations remain open to argument, the same representational richness leaves the frontier nearly where it was. In both, the unit of transfer is the surface rather than the profession: a reconciliation may be mechanized while a materiality judgment stays human; a deadline may be enforced while an interpretation stays open. Asking whether a profession as a whole "admits MAGE" is the wrong grain of analysis.
7.3.4 Science as the Harder Case
Scientific work is worth examining because it tests the theory rather than flattering it. Much of what an agent needs can be represented and inherited: hypotheses, experimental designs, datasets, provenance, measurement models, statistical assumptions, analysis plans, and the evidence relationships among them. Some obligations can be enforced outside the producing reasoner. An analysis plan can be preregistered and held to. Data integrity and provenance completeness can be checked mechanically. A computational result can be refused admission until its steps reproduce.
What resists is the purpose of the work. A scientific claim is an attempt to revise the very knowledge a model would encode, and its ground truth is precisely what is under negotiation. The environment can verify that an analysis followed its plan; it cannot decide whether the explanation the analysis supports is scientifically compelling, or whether a surprising result reflects the world rather than the instrument. Accounting's consequential obligations were settled by the profession before the work began. Science's most consequential judgments are the ones the work exists to make.
MAGE's role here is coherent but bounded: govern the conduct of inquiry, and leave its conclusions to the community that owns them. Provenance, preregistration, reproduction, and disclosure are governable surfaces with independent paths to evidence. Novelty and interpretation are not. A governed environment for science that claimed to decide what counts as a discovery would not be an advance in rigor. It would be a category error.
7.3.5 Where the Generalization Fails
The transfer conditions predict their own failures, and the failures deserve naming rather than a passing caveat.
Some consequential knowledge is tacit or embodied: the surgeon's feel for tissue, the negotiator's read of a room, the mechanic's ear for a bearing going bad. Where the relevant state lives in trained perception rather than in any external record, there is no representation to maintain and nothing for a mechanism to hold. Some domains lack settled ground truth, or dispute it; evidence there cannot anchor enforcement because the parties do not agree on what the evidence shows. Some work changes its object by representing it. A disclosed negotiating position, a published trading model, and a community under observation all respond to their own description, so a representation is an intervention rather than a reduction, and correspondence in the engineering sense cannot be established. Highly novel work poses a different obstacle: stable models do not yet exist, so there is nothing for later work to inherit and no recurrence against which to amortize the structure. And some obligations cannot responsibly be interpreted apart from their context—a clinical decision, a use-of-force judgment—so moving them into machinery would not enforce the obligation. It would replace it with a proxy.
Finally, some environments offer no meaningful admission boundary and no independent source of evidence. Where nothing stands between the producing reasoner and consequence, Alignment has nowhere to act. Whatever governance exists must live inside the reasoner or its supervisor, which is the arrangement whose limits motivated this book.
These settings are not exceptions to the theory; they are its boundary behaving as stated. In such settings, better representations may still improve the agent's reasoning without making the consequential judgment mechanically decidable. Modeling can help even where strong Alignment cannot. Such domains may repay investment in representation while resisting independent enforcement, and should therefore expect to retain more human judgment per unit of consequence.
7.3.6 A Research Prediction
The broader interpretation produces a testable prediction. Holding agent capability roughly fixed, consequential work should become cheaper, more reliable, or require less human reconstruction when the environment supplies trustworthy task-relevant representations and independently governs obligations that would otherwise be repeatedly inferred. The effect should grow with task scale and recurrence, and shrink as representation, correspondence, or enforcement becomes expensive or unreliable.
The strongest test would be comparative rather than rhetorical. If the account is right, independently evolved systems for governing consequential agentic work should develop similar underlying structures despite producing very different outcomes: purposeful representations kept connected to the work they describe, independently produced evidence, allocated authority, and mechanisms that convert recurring judgment into structure later work inherits. The broader claim should fail where consequential work does not admit useful external representation, where correspondence cannot be maintained well enough to support consequential reasoning, where delegated actions cannot meaningfully be governed outside the producing agent, or where recurring experience cannot be converted into structure that later work can inherit. It should also fail if software's unusually symbolic realization substrate turns out to be essential rather than merely favorable.
That prediction has been developed here from software engineering. Testing it elsewhere is future work.
Works Cited
- Dufwa, Philip, and Thomas Luvö. “A Platform for Scalable Enterprise AI Agents.” Zenseact, May 29, 2026. https://zenseact.com/news/a-platform-for-scalable-enterprise-ai-agents/.
- International Council on Systems Engineering. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. 5th ed. Wiley, 2023.
- Grieves, Michael, and John Vickers. “Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems.” In Transdisciplinary Perspectives on Complex Systems: New Findings and Approaches, Transdisciplinary Perspectives on Complex Systems: New Findings and Approaches, edited by Franz-Josef Kahlen, Shannon Flumerfelt, and Anabela Alves. Springer, 2017. https://doi.org/10.1007/978-3-319-38756-7_4.
- Davis, James C. The Software Engineering Handbook: A Judgment and Decision-Making Approach. 1st ed. 2026. https://davisjam.github.io/model-based-agentic-software-engineering/book/se-handbook/index.html.