Abstract

The Art of Computer Programming, Code Complete, Refactoring, Design Patterns, and The Mythical Man-Month do not become irrelevant when AI can write code. The deeper risk is that programmers once turned the ideas in those books into intuition by implementing things, tracing failures, maintaining old systems, and living with the consequences. AI can let us skip that experience and arrive directly at something that looks finished.

The canon is not simply aging. Its path into practice is being interrupted. Sending the next generation back to an all-manual workflow would be pointless, and there is no virtue in preserving drudgery. What matters is preserving prediction, close contact with implementation, causal feedback, explanation, and long-term ownership. Unless those acts are designed into AI-assisted work, practical wisdom will slowly flatten into prompt vocabulary.

The part of programming culture worth passing on is not the ritual of typing code by hand. It is the ability to stay in direct contact with complexity. Classic books are compressed experience; our task is to build a learning loop in which that experience can expand again.

Part I · The canon does not contain answers

01A harder version of “Do these books still matter?”

I recently found myself asking a practical question: how useful are books such as Code Complete, Refactoring, and Design Patterns when AI can produce so much of the code? The easy answer is that they still teach us how to judge what AI writes. That is true, but it steps around the difficult part. How does someone who has never been trapped inside a bad codebase acquire the judgment to recognize one?

For many programmers of my generation, the feeling came before the terminology. Change one branch in a thousand-line method and an apparently unrelated feature fails. Follow an ambiguously named field through a dozen calls and you begin to sense that the design is wrong before you can explain why. Deploy a change to shared state without tests and you hesitate for a moment before pressing the button. That hesitation is already a form of knowledge. Books later gave names to what we had felt: divergent change, confused responsibility, hidden coupling. They turned experience into a vocabulary that could be examined and shared.

A young programmer today may follow a different route: describe the feature, generate an implementation, run the tests, and return any failures to the model. The defects and complexity remain, but the programmer may encounter them only through the model’s account. What gets delegated is not just the typing. It can also be the experience that teaches you where to look when something breaks.

The useful question, then, is no longer whether the classics are dated. It is where the experience that makes them intelligible will come from.

02One shelf holds several different kinds of craft

Calling all of these books guides to “writing clean code” misses most of what they contain. Together they span the distance from computation to organizational life.

Some of these books are too large to read straight through. Some use machines and languages that have long since disappeared. Modern type systems, frameworks, and delivery practices have absorbed or corrected parts of their advice. None of that makes them weightless. They preserve a history of how software learned to think: which failures exposed a weak idea, which practices survived contact with production, and which tradeoffs repeatedly proved expensive. Reading them gives us access to experience we did not have to acquire entirely on our own.

When Donald Knuth called programming an art, he was not appealing to mysterious talent. He meant the application of accumulated knowledge, skill, and ingenuity to real problems. TAOCP’s imaginary machine forces the reader to account for the cost of an algorithm. SICP offers a different lesson: change the evaluation model, representation of state, or abstraction boundary and the same problem becomes a different program. A capable tool can implement either version. It cannot remove the semantic and operational differences between them.

03A pattern is compressed accident history

Ask an AI to “improve this code with the Strategy pattern” and it can produce an interface, concrete strategies, a factory, and tests within seconds. The shape appears so cheaply that it is easy to forget why patterns exist.

A pattern usually earns a name after people meet the same tension across many systems. A behavior really does vary independently. An external dependency repeatedly leaks into the core. A thicket of conditionals is better understood as state transition. The name is an index into that experience. Behind it sit a context, competing forces, known consequences, and the cost of leaving the problem alone.

Take Strategy. It rarely begins with a desire for an elegant interface. More often, a billing function accumulates ordinary users, VIP rules, promotions, cross-border taxes, and refund behavior until each change risks breaking another case. Eventually someone separates the part that genuinely varies, how the charge is calculated, from the rest of the flow. The pattern gives a name to that recurring pressure. Generating the familiar class structure is easy. Understanding the pattern means recognizing whether the same pressure is actually present in your code.

That is why generating a pattern and understanding one are different acts. Generation reproduces a shape. Judgment asks whether there is a stable axis of change here, whether the cost of another indirection is lower than the cost of the expected change, and what evidence would justify deleting the abstraction later.

That is also the transmission problem in miniature. We can copy the index perfectly. The experience to which it points cannot be downloaded.

Part II · AI changes how experience is formed

04The old feedback loop was inefficient, and effective

The traditional route into engineering judgment was slow and often frustrating. A programmer wrote code, a later requirement or production failure exposed a weakness, and the repair required tracing unfamiliar state, reading an overlooked module, adding tests, and changing the system in small steps. Review supplied another person’s perspective. Long-term maintenance revealed the delayed cost of short-term decisions. The classics then gave names and structure to those scattered experiences. This loop was inefficient, but it repeatedly connected a decision to its consequences.

Peter Naur’s 1985 essay “Programming as Theory Building” argued that programmers create more than program text. They develop a theory of how a problem in the world is solved by a particular system. When the original team leaves, the files and documentation may remain while that theory disappears, forcing maintainers to build it again.^[9]

The argument lands differently now. Anyone who has inherited a well-documented system from a departed team knows the problem: each function may be readable while the reasons behind the boundaries remain obscure. A harmless-looking change can still violate an assumption that nobody wrote down. AI can explain every file on demand, but that does not mean the team shares a theory it can use when evidence is incomplete or constraints conflict. An explanation answers the current question. A theory lets maintainers make coherent decisions when there is no ready answer. The former can be generated; the latter has to be developed.

05Completion and comprehension can now separate at scale

The speed gains from AI-assisted coding are real, and they are highly sensitive to the task. In a controlled 2022 experiment, participants with early GitHub Copilot access finished a standardized JavaScript HTTP server task 55.8 percent faster. The authors explicitly noted that the experiment did not measure collaboration or code quality in a large project.^[11] METR studied experienced open-source developers working in repositories they knew well and found that early-2025 tools increased task time by 19 percent. Its 2026 update saw signals of a possible speedup from newer tools, but the researchers judged selection effects too serious for a reliable estimate of its size.^[16]

These results do not settle whether AI is “really” faster. They show how much the answer depends on the task, the developer’s familiarity with the repository, and the generation of tools being tested. More importantly, completion speed and depth of understanding are different measures. Someone can ship a working feature quickly while knowing little about why it works or when it will fail. AI makes that separation possible at a scale that older forms of abstraction did not.

An observational study of 21 novice programmers found that 20 completed the assigned task with generative AI. But AI did not resolve an existing problem for the weaker students: they still struggled to tell whether they understood the problem, and some mistook a finished task for mastery.^[12]

Another experiment asked 15 computer science graduate students to modify an existing codebase. With Copilot, they finished faster and passed more tests, but their understanding of the original code did not improve accordingly. Both studies are small and cannot support broad claims. Their narrower warning is still useful: completing a task is not the same as understanding the system.^[13]

This separation is not entirely new. Copying an answer, using a framework, or calling a cloud API has always allowed programmers to skip lower layers. AI differs in reach. A single interaction can delegate interpretation of the requirement, architectural choices, implementation, tests, and diagnosis. The result may be useful and correct, but much of the reasoning path can remain invisible to the person who accepts it. The saved time is real. So is the lost opportunity to calibrate judgment against consequences.

06Three abilities can thin out without much pain

The first is a causal map. Someone who traces a difficult failure learns where state changes, how exceptions propagate, and why a seemingly redundant check may encode the memory of an earlier incident. Someone who sees only the final diff can know what the system contains without understanding what holds its behavior in place.

The second is calibration. Recognizing a code smell is not the same as deciding whether it matters now, whether two similar blocks express one concept or merely resemble each other, or whether an abstraction isolates real change rather than imagined change. Judgment develops when we make a prediction and compare it with the outcome. If AI supplies an apparently correct answer before we form a view of our own, that calibration step can disappear.

The third is authorship and responsibility. A mistake you make and later repair tends to change your next decision. When a model generates the code, fixes it, and explains the fix, it is easy to record the episode as “the model got this one wrong.” The immediate problem is solved, but nobody necessarily absorbs the lesson.

A survey of 319 knowledge workers found a related tension: greater confidence in generative AI was associated with less self-reported critical-thinking effort. The study did not suggest that thought simply vanished. It shifted toward verification, integration, and oversight. This was not a programming study, and its evidence was self-reported, so the result should be read cautiously. It nevertheless points to an important design problem: AI-assisted work needs new opportunities for active judgment because the old ones may not survive by default.^[14]

07When practical wisdom becomes prompt vocabulary

The likely future is not one in which nobody mentions the classics. SOLID, DDD, Clean Architecture, Strategy, and Repository may become more common than ever in prompts and repositories. Every name will sound professional and each layer will have a plausible explanation. Nobody will be able to say which real force the structure is resisting.

“Refactor this according to SOLID and appropriate design patterns” can become an incantation. A twenty-line function turns into Factory, Manager, Provider, Handler, and Resolver. The tests remain green and every class has a plausible justification, yet a small change now requires navigating five files to reconstruct the original flow. The system is not simpler; its complexity has acquired more respectable names. AI makes that kind of abstraction cheap to produce, while the maintenance cost is deferred to another person or another quarter.

That is the cultural hollowing-out I worry about. The vocabulary survives while the experience that gives it meaning becomes thinner. A programmer may speak fluently about boundaries, cohesion, and dependency inversion, yet have no way into a race condition, a data mismatch, or a slow production path. Knowing the terms is useful. It is not the same as having learned when and how they matter.

Part III · Rereading the classics for an AI workflow

08The great big books teach respect for cost

TAOCP is not a handbook for everyday web development, nor should it be a barrier to entry. Engineers do not need to implement sorting in MMIX before using a standard library. Its durable value is the discipline of asking what lies behind an operation that appears simple: the model, proof, boundary conditions, and costs that libraries and hardware usually hide. It teaches respect for those costs without demanding that every reader reproduce the machinery by hand.

AI makes implementation cheap, which makes it easier to confuse generatable with understood. Code can run and pass its tests while hiding an algorithm that fails at a larger scale. Studying algorithms and models of computation is not an exercise in recalling more facts than a model. It gives us questions to ask: What happens when the input grows by an order of magnitude? Which invariants carry correctness? Do the assumptions still hold under different precision, memory, or concurrency constraints? When is a mature library enough, and when does the implementation or original paper need to be read? Those questions turn “it seems to work” into an account of why it works and where it may fail.

SICP likewise matters for more than Scheme. It trains the reader to look through syntax toward evaluation, composition, state, and interpretation. An agent that can write ten languages makes that ability more valuable, not less: surface differences grow ever easier to erase, while semantic differences will still demand payment at runtime.

09Refactoring should recover its meaning as an experiment

Of all the classics, Refactoring may have become more important. Fowler’s definition is deliberately narrow: improve internal structure through a sequence of small changes that preserve observable behavior. Small steps are a method of risk control, not an aesthetic preference. Tests are not only a final gate. They are feedback that says each step remains inside the known world.^[6]

AI is very good at producing a cleaner-looking version of a module. In the same change it may replace an interface, upgrade a dependency, alter an exception, and add tests tailored to the new implementation. When a caller fails weeks later, the commit offers little help in locating the behavioral change because rewriting and refactoring were mixed together. Refactoring is safe precisely because observable behavior is held constant while the internal structure changes. Once a new behavior or implementation strategy enters the same step, the team loses that guarantee and makes the source of a regression harder to trace.

Working Effectively with Legacy Code adds another practical lesson: an old system usually lacks, before it lacks elegance, the seams that let you sense behavior and separate dependencies.^[7] An AI-era team can turn that lesson into an explicit change contract. List observable behavior and unknown regions first. Add characterization tests. Restrict the write scope. Validate every small diff independently. Move to the next step only when the evidence permits it. The agent can perform much of the mechanical work; a human still defines what must not change.

10Treat every pattern as a falsifiable design hypothesis

Patterns do not need to be banned, and they should not be enabled by default. A better rule is to write each pattern as a hypothesis that reality is allowed to overturn.

Under this discipline, Strategy is a claim that there is a real axis of independent change, not merely a familiar set of class names. Adapter protects the core from the semantics of an external model. Observer trades an obvious call path for looser coupling in time and dependency; whether that trade is worthwhile depends on the context. AI is useful here because it can generate several candidate structures and counterexamples quickly. The engineer’s job is to compare them against evidence rather than reward the most recognizable pattern.

11Organizational classics remind us that code is not the whole system

The Mythical Man-Month, Peopleware, and Naur’s essay address different subjects, but they share an important premise: software is more than text. It is also a set of concepts, a communication structure, a working environment, and an allocation of responsibility. Faster local implementation does not remove any of these concerns. Code may be generated in minutes, but a team still has to decide whether it should be merged, who approves it, and who responds when it fails. Brooks’s “no silver bullet” remains relevant because much of the difficulty lies in deciding what to build and coordinating the people who build it.

DORA’s 2025 research describes AI as an amplifier of an organization’s existing capabilities. It can magnify strengths as well as weaknesses, so the returns depend on the system into which the tool is introduced.^[15] A coherent repository gives an agent stable examples to follow. Fast tests and short feedback loops allow a team to absorb more change safely. Clear responsibility makes escalation possible when risk appears. In a team with vague boundaries, stale knowledge, and little shared understanding, AI can instead produce more locally plausible changes that fail to fit together. The tool does not create those conditions, but it can make their consequences arrive faster.

Reading the classics in the AI era therefore cannot remain a matter of individual taste. Their ideas need somewhere to attach: review, task design, incident analysis, architecture decisions, and team development. Otherwise the knowledge you finish reading still has nowhere to land.

Part IV · A new apprenticeship for software craft

12Restore feedback, not scarcity

Asking new programmers to avoid AI and write everything by hand for several years is neither realistic nor educational by itself. Much of the old friction was simple drudgery: looking up syntax, copying boilerplate, porting the same logic between frameworks, or waiting for a build. Removing that work is a genuine improvement.

Other kinds of friction are educational because they change the next decision. Predicting an outcome before acting, tracing a state transition personally, explaining an abstraction to another engineer, and maintaining a change months later all connect judgment with evidence. The aim is not to preserve pain. It is to remove drudgery without removing feedback.

Cognitive apprenticeship moves through modeling, coaching, scaffolding, articulation, reflection, and exploration, with support gradually withdrawn as the learner gains competence.^[10] AI fits this model well. It can demonstrate how an expert traces a failure, provide progressively stronger hints, generate counterexamples, and compare several solutions. The least useful learning design reverses the sequence by supplying a polished answer before the learner has formed a model of the problem. The tool remains available, but the learner has little to do beyond accepting its output.

13Separate production mode from learning mode

A team does not have to sacrifice delivery speed on every task. It does have to admit that finishing work and building capability are different modes, then reserve explicit capacity for the second.

For a novice, a vague “no-AI zone” is difficult to enforce and easy to experience as punishment. A difficulty budget is more precise: identify the parts of a task the learner must attempt before receiving a complete solution. In debugging, the learner can draw the call path and record a hypothesis before using AI to test it. In an algorithm exercise, they can state the complexity and invariants while AI provides hints in stages. More automation becomes available as the learner’s own model becomes stronger. The default should follow the person’s capability, not the tool’s capacity to generate.

Senior engineers are learning as well. They must divide large tasks into units an agent can complete and return with useful evidence, detect architectural drift in code that looks locally tidy, design validations whose success carries real information, and review a much larger volume of output without losing judgment. The classics provide a language for assessing these decisions. Current practice must adapt that language to a different means of production, and even experienced engineers are still learning how.

14Six feedback devices that fit into ordinary team life

15Senior programmers will still need a nose for trouble

Teams also need better measures. If the scorecard includes only closed tickets and merge speed, the cost of understanding is easy to push into the future. Delivery metrics should be considered alongside less convenient questions: Where does rework cluster? How many people can explain a critical module without asking AI? How expensive is it to modify code generated three months ago? Did an incident produce a reusable test or rule? Does review catch semantic problems or merely improve presentation? These signals are imperfect, but they reveal whether a team is accumulating understanding or borrowing against its future.

None of this means everyone must master all of TAOCP or that senior engineers should write every function by hand. A healthy engineering culture is not a shared reading list or vocabulary. It consists of habits: respecting complexity, refusing to equate passing tests with understanding, deleting a failed abstraction instead of hiding it behind another layer, naming the behaviors that must not change, investigating a failure before blaming the model, and accepting responsibility for what happens after release. No single book contains those habits, but the best books help us recognize and practice them.

The books still belong in that culture, but the way we read them will change. The Art of Computer Programming can be read beside a profiler and a model-generated algorithm. Refactoring can become a protocol for agent changes. Design Patterns can become a review form for design hypotheses. The Mythical Man-Month and Peopleware can help a team resist the naïve arithmetic that more agents automatically mean more throughput. A classic no longer waits for the mythical month when we finally read it cover to cover. It supplies a longer history and a more accurate language at the moment a real problem makes us ready for it.

AI is making implementation cheaper. That raises the value of knowing why a design works, what should not be generated, and who owns the result when it fails. Software craft will not disappear merely because less code is typed by hand, but it will not pass to the next generation simply because the classics remain on the shelf. It survives only if teams design understanding into the workflow, preserve feedback, and attach responsibility to real people.

A programmer does not need to repeat every old hardship to develop sound judgment. They do need direct contact with the system: enough to trace a failure, explain its cause, decide how to repair it, and live with the result. Keeping people inside that causal loop is how software craft can continue in the age of AI.

Abstract

AI coding lets one person turn a few sentences into a convincing application prototype. In doing so, it undermines the most visible promise of traditional low-code. Natural language is closer to business intent than drag-and-drop, while generated code can be more flexible than learning another proprietary expression language. A low-code product whose main achievement is saving keystrokes has good reason to worry.

Yet there is a wide gap between generating software that runs and entrusting a continuing business operation to it. Permissions, data consistency, failure recovery, performance, audit, upgrades, and ownership live in that gap. The scarce asset in a mature low-code platform is not its canvas. It is the set of production-tested components, models, and runtime contracts underneath. AI can interpret intent and propose a change; the platform can constrain and reuse; the engineering system can verify and deliver. Natural language plus a CLI is not necessarily the final interface, but it looks like a credible entrance to the next phase.

AI coding will first displace the old low-code proposition of replacing hand-written code with drag-and-drop. If the next generation of low-code can become a machine-readable, verifiable, reversible foundation for enterprise applications, it will inherit a harder and more valuable job: making generation fast without making change uncontrollable.

Part I · When code becomes cheap

01Why the death of low-code sounds plausible

The classic low-code demo begins with a table dragged onto a canvas. A data source is attached, a form is configured, and a working management application appears within minutes. The result felt remarkable because the alternative was assumed to be slower: find developers, create a project, choose a stack, implement the interface and API, then wait for deployment. That comparison has changed.

A user can now ask an AI for a supplier onboarding application. Suppliers submit credentials; procurement performs the first review; legal checks the contract; finance verifies the bank account; high-risk suppliers receive an additional compliance review; every action must be traceable. A few minutes later, the pages, API, database, and sign-in flow may already exist. The result may not be reliable, but it can look remarkably complete.

In his talk “Software Is Changing (Again),” Andrej Karpathy describes large language models as a new kind of computer programmed through natural language. ^[1] Follow that argument into application development and drag-and-drop begins to look indirect. The user does not really want to say, “Place a dropdown in the second column.” The user wants to say, “High-risk suppliers require an additional compliance decision.” If natural language can carry the latter, the canvas loses much of its advantage as the primary interface.

This is not the first time a higher-level abstraction has challenged low-code. Code generators, fourth-generation languages, model-driven development, and cloud services have all removed implementation work. AI is different because it can work with incomplete intent, explain its interpretation, and revise the result without requiring the user to learn a precise formal language first. The low barrier once associated with low-code is no longer exclusive.

I therefore agree with the first half of the pessimistic case. If writing less code remains a platform’s main claim to value, its moat is disappearing. A fixed template is not necessarily more adaptable than generated code. A proprietary formula is not necessarily easier than natural language. A constrained component set may offer less freedom than a conventional codebase. AI does not need to replace the whole platform at once. It only has to invalidate the reason customers originally accepted its constraints.

02Zero to running has become genuinely cheap

The clearest effect of AI coding is that software work can begin with “let us make one and see” rather than a request ticket. Product managers can test an interaction themselves. Operations teams can create a temporary tool. A founder can compare several product directions in a day. Ideas that would never have reached an engineering backlog can now acquire an executable form.

Addy Osmani calls the resulting experience the “70% problem.” AI can take someone to a surprisingly complete first version, while the remaining distance to maintainable, production-worthy software still demands architecture, edge-case reasoning, and verification. ^[2] The percentage is best treated as a useful engineering metaphor, not a universal project measurement. The first stretch feels quick because it is easy to demonstrate. Much of the last stretch appears only under failure, growth, and change.

A complaint-management prototype may already include authentication, a list, a detail view, and a state transition. Before production, the questions change:

• How does the system identify and merge duplicate complaints from the same customer?
• Customer service agents may see only their product line, while quality leads see across lines. Is that rule enforced centrally or reimplemented in every page?
• Does “no response within 24 hours” use elapsed time or a business calendar? What happens on a holiday or while a case is paused?
• If a notification succeeds but the state update fails, can a retry escalate the case twice?
• When a complaint contains private customer information, what rules govern exports, search indexes, logs, and backups?
• When the workflow changes six months later, do in-flight cases remain on the old version or migrate to the new one?

These questions rarely appear in the first screenshot. They determine whether a company should trust the application with customer relationships and service obligations.

03A prototype can be most dangerous when it looks finished

A rough prototype invites skepticism. A polished interface with smooth transitions and a deployment URL does the opposite. Visual completeness becomes a proxy for engineering completeness, and “a few fixes before launch” begins to sound reasonable.

Enterprise qualities are rarely plugins fitted at the end. A data model’s treatment of history sets the limit for audit and migration. Whether permissions are enforced by the service or scattered through the frontend determines the exposure to unauthorized access. Transaction boundaries determine whether a partial failure can be recovered. Dependency choices determine whether growth can be accommodated or requires a rewrite. These decisions already exist in the first version, even when nobody has asked them to survive scrutiny.

AI increases the scale of this misjudgment. One agent creates pages, another adds APIs, a third changes the database, and a fourth edits deployment configuration. Every local answer may be plausible while no one understands the assembled system. Producing ten times more code does not create ten times more review capacity, test coverage, or architectural understanding. The bottleneck moves from “Who can write this?” to “Who can prove this?”

Part II · Enterprises buy controlled change

04Enterprise is a statement of responsibility, not size

“Enterprise-grade” is often confused with a larger feature set or a more elaborate stack. Microservices, containers, and Kubernetes become ceremonial markers of maturity. In practice, a three-screen approval tool may need enterprise safeguards if it carries real money, customer data, or regulatory obligations. A fifty-screen demonstration with no continuing dependency is still a prototype.

A more useful definition is a statement of responsibility: the organization is willing to entrust an ongoing business operation to this system and knows who must detect, explain, and recover it when something goes wrong.

That responsibility needs at least six kinds of certainty:

• Outcome certainty. The same business conditions produce the same result, and retries or concurrent actions do not silently create conflicting facts.
• Boundary certainty. Identity, role, tenant, and data permissions remain consistent at every entry point; security cannot depend on one page remembering to hide a button.
• Operational certainty. The system can isolate, degrade, or recover when a dependency times out, a network becomes unreliable, or traffic changes abruptly.
• Change certainty. The impact of a model, workflow, or interface change can be inspected; old data can be migrated; a failed release can be reversed.
• Evidence certainty. It is possible to reconstruct who acted, when, with which information, and under which rule.
• Ownership certainty. Business meaning, technical risk, and production release have accountable owners. AI is not one of them.

These properties are not proportional to the number of features. They determine whether software becomes an organizational asset rather than a disposable output.

05AI raises output; the engineering system decides what it amplifies

DORA’s 2025 research on AI-assisted software development offers a more useful conclusion than either “AI works” or “AI harms delivery.” AI acts as an amplifier of an organization’s existing strengths and weaknesses. The study associated AI adoption with higher delivery throughput while delivery stability remained under pressure. ^[3] That does not predict the outcome for an individual team. It does warn against treating local coding speed as end-to-end delivery performance.

In a team with clear boundaries, fast tests, short feedback loops, and dependable releases, AI can reproduce good practice more quickly. In a team where requirements change verbally, permission rules are scattered, tests are chronically deferred, and deployment depends on memory, AI can multiply inconsistency just as efficiently. Generation has no direction of its own. The surrounding engineering system determines whether it amplifies order or disorder.

This is where low-code may find a more defensible purpose. It does not have to beat AI at generating code. It can supply engineering facts that already exist: how identity is integrated, how workflow state is persisted, which components may access sensitive fields, how tasks are timed, how data is audited, and how applications are released and rolled back. AI need not reinvent those answers for every project.

06The valuable part of low-code lives below the canvas

A mature table component appears to offer columns, filters, pagination, and buttons. Its real accumulation sits underneath. How does it paginate large datasets? Do field permissions also constrain query and export? How are concurrent updates detected? What do locale and time zone do to sorting? How does the component behave on mobile or with assistive technology? What is retried after failure? Which actions produce audit evidence?

AI can certainly generate a table on demand. Generating a similar appearance does not reproduce every incident, correction, and trade-off learned over years of operation. The value of a mature component is not the number of lines it saves. It is a compressed history of failure turned into reusable default behavior.

The same accumulation exists in workflow, identity, files, messaging, scheduling, and integration. An approval engine is not merely a set of connected boxes. It must account for withdrawal, reassignment, additional reviewers, duplicate submission, old workflow versions, departed employees, time zones, and business calendars. A file service is not just an upload button. It includes malware scanning, access control, lifecycle rules, and retention.

None of this means that using a mature component guarantees a stable application. Components can be combined incorrectly, and platforms have defects. The defensible claim is narrower and more useful: reusing proven capabilities reduces the amount of foundational failure each project must rediscover, but it does not eliminate architecture or acceptance testing.

07From development tool to runtime contract

If the canvas is no longer central, what remains of low-code? I believe the answer is an application model that both people and machines can understand:

• the fields, uniqueness rules, states, and lifecycle of a business object;
• the nodes, transitions, conditions, validations, and compensation paths in a process;
• who may perform an action and which fields and records that person may see;
• the semantic components on a page and the business capabilities on which they depend;
• capacity, availability, audit, recovery, region, and retention requirements;
• the live instances affected by a change and the checks required before release.

When this information exists only as canvas coordinates and proprietary JSON, it remains configuration inside a closed tool. Once it has stable semantics, versions, interfaces, diffs, and validation rules, it becomes a runtime contract. AI can generate the contract, people can review it, the platform can execute it, and a delivery pipeline can verify it.

Writing on Martin Fowler’s site, Evan Bottcher describes a digital platform as self-service APIs, tools, services, knowledge, and support presented as a compelling internal product. A good platform offers a safe and compliant paved road rather than forcing every team down one mandated route. ^[4] The next generation of low-code should work the same way. It cannot become a larger shared-services queue, and it cannot use “governance” as an excuse for poor usability. Trusted defaults must be easier to consume than bypassing the platform and rebuilding them.

Part III · Natural language plus CLI, not a magic textbox

08Natural language should carry business intent

Drag-and-drop works well for a local layout adjustment. It is a poor medium for the complete meaning of a business process. When a user asks for supplier onboarding, the important material is the set of objects, roles, transitions, exceptions, and obligations, not the coordinates of controls.

A useful AI should not immediately create pages. It should first turn the request into a plan that people can challenge:

This step can look like a delay because no code has appeared. In reality, it prevents one of the most expensive mistakes: a fluent interface hiding the assumptions the AI made on the user’s behalf. Natural language should not leave ambiguity permanently ambiguous. Its value is helping a team turn ambiguity into confirmable structure earlier.

09A CLI bridges intent and engineered delivery

Why introduce a CLI when the user can already describe the outcome? Because a sentence is suitable for expressing a goal, not for serving as a production change record. Enterprise delivery must identify the target environment, current version, exact mutation, validation result, and recovery material. A CLI turns those actions into repeatable, composable, auditable commands. It also lets an AI operate through business semantics instead of screen coordinates or guessed internal JSON.

The current Spark CLI provides a concrete example. It establishes an authentication profile, application, editable version, and workflow context before exposing commands such as add a node, connect a transition, or attach a validation rule. High-impact writes require an explicit --yes. The result can be checked and exported as a package. The visual designer remains the place for graphical inspection and human governance; the CLI handles automation, batch work, structured output, and AI integration. ^[5]

The following is an illustrative scenario assembled from real command semantics. It assumes that the application, workflow, form, and reusable Step already exist. The names explain the method; they do not refer to a particular production environment.

# Prove the target context instead of inferring it from chat history
spark auth use spark-dev
spark-designer task app use customer-service
spark-designer task current
spark-designer task workflow use "Complaint Handling"
spark-designer task workflow current
spark-designer task workflow describe --json

# Read the rules registered by the target service, then prepare a change plan
spark-designer task workflow rule-types

# After a person approves the plan, add a quality review for major complaints
spark-designer task workflow add-node \
  --type status \
  --name "Quality Review" \
  --step "Quality Review" \
  --yes

spark-designer task workflow connect \
  "Product Review" \
  "Quality Review" \
  --name "Escalate Major Complaint" \
  --form qualityReview \
  --yes

# Read back the result, run checks, and preserve recovery material
spark-designer task workflow describe
spark-designer task check workflow-config --yes
spark-designer task package export \
  --output complaint-management-backup.json

This is less magical than the invented platform create command in the original outline, and more useful for that reason. AI can still translate a business request into these operations, but it must show the target context, actual capability catalog, and expected change. A person confirms before the write; the tool reads back afterwards; the designer and a suitable runtime environment remain part of validation. The CLI does more than save typing. It gives generation an evidence trail that can be questioned.

10A trusted build is a loop, not a prompt

Combining AI and low-code into a responsible delivery process requires roughly seven movements:

1. Express intent. A business owner states the outcome, roles, exceptions, and constraints that must not be violated.
2. Form a plan. AI decomposes objects, workflows, permissions, components, and open questions without immediately changing production data.
3. Prove context. Tools read the actual application, version, environment, and capability catalog so the wrong target is not modified.
4. Compose capabilities. The platform prefers mature identity, workflow, SLA, audit, notification, and data components.
5. Generate the difference. AI creates only the model, configuration, or extension code not covered by the platform, with an explicit impact surface.
6. Verify the result. Automated checks cover primary flows, permission matrices, retries, escalation, recovery, and performance baselines; people validate business meaning and high-risk decisions.
7. Operate and learn. Monitoring, audit, versioning, progressive delivery, and rollback produce evidence for the next change.

The third approach is not a mechanical sum of the first two. Its generation space is different. Open-ended AI coding may choose any framework, dependency, or design. A trusted platform prefers approved components, shared identity, and standard connectors. Sensitive actions must be audited, and releases must pass known gates. This reduces freedom, but it also reduces the cost of proving the same foundational properties for every new application.

Part IV · Low-code still needs a revolution of its own

11“Fast and good” is not automatic

AI and low-code can improve speed and quality together, but the mechanism matters.

Speed comes mostly from interpreting intent and automating boilerplate configuration, documentation, and differential implementation. Quality comes mostly from mature components and a shared runtime, not from AI becoming incapable of error. Stability comes from failure boundaries, observability, and recovery. Reliability comes from constraints, tests, audit, and release ownership. Maintainability comes from models, code, versions, and decision records existing together.

Remove any one of those pieces and the promise changes. Natural language without a stable platform creates a fast-growing code pile. A closed platform without a better intent interface leaves users trapped in laborious configuration. Both together, without validation and responsibility, send mistakes into production at greater speed.

The division of labor is therefore subtler than “AI supplies speed and low-code supplies stability.” AI can help with testing and governance; a poor platform can slow everything down. The effective pattern is to let probabilistic generation propose candidates, deterministic systems enforce constraints, and people remain responsible for judgments that cannot be outsourced.

12Seven changes the next platform must make

Years of component development do not guarantee that a low-code platform will survive this transition. If the accumulated knowledge remains locked inside browser clicks, private formats, and manual operations, AI cannot invoke it reliably and an enterprise cannot inspect it well.

Forrester analysts Diego Lo Giudice and John Bratincevic use the term AppGen for a related direction: an AI-native, business-aware full-stack platform with intermediate models between business intent and executable systems, plus domain knowledge and governance embedded in the platform. ^[6] Whether that label survives does not matter much, and their timeline for reshaping the software lifecycle remains a forecast. The more durable observation is that low-code and generative AI are converging, and the competitive unit is shifting from an editor to the entire application delivery chain.

Security cannot be established by a platform promise either. NIST’s Secure Software Development Framework places security requirements, provenance, design decisions, release integrity, and vulnerability response across the development lifecycle. ^[7] A platform that expects to carry core enterprise work must turn requirements like these into executable defaults and evidence, not check them once in a procurement questionnaire.

13A stronger platform needs clearer boundaries and an exit

Not all software belongs on a shared low-code runtime. Novel interaction models, extreme performance or real-time requirements, infrastructure systems, algorithmically distinctive products, and regulated scenarios the platform has not proven may require direct engineering control. Even an ordinary business application can contain a rule too specific to force into the wrong component.

AI can also deepen platform lock-in. In the past, a developer at least knew which configuration screens had been used. In the future, AI may continuously invoke proprietary platform semantics while the application portfolio expands faster than the team can map its dependencies. A responsible platform needs data export, open interfaces, versioned models, observable runtime behavior, and explicit extension boundaries. A good paved road has signs and exits. It does not turn its guardrails into walls.

False certainty remains another danger. Stable components can still be assembled into an unstable system. An automatically generated permission matrix may be internally complete while misunderstanding the organization. Every test may pass because the tests simply repeat the AI’s mistaken assumption. A platform can lower risk. It cannot define correctness on behalf of the business owner or accept production consequences on behalf of the technical owner.

14The destination is not No Code, but Trusted Build

AI coding will eliminate some low-code products. Platforms built mainly on templates, drag-and-drop, and the promise that non-programmers can make apps will struggle to justify their learning cost and lock-in. Natural language is more direct, conventional code is more open, and AI will keep improving the conversion between them.

Cheaper code does not make the whole cost of enterprise software cheap. If anything, more candidate implementations make proven components, explicit runtime contracts, automated governance, and recoverable delivery more scarce. Enterprises do not need a larger supply of code with unknown origins. They need controlled change at a lower cost.

The most competitive low-code platform may no longer begin with a canvas. A user states the business objective and AI produces a structured plan. The platform composes pages, data, workflow, and permissions from trusted capabilities. CLI and API calls make every mutation traceable. Tests, policy, and accountable approval decide whether to release. Operational evidence improves the next generation.

I call this Trusted Build, not to invent another market category, but to change the acceptance questions. We should ask more than whether the system can generate:

• Does it express the business intent and surface its unknown assumptions?
• Does it reuse proven capabilities instead of rebuilding infrastructure?
• Can it provide evidence about permissions, data, performance, and failure paths?
• Is the change explainable, reversible, and transferable to another owner?
• If the platform stops fitting, does the organization still own its data and business knowledge?

If those questions have credible answers, AI coding and low-code are not engaged in a simple replacement war. AI changes the application interface. Low-code contributes capabilities selected by time and failure. The engineering system constrains both into a delivery process for which someone can responsibly answer.

The contest is no longer about who can let a non-programmer make software. AI has already pushed that door open. The harder question comes next: when everyone can generate software, who can make it worthy of an enterprise’s long-term trust?

Abstract

AI has made code generation astonishingly fast. It has also encouraged a dangerous assumption: if implementation is cheaper, software projects should move faster and teams should shrink. In practice, the opposite pressures soon appear. More generated code means more to understand, test, coordinate, and own. The more agents can do in parallel, the more human attention, judgment, and accountability become points of congestion.

Peopleware was never merely a book about noisy offices or management technique. It was a book about the conditions under which knowledge work can happen: how concentration forms, how teams cohere, how trust makes learning possible, and how management quietly destroys all three. AI has not made those questions obsolete. It has simply added machines to the list of things that can interrupt us, while giving every strength and weakness in an organization a larger lever.

AI has changed the speed of software production. It has not changed the fact at the heart of Peopleware: the hardest part of a software project is rarely the code. It is the people living with it.

Part I · The people hidden by the tools

01Why revisit Peopleware now?

The first time I read Peopleware, I took it for a book about managing software teams. Its concerns seemed wonderfully concrete: noisy offices, too many meetings, impossible schedules, staff turnover, team cohesion, and the many ways a manager can dismantle a good team without quite realizing it.

Reading it again after the arrival of AI coding tools, I noticed that Tom DeMarco and Timothy Lister were asking a more fundamental question. In software development, is the real constraint technical—or human?

For years, the industry treated productivity as a typing problem. We invented higher-level languages, more capable frameworks, better IDEs, and increasingly automated delivery pipelines. AI has carried that instinct to its logical extreme. One developer can now ask several agents to search a repository, change code, write tests, inspect logs, and update documentation at the same time. Work that once took days can produce a plausible candidate in hours.

And yet projects have not acquired infinite speed. Requirements are still ambiguous. Systems still have histories. Boundaries still require judgment. Releases still fail. Responsibility still has to land somewhere. When the third edition of Peopleware appeared in 2013, its publisher still described software development as being shaped by human rather than technical issues. In the age of agents, that claim feels sharper, not weaker.^[1]

As execution gets cheaper, framing, judgment, verification, and ownership get more expensive. AI did not remove the human bottleneck. It moved it upstream from the keyboard into the decision chain.

02The bottleneck did not disappear. It moved.

In conventional development, implementation time was the most visible scarcity. Plans revolved around one question: how long will it take to build? AI cuts that cost dramatically, but it does not reduce every adjacent cost at the same rate. Someone still has to understand the problem, choose an approach, review the change, verify the business rules, assess security, plan a migration, observe the release, and restore service when things go wrong.

The cost simply travels downstream. The old shape of the work might have been four hours of coding followed by one hour of review. The new shape might be ten minutes of generation followed by two hours of reconstruction and verification. In the first case, the waiting happened before production. In the second, the queue forms after it. Measure only generation and the improvement looks spectacular. Measure the entire value stream and the gain may be modest—or swallowed by rework.

DORA’s 2025 research on AI-assisted software development treats this as a systems problem. AI magnifies the conditions already present in a team and its delivery system. Strong platforms, loosely coupled architectures, and fast feedback can absorb a larger volume of change. Weak tests, slow workflows, and tightly coupled systems turn that same volume into instability.^[6]

That is where a modern reading of Peopleware begins: never mistake the local speed of a tool for the productivity of an organization.

Part II · Attention becomes the new production line

03AI removed waiting—and created more interruption

One of the most durable ideas in Peopleware is the value of uninterrupted time. Programmers, designers, and architects rarely do their best work in the gaps between notifications. The problem, the code, the business constraints, and the available design choices have to coexist in the mind long enough to become a usable model.

That model may take fifteen minutes to assemble; it may take half an hour. A message that consumes two minutes can therefore cost much more than two minutes. Research on task switching finds the same pattern: changing tasks requires people to shift goals and reactivate rules, and the cost grows with the complexity of those rules.^[2]

In the old development environment, interruptions mostly came from other people: a product manager asking for status, a tester reporting a bug, a manager calling an impromptu meeting, a colleague asking for help. In the AI environment, machines have joined the queue.

A developer may have three, five, or more agents running at once: one refactoring a service, another building a UI, a third writing tests, a fourth reading production logs. Each returns results, asks questions, requests permissions, reports a failure, or waits for a decision. The developer stops working on one coherent problem and starts hopping among several partially remembered worlds:

• What exactly did agent A change, and did it cross the task boundary?
• Is agent B’s failing test a code problem or an environment problem?
• Which approach did agent C take, and what assumptions did it discard?
• How do I stop agent D from “helpfully” refactoring an unrelated module?
• How do these independent outputs fit back into one system?

The programmer has become a scheduler of concurrent cognitive work. The catch is simple: agents can run in parallel; human understanding, judgment, and accountability remain largely serial.

This explains a distinctly modern kind of exhaustion. You may spend little of the day typing and still finish it depleted. The effort went into rebuilding context, handling exceptions, and closing cognitive loops that kept reopening.

04Code is abundant. High-quality attention is not.

The easiest mistake in AI-assisted development is to confuse lower implementation cost with lower cost everywhere. When generation capacity surges upstream, review, testing, integration, and decision-making become the new places where work waits.

Code can be generated in parallel; careful review cannot scale without limit. Options can be produced in batches; a team still has to choose among them. Tests can run automatically; someone still has to understand why they failed. Agents can retry indefinitely; people still own the production incident. If every workflow sends every exception to a human, attention becomes the single-threaded lock shared by the entire automation system.

A manager therefore needs questions more useful than “How many more agents can we add?”

Without answers, adding agents is like increasing the speed of an upstream conveyor belt after the line is already jammed. The result is not faster delivery. It is a review backlog, an overloaded test system, architectural drift, and more operational risk.

When production becomes cheap, the organization has to protect attention—not spend it even faster.

05The codebase grew. The team’s understanding did not.

Software organizations have always been tempted to substitute visible activity for difficult-to-measure value: lines of code, commit counts, features shipped, tickets closed, sprint velocity. AI makes those proxies more dangerous.

An agent can produce thousands of lines in minutes. It can create a dozen modules in one pass. It can turn a small fix into a handsome, fully structured refactor. If output is still the measure of productivity, AI can make almost any team’s numbers look excellent.

But code is not automatically an asset. It becomes one only when the team understands it, has evidence that it works, can change it safely, and knows why it exists. Otherwise, faster generation does not build capability. It builds cognitive debt.

When a developer writes a piece of code, they usually remember why it took that shape, which boundary conditions mattered, and which alternatives were rejected. The documentation may be incomplete, but the decision passed through a human mind. AI-generated code can arrive in the repository without that journey. It may run. It may pass the tests. It may even look cleaner than the handwritten version. And no one on the team may truly own it.

This creates a convincing project illusion. The feature is done. The demo works. The repository is growing. Yet the engineers are looking at a system that feels less familiar every week. Only when production misbehaves, a business rule changes, or a cross-cutting refactor becomes necessary does the organization discover that generated code never became controlled software capability.

In 2025, METR ran a randomized study with 16 experienced developers working on 246 real tasks in mature open-source repositories. With the particular tools and sample used at the time, developers allowed to use AI took about 19 percent longer on average, even while believing they had become faster. The researchers stressed that this was a snapshot of early-2025 tools and a specific population. By 2026, selection effects made a follow-up experiment too unreliable to support a confident current estimate. The enduring lesson is not that “AI makes developers slower.” It is that feeling faster is not a substitute for measuring the whole workflow.^[7][8]

Part III · A team is not a container to be compressed

06Psychological safety is part of AI reliability

Peopleware returns again and again to a truth that management theory often misses: a team cannot be assembled into cohesion by command. A real team develops trust, a shared purpose, an identity, and enough autonomy to act as a unit. None of these qualities matters less in the AI era. They matter more.

As AI takes on more coding work, engineers have reasonable questions. Is my experience becoming less valuable? Is the company adopting AI to help me, or to reduce headcount? If I turn my working methods into a skill or an agent, am I documenting my way out of a job? When generated code fails, who is accountable?

If management avoids those questions and talks only about efficiency, people protect themselves. Some keep useful methods private rather than turn them into organizational knowledge. Some perform adoption without changing how they work. Some create complexity only they can explain. Others lower their sense of ownership because “the model wrote it.” None of this is irrational. It is what uncertainty produces when candor feels unsafe.

Amy Edmondson defined team psychological safety as a shared belief that interpersonal risk-taking is safe within the team. Her study of 51 work teams associated psychological safety with learning behavior, which in turn connected to team performance.^[3] AI collaboration demands exactly this kind of risk-taking. People have to be able to say:

• “I do not understand this generated code yet.”
• “The tests pass, but I do not believe they cover the real risk.”
• “My prompt sent this in the wrong direction. We should start again.”
• “This problem is not ready for more automation. We need to clarify it first.”

If an organization makes “I don’t know” unsafe, AI magnifies false certainty. The model answers confidently. The engineer hesitates to object. The manager wants a visible win. Those three forces can carry code that nobody understands through every review and into production.

07Teamicide in the AI era

Peopleware coined a wonderfully severe word: teamicide. Capable teams are often damaged not by a lack of talent, but by the way they are managed—impossible deadlines, constant reshuffling, internal competition, excessive standardization, and process used as a substitute for trust.

AI gives management several new ways to commit the same old crime.

Turn engineers into agent operators

A manager may decide that the model can now handle most technical work, gradually remove design authority from engineers, and leave them to receive tasks, invoke agents, and submit the results. Output may rise for a while. Judgment will not. People who are no longer expected to make design decisions eventually lose the opportunity—and then the ability—to make good ones.

Turn AI use into an individual output contest

Who generated the most code? Who closed the most tickets? Who ran the most agents at once? These metrics look objective and reward exactly the wrong thing: local activity at the expense of shared review, knowledge, and responsibility. The SPACE framework already argues that developer productivity spans satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. No single activity metric can stand in for the whole.^[4] As generation gets cheaper, the distance between activity and value only grows.

Cut until the system loses its memory

Once some tasks can be automated, it is tempting to conclude that work once done by ten people now requires three. But those ten people did more than write code. They carried business memory, operational judgment, cross-functional relationships, customer context, on-call experience, and spare capacity for the unexpected. Those contributions are almost invisible in task counts. They are also what let a team recover when reality departs from the plan.

The people who look least productive on a dashboard may be carrying the context the system cannot regenerate.

08The best AI team is not the one with the fewest people

The AI era has produced an extreme but seductive picture of the future: one founder, surrounded by a tireless workforce of agents. That model can produce prototypes at remarkable speed. It may even operate a small product with clear boundaries. It is less convincing as a plan for the long life of a complex system, because the hardest problems in such systems are rarely questions of code generation.

Complex systems need the friction of different responsibilities. Architects think about long-term evolution. Developers see implementation and readability. Testers search for failure paths. Operators watch runtime behavior. Product people ask whether the work creates value. Security specialists imagine the paths ordinary use never takes.

AI can simulate each role and list the questions it might ask. What it struggles to reproduce is the judgment created by real consequences. The person responsible for production stability treats a harmless-looking dependency update differently. Someone who has lived through a financial reconciliation failure asks about idempotency before being prompted. Someone who has served the same customers for years knows which innocent sentence in the requirements is actually non-negotiable. That knowledge comes from experience under responsibility, not from information alone.

The aim of a strong AI team, then, is not to drive the human count toward zero. It is to move human time away from mechanical implementation and toward work that carries more value: framing problems, designing boundaries, testing reality, handling exceptions, building knowledge, repairing systems, and making tradeoffs that can be explained.

Part IV · Designing an environment for people and agents

09The manager’s new job: redesign the work environment

In the view of Peopleware, management is not primarily the art of keeping people busy. It is the work of creating an environment in which people can get something done. That idea survives intact in the AI era, but the environment has become larger.

It now includes more than quiet rooms, sensible meetings, and stable teams. It includes which resources an agent may access; which actions require human approval; which results must pass automated checks; how much of the system one task may change; how context is preserved and handed over; how concurrent workflows avoid overwriting each other; how work stops, rolls back, and recovers after failure; and who owns the final result.

None of this can be solved by adding one clever sentence to a prompt. If an organization buys AI tools for everyone but leaves the development system untouched, AI becomes an accelerator bolted onto the old machinery. It produces code faster. It does not make the requirements clearer, the decisions wiser, the tests stronger, or the releases safer.

The real change is to treat software delivery as an operating system shared by people and agents. Machines search, generate, repeat, and perform preliminary checks. People define goals, resolve ambiguity, make tradeoffs, recognize risk, and accept responsibility. The interface between those roles has to be explicit. So does the pace.

10Treat human attention as capacity, not as a free resource

The most common design error in an AI workflow is to count model throughput without counting human absorption. A patch may cost almost nothing to generate. Turning it into a trustworthy change still requires review time, domain knowledge, test evidence, and a release window. If any one of those is scarce, candidates wait in line.

Even a team with unlimited agents cannot deliver faster than its weakest control loop. Too much work in progress also damages the very capacity needed to clear it. Unfinished reviews, unanswered questions, parallel branches, and unresolved options occupy working memory and make every context switch more expensive.

Limiting concurrency is not a retreat from modern tooling. It is an engineering measure that protects cognitive integrity. A team can start with a few unglamorous practices:

• Set a limit on active agent workflows per engineer instead of rewarding unlimited concurrency.
• Filter low-confidence, duplicate, and out-of-scope results automatically before asking for human attention.
• Require every agent to deliver a change summary, key assumptions, verification evidence, and known gaps.
• Reserve uninterrupted, notification-free time for understanding and reviewing complex work.
• Measure the path from start to safe production, not merely the time the model spent generating.

Productivity research supports this broader view. SPACE rejects the single metric; DORA emphasizes the way platforms, process, architecture, and value streams shape the outcome of AI adoption.^[4][6] The manager’s real optimization target is not “model calls per engineer.” It is whether the team can deliver the right value with less cognitive strain and more dependable quality.

11Six Peopleware rules for AI teams

Bringing Peopleware into an agent workflow does not require a grand new management doctrine. A better place to start is to turn respect for human work into concrete system constraints.

12The better AI gets, the more Peopleware matters

The Mythical Man-Month taught us that adding people does not accelerate a software project linearly because communication and coordination grow with the team. Peopleware went further: even without adding people, even with better tools, productivity collapses when an organization ignores cognition, emotion, relationships, and the conditions of work.

AI has not overturned either book. It has given their old problems new forms.

We once worried about adding programmers to a late project. Now we should worry about adding agents to a process already out of control. Managers once consumed engineers’ days with meetings, reports, and procedure. Now model output, permission requests, review queues, and parallel tasks can consume the same finite attention. Teams once lost flow to office noise. Now they can lose it to AI workflows that never stop asking for the next decision.

The more capable the tool becomes, the easier it is to see the person as the slow, expensive component that should be compressed. Yet this is exactly when judgment, trust, responsibility, and imagination become most valuable. AI can generate code, but it cannot decide on behalf of an organization what deserves to exist. It can offer options, but it cannot carry the consequences of choosing one. It can imitate the language of collaboration, but it cannot automatically create trust.

After rereading Peopleware, my conclusion is not the comforting slogan that people will never be replaced. It is something less reassuring and more useful:

AI will not make a software organization better by itself. It will make the organization more like itself.

An organization that trusts people, protects focus, and cares about quality can use AI to extend its abilities dramatically. One that worships metrics, exhausts teams, and chases short-term output will use the same technology to accumulate technical debt, cognitive debt, and organizational debt at greater speed. DORA’s description of AI as an amplifier gives that observation a timely empirical echo.^[5]

The software teams that lead the next era may not run the most agents or have permanent access to the strongest model. They may simply be the first to understand that when code is no longer scarce, people are what must be protected.

Abstract

Generative AI has pushed the marginal cost of producing code to a level few software teams would have believed possible only a few years ago. That has encouraged a seductive conclusion: if code can be produced almost on demand, the old laws of software engineering must be on their way out.

This essay argues the opposite. What endures in The Mythical Man-Month is not Brooks’s view of a particular language or tool. It is his account of complexity, communication, organizational structure, and conceptual integrity. AI changes the division of labor and the speed of feedback. It does not decide what a product ought to be, which constraints matter, or who remains answerable when a system fails.

The chapters that follow revisit Brooks’s central arguments and carry them forward into coding agents, multi-agent coordination, context engineering, architecture constraints, evaluation, and organizational knowledge. The point is neither that AI is merely another tool nor that it makes software engineering obsolete. The control plane of software development is moving upward—from code toward knowledge, boundaries, and systems of verification.

AI has not retired The Mythical Man-Month. It has enlarged the question: from organizing programmers to produce code, to organizing people and agents to keep complexity under control.

Part I · Returning to Brooks's problem

01Why reread The Mythical Man-Month now?

When The Mythical Man-Month first appeared in 1975, software was typed into terminals by hand, build cycles were expensive, and large systems were the province of a small number of institutions. Half a century later, we can ask a model—in ordinary language—to write an endpoint, expand a test suite, migrate a framework, or dispatch several agents into isolated workspaces. It looks like a different profession. Yet we have arrived at a version of Brooks’s old tar pit: output rises, but the system does not necessarily become easier to understand; more participants join the work, but the project does not necessarily finish sooner. ^[1]

The book survives because it is less concerned with tools than with ratios. How much of the work can be parallelized, and how much still depends on sequential decisions? How much local speed becomes end-to-end throughput? How much new capability can a system absorb before its cognitive burden outruns the team that owns it? Tools change those ratios. They do not make them disappear.

AI makes visible output unusually easy to count: lines changed, pull requests opened, prototypes produced, tickets closed. The less visible liabilities accumulate elsewhere—unstated assumptions, permissions no one modeled, migration paths no one rehearsed, on-call load, hidden coupling, and the mental model a future maintainer will have to reconstruct. Brooks’s enduring contribution is to pull our attention away from the pile of output and back toward the shape of the system.

A useful rereading therefore starts with three questions. Which costs has AI actually removed, and which has it merely pushed downstream? What happens to coordination when the set of contributors includes agents whose context is assembled afresh for each run? And what kind of knowledge and governance turns faster generation into software that can remain healthy for years?

02What a $5 billion bet taught us about software

Brooks did not arrive at his conclusions from a quiet study. In 1964 IBM introduced System/360, a compatible family of computers intended to replace several incompatible product lines. IBM remembers the program as a $5 billion, bet-the-company gamble; Fred Brooks was one of its project leaders. Its defining commercial promise was portability within the family: customers could grow their hardware without rewriting all their software. ^[3]

A unified hardware architecture created a platform, but it also concentrated unprecedented complexity in OS/360. Compatibility requirements, machine configurations, delivery schedules, organizational growth, and communication paths became one engineering problem. Under that pressure Brooks saw the flaw in treating software as divisible labor. Some tasks have an irreducible order. Newcomers must learn the system. Interfaces have to be negotiated. Existing team members stop producing while they explain, align, and integrate.

The modern parallel is not that an AI agent resembles a 1960s programmer. It is that we are living through another change in the production platform. Software organizations once treated the number of people available to write code as a scarce resource. Code supply is now expanding, so scarcity moves elsewhere: precise problem framing, domain judgment, architectural context, credible verification, and accountability for production outcomes. The production function has changed. Any organization that continues to manage the old scarcity will accumulate a large inventory of work that appears finished but has not truly been absorbed.

03What did fifty years of software engineering actually change?

Read as a list of technologies, the last fifty years look like a sequence of revolutions. Read as an engineering history, they form a surprisingly continuous line. Structured programming constrained arbitrary control flow. Object orientation tried to gather data and behavior into comprehensible units. Agile shortened the distance between a requirement and the feedback that could disprove it. Cloud computing made infrastructure programmable. DevOps brought build, test, release, and operations into one feedback system; platform engineering turned that system into an internal product. AI coding and Agent Engineering extend the same movement by making candidate implementation—and parts of the toolchain itself—delegable.

1968

The “software crisis” entered public debate, and software engineering began to take shape as a discipline.

1975

The Mythical Man-Month distilled the scheduling, organizational, and design lessons of large software programs. ^[1]

1987

Brooks published “No Silver Bullet,” separating essential complexity from accidental difficulty. ^[2]

1990s

Object orientation, design patterns, and open-source collaboration widened the boundary of reuse.

2001

The Agile Manifesto emphasized working software, human interaction, customer collaboration, and responsiveness to change. ^[10]

2010s

Cloud, continuous delivery, SRE, and DevOps pulled feedback and operations into everyday development.

2021

Natural-language code completion reached a mass audience; developers began working alongside models.

2024

Tool use and protocols such as MCP made it easier to connect models to repositories, data, and external systems. ^[28]

2025–26

Coding agents moved beyond completion to reading repositories, editing files, running tests, preparing changes for review, and working in parallel agent workbenches. ^{[24] [25]}

AI is not an alien break in this history; it is the next rise in the level of abstraction. Every such rise removes some manual work and creates a new control surface. High-level languages needed compilers and type systems. Cloud needed infrastructure as code and observability. Continuous delivery needed automated gates. Agents need context, tool permissions, run traces, evaluations, and human approval.

Part II · Eight classic arguments, read for the AI era

04AI changes the speed of coding, not the existence of essential complexity

In “No Silver Bullet,” Brooks separates two sources of difficulty. Essential complexity belongs to the problem itself: the relationships the software must faithfully express. Accidental complexity is imposed by our tools, representations, and implementation process. The distinction is often flattened into a slogan—“AI can only remove accidental complexity”—but the reality is more interesting.

AI plainly reduces a great deal of implementation friction. Boilerplate, data conversion, familiar endpoints, test scaffolding, query construction, first-draft documentation, and translation across languages can all be produced faster. It can also help people explore the essential problem by summarizing interviews, proposing counterexamples, comparing designs, tracing dependencies, and explaining an unfamiliar domain. AI is not merely a faster typist. Used well, it expands the surface area of thought.

Assistance is not abolition. A bank still has to decide what evidence justifies declining a transaction. A medical system still needs a defensible definition of acceptable risk. A collaboration product still has to reconcile permission inheritance, retention policy, and legal obligations. A model can offer candidate answers. It cannot make the trade-offs vanish, and it cannot grant itself the authority to bear the consequences.

There is a second-order effect as well. When accidental costs fall, systems tend to grow. If another service, setting, workflow, or abstraction can be added almost for free, “one more” becomes the default answer. The local implementation gets easier while the whole system becomes harder to hold in mind. This is complexity rebound: coding cost saved at one point in the value stream is consumed by more features, dependencies, states, and operational obligations elsewhere.

“There is no single development … which by itself promises even one order-of-magnitude improvement.”

Frederick P. Brooks Jr., “No Silver Bullet,” 1987 ^[2]

Brooks was not arguing against progress. He was arguing against the promise that one breakthrough would transform the entire economics of building software. AI may deliver order-of-magnitude gains on particular tasks. Once the unit of analysis expands from “produce a function” to “operate the right system safely for a decade,” the claim has to be tested again.

05Brooks’s Law: more agents can make a bad architecture fail faster

“Adding manpower to a late software project makes it later.”

The Mythical Man-Month, Chapter 2 ^[1]

The law bites when three conditions hold: the work cannot be divided cleanly, newcomers need context, and the outputs must eventually be integrated. Human teams meet all three conditions. Agent systems do too. Ten agents do not create ten times the throughput if they read different versions of the requirement, edit the same surface, invent incompatible interfaces, and leave a human to settle the semantic conflicts at the end.

An agent appears to have almost no onboarding cost. Give it a repository, instructions, and tools, and it can begin. But its context is not durable understanding; it is a selection of information assembled, compressed, and reconstructed for a particular run. More parallel tasks mean more context slices, branches, build slots, and candidate changes demanding judgment. Where boundaries are vague, agents scale the vagueness with impressive efficiency.

A contemporary form of Brooks’s Law might read: adding agents to a project that has lost its conceptual boundaries usually produces more locally plausible work that cannot be safely combined. The remedy is not to reject parallelism. It is to improve divisibility first: define ownership, stabilize interfaces, write acceptance conditions, restrict write scopes, make every change independently testable—and only then choose the level of concurrency.

06The Surgical Team: are agents its digital counterpart?

Brooks borrowed Harlan Mills’s idea of a “surgical team”: one chief programmer preserves the intellectual unity of the design and implementation, while specialists support that person much as anesthetists, nurses, and technicians support a surgeon. The point was not to celebrate the lone hero. It was to avoid dividing one central design evenly among many people and hoping that coherence would somehow emerge.

Coding agents give the idea a new and quite practical form. A technical lead can ask one agent to search the project history, another to write a migration, a third to extend the tests, and others to inspect security risks or update documentation. The lead keeps authority over the problem statement, the choice of design, and the final merge. OpenAI’s 2025 introduction of Codex described an engineering agent that could work on software tasks in parallel, inside isolated cloud environments, run tests, and return changes for review. By 2026, the product surface had shifted further toward supervising several long-running agents at once. ^{[24] [25]}

This digital surgical team works only when the surgeon actually understands the system. If the lead merely distributes vague requests and nobody maintains the whole model, the arrangement becomes ten scalpels cutting at once. AI cannot supply an absent design authority. It can only amplify the authority, rules, and blind spots already present.

Nor should a modern version reproduce every weakness of a single-expert hierarchy. Conceptual authority may be concentrated, but evidence and dissent should be distributed. A security agent should be able to challenge the favored design; a test agent should look for counterexamples; a domain expert should be able to reject a false premise; important decisions should still face team review. The strongest structure is not “one person is always right,” but “one design thread remains legible while disagreement is deliberately organized.”

07Conceptual integrity is becoming a scarce advantage

Brooks considered conceptual integrity the most important quality in system design. Users do not experience the organization chart behind a product. They experience whether the product follows a predictable set of ideas: whether the same word means the same thing, similar actions behave alike, errors are expressed consistently, and permissions and data lifecycles obey a recognizable logic.

Conceptual integrity is not the same as stylistic consistency. A formatter can standardize indentation, but it cannot decide whether “customer” and “account” belong to the same domain boundary. A framework can standardize controller code, but it cannot decide whether inventory should be reserved at order time, payment time, or shipment. The integrity that matters lives in meaning and trade-offs.

AI magnifies the difference. In a repository with precise names, stable boundaries, and tests that express business invariants, an agent can infer a sound pattern from many consistent examples. In a ten-year-old codebase containing five competing architectures, it has no reliable way to know which one represents the future. A model tends to choose the most locally plausible answer, and a historical accident quietly becomes the next convention.

This is why domain-driven design, architecture decision records, the C4 model, and evolutionary architecture have fresh importance in the AI era. ^{[12] [16] [17] [18]} Each, in a different way, makes the reason behind a design searchable, reviewable, and traceable. Their purpose is not to feed a model more prose. It is to give people and models a small, stable set of concepts they can share.

08The documentary hypothesis: the central repository will be a knowledge repository

In his “documentary hypothesis,” Brooks argued that a project needs a small set of pivotal documents to express its objectives, constraints, organization, budget, schedule, and interfaces. The lesson was never that more documentation is always better. It was that a few authoritative objects are needed to preserve a shared reality. In the AI era, that principle is more dependable than “the code is the documentation.”

When most code was written by people, an experienced developer could sometimes recover intent from names, commit history, and implementation detail. When agents generate substantial amounts of code quickly, the code looks more like the sediment left by decisions; it may contain very little of their rationale. An implementation passing today’s tests does not tell its next owner which behaviors are contractual promises, which are temporary choices, or which changes require a data migration or a customer notice.

A useful knowledge repository needs at least six kinds of material: business vocabulary and important scenarios; a system map and ownership boundaries; architectural principles and ADRs; interface and data contracts; build, test, and release instructions; and the lessons of incidents, rollbacks, and security boundaries. Prompts, skills, project rules, retrieval indexes, and agent memory can form an access layer. They are not substitutes for the underlying facts.

Documentation also needs a lifecycle. Material without an owner or a version—material that cannot be tested and expires separately from the code—gives an agent confidently wrong context. The healthier pattern is straightforward: one authoritative source for each fact; decisions linked to changes; contracts checked by machines wherever possible; examples drawn from real tests; and a way to detect and remove stale material.

09Why Babel failed: shared language is still infrastructure

The Mythical Man-Month uses Babel to discuss a failure of communication. Projects fail not only because the technology is hard, but because their participants cease to share a language and a picture of the system. As a group grows, its potential communication paths rise roughly with the square of its size. Hierarchies, modules, and interfaces exist in part to prevent every participant from having to communicate with every other one.

Agents do not tire of meetings, but they bring their own version of Babel. One reads the product specification, another reads the code, and a third receives only the task description. Each may carry a different definition of “done.” A larger context window does not settle conflicts between sources, determine which one is current, or establish which one has authority. Memory can make matters worse by carrying an obsolete judgment cleanly and consistently into a new task.

Open protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A) aim, respectively, to standardize how models connect to tools and data and how agents interoperate. ^{[28] [29]} This work matters, but a protocol answers whether information can be exchanged, not whether its meaning is agreed. HTTP allowed services to communicate; it did not eliminate contract failures in distributed systems. Agents being able to call one another does not give them a shared understanding.

Context engineering is therefore an information-architecture problem before it is a prompt-size problem. A system needs priorities among sources, timestamps, scope, versions, and a way to resolve conflict. A handoff should contain the decision summary, open questions, evidence, and validation status—not merely the full chat transcript. Shared language has to be designed.

10The second-system effect when features become nearly free

Brooks observed that designers of a second system are tempted to include every idea they restrained themselves from putting into the first. The result is often bloated and over-engineered. AI makes that temptation stronger. Features once rejected because they were expensive can now appear as prototypes in hours. An abstraction that once demanded careful debate can be produced by asking a model to “make it more general.”

The cost of generating a feature and the cost of owning it are not the same number. Every new capability widens the test matrix, permission surface, documentation, monitoring, compatibility promise, and set of choices presented to users. Agents are good at completing a visible happy path. Most long-term cost lies in the failure paths: how old data migrates, how partial success is compensated, what happens when a dependency times out, and how an audit explains an automated decision.

The danger in vibe coding is not the use of natural language. It is the confusion of “it runs” with “we can responsibly own it.” Prototypes should move fast. Once a system carries real money, data, or organizational process, it owes a productionization tax: threat modeling, observability, capacity planning, recovery, data governance, and service objectives. AI can help pay that tax. It cannot declare the bill nonexistent.

Resisting the second-system effect means valuing deletion as highly as addition. Give the product a feature budget. Ask what concept each new concept replaces. Put limits on dependencies and configuration. Judge value by product outcomes, not generation speed. Mature AI engineering is not the ability to make anything; it is the judgment not to generate what should not exist.

11Plan to throw one away: from grand rewrites to replaceable experiments

“Plan to throw one away” is often repeated as a romantic case for the rewrite. Its real warning is that a first design, made before the problem is understood, will usually be a learning instrument. AI does make exploratory implementation cheaper. A team can compare data models, API shapes, or migration strategies quickly, using working code rather than slides to expose what it does not yet know.

Brooks reconsidered the maxim in the anniversary edition. He came to favor incremental growth: a system should develop through continuing feedback, not by completing one disposable whole and then replacing it wholesale. That revision matters even more now. AI lowers the cost of regenerating an implementation; it does not lower the cost of replacing a production system by the same amount. Production contains data, customer habits, external integrations, audit history, and hard-won operating knowledge. None can be recreated with a prompt.

The modern rule should be: make experiments disposable and assets migratable. Isolate uncertainty in a spike, sandbox, or shadow implementation. State the learning goal before the work enters the main branch. Protect external behavior with contract tests, make database migrations reversible, and replace old capability a piece at a time. When a prototype accidentally becomes production, require an explicit ownership and production-readiness review; having run once is not an inheritance mechanism.

AI also makes it practical to generate several candidates for the same requirement and choose among them with evaluations and benchmarks. Throwing one away then becomes the ordinary cost of search, not a failure. The evaluation criteria must come first, however. Otherwise, the team is simply choosing the most attractive of several answers it cannot explain.

12No silver bullet: why the myth keeps returning

Every generation of software technology spends a little time cast as the silver bullet: fourth-generation languages, objects, components, low-code systems, microservices, cloud-native platforms, and now large language models. All created genuine value. All met a new form of complexity when their field of application widened. The myth returns because a local gain in production is so easily projected onto the delivery of the whole system.

AI is unusual in that it touches many stages at once—requirements, design exploration, implementation, testing, operations, and knowledge retrieval. Its reach may prove broader than that of any previous single tool. Breadth is still not freedom from constraints. As long as software models a changing world, it must deal with incomplete requirements, conflicting aims, organizational power, and an unknowable future.

“No silver bullet” must not become an excuse for conservatism. Brooks did not claim that tools were useless. He argued that no single technology promised an order-of-magnitude improvement in software productivity, reliability, and simplicity within a decade. ^[2] An engineer can hold two ideas at once: use AI aggressively to remove repetitive work, and refuse to treat demo speed as lifecycle evidence.

Durable improvement usually comes from a combination: smaller system boundaries, clearer domain models, shorter feedback loops, better tools, more automated verification, safer releases, and healthier organizational design. AI can strengthen that combination. It cannot stand in for it.

Part III · From AI Coding to Agent Engineering

13From code assets to knowledge assets

Software organizations have long treated source code as their central asset, and with good reason: code is the final authority executed by the machine. As AI generation becomes ordinary, however, the economics begin to change. More implementations can be reproduced from specifications, contracts, and examples. Some code starts to resemble a compiled artifact or a cache—still important and carefully controlled, but no longer a complete account of the organization’s rarest knowledge.

That idea should not be stretched into another grand claim. Production code is not a temporary file that can be deleted on a whim. It contains verified edge cases, performance work, compliance evidence, and repairs made after incidents. If the knowledge that produced it is incomplete, the code itself may be the only surviving truth. “Code as cache” is a directional observation: stronger specifications and verification make more implementation detail reproducible. It is not a description of where most systems are today.

The assets that grow in value are those behind generation and judgment: domain models, constraints, policy, decision records, evaluation suites, failure cases, operational experience, tool capabilities, and permission models. They determine what an agent can produce and what must never enter production. TOGAF’s Architecture Repository, DDD’s domain knowledge, and SRE runbooks begin to look like parts of the same control plane. ^{[12] [14] [20]}

Knowledge assets differ from code assets in a fundamental way: storage alone does not make them valuable. Knowledge needs provenance, an owner, an applicability boundary, a refresh cycle, and a process for resolving conflict. A vector database can retrieve a passage; it cannot decide whether that passage still represents an organizational decision. Knowledge Engineering is less about retrieval scores than about governing what counts as fact.

14Agent Engineering: beyond the prompt, toward an operating system

Prompt Engineering asks how a single input can elicit a better output. Context Engineering asks which information a model should receive, and when. Loop Engineering deals with how a model uses tools, observes results, corrects itself, and stops. Agent Engineering places that model inside an operable, observable, governable system. Knowledge Engineering, finally, manages the production and lifecycle of the facts on which the whole system depends.

These are not competing phases. They contain one another. A good prompt cannot repair bad data. Good context cannot make an unbounded permission safe. A sound loop cannot rescue the wrong goal, and a well-designed agent cannot compensate for the absence of an authoritative source of organizational knowledge. As the engineering matures, attention shifts from “What did the model say?” to “Under what conditions may this system act, and how can its result be proved?”

OpenAI’s practical guide treats models, tools, and instructions as foundational, distinguishes single-agent from multi-agent orchestration, and emphasizes guardrails. The Agents SDK brings tool use, handoffs, sessions, human intervention, and tracing into the runtime; traces can capture generations, tool calls, handoffs, and guardrail events. ^{[26] [27]} Anthropic’s account of effective agents offers a complementary lesson: begin with simple, composable patterns and add autonomy only when the value of the task justifies the added complexity. ^[30]

The family resemblance to Brooks is strong. A few clear components beat an ornate framework. Organization and interfaces matter more than headcount. The system needs a control thread a person can still follow. Agent Engineering is not the art of connecting more models. It is the design of an execution organization that can delegate safely, detect drift, retain evidence, and stop when it should.

15Multiple agents are an organizational design, not free parallelism

Treating agents like cloud instances is one of the most misleading analogies in this field. Computation scales out cleanly when it has no shared state. Software work commonly revolves around shared concepts and shared files. Multiple agents help when the work is genuinely divisible: independent modules, distinct evidence sources, non-overlapping verification roles, or candidate results that can be recombined through explicit contracts.

As coupling rises, four taxes appear. There is a decomposition tax: someone must cut the problem into units that can actually be completed independently. There is a context tax: each agent needs enough information, without contradictions. There is a coordination tax: dependencies, order, and changes have to be scheduled. And there is a verification tax: the local results must eventually be shown to fit together at the system level.

Multi-agent designs tend to use one of two basic shapes. In a manager pattern, a central agent retains control and invokes specialist agents as tools. In a handoff pattern, control passes to a new specialist. The first keeps the main thread coherent; the second allows greater specialist autonomy in a long workflow. Neither is universally better. The choice depends on who must retain the final context, whether mistakes are reversible, and whether a transfer of control should involve the user. ^{[26] [27]}

The most useful rule still comes from queueing theory and continuous delivery: limit work in progress, keep batches small, and integrate early. Starting twenty tasks at once and settling the conflicts at the end is rarely as effective as maintaining a few high-value parallel streams, each continually passing build, test, and contract gates. The faster the agents work, the more important WIP limits become; otherwise, verification is simply the new late project.

16Architecture must become executable governance

Architecture documents have traditionally been written for people to read. With agents in the development path, architectural principles also have to operate at execution time. “Keep modules loosely coupled” is too vague on its own. A useful rule says which modules may depend on which, which service alone may write a particular class of data, which APIs require idempotency keys, which directories an agent must not edit, and which changes need approval from a security owner.

Architecture now needs two representations. One expresses intent for people: principles, models, trade-offs, and the reasons for exceptions. The other expresses constraints for machines: types, schemas, static-analysis rules, policy as code, tests, CI gates, permission manifests, and deployment checks. Intent without enforcement becomes a wish. Enforcement without intent becomes a prohibition nobody can explain.

An Architecture Guardian should not merely be another agent that leaves comments. It should be a layered control system. Low-risk rules run automatically. Medium-risk deviations require an explanation. High-risk actions require human approval. Every exception carries an owner and an expiry date. Tools follow least privilege; reading and writing are separated; an agent stops before an irreversible production action by default; important runs remain auditable; sensitive context has an explicit boundary.

Testing also expands into evaluation. Deterministic code can be checked with input-output assertions. A system containing models must also be evaluated for task success, tool choice, factuality, safety, cost, latency, and regression. Its evaluation suite should grow from real failures and critical business scenarios. Otherwise a model upgrade can improve the headline score while quietly changing the behavior at the edge of the business.

17Rethinking productivity: more code is not faster value

The worst managerial response to AI is to prove the return on investment with lines of code, commit counts, or tasks completed by agents. The SPACE framework already warns that developer productivity spans satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. No single measure can stand in for all five. ^[21] As generation gets cheaper, the distance between visible activity and delivered value only widens.

Empirical results also argue for restraint. In 2025, METR ran a randomized controlled trial with 16 developers working on 246 real tasks in mature open-source projects they knew well. Under the study’s particular population and early-2025 tools, the group allowed to use AI took about 19 percent longer on average. The researchers explicitly framed the result as a snapshot of a population, a toolset, and a moment—not a conclusion that AI will always reduce productivity. ^[32] Its most useful lesson is simpler: feeling faster is not a measurement.

The 2025 DORA report approaches the other side of the question. It describes successful AI adoption as a systems problem rather than a tool problem, and emphasizes value-stream management as the means by which local gains become product performance. ^[31] That is a Brooks-shaped argument. Individual speed is not project throughput; project throughput is not a business outcome. Architecture, platforms, process, and culture mediate the effect of the tool.

A credible scorecard watches four levels at once. At the task level: completion time, rework, and evaluation pass rate. At the engineering-system level: change lead time, deployment frequency, failure rate, and recovery time. At the team level: cognitive load, review queues, and the spread of knowledge. At the business level: user outcomes, risk, and total cost. The analysis should also separate greenfield work from legacy systems, familiar repositories from unfamiliar ones, and short tasks from long ones. An average is not a universal law.

18The human role moves toward intent, boundaries, and responsibility

“AI amplifies architects, not programmers” is memorable and incomplete. Good programmers have never been mere typists. At the level of code, they discover contradictions in requirements, performance limits, and failure modes. The change is not that programmers disappear while architects prevail. It is that every software role has to move toward judgments with greater leverage.

The engineer’s growing responsibilities include turning vague problems into testable hypotheses; finding domain boundaries and invariants; designing tasks that can be delegated safely; creating evaluations that expose mistakes; understanding the consequences for security, data, and operations; and maintaining a habit of disproof when a model offers a fluent answer. Reading and reviewing may matter more than personally entering every line.

Architects cannot retreat into the writing of rules either. Architecture is a set of decisions continually tested by code, measurements, and incidents. It belongs in the value stream. The architect needs to see where agents misread the system, which rules are routinely bypassed, and which boundaries create needless coordination—and then simplify the system in response. Governing AI behavior and governing software boundaries are becoming the same work.

Responsibility, above all, cannot be outsourced. An agent may propose a migration; the person approving the outage window still needs to understand the risk. An agent may generate an access policy; the person signing the compliance statement still needs to know who can reach the data. “The model recommended it” must not become an organizational passive voice. Every irreversible decision should have an answer to four questions: Who authorized it? On what evidence? How will it be monitored? How can it be undone?

Part IV · An engineering path for organizations

19From individual acceleration to organizational capability

The most common mistake in adopting coding agents is to buy seats first and wait for productivity to appear. Individuals can gain locally without much governance. Scaling the gain across an organization requires absorptive capacity. The sequence below is not a maturity certification. It is a practical order of operations intended to keep learning ahead of risk.

Phase one: choose bounded, verifiable work

Begin with tasks such as adding tests, synchronizing documentation, upgrading dependencies, fixing static-analysis findings, and building internal scaffolding. Each task class needs clear acceptance conditions, a dependable build, and a rollback path. Record baseline time and rework, not merely satisfaction. High-risk production actions, critical permissions, and irreversible data migrations should not yet be autonomous.

Phase two: repair the knowledge entrance and feedback loop

Give each repository a one-page system map: how to build, test, and run it; its major modules and owners; and its critical constraints and prohibitions. Remove stale documentation, add high-value tests, and shorten CI. Agents do not offer a shortcut around engineering health. Brittle tests and slow feedback directly limit how many useful loops an agent can complete.

Phase three: make architectural rules machine-checkable

Choose three to five of the most expensive kinds of drift—cross-layer dependencies, unauthorized data access, incompatible APIs, missing migrations, or leakage of sensitive information, for example—and turn them into static rules, contract tests, or policy gates. Keep the rule set small enough to trust, and give exceptions a formal route.

Phase four: delegate by risk tier

Classify work by reversibility, data sensitivity, blast radius, and user impact. Low-risk changes may be generated and verified automatically. Medium-risk work gets a named reviewer. For high-risk work, the agent researches and proposes but does not act. Every tier preserves provenance and traces. Permissions are granted for the task, not left open indefinitely.

Phase five: add multiple agents and long-running work later

Introduce specialist agents through a manager or handoff only after the failure modes of the single-agent workflow are understood. Give every handoff a structured packet: objective, current state, evidence, change scope, unresolved risks, and next step. Limit work in progress, and give long-running tasks budgets, checkpoints, and stop conditions.

Phase six: turn incidents and evaluations into knowledge

Convert misgenerations, missed defects, bad tool calls, and human takeovers into evaluation cases or clearer constraints. Regularly delete ineffective rules and obsolete memory. A mature organization is not one that never makes a mistake. It is one in which every mistake sharpens the control plane instead of merely lengthening the prompt.

20Software engineering’s next job: governing generative systems

The next era of software engineering will not be one in which nobody writes code. It will be one in which more systems contain deterministic software, probabilistic models, and agents able to take action. Their boundaries will be more dynamic than those of conventional applications: the same objective may produce different paths; tools and data change in real time; persistent memory carries the past into the present. Engineering expands from managing static artifacts to managing generative behavior.

The first change is that specifications become first-class assets again. This is not a return to enormous waterfall documents. It means maintaining evolvable, testable intent: scenarios, contracts, invariants, policies, and evaluations. Specifications and implementations will exchange feedback more rapidly and may even generate parts of one another, but people retain judgment over meaning.

The second is that the software supply chain becomes a knowledge supply chain. Organizations will track not only the origin of dependency packages, but also the models, instructions, tools, knowledge sources, and evaluation versions used by an agent. A defect may enter through an expired retrieval result, contaminated memory, or a changed permission—not through a code commit.

The third is that architecture extends from structural design to behavioral governance. Yesterday’s diagrams mainly explained how components connect. Tomorrow’s must also say who may act for whom, which decisions require approval, how a system presents evidence, and when autonomy must stop. Security, compliance, SRE, product, and architecture will meet earlier in the work.

The fourth is that source code is no longer the only human-machine boundary. Natural language, schemas, policies, skills, evaluation sets, and operational traces all define system behavior. Teams will need to version, test, review, release, and roll back these objects as they do code. Prompt review, skill review, and memory review are not replacements for code review; they are new surfaces of review.

The fifth is that advantage comes from the feedback system, not from one model. Foundation models will change and tools will converge. What remains difficult to copy is the organization’s way of encoding domain knowledge as boundaries, turning real failures into evaluations, turning operational evidence into improvements, and letting agents accelerate within those constraints. The stronger the loop, the more AI behaves like leverage. The weaker the loop, the more it behaves like an amplifier of complexity.

Conclusion: Brooks was not wrong; the object of management has changed

In 1975, the visible problem was how to organize programmers to deliver software systems of unprecedented size. In 2026, the problem has widened: how to organize people, models, tools, knowledge, and automation as they evolve a system together. We used to review commits; now we must also review an agent’s context and trail of action. We used to manage communication among developers; now we must manage handoffs among agents. Architectural constraints once lived mainly in human memory; now they must be understandable to people and executable by machines.

Some things have not changed. Software is still a model of a real problem, and every model contains choices. Complex systems still need conceptual integrity. Communication still consumes time. More participants still create coordination. Rapid production still does not replace sound judgment. Responsibility still belongs to people and institutions.

What has changed is the location of scarcity. Code is no longer the rarest input; knowledge and verification become the bottlenecks. Prototypes and candidate solutions are cheap, while selection and long-term ownership matter more. Agents amplify an architect’s reach—and propagate an architectural mistake at the same speed.

The deepest lesson of The Mythical Man-Month for the AI era is therefore not to distrust new tools, but to put them back inside the system. AI can help a good team verify, learn, and ship faster. It can also help an organization with unclear boundaries accumulate unexplained code at unprecedented speed. The difference has never been generation alone. It is the presence of clear intent, coherent concepts, dependable feedback, and people willing to own the consequences.

When code becomes cheap, judgment becomes expensive. When agents become ordinary, the heart of software engineering will be the reality they are required to obey.

Abstract

AI-assisted development has compressed feature work from hours to minutes, but production systems do not run under ideal conditions. Databases become unavailable, networks time out, clients repeat requests, deployments stop halfway, and operators make mistakes. That is why so many AI-generated systems share the same contradiction: they look complete as software and naive as operations.

Reliability is not an infrastructure layer to add after launch. It is a set of behaviors that must be defined with the product: how failure is detected, how far it can spread, what the service does while degraded, how data remains recoverable, and how people intervene safely. AI can implement many of these mechanisms—but only after we make failure part of the assignment.

Functional requirements say what the system should do when things go right. Reliability requirements say what the system must still protect when they do not.

Part I · Put failure back into the design

01Functionally complete, operationally naive

Over the past two years, AI-assisted development has changed the pace of software construction. APIs, data models, frontend components, and test scaffolds that once took hours can now appear in minutes. The danger is not that this code never works. It is that the code usually proves only one thing: it works along the happy path we arranged for it.

Production does not remain on that path. A database becomes briefly unavailable. A third-party API slows down during peak traffic. A client repeats an order because the first response never arrived. Half the fleet accepts a release while the other half fails to start. A harmless-looking configuration change bypasses every test written for the application code.

For an order-creation API, the questions that separate a demo from a production service are therefore different:

• If a client retries after an ambiguous timeout, can it create two orders?
• If inventory is reserved and the payment call times out, what state is the order in?
• If a dependency stays slow, can it exhaust threads, connections, or queues upstream?
• During a partial rollout, can old and new versions safely share the same data?
• How will the on-call engineer locate the failure and restore service without making it worse?

These are not advanced optimizations. They are the other half of the feature. A system that defines only success has not yet been fully specified.

02Reliability is more than a string of nines

Availability is the most familiar expression of reliability, but it is not the whole of it. A 99.9% figure describes an allowed amount of failure over a window. On its own, it does not tell us whether that failure harmed the most important customers, corrupted data, remained invisible for hours, or required the one engineer who understands the system to recover it.

A more useful view asks four connected questions:

In a simplified repairable-system model, availability is often expressed as:

Google’s SRE practice also makes a more important point: reliability is not a race to 100%. Different user journeys carry different costs of failure, so investment should follow risk and user experience rather than an abstract contest for more nines. In partially available distributed systems, request success rate can also describe user experience better than whole-site downtime alone. ^[1]

03Failure is an input, not an exception

Murphy’s Law endures in engineering because it forces us to reason about scale. An event can be unlikely per operation and still become routine when enough components run for long enough.

Disks fail. Processes crash. Certificates expire. Networks become unstable. Cloud services suffer outages. External APIs change behavior. Human operations cannot be perfect either. Reliability design does not attempt to remove these facts from the world. It decides what the system will do after they arrive.

That changes the question from “How do we prevent every failure?” to: What must keep working? What can pause? How far can an error spread? Which state can be rebuilt? Who owns the recovery decision? The Azure Well-Architected Framework similarly places business requirements, resilience, recovery, operations, and simplicity in one reliability model. It explicitly distinguishes critical paths from degradable components and asks teams to analyze blast radius instead of protecting every component equally. ^[2]

Part II · Spend reliability where it matters

04Find the promises the business cannot lose

Not every component deserves the same protection. Product recommendations can disappear temporarily while customers continue to place orders. An order submitted twice can trigger duplicate charges, inventory errors, and support work. A report may be ten minutes late; a settlement record may create financial and compliance exposure if it vanishes.

The 80/20 rule of reliability is not about finding exactly 20% of the code. It is about identifying a small set of business promises that cannot be violated:

Only then do redundancy, audit trails, reconciliation, compensating workflows, multi-zone deployment, and enhanced monitoring have a cost model. Google SRE uses different classes of data to make the same point: privacy-critical data and optional experience-enhancing data should not receive identical storage guarantees. ^[1]

05Simplicity, dependencies, and fault boundaries

AI-generated architecture can mistake “using more patterns” for “thinking more completely.” Event-driven design, CQRS, distributed workflows, layered caches, and a service mesh may all be justified. Every additional moving part also adds state, contracts, monitoring, and recovery work.

Simplicity does not mean forcing everything into one process. It means introducing complexity only for constraints that already exist, keeping the critical path short, and making failure modes enumerable and testable. Azure’s reliability guidance names simplicity as a design principle while correctly warning that oversimplification can create single points of failure. ^[2]

A dependency, meanwhile, must be treated as a fault boundary rather than merely an integration endpoint. For every database, queue, identity provider, payment gateway, or AI API, ask:

• How long will we wait before giving up?
• On failure, do we degrade, queue, serve cached data, or reject the request?
• Which layer retries, how many times, and with what backoff and jitter?
• Does repeating the operation cause side effects, and how long does an idempotency key live?
• When latency rises, what isolates connection pools, threads, queues, and upstream traffic?
• If the dependency remains unavailable, is there an alternative path or a recoverable backlog?

Stripe’s API provides a concrete example: clients attach an idempotency key to create or update operations, making it safe to retry after an ambiguous connection failure while the server returns the result of the first execution for the same key. ^[5] The lesson is not to copy a header. It is to turn “we do not know whether it succeeded” from an ad hoc exception into a state the protocol understands.

Redundancy must be equally specific. Two instances that share a power source, network path, or bad configuration are not independent protection. Useful redundancy states which failure it covers, how the primary failure is detected, how traffic or leadership moves, how data remains consistent, and how the system returns after the incident.

06Reliability is also about people

Severe incidents do not come only from code defects. Bad configuration, accidental deletion, oversized permissions, skipped deployment steps, and unsafe recovery commands can all expand a local problem into a business outage. Calling the operator careless usually avoids the better question: Why could an ordinary mistake cause extraordinary damage?

Good operational interfaces and release systems deliberately reduce the error surface:

• Clear names, typed configuration, and validation reject invalid states early.
• Safe defaults make risky operations require explicit elevation.
• Destructive changes show their real impact instead of a generic confirmation dialog.
• Releases enter production in stages with observable stop conditions.
• Rollback, recovery, and audit are routine paths rather than improvised incident work.

The goal is not to remove people from the system. It is to reserve human judgment for places that require judgment. Automation should eliminate error-prone repetition while preserving clear authority, evidence, and an undo path.

Part III · Move from architecture into operations

07Reliability is a loop, not a diagram

An architecture diagram can show redundancy and dependencies. It cannot prove that a team can detect and recover from failure. A mature reliability lifecycle needs at least the following loop:

Prevent

Identify critical paths, failure modes, and high-risk changes.

Detect

Observe user outcomes instead of waiting for customer reports.

Analyze

Establish impact, current state, and likely triggers.

Contain

Shed load, open a circuit, degrade, or stop a rollout before the fault spreads.

Recover

Roll back, fail over, replay, compensate, or restore to a known state.

Repair

Remove both the trigger and the conditions that amplified it.

Learn

Feed postmortems, drills, and verifiable action items back into the system.

Missing any link can leave reliability on paper. Without detection, recovery starts late. Without containment, a local fault expands while people investigate. Without drills, a runbook may be only an untested wish. Without action items, a postmortem preserves a story without changing the next outcome.

Google’s incident-response practice emphasizes predefined command roles, a working record of diagnosis and mitigation, and regular exercises. Its postmortem guidance asks teams to explain impact, recovery, and causes with evidence, then assign action items to clear owners with measurable end states. ^[6][7]

08Observability and recovery are product features

Teams often fund feature implementation generously and postpone logs, metrics, alerts, recovery scripts, and drills until “after launch.” The predictable result is a system that has already failed while its operators infer customer impact from fragments. Backups may run every day without ever proving that they can restore complete data within the required window.

Reliability requirements should be testable like API behavior. For every critical user journey, write down:

Answering those questions is the difference between owning an operable service and possessing a deployable program.

Part IV · Teach AI to reason about failure

09Turn a feature prompt into a production contract

Coding assistants usually seek the shortest path from a requirement to a working implementation. If the input says only “build an order processing service,” then controllers, services, persistence, validation, and unit tests are natural outputs. Timeouts, idempotency, containment, and recovery may be absent not because the model has never encountered them, but because the assignment never made them part of done.

A failure contract is more effective than a vague instruction to “consider reliability”:

Implement an order processing service. Functional correctness is only part
of acceptance.

First identify the critical business promises and external dependencies.
For every material failure mode, specify:
1. Trigger and business impact;
2. Detection signal and alert condition;
3. Timeout, load-shedding, isolation, or degradation behavior;
4. Retry owner, limit, backoff, and idempotency semantics;
5. Data consistency, compensation, and human-intervention boundary;
6. Recovery steps, RTO/RPO, and rollback path;
7. The test or drill that proves the mechanism works.

Deliver the implementation, risk register, observability, fault-injection
tests, deployment and rollback plan, and an executable recovery runbook.
List unresolved decisions explicitly instead of inventing assumptions.

The value of this prompt is not the number of reliability terms. It forces every mechanism to connect to a failure scenario, a business consequence, and evidence. Otherwise, “add a circuit breaker” becomes decorative architecture and “add monitoring” becomes a pile of signals that nobody can act on.

10AI cannot own the consequences of failure

AI can help enumerate failure modes, generate fault-injection tests, inspect configuration, draft runbooks, and—in tightly constrained systems—even execute parts of recovery. It is particularly good at expanding a team’s capacity to search for counterexamples and repeat verification.

The model does not know the true cost of a delayed settlement to this company. It cannot independently decide among privacy, money, and customer trust. It sees requirements, code, and available context; engineers face promises, organizational capability, and consequences.

Our role therefore moves beyond implementing every line by hand. We must build the control plane for reliability: define what cannot be lost, choose a risk budget, bound automation privileges, review fault boundaries, demand verification evidence, and ensure someone can restore the service at 3 a.m.

11Reliable from the beginning

The software industry has spent decades optimizing how code is written. AI has pushed that process to a new speed. The physical and organizational facts of production have not changed: servers fail, networks fail, people make mistakes, and dependencies change at inconvenient moments.

Building functionality is becoming rapidly automated. Anticipating failure, choosing the boundary of loss, and accepting responsibility for recovery are becoming more valuable as a result.

“Reliable by design” does not mean infinite redundancy in the first release, or a system that never breaks. It means the success path and the failure path are equally real from the first requirement. From the first deployment, detection, containment, recovery, and learning are treated as part of the product.

Abstract

When I joined Company A in early 2015, its transaction platform was already living with a contradiction. The system had been divided into ever smaller services, and the platform exposed more APIs and extension points than ever, yet delivering a business change had not become easier. Teams were short-handed, schedules were long, and delays were common. Every Thursday, dozens of branches converged on the fixed release window, and a change for one business could force many unrelated businesses through another round of regression testing.

The deeper problem was not merely an excess of if/else, nor an SPI mechanism that lacked flexibility. The platform could not answer a more important set of questions: Who owns a customization, and whom should it affect? How does one business scenario remain whole across many applications? How should several rules compose when they apply at once? Can business code evolve and ship without requiring a platform release? Lattice emerged as an open-source business extension framework built around those questions. It separates business code from platform code, one business from another, and logical business architecture from physical application topology. Business identity, Ability, Use Case, vertical and horizontal composition, and Reduce then turn “modify the platform everywhere” into “assemble a business within an explicit boundary.” The essay closes by showing how I turned those judgments into an architecture Skill that reviews design, module placement, and generated code during AI-assisted development.

The decisive quality of a highly customizable platform is not the number of extension points it exposes. It is whether every change has a clear owner, scope, composition rule, and delivery boundary. Lattice is less about inserting business code than about keeping each business change from spilling across the entire platform.

Part I · When the platform can no longer keep up

01In 2015, the problem I saw was not merely technical

During my first six months at Company A in 2015, I spent a great deal of time watching the transaction platform absorb new businesses. What stood out was not one poorly designed interface, but a system under persistent strain: too few people, punishing overtime, long lead times, and projects that routinely slipped. Platform and business teams worked through a co-development model, but every additional participant made coordination more expensive. Everyone was working hard, and the system contained no shortage of sophisticated mechanisms. Still, each new business became harder to deliver.

Distributed architecture was not itself a mistake. Company A’s early commerce business was relatively homogeneous, and a single system could contain product listing, cart, order creation, and fulfillment. As traffic, businesses, and teams grew, splitting that monolith into cohesive user, product, transaction, and shop systems was both necessary and successful. Each system could make local design decisions, own its requirements, and release independently. For a time, development speed and reliability improved.

Every architectural advantage, however, has a scale at which its costs become visible. As the business expanded across industries and the number of applications and services reached into the thousands, the decomposition that had reduced local complexity began producing a different kind of complexity: one coherent business intent was scattered across many applications and teams.

A single request might require several teams to analyze, design, build, integrate, and release changes in a particular order. Worse, nobody could confidently enumerate every system it touched. The main path was usually visible; edge cases and side paths accumulated over years tended to surface late. Missing one could mean reopening the design, reworking the implementation, and delaying the release again.

We had decoupled applications without reassembling business intent.

02From open APIs to business co-development

APIs were the platform’s earliest and most important way of exposing capabilities. Stable service interfaces let business systems reuse product, transaction, marketing, and other functions. APIs described stable behavior well, but they could not anticipate every difference among industries.

As those differences accumulated, Map parameters appeared. Callers could inject context the platform model had never anticipated, but a platform that did not understand those parameters could hardly understand their business meaning. Java SPI came next: the platform defined an interface, and a business team implemented it so that specialized logic could run inside the platform’s execution path. This co-development model made business teams far more productive.

Its limits gradually became just as clear. The platform did not provide a strong separation between business and platform code, so both continued to accumulate in the same repositories. A customization could not ship independently; it had to join the shared release train. I remember the fixed release window every Thursday, when forty or fifty branches had to be merged. Each branch made sense in isolation. Together they created an enormous system-wide regression effort: when Business A went live, Business B had to wonder whether its behavior had changed too.

Isolation and quality depended mainly on developers being careful rather than on a structure that could be verified. Experience and code review may be enough when the organization is small. At scale, “everyone should be more careful” is not an architecture.

03How an inventory-decrement method decays

Inventory decrement is a small but representative example. The following code is illustrative and is unrelated to any production source.

The platform initially reduced stock when an order was placed. Large appliances were expensive and scarce, however, and unpaid orders could lock inventory. That business needed stock to be reduced only after payment:

public ReduceType getInventoryReducePolicy(OrderLine orderLine) {
    if (orderLine.getProduct().hasTag(9527)) {
        return ReduceType.AFTER_PAYMENT;
    }
    return ReduceType.BEFORE_PAYMENT;
}

When digital goods arrived, some required no inventory decrement at all, so another condition appeared before the first. Large appliances later gained in-store pickup: customers received a digital collection code, yet the physical inventory still had to be decremented. “Digital goods do not decrement inventory” now intersected with “large appliances decrement inventory after payment,” and evaluation order began changing outcomes.

Eventually, large appliances were no longer uniform either. Items above a price threshold reduced stock after payment; cheaper ones still reduced it at order placement. A simple default policy had become a branching tree over product type, industry tag, delivery mode, and price.

No single bad programmer created this decay. On the contrary, every change answered a real request, and every local condition may have been the cheapest reasonable choice at the time. Years later, a method could span thousands of lines. The next developer would search cautiously for a plausible insertion point, add another branch, and hope they had not changed another business’s behavior.

This history changed how I understand legacy code. Often it suffers not from a lack of refactoring, but from a missing ownership model for business change. The code does not know which rule belongs to which business, nor whether two rules should be isolated, overridden, or combined. Execution order ends up making an organizational decision.

04SPI made the code cleaner, not the businesses independent

The natural response is to extract those branches into SPI implementations. Each implementation supplies a filter and an execute method; the platform iterates over the list and runs the first matching strategy.

public interface InventoryReducePolicySpi {
    boolean filter(ReducePolicyRequest request);
    ReduceType execute(ReducePolicyRequest request);
}

With a small number of implementations, this works well. A thousand-line method becomes several more cohesive classes, improving local readability and testability. At larger scale, however, the same difficulty reappears in another form:

• Should a new requirement modify an existing implementation or register another one?
• Where in the list can it sit without being intercepted by an earlier rule?
• Does its filter overlap with any of the dozens already present?
• Which businesses silently change when the order is adjusted?

In harder cases, a filter calls a rule engine or remote service. Reading the code is then insufficient to determine statically when an implementation will apply. I have seen complex platforms accumulate nearly a thousand SPI contracts, with dozens of implementations behind a single interface. Global traversal plus “first match wins” turns every business into a participant in one invisible decision tree.

The platform appears to have removed if/else; in reality, the conditions moved into registration order and filter logic. The coupling remains and is harder to see.

05An application view is not a business view

A subtler problem was that the platform exposed extension points by application, while business teams reasoned in scenarios.

At Company A’s scale, business capabilities had already been divided among more than 2,000 microservices. The number mattered not as a measure of prestige, but because the system landscape had grown beyond what any one person could remember, assess, or control as a whole. No individual could reconstruct the complete dependency graph from experience alone. At the start of a request, nobody could confidently say which applications it would traverse, which teams it would involve, which extension points it would change, or which entrances outside the main path might be missed.

This does not mean that one requirement modified 2,000 services, nor that microservice decomposition was itself a mistake. The problem was that after one business intent had been scattered across so many technical boundaries, impact analysis still depended on people discovering and reconnecting the pieces by hand. Analysis became repeated rounds of assembling teams, tracing paths, and confirming assumptions. Missing one system or side entrance could invalidate the result.

Suppose one business does not allow products to be bought through a shopping cart. In business language, there is one rule: “This business does not support cart purchases.” In an application view, the team may need a string of scattered customizations: hide the Add to Cart button on the product page; reject API calls that bypass the page; prevent the order service from accepting requests falsely marked as cart orders; and repeat the same check at every side entrance.

Each application may offer a perfectly reasonable extension point in isolation, but responsibility for completeness has been transferred to the delivery team. Developers must understand not only their industry, but also which small subset of more than 2,000 microservices matters to the scenario, what each service exposes, how the services interact, and whether any critical entrance has been overlooked. Finer decomposition clarifies the responsibility of each system while making end-to-end business analysis harder.

The real challenge, then, was not to invent a stronger SPI. It was to move the organizing unit of extension upward—from applications and technical processing points back to businesses and scenarios. The platform should let developers see the outcome of a complete business scenario first, then let that scenario organize the capabilities it needs. Every delivery team should not have to rediscover the application map from scratch.

Part II · Define the problem before designing the framework

06Six questions the architecture had to answer

During several design workshops, I asked the team not to begin with class diagrams or framework choices. Instead, we completed one sentence: “If the platform could …, then we could ….” This kept us anchored in actual friction rather than technical preference.

The answers were concrete. A team should be able to package the contracting and fulfillment model of a particular business, then keep that package independent of both the platform and other businesses. It should be able to select and compose existing capabilities along real business flows. Product managers and developers should be able to see both what the platform offers and what a business has adopted. No business should have to wait for a shared platform release, and the same logical architecture should work across different deployment models.

Condensed further, those wishes became six questions the framework had to answer explicitly:

These six questions determined the shape of Lattice. Its annotations, interfaces, and runtime are implementation devices. Forget the questions and Lattice can easily be reduced to yet another SPI toolkit.

07Rereading Clean Architecture: the circles are not the point

When I returned to Robert C. Martin’s Clean Architecture, its most useful lesson was not which project directory should contain Entities, Use Cases, Interface Adapters, and Frameworks. It was the direction in which change is allowed to travel.

The book’s best-known principle is the Dependency Rule: source-code dependencies point inward. The outer layers contain volatile mechanisms; the inner layers hold more stable policies closer to business purpose. Web frameworks, databases, and delivery mechanisms serve business rules, not the other way around. A use case coordinates entities toward an application goal and exchanges data with external systems through boundaries, while dependencies across those boundaries still point inward. ^[1][2]

For a large business platform, however, making a database depend on a domain interface is not enough. Business customization is itself an external source of change. The inventory policy of one industry, the purchasing limit of one promotion, or the redemption requirements of one fulfillment model should not leak back into the core shared by every business.

That led me to a more concrete reading of the Dependency Rule. Architectural “inside” and “outside” are separated not only by technical layer but also by policy scope. Shared entity rules, scenario rules, vertical-industry rules, and horizontal capability rules differ in stability and reach. They need explicit boundaries through which to collaborate, rather than a single global list in which they all compete.

Clean Architecture also emphasizes independent development and deployment, plugin boundaries, and an architecture that reveals the system’s purpose before the frameworks it uses. ^[1] Those ideas gave me better language for conclusions that practice had already forced upon us:

• Separating business from platform code controls the direction of change; it is not merely tidier code.
• Separating the logical business view from physical application topology restores coherent business intent; it is not merely a search convenience.
• Organizing extensions around use cases makes the architecture speak business language; it is not merely a directory change.
• Delivering plugins independently turns a logical boundary into a real one; it is not merely release acceleration.
• Letting the runtime execute an already determined composition makes hidden conflicts into explicit policy; it is not merely a performance optimization.

Part III · How Lattice answers the problems

08Why the name Lattice

A lattice is a grid. When we looked at a business platform, we saw two interwoven dimensions: isolated vertical businesses and horizontal capabilities that could be selected and overlaid. Their intersections looked like a lattice. There was also a less solemn reason: programmers are famously fond of plaid shirts.

That is why we named the business extension framework Lattice. It was not an attempt to give conventional SPI a new label, but to make business identity and capability composition first-class concepts. The source is available at hiforce/lattice; at this essay’s most recent update, the main branch version was 1.0.21. ^[3]

09Lattice begins with three separations

The failures described above look varied, but all three fundamental boundaries had collapsed. Business code had entered the platform core; implementations for different businesses competed in one global decision space; and physical applications had fragmented the view of an end-to-end business process. Lattice does not begin by adding more hooks. It begins by restoring those three separations.

These are not three unrelated features. The first determines where code belongs. The second determines which rule space a request may enter. The third determines what people see when they design a change. Omit any one and the others weaken: plugins without identity can still match the wrong business; identity without a code boundary still ties every business to the platform build; runtime isolation without a logical view still leaves impact analysis wandering through more than two thousand services.

10First separation: business code from platform code

The old co-development model asked the platform to define an SPI and business teams to submit implementations directly into the platform project. It worked well at first because a new business could enter the main flow quickly. At scale, however, stable platform mechanisms and local business policies accumulated in the same repository. Platform changes had to account for business implementations; business changes inherited the platform’s branching, regression, and release cycle. Each side became embedded in the other.

Lattice keeps only stable entities, use cases, abilities, extension contracts, and default behavior in the platform repository. Concrete business rules live in separately owned plugin packages and repositories. Registration and plugin loading connect the two at runtime: the platform declares what may vary, while the plugin declares how one business behaves at that point. Dependencies point toward stable platform contracts; the platform core does not depend on a particular business. ^[3]

Three boundaries can then align:

• Code boundary — Customization does not enter the platform core repository.
• Test boundary — A plugin can verify its own rules and selected capabilities.
• Release boundary — A business change is no longer inherently tied to a platform version or a regression cycle for every other business.

Plugins do not guarantee independent delivery. Shared data, contract compatibility, runtime containers, and organizational process can still couple releases. They do, however, remove the most dangerous reverse dependency from the source tree and make independent build, verification, and delivery an option the architecture genuinely supports.

11Second separation: one business from another

A conventional SPI asks, “Which implementation’s filter matches this request?” Lattice first asks, “Which business does this request belong to?”

The questions sound similar but produce very different systems. In a conventional SPI, every implementation uses a filter to guess whether it applies to the current request, so implementations owned by every business share one candidate set. Miss one constraint, cover one channel too broadly, or let two conditions overlap, and a rule written for Business A may execute for Business B. Correctness is distributed across every implementation; as businesses and combinations grow, proving that all filters remain mutually exclusive becomes unrealistic.

Lattice reverses the order: the first action at every business-scenario entry point is to establish business identity. Once identity is known, the runtime has an explicit coordinate. It loads only the plugin packages and realizations associated with that identity; code owned by other businesses never enters the candidate set. Isolation is no longer a fragile convention that every developer must preserve in every filter. It becomes part of the execution model.

@Business(code = "business.a", name = "Business A")
public class BusinessA extends BusinessTemplate {
}

@Realization(codes = "business.a")
public class BusinessAExt extends BlankOrderLinePriceExt {
    @Override
    public Long getCustomUnitPrice(OrderLine orderLine) {
        return 2000L;
    }
}

@Business declares the business; @Realization declares which business owns the implementation. The call chain carries a unified business code, and the runtime locates plugins and realizations by that identity. The annotation syntax is incidental. The important shift is from ownership inferred through conditions to ownership declared explicitly: establish who I am first, then discover which rules are mine.

The identity must survive the entire call chain. If an entry point knows the business but loses that identity when it calls a downstream service, isolation ends at the process boundary. Lattice treats the business code as a core piece of extension context, keeping one business’s rules coherent across capability calls.

The first two separations now establish code ownership and runtime scope. The third requires a vocabulary that can lift platform capabilities out of scattered interfaces and organize them into complete use cases. Ability, the two business axes, Reduce, and Use Case provide the language from which that logical business view can be built.

12Ability makes platform capabilities discoverable and callable

Business identity answers “whose rule?” An Ability answers “what can the platform do for this business object?”

In Lattice, an ability groups extensible behavior around a particular business object. An order line may be that object, pricing the ability, and “custom item unit price” one extension point. The ability loads realizations for the current business and combines their results according to explicit reduction semantics; the business implements only the behavior it needs to change.

public interface OrderLinePriceExt extends IBusinessExt {
    String EXT_ORDER_LINE_CUSTOM_UNIT_PRICE =
        "OrderLinePriceExt.EXT_ORDER_LINE_CUSTOM_UNIT_PRICE";

    @Extension(
        code = EXT_ORDER_LINE_CUSTOM_UNIT_PRICE,
        name = "Custom the Item's unit price of OrderLine",
        reduceType = ReduceType.FIRST
    )
    Long getCustomUnitPrice(OrderLine orderLine);
}

@Ability(name = "OrderLine's Price Ability")
public class OrderLinePriceAbility
        extends BaseLatticeAbility<OrderLinePriceExt> {

    public OrderLinePriceAbility(OrderLine orderLine) {
        super(orderLine);
    }

    public Long getCustomUnitPrice(OrderLine orderLine) {
        return Optional.ofNullable(reduceExecute(
                ext -> ext.getCustomUnitPrice(orderLine),
                Reducers.firstOf(Objects::nonNull)))
            .orElse(orderLine.getUnitPrice());
    }

    @Override
    public BlankOrderLinePriceExt getDefaultRealization() {
        return new BlankOrderLinePriceExt();
    }
}

This changes three things. First, platform capabilities become discoverable; developers no longer search thousands of applications for scattered SPIs. Second, the platform still supplies default behavior, so a business with no customization falls back naturally. Third, the meaning of multiple results is defined by the ability rather than by accidental registration order.

Restraint matters here. Ability is not a new word for wrapping every method. Only behavior with stable business meaning—and for which different businesses genuinely need different choices—deserves to become an ability or extension point. More interfaces do not automatically create a more flexible platform. They may simply create another surface that must be maintained.

13Before the two axes, what counts as a business?

“Business” is one of those words that can expand to mean almost anything. People often call whatever they happen to own “the business,” or equate a business with a box on the organization chart. For the model to be useful in code, I need a more operational definition: a business is a sustained set of activities, decisions, and rules that delivers a product or service and produces an economic outcome through revenue growth or lower cost.

That definition includes both sides of the ledger. Companies often organize teams as profit centers and cost centers. Profit centers focus more heavily on markets, products, operating models, and supply chains that create revenue. Cost centers focus more heavily on shared platforms, process improvement, and efficiency. Their immediate concerns differ, but both ultimately answer the same operating question: how can the company keep creating value while preserving healthy room between revenue and cost?

On a software platform, those operating changes consistently produce two kinds of rules. One kind usually belongs to a particular industry and describes how that industry prices, transacts, fulfills, and manages risk. Together, those rules form a coherent operating model. The other kind comes from an industry-agnostic play or platform capability. It changes one part of the transaction in a way that can add revenue, efficiency, or customer value across many industries. The first kind needs autonomy; the second needs reuse. One answers “which industry’s rules are these?” The other answers “which reusable plays has this industry chosen?”

That is where the vertical and horizontal axes come from. They were not invented to make an architecture diagram look tidy. They are the rule-level projection of two realities: who owns an operating outcome, and how a platform reuses capabilities across owners.

14Why business rules fall along vertical and horizontal axes

A vertical business is usually an industry. It is a business space with end-to-end operating responsibility: auto finance, on-demand delivery, or movie tickets. It owns more than a few configuration differences. It is accountable for the industry’s customers, revenue, fulfillment, risk, and final operating result. Its rules therefore need isolation. Auto finance rules for qualification, preauthorization timeout, and non-logistics fulfillment should not leak into on-demand delivery. Delivery pricing, service radius, and SLA rules should not become defaults for movie tickets.

Even when two vertical businesses happen to use the same ten-minute payment timeout today, each should declare that value in its own business space. They may reuse the payment-timeout capability and its implementation, but they should not share one business’s ten-minute decision. If one changes the value to fifteen minutes tomorrow, the other should not change without taking part in that decision. The vertical axis establishes ownership and isolation: similar code does not turn one operator’s policy into another operator’s policy.

In the Lattice model, a horizontal business is usually an industry-agnostic play or platform. We might also call it a platform business or cross-cutting capability. It does not own a complete industry operating model. Instead, it packages a reusable way of creating value and modifies a slice of the vertical baseline. The core of electronic vouchers is code issuance, redemption, and refunds; it does not matter whether the adopter sells movie tickets, attraction tickets, or car-care services. A campaign may change the purchase entry point, price, and sales-counting rules across industries. Cash on delivery changes when payment occurs, how checkout behaves, and how small cash amounts are rounded, regardless of the vertical.

A horizontal business is defined independently of any one vertical, but many verticals may choose to adopt it. Movie tickets and car-care services can both use electronic vouchers while choosing different redemption counts. One business can install vouchers and presales together, then add a campaign as well. A vertical adopts those changes because a horizontal capability can expand what is sellable, improve conversion, lower cost, or improve the customer experience. The horizontal axis provides reuse and controlled variation: it does not replace the vertical business, but supplies optional changes to its baseline.

The two kinds of business also differ in a way that matters enormously to the architecture: vertical industries are relatively enumerable and stable; horizontal plays are open-ended, effectively impossible to enumerate in advance, and change frequently. I do not mean “countable” and “uncountable” in the set-theoretic sense. This is an engineering distinction. A company can usually list the industries it operates today. Entering a new industry is an explicit, relatively infrequent strategic decision, so an industry can carry a durable business identity. There is no equivalent final list of horizontal plays. New campaign mechanics, fulfillment methods, payment options, membership benefits, and risk controls keep appearing—and keep combining with one another.

If every “industry × set of horizontal plays” became a new business type, then with |V| verticals and |H| independently selectable horizontal capabilities, the theoretical number of combinations would approach |V| × 2^|H|. Each new horizontal capability could double the combination space. Encoding those combinations as subclasses, business codes, or global SPI conditions would make the type system and the decision tree explode together.

Lattice models the problem in the opposite direction. A relatively small, stable set of vertical industries provides the coordinate system and the business identities. Each identity then selects N horizontal businesses from an open-ended set. Each request is first anchored to one vertical identity, acquiring that vertical’s defaults and ownership boundary. The runtime then resolves the horizontal capabilities and realizations selected for that identity. Adding a horizontal play is like adding a new optional column; it does not require redefining every vertical. Changing one vertical’s selection does not rewrite another vertical’s baseline. A stable identity carries an open-ended composition, which is what keeps high-frequency customization from destabilizing the platform.

Two boundaries follow. A workflow that crosses industries should coordinate several explicitly identified business contexts, not make one request belong to several vertical spaces at once. And within each vertical baseline, the platform may select zero, one, or many horizontal capabilities. N may be zero, and it may keep growing as the business innovates.

The effective rule set for a business can therefore be expressed as:

The “1” establishes a single, stable owner and a set of defaults. The “N” represents open-ended, reusable, composable enhancements. This is not class inheritance, nor is it a blind concatenation of configuration files. It is a sparse, scoped composition—each vertical selects only the horizontal capabilities it needs—with explicit ordering and reduction semantics. Conventional SPI offers one flat global list of implementations. Lattice first resolves the vertical business space, then the horizontal capabilities selected in that space, and finally the way their rules combine at each extension point.

15Reduce does not make the policy decision; it makes conflict explicit

Once the complete rule set is defined as one vertical baseline plus N horizontal increments, conflict is no longer an edge case. It is a question the composition model must answer directly. Several horizontal capabilities may modify the same business decision, and the vertical baseline may already have a policy of its own. The framework must do more than find those rules: it must state whether they can coexist and, if they can, how they produce one result.

Some rules are reducible. Consider purchase quantity. The vertical business says it cannot exceed available stock. An electronic-voucher capability allows at most 250 units per purchase. A campaign limits the order to 10. These are upper bounds from different sources, not attempts to override one another. Taking the minimum satisfies all three, so a reducer such as MIN has clear business meaning.

Other rules are mutually exclusive. A campaign may exclude a sale from volume statistics by default, while a particular vertical business—after agreement between the two owners—requires its own sales-counting policy to prevail. Two Boolean answers cannot be reconciled by taking a minimum or merging a collection. The composition needs an explicit priority rule stating whether the vertical or horizontal policy has final authority.

Lattice therefore treats composition as two separate questions: a Reduce algorithm answers “how can several results be combined?”; conflict priority answers “who decides when they cannot be combined?” A reducer may select the first non-null value, merge collections, take a minimum, or apply another algorithm with clear business semantics. Priority must be agreed and declared by the relevant business owners. A framework cannot make that policy decision for them, but it can require the decision to be explicit instead of hiding it in registration order.

16Use cases let architecture speak business language again

Abilities organize extensible behavior, but business stakeholders rarely frame a problem as a method on an entity. They talk about scenarios such as “buyer places order,” “seller fulfills,” or “buyer requests refund.” Clean Architecture places use cases outside entities: a use case guides data through entities and coordinates them toward a particular application goal. ^[2]

That distinction matters in a transaction platform. An electronic-voucher scenario spans orders, voucher issuance, notifications, redemption, and several systems. Entity-level SPIs alone still leave the business team to assemble the end-to-end process. Lattice therefore supports reusable assets at the use-case layer and scenario SDKs organized around business activities.

For electronic vouchers, the platform can provide the end-to-end capabilities for generating, issuing, redeeming, and refunding vouchers, while opening only policies where real differences exist:

public interface ETicketTradeSDK extends IBusinessExt {
    @Extension(reduceType = ReduceType.NONE)
    Boolean isVoucherSupportMultiWriteOff();
}

A movie-ticket business can allow a single redemption; a car-care package containing twelve washes can allow multiple redemptions. The business developer sees the policy “does this voucher support multiple redemptions?” They do not need to know which K/V attribute an order uses to store the answer, or search each application for a technical hook.

The scenario layer maps a meaningful rule onto lower-level entities. During order persistence, for example, the voucher use case can translate “multiple redemption allowed” into an order attribute. The entity knows how to save attributes reliably; it need not know about movie tickets, wash packages, or a future industry. The scenario depends on the entity, while the entity does not depend on a specific scenario—an instance of the Dependency Rule applied to business extension.

Most importantly, scenario assets can compose. A movie-ticket business can install both electronic voucher and presale capabilities: vouchers decide redemption behavior, while presale determines the deposit ratio. The business does not inherit an ever-growing “movie ticket platform.” It installs two relatively independent scenario capabilities inside its own business space.

17Third separation: logical business architecture from physical application architecture

The first two separations determine where code belongs and which rule space a request enters. Ability and Use Case then provide a vocabulary for capabilities and complete scenarios. On that foundation, the third separation determines how people understand the platform. Traditional platforms expose extensions through physical applications: the product service has one set of SPIs, while cart, transaction, and fulfillment services each expose another. That catalog faithfully describes deployment, but it does not explain how a business scenario works end to end. Once the estate exceeds two thousand microservices, asking any person to master the application topology before designing a business change is asking for impossible impact analysis.

Lattice uses annotations such as @Ability and @Extension to declare capabilities, extension points, defaults, and reduction semantics. @Business and @Realization declare businesses and implementation ownership. A runtime can discover this metadata and report it into a common business-management plane. The resulting organizing unit is no longer “a Java interface in application X.” It is a business flow—ordering, fulfillment, refunds, redemption—and the business policies that may vary along that flow.

Business stakeholders and designers can therefore begin with the logical view. They can follow an end-to-end process, see which capabilities the platform already provides, which horizontal plays the current business has installed, which extension points already have realizations, and which Reduce policy governs a collision. Existing pieces can be selected and composed. Anything that still appears to be missing becomes a concrete gap list for discussion with platform designers. The conversation changes from “I think some system may need a change” to “this business step lacks a reusable policy.” Platform evolution becomes more deliberate as a result.

The management view must be more than a flat extension registry. To support design and impact analysis, each extension point needs business meaning, scenario placement, inputs and outputs, default behavior, Reduce policy, owner, compatibility information, and current adopters. The platform should also preserve traceability from each logical node to its physical applications, interfaces, and runtime instances. Separating logical from physical architecture does not hide the physical system. It stops making deployment topology the starting point for business design.

Annotations do not create a sound business model by themselves. Reporting every low-level method would merely replace a map of two thousand services with an equally unmanageable interface catalog. Platform designers must still identify stable business semantics, organize use cases and abilities, and own contract evolution. Lattice provides a loop from code declaration to unified reporting, business design, and runtime execution; it does not replace modeling.

This also reflects my reading of “frameworks are details.” Lattice belongs in its proper place. It resolves identity, invokes extensions, loads realizations, discovers metadata, and reduces results, but the business rules that matter still belong to businesses and use cases.

18Do not make the runtime rediscover decisions we can make up front

Much of the risk in conventional SPI comes from dynamic guessing: iterate over every implementation and run an arbitrary filter until something matches. The answer may depend on current data, a remote call, or implementation order, making the blast radius impossible to state in advance.

Lattice favors determining which capabilities a business uses, how rules compose, and how conflicts are resolved during management and configuration. Runtime then executes the established rule set and conflict policies. The official repository likewise identifies separation of management and runtime domains as a core design. ^[3]

This does not mean runtime behavior has no dynamic conditions. It means distinguishing two kinds of information. Which rules belong to this business should be as static, visible, and auditable as possible. What those rules do with this particular order depends on runtime data. The former should not be rediscovered on every request.

Once composition can be inspected before execution, product managers and developers can perform impact analysis together: which scenarios are installed, which extension points they cover, how many realizations target the same point, and which Reduce policy applies. Architecture no longer exists only in a code reader’s head; it becomes a manageable business model.

Part IV · A minimal example, then a complete composition

19Business A customizes price; Business B keeps the default

The smallest end-to-end Lattice example is straightforward. The platform defines an extension for customizing an order line’s unit price, along with a pricing ability. Business A declares its identity and implements that extension to return 2000L; Business B makes no customization. Both orders start with a default unit price of 1000L.

OrderLine orderLine = new OrderLine();
orderLine.setUnitPrice(1000L);
orderLine.setBizCode("business.a");

OrderLinePriceAbility ability = new OrderLinePriceAbility(orderLine);
Long unitPrice = ability.getCustomUnitPrice(orderLine);

The result for Business A is 2000L; Business B still receives 1000L. Superficially this resembles the Strategy pattern. The difference is that business identity locates the realization, the ability owns the default, and the extension contract defines result reduction. The complete Quick Start and more realistic compositions are available in lattice-sample. ^[4]

At this essay’s latest update, the sample repository’s main branch still pinned Lattice at 1.0.19. I temporarily changed it to 1.0.21 and rebuilt both the Quick Start and Use Case modules; both passed. The console output in the next section also came from an actual 1.0.21 run. This is modest verification, but it keeps the code in an architecture essay from being merely plausible.

As the number of realizations grows from two to hundreds or thousands, the value of these extra concepts becomes clear. They restore the information that old implementations lacked: which business owns the change, which capability it extends, how it composes, and what happens when no realization exists.

20Electronic vouchers and presales in one business

Consider a combination closer to a real business. The movie-ticket business installs the electronic-voucher scenario and declares that a voucher may be redeemed only once. It also installs a presale scenario with a 40 percent deposit. The ordering use case invokes both scenario abilities and maps the business data that must be persisted onto the order entity.

[UseCase]PreSaleTrade load custom down payment ratio: .40
[UseCase]ETicketTrade is support multiple write-off: false
Save OrderLine id: 1, bizCode: hi.movie
-- Total Pay Price: 4000
-- Order Attributes: [e_multi_write_off:0]

Four responsibilities remain distinct behind this output. The business plugin declares what differs for movie tickets. The presale and electronic-voucher use cases encapsulate reusable scenarios. The order entity owns stable data and lifecycle. The Lattice runtime connects realizations by business identity and reduces extension results.

If a car-care business is added later, it can reuse the same voucher scenario while allowing multiple redemptions. If it also uses presales, its deposit ratio can be configured independently. The movie-ticket rules do not change, and the new business does not enter a global SPI ordering contest.

21A complete mapping from problems to mechanisms

This table captures the point I most want readers to retain. A framework should not be evaluated first by the number of annotations and extension strategies it offers. Each mechanism should answer a real problem that appears repeatedly.

Part V · Rereading the book made the limits matter more

22Lattice does not eliminate business complexity

Clean Architecture is easy to misread as a promise that correct layering keeps a system clean by itself. Extension frameworks invite a similar mistake: once code is plugin-based, any business can supposedly customize at no cost. I now prefer the opposite emphasis. Lattice does not remove business complexity; it tries to put each kind of complexity where it belongs.

Whether two vertical businesses should be isolated is a modeling decision. Whether a horizontal capability is genuinely reusable requires evidence from real scenarios. When two rules conflict, an owner still has to decide which wins. If an extension point is too fine-grained or too technical, business teams will still drown in implementation detail. A framework can make decisions explicit, but it cannot make the right decisions for us.

Several misuses deserve particular caution:

• Opening every method as an extension point. This exposes platform internals and lets contract count grow without control.
• Using a business code as a substitute for domain modeling. bizCode defines scope; it does not explain the business.
• Treating Reduce as an escape hatch. A reducer without business semantics only conceals a contradiction.
• Building a runtime without a management view. If nobody can inspect the active composition, impact analysis remains difficult.
• Separating plugin code while coupling all data. A code boundary does not solve shared-data ownership or interface evolution.

Before adding Lattice, I would ask three questions. Is this a stable, nameable point of business variation? Are its owner and scope clear? If two realizations apply, is there an explainable composition rule? If I cannot answer all three, adding another extension point usually postpones the modeling problem rather than solving it.

23Seven engineering judgments I took from rereading Clean Architecture

Years later, I no longer read the book mainly as advice about which directory should contain entities, use cases, and adapters. Circles, module names, and interfaces are representations. The real test is the cost of change: how many unrelated teams a new business must involve, how many existing businesses need regression testing, whether a fault stays inside a known scope, and whether the system preserves the option to replace mechanisms and deployment forms later.

Combined with the Lattice experience, that reading produced seven engineering judgments. They are not a second summary bolted onto the essay. They compress business identity, use cases, Reduce, plugin boundaries, and the management view into one design-review checklist.

The first judgment states what architecture ultimately optimizes. Judgments two through six describe the boundaries through which change should travel. The seventh prevents the solution itself from taking control of the business model. At this point, however, people still have to remember to apply them. In the age of AI-assisted programming, the next step is to turn those judgments into a workflow that a coding agent must execute before it touches the code.

24From the transaction platform to Spark: turn architecture into a Skill for AI coding

The transaction-platform experience taught me why boundaries matter. Spark introduced a more immediate problem. An AI agent can generate changes across several modules in minutes, but it usually sees the current task and nearby files—not the dependency direction, ownership decisions, and expensive failures that shaped the repository over years. “Please follow clean architecture” is far too weak a prompt. It still tends to produce locally reasonable code that crosses system-wide boundaries.

I began organizing architectural knowledge into four layers. docs/principle/01.clean_architect_with_lattice.md preserves the narrative and explains why the boundaries exist. docs/principle/02.ai-clean-architecture-lattice-guidelines.md reduces that history to checkable placement rules, Session Scope rules, and Process / Activity / Result rules. The repository-level AGENTS.md states which kinds of work must load those rules first. An architecture Skill then turns reading, reviewing, designing, coding, and auditing into a workflow the AI is required to follow.

The Skill is not the sole copy of architectural truth. Durable rules stay in the repository so Codex, Claude, and human engineers can all read the same source. The Skill is an execution adapter: it loads those facts at the right moment and prevents the agent from skipping directly to code generation. A shortened version derived from Spark’s actual rules looks like this:

---
name: spark-clean-architecture-review
description: Review Spark backend design, module changes, and Lattice extensions before coding.
---

# Workflow
1. Classify the change as Entity, Use Case, Adapter, or Plugin.
2. Declare modules, packages, and dependency direction; never put DOs, repositories, or plugin clients in an SDK.
3. If the platform path branches on cluster, language, or cloud provider, replace the branch with a stable business identity and plugin realization.
4. Open one Session Scope at the scenario boundary; propagate that identity through Process and Activity code.
5. Give a complex Use Case one Request and one Result; gather side effects at the end of the Process.

# Required output
- Business identity and scope entry point
- Module placement and dependency direction
- Ability / Extension / Reduce design
- Use Case / Process / Activity / Result design
- Existing violations and verification plan

In practice, I do not begin by asking the AI to “implement the feature.” I make the Skill force an architectural answer first. Suppose Spark needs Python builds on Kubernetes. The conversation might look like this:

Me: Add Kubernetes-based Python builds to Spark Flow. Run the architecture Skill first and do not write code yet. Show the business identity, module boundaries, dependency direction, extension contract, and verification plan.

AI: Use the identity build.k8s.python. Stable Context, Result, Extension, Ability, and default behavior belong in spark-console-sdk; orchestration remains in spark-pipeline; the Kubernetes-specific Python implementation belongs in spark-k8s-plugin. The plugin receives source material, build parameters, and credential references prepared by the platform, then returns image, log, and status observations. It does not read platform business tables. The scenario entry point opens one Session Scope, and Pipeline does not add a new PYTHON branch.

Me: Check that design against the dependency rules. If it passes, implement one module at a time and report the governing rule and test evidence after each layer.

AI: I will implement the leaf extension contract and safe default, then the Ability, plugin @Realization, platform invocation, and tests. Before handoff I will check that the platform does not depend on the plugin, the SDK contains no implementation objects, and no internal helper rediscovers business identity.

The module names are not the important part of that exchange. What matters is that the AI exposes its architecture model before generating thousands of lines. Identity, placement, and dependency direction can be corrected while the cost is still low. The same Skill audits the result afterward: Did a Controller quietly acquire orchestration? Did a database object enter the SDK? Did a plugin bypass Context and read a platform table? Did an inner helper open another Session Scope? Did individual Activities write the database and search index on their own?

For complex operations such as creating, transitioning, or bulk-updating tasks, the Skill also requires one Request and one Result before code generation. A Process orchestrates several Activities; each Activity adds validation, authorization, assignment, persistence plans, and event plans to the same Result. Database, index, and event side effects occur together at the end. The AI therefore generates more than a set of classes that happen to run. It generates a use case whose conceptual integrity remains visible.

This changed my view of architecture documentation. It used to explain code after the fact. In AI-assisted development, it is both knowledge and control input. It must carry reasons, permissions, prohibitions, triggers, and evidence of verification. AI does not automatically produce clean architecture, but it gives us an opportunity to turn judgments once passed down by senior engineers into a repeatable review performed on every design and implementation.

Seen this way, Lattice is more than a runtime mechanism for locating an extension implementation. Business identity, Context, Result, Ability, and plugin contracts form a change protocol that people and AI can both understand: who may alter what, where the code belongs, what material crosses the boundary, what evidence comes back, and where the effect should stop.

25Conclusion: let change stop where it belongs

The transaction platform I encountered in 2015 did not lack APIs, services, or extension mechanisms. What it lacked were boundaries: between business and platform, between one business and another, between logical business flows and physical application topology, and between management decisions and runtime execution.

Without those boundaries, adding APIs creates more context parameters, adding SPIs creates a larger global implementation tree, and splitting more applications creates more coordination. Each locally reasonable technology shifts its cost somewhere else as scale grows.

Lattice began by making those displaced and hidden costs explicit in the architecture. Business plugins separate business from platform. Business identity separates one business from another. Annotation reporting and a management view separate logical architecture from physical topology. Ability then organizes extensible behavior; vertical and horizontal dimensions express isolation and reuse; Reduce states how rules compose; and use cases restore the language of complete business scenarios. The three separations establish the boundaries, while the remaining mechanisms make those boundaries designable, executable, and verifiable.

Rereading Clean Architecture has made me more certain that the value lies not in the number of concepts invented. Good architecture does not promise that business will cease to be complex. It lets us say, when a new change arrives, where it belongs, what it depends on, whom it affects, and where it should stop.

Now that AI participates in design and implementation, those boundaries cannot remain private experience held by a few senior engineers. They must exist at once as repository knowledge, executable Skill steps, and verification evidence at handoff—so that faster code generation does not erase the intended direction of change.

That is what “clean” means to me now: not an absence of change, but change that no longer spills everywhere.