Ali Ahmed Thawerani

A Requirement Rather Than a Reality

Thu, 29 Oct 2026 00:00:00 +0000

I gave a guest lecture this week on software requirements and design: what happens to the SRS and the SDS when AI agents write much of the code. We covered specifications, architecture decision records, C4 diagrams and automated guardrails. Somewhere in the middle I realised I had skipped something more basic. I had presented spec-driven development as the natural way to work with agents, and never stopped to compare it with the way many people actually work with them today: describe what you want, accept what comes back, and keep going until it runs.

Thinking about that gap afterwards, I found the real question was not about tools at all. It was about what we mean by engineering. This post is my attempt to think it through. It is an opinion, not advice, and I hold it loosely.

A requirement rather than a reality

The phrase software engineering is younger than many of the people who use it. It was popularised at a NATO conference in Garmisch, Germany, in October 1968, called because large software projects kept arriving late, over budget and unreliable. Some of the participants were willing to call it a “software crisis.”

Brian Randell, who was there and co-edited the conference report, looked back fifty years later. The title, he wrote, had been chosen deliberately to be provocative, “describing a requirement rather than a reality,” and he credits the choice to Fritz Bauer [1].

I find that phrase humbling. Engineering discipline was never something software simply had. It was something the field decided it needed, because too much was falling through the cracks. Testing and design reviews already existed in some form, but requirements engineering, systematic reviews, configuration management and change control became, over the following decades, the field’s way of trying to make that aspiration real.

That is the lens I want to use for vibe coding. The question is not whether AI is good or bad for software. It is whether a new way of working keeps the aspiration, or quietly drops it.

What the discipline is actually for

“Discipline” can sound like a virtue word, so it is worth being concrete about what it does.

Most of the practices we call engineering exist for one reason: to catch what a single person’s attention misses. Each one is a net. None is perfect, but together they mean that a mistake has to slip through several independent checks before it reaches production.

There is a long-standing reason these nets matter so much. Robert Glass collected the evidence decades ago: historically, maintenance has consumed 40 to 80 percent of software costs, about 60 percent on average, and the single largest maintenance activity is simply understanding the existing code [2]. Manny Lehman’s first law of software evolution adds that software used in the real world must keep changing or become progressively less useful [3]. Software is read and changed far more than it is written. The discipline exists largely for those later readers.

What vibe coding removes

The term vibe coding comes from Andrej Karpathy, who described in February 2025 “a new kind of coding … where you fully give in to the vibes, embrace exponentials, and forget that the code even exists” [4]. He was clear about where it belonged: “not too bad for throwaway weekend projects.”

Simon Willison gave the clearest definition I have found: vibe coding is “building software with an LLM without reviewing the code it writes” [5]. He is equally clear about what it is not. If an LLM wrote every line but you reviewed it, tested it and can explain it to someone else, that is not vibe coding; it is software development. His own rule is that he will not commit code he could not explain to somebody else. Martin Fowler draws the same line [6].

This is why I think the usual framing, “AI coding versus traditional coding,” misses the point. Using AI heavily is not the problem. Teams can and do use AI to write most of their code while keeping every net in place.

What vibe coding removes is more basic than any single practice. Code review assumes there is an author who understood the code, and adds a second reader. Vibe coding removes the first reader: not the model, which has certainly processed the code, but the person who can explain what it does, question its assumptions and take responsibility for its behaviour. Tests can still run, but unless someone has checked what they assert against the actual requirements, they may faithfully verify the wrong interpretation. The nets are still hanging there, but the person they were tied to is gone.

I should be fair to the strongest objection here. Reading every line by hand is not the only way to gain confidence in software. Behavioural and property-based tests, static analysis, independent review, observability and staged releases all produce evidence about whether a system works, and a team can lean on them heavily. I agree. But evidence still needs someone to judge it: someone who understands the system well enough to know whether the tests check the right things, and who has the authority to say the business rule itself is right. Those are not always the same person; an engineer may understand the code perfectly without being able to confirm the rule, and a product owner may own the rule without being able to read the code. What I am really arguing for is not line-by-line reading. It is that, for anything that matters, someone accountable has understood what was built and the evidence that it works.

How much discipline does a system need?

None of this means every line of code deserves full ceremony. A demo for tomorrow’s meeting does not need traceability or change control. Discipline has a real cost, and spending it where nothing can fall far is waste.

My instinct is that the amount of discipline a system needs depends on two things: how long it will live, and what it touches, which is really a question of what happens if it fails. A script that runs once sounds disposable, until it is the script that migrates a bank’s ledger records.

How long it lives is where the difference between project companies and product companies comes in. A project delivered once might survive vibe coding, and the speed might genuinely help it win. A product shipped release after release for years is read and changed by people who did not write it, which is exactly where Glass’s numbers bite.

Even here, though, I have learned to be careful:

Few projects are as one-time as they look. Warranty periods, change requests and maintenance contracts mean that a system built as a project for a bank can still be running a decade later.
In a project, the cost does not disappear; it moves. The team that delivered moves on, and whoever maintains the system next, often the client’s own team, inherits code that nobody ever read.
It may close the road from project to product. In The Inevitable Cycles I described how software houses usually become product companies: similar projects repeat, teams notice common components, and reuse gradually becomes a product [7]. That depends on someone understanding the projects well enough to see what they share. If nobody read the code, there is nothing to harvest.

What the system touches is the second dimension, and it is where my own field sits at the extreme.

In fintech, the discipline is written down

In payments, “nothing falls through the cracks” is not a figure of speech. A crack is a debit with no matching credit, a reversal applied twice, a transaction the ledger says failed while the bank says it succeeded. In The Hollow Sprint I used the example of a wallet that assumes a switch timeout means the debit failed: once that assumption has shaped the ledger, the reconciliation job, the customer notification and the settlement file, correcting it is no longer a small change [8]. Those are exactly the cases the engineering nets exist to catch, and exactly the cases that only appear when someone thinks carefully about what can go wrong.

In this domain the discipline is also not left to taste. Take the card industry’s security standard. PCI DSS version 4.0.1 requires that bespoke and custom software is reviewed before it is released to production, to find and correct coding vulnerabilities (Requirement 6.2.3). Where those reviews are manual, code changes must be “reviewed by individuals other than the originating code author” and approved by management before release (Requirement 6.2.3.1) [9].

I want to be careful about what the standard does and does not say. It does not prescribe how much code a person must write, and it does not say the originating author must have written or understood every line. Its concern is that software is reviewed before release and, where reviews are manual, that the review is independent and approved. Whether a vibe-coded module can pass an audit depends on how a particular organisation implements its controls.

My concern is the one underneath. When most of an implementation is generated, who can explain its assumptions, judge whether the review was meaningful, and take responsibility for the result? Complying with a review requirement and genuinely understanding the code are related, but they are not the same thing. Still, the direction of the standard is clear: in fintech, the 1968 aspiration has become, at least in places, a written obligation.

Where vibe coding belongs

None of this makes vibe coding useless. I think it has a proper place, and it is at the very beginning.

Customers are often much better at reacting to something they can see than at describing what they want. Requirements engineering has known this for a long time: Karl Wiegers and Joy Beatty distinguish throwaway prototypes, built to learn and then discarded, from evolutionary prototypes that grow into the product [10]. Fred Brooks put the older version more bluntly: “plan to throw one away; you will, anyhow” [11]. What vibe coding changes is the cost. A throwaway prototype that once took weeks can now be produced in an afternoon, with the customer in the room. In The Hollow Sprint I suggested exactly this for uncertain decisions: build the visible part with the customer, keep the confirmed decisions, and throw the prototype away [8].

The important words there are throw the prototype away. What should survive a vibe-coded prototype is not its code but the decisions it helped people make, written down where they can be checked.

This is also where my earlier post on technology stack selection comes back in, with a caveat against myself [12]. In that post I argued that starting in a stack where AI tools are strongest is sensible, and that a product can later move parts of itself to the stack its domain demands, as fintech cores often drift towards ecosystems with stronger compliance tooling. But I also wrote that “the prototype built with speed but no structural discipline tends to become the thing that blocks future progress — not because it failed, but because it succeeded.” Those later migrations only stay small because the prototype had clean seams from the first day: domain modules, one interface file per external service, an architecture file the agent reads.

A vibe-coded prototype has none of those seams. That is fine if it really is thrown away. The danger is the prototype that impresses the customer and quietly becomes version one. Then nobody ever chose the stack deliberately, and there is no clean seam to migrate along.

So the shape I keep coming back to has three phases: vibe-coded discovery, a deliberate break, and disciplined product development.

Two details matter. In fintech, discovery should use fake data only; a prototype holding real customer or card data inherits the product’s obligations. And “throw it away” is a default, not a rule: code that has genuinely been reviewed and tested to production standards can be reused on that evidence. What should not cross the break is code nobody has read, simply because it already works.

The signed document we gave up

That brings me to something I talked about in the lecture without having planned to.

For most of my career, a project began with a detailed functional specification or SRS. The customer read it, argued over it and signed it. It was not only a technical document. It was the scope of a commercial agreement: the price was attached to it, and any change after signature went through a change management process, with an impact assessment and, often, a revised cost. Wiegers and Beatty describe this as the requirements baseline, the agreed set against which every later change is evaluated [10].

That document was far from perfect. Customers signed pages they had not fully understood, and the gap between what they read and what they later saw on screen was a constant source of change requests. Agile was partly a reaction to exactly this.

Vibe coding has made much of that document feel unnecessary. For visible behaviour, a customer who can click through a working prototype understands what is being built far better than one who reads two hundred pages of “the system shall.” But a prototype does not by itself establish what has been agreed, what remains undecided, or what the system must do when things go wrong. It is a discovery tool, not a requirements baseline.

The signed document did at least two jobs the prototype does not.

It was a baseline. It said what had been agreed, so that a change could be recognised as a change. A prototype does not separate what was agreed from what the model happened to generate. When the customer later says “but it did this in the demo,” it is hard to say whether that behaviour was a decision or an accident.

It covered what screens do not show. A prototype shows the happy path beautifully. It is mostly silent on what happens when the switch times out, when a reversal arrives late, when a limit is breached, or how fast the system must respond under load. In payments, those are precisely the things that turn into disputes.

And there is a third problem the old document never had. A customer who has clicked through something that looks finished tends to believe it nearly is. The prototype becomes the product in their mind, and sometimes in the plan, which is the failure from the previous section arriving through the commercial door rather than the technical one.

All of this makes requirements much harder to freeze. When the next version is one prompt away, every meeting can produce a new idea, and without a baseline every change request becomes a negotiation.

Freezing what can be frozen

I do not think the answer is to go back to two-hundred-page specifications. I think it is to be selective about what we freeze.

In The Hollow Sprint I separated two kinds of decision [8]. Regenerable decisions, such as screen layouts, wording or the order of steps in a form, are cheap to reverse; being wrong means regenerating one piece. Load-bearing decisions are the ones everything else comes to depend on: what counts as a completed transaction, how a reversal settles, what is written to the ledger, which limits and controls apply, what the integration contracts with the bank or switch look like, and the performance and security requirements the system must meet.

That distinction suggests a different shape for the agreement:

Freeze the load-bearing decisions. Write them down precisely, have the customer confirm them, baseline them, and put them under change management. This is a much shorter document than the old SRS, but each line in it matters.
Let the regenerable decisions stay open. Iterate on them with the customer using the prototype, which becomes an illustration of intent rather than the contract itself.
Apply change management where change is expensive. A new screen layout should not need an impact assessment. A change to how reversals settle always should.

I have not seen many contracts written this way yet, and I am not sure how pricing should work when part of the scope is deliberately left open. That feels like an unsolved problem for project companies in particular. One possibility I would like to explore is to fix the price and acceptance criteria for the load-bearing decisions, and treat the visible experience as iterative scope within an agreed time budget. The contract would then protect what must not change without pretending every screen is known in advance. I offer that as an idea, not as something I have seen proven. But it seems closer to the truth than either extreme: a signed document that pretends everything is known, or a prototype that pretends nothing needs to be.

What spec-driven development looks like today

Those frozen, load-bearing decisions have to live somewhere, and spec-driven development is the obvious candidate. Before arguing about whether it is the answer, it is worth looking at what the term currently means in practice, because it is younger than it sounds. Most of the tooling appeared in the second half of 2025. Three tools come up most often, and Birgitta Böckeler’s hands-on review of them on martinfowler.com is the most careful comparison I have found [13].

GitHub Spec Kit is an open-source, MIT-licensed toolkit that sets up a repository so that a coding agent works through a fixed sequence [14]. A project starts with a constitution.md of principles that apply to every change. Each feature then moves through specify, plan, tasks and implement, producing a spec.md, a plan.md and a tasks.md. The current documentation adds an analyze step that reports gaps between those artifacts and a converge step that checks the implementation against them. The philosophy is stated bluntly in the project’s methodology document: “Specifications don’t serve code—code serves specifications” [15]. The project began in August 2025 and reached version 1.0.0 in August 2026, by which point its documentation listed 38 coding-agent integrations [14].

Kiro is Amazon’s agentic development environment, built on VS Code and launched in July 2025 [16]. Its pitch was explicitly framed against vibe coding: to combine “the flow of vibe coding” with “the clarity of specs.” A Kiro spec is three files: requirements.md, written as user stories with acceptance criteria in EARS notation (“WHEN [condition or event] THE SYSTEM SHALL [expected behaviour]”), design.md for architecture and sequence diagrams, and tasks.md for the implementation plan [17]. Alongside specs, Kiro has steering files that describe the product, technology and structure, and hooks, event-driven automations that run an agent when something changes, such as updating a test file when a component is saved [16].

Tessl is the most ambitious of the three and, when Böckeler reviewed it, still in private beta [13]. Specifications live in *.spec.md files, each currently mapped to one code file, and the generated code carries a header comment telling people not to edit it: // GENERATED FROM SPEC - DO NOT EDIT. Of the three, it is the one that openly aims beyond the first release.

Böckeler offers a useful way to place them. She distinguishes three levels of spec-driven development: spec-first, where a specification guides the task in hand; spec-anchored, where it is maintained as the feature evolves; and spec-as-source, where people edit only the specification and never touch the generated code [13]. Putting vibe coding at the start of the same scale makes something visible that the prose hides.

Her experience with the tools in October 2025 was mixed, and I think her caveats matter as much as the features. Kiro turned a small bug into four user stories with sixteen acceptance criteria. Spec Kit generated many verbose markdown files that she found more tedious to review than code, and its agent sometimes ignored notes about existing classes and created duplicates. Regenerating code from the same Tessl spec produced different results each time. Her review predates Spec Kit 1.0, so some of this may have moved on; I take it as a snapshot of where the tools were, not a ranking of where they are.

A tool, not the discipline

What strikes me most is not any individual feature but where the tools stop.

A product does not just need a well-documented first release; it needs a specification that is still true at release ten. That is the spec-anchored level, and it is exactly the part the tools leave to people. Spec Kit’s own documentation is admirably honest about this. It now names Böckeler’s three levels itself, describes three ways a team might maintain its specs after delivery, and says plainly that none is the default: “The model is a team convention, not a CLI setting” [18]. In other words, the tool can carry a specification to the first release. Whether it stays true afterwards is still a matter of discipline.

There is a subtler limit as well. A specification can make a wrong decision consistent and repeatable; it cannot make the decision right. If the reversal rule in the spec is wrong, the agent will implement it faithfully and the tests will confirm it faithfully. That still depends on domain knowledge and on the people with the authority to make the decision.

Spec-as-source makes me pause for a different reason. It asks people never to touch, and in practice never to read, the generated code. Structurally, that is the same bet vibe coding makes. Böckeler raises a related worry: that it may combine the rigidity of model-driven development with the non-determinism of language models [13]. A careful specification in front of the bet is much better than nothing, but it does not bring back the reader.

And even a correct, current specification and well-understood code are not the whole story. Someone also has to be accountable once the system is live: for what happens when an assumption fails at month-end, when the bank changes its message format, or when reconciliation shows a difference nobody predicted. Understanding the code, owning the business rule and owning the system in production are three different responsibilities, and a healthy team knows who holds each.

So I have ended up thinking of spec-driven development as a very useful tool for carrying the discipline, not as the discipline itself. Whatever a team chooses, the discipline still has to live somewhere: in someone who understands the specification, the code, and the gap between them.

Where I have landed, for now

If I had to put my current view in a few sentences:

Software engineering began as an aspiration to stop things falling through the cracks, and most of its practices are nets that catch what one person misses.
Using AI to write code does not abandon that aspiration. Removing the accountable human reader does.
How much discipline a system needs depends on how long it lives and what its failure would cost; few systems are as short-lived as they first appear.
In fintech, the discipline is partly written into standards, which makes code that nobody read hard to defend.
Vibe coding belongs at the start, as a way of seeing requirements. What should survive it is the decisions, not the code.
For visible behaviour, a prototype builds shared understanding better than a prose SRS, but it is not a baseline. Freeze the load-bearing decisions; let the regenerable ones stay open.
Today’s spec-driven tools, such as Spec Kit, Kiro and Tessl, are good at carrying a specification to the first release. Keeping it true afterwards, and understanding the code beneath it, is still left to people.

Randell’s phrase has stayed with me since I first read it. Fifty-eight years on, software engineering is still in some ways a requirement rather than a reality. AI has made it far easier to produce software, and so it has also made it easier to forget the requirement. I do not think the answer is to produce less. I think it is to keep asking, for each piece of code, who has actually understood it.

I may well be wrong about parts of this. If you have seen vibe-coded systems hold up well over years of change, or disciplined teams where the nets failed anyway, I would genuinely like to hear about it.

Sources

[1] Brian Randell, “Fifty Years of Software Engineering, or The View from Garmisch,” keynote at ICSE 2018 (May 2018). arXiv:1805.02742

[2] Robert L. Glass, Facts and Fallacies of Software Engineering (Addison-Wesley, 2002), Facts 41 and 44.

[3] M. M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proceedings of the IEEE 68, no. 9 (1980).

[4] Andrej Karpathy, post on X (2 February 2025). x.com

[5] Simon Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)” (19 March 2025). simonwillison.net

[6] Martin Fowler, “Vibe Coding,” martinfowler.com bliki. martinfowler.com

[7] Ali Ahmed Thawerani, “The Inevitable Cycles: Why Software Houses Keep Returning to Square One,” TECTONICS (January 2026). aathawerani.github.io

[8] Ali Ahmed Thawerani, “The Hollow Sprint,” TECTONICS (October 2026). aathawerani.github.io

[9] PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, version 4.0.1 (June 2024), Requirements 6.2.3 and 6.2.3.1. PCI SSC Document Library

[10] Karl Wiegers and Joy Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), chapters on prototyping and on requirements change management.

[11] Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975), chapter 11, “Plan to Throw One Away.”

[12] Ali Ahmed Thawerani, “Tech Stack Selection in the Age of AI Agents,” TECTONICS (May 2026). aathawerani.github.io

[13] Birgitta Böckeler, “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl,” martinfowler.com (15 October 2025). martinfowler.com

[14] GitHub, Spec Kit repository, README and project history (accessed October 2026). github.com/github/spec-kit

[15] GitHub, “Spec-Driven Development,” spec-driven.md in the Spec Kit repository. github.com

[16] SD Times, “Amazon launches spec-driven AI IDE, Kiro” (14 July 2025). sdtimes.com

[17] Kiro documentation, “Specs: concepts.” kiro.dev

[18] GitHub, “Spec Persistence Models,” Spec Kit documentation (accessed October 2026). github.com

The Hollow Sprint

Fri, 09 Oct 2026 00:00:00 +0000

A team can now build in days what the business needs weeks to confirm. The sprint still ends on Friday, the demo still runs, and every signal says the work is done. Whether it is the right work is a question the process no longer has time to answer.

That is a new problem, and to see why, it helps to remember what Agile was for in the first place.

Agile was an answer to a hard question: what do you do when you cannot know what to build until you have built some of it?

The answer before Agile was to try harder at knowing. Barry Boehm’s work showed that a defect found late can cost far more to fix than the same defect found early [1], so the rational response was to specify as much as possible before building. That is the logic of Waterfall, and it was not stupid. Its weakness was the assumption that enough upfront effort could produce certainty about what customers needed. It usually could not.

Agile’s answer was different. Kent Beck argued that with test-driven development, continuous integration and refactoring, the cost of change could be flattened enough that deferring decisions stopped being reckless [2]. Mary and Tom Poppendieck gave the idea its best name: make each decision at the last responsible moment [3]. Plan a little, build a little, show it to the customer, learn, adjust.

That answer was a trade-off between two costs. One was the cost of building: every increment took real developer time, so you could not afford to build many versions of anything. The other was the cost of being wrong: the further you went on a mistaken assumption, the more you had to throw away. Short iterations balanced the two. Build enough to learn something; not so much that being wrong is ruinous.

AI has changed one side of that trade-off dramatically. Building is far cheaper than it was. The cost of being wrong has not moved in the same way. When one side of a balanced trade-off changes, the balance point moves. The question for anyone running software delivery is where it moves to, and whether our processes have noticed.

My answer is that it moves in two directions at once. Before getting there, it is worth looking at what happens when a team does not notice at all.

The hollow sprint

When I learned Scrum, the purpose of a sprint was to produce a shippable outcome frequently. The 2017 Scrum Guide said exactly that: “the purpose of each Sprint is to deliver Increments of potentially releasable functionality.” [4] The 2020 edition kept the idea, requiring the increment to be usable, and added a second purpose that is easy to miss: “Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame.” [5]

So the sprint has two jobs. It turns ideas into usable value, and it limits risk by capping how much gets built before the next chance to learn whether it was the right thing. For twenty years these jobs moved together. Two weeks of human effort produced an increment small enough for a review to absorb. Don Reinertsen’s work on product development flow explains why that size mattered: the more work built between two feedback points, the more assumptions ride on each one, and the more rework a wrong assumption causes [6].

AI separates the two jobs. The first gets easier: usable increments arrive faster than ever. The second quietly fails, because the time-box only limited risk while human output limited the batch. Put another way, the sprint used to control two capacities at once: how much the team could build, and how many decisions the business could absorb. As long as the first was the smaller of the two, controlling it controlled both. AI has made build capacity and decision capacity diverge.

I call the result the hollow sprint: a sprint that still delivers a usable increment on schedule, with every ceremony intact, while the amount of unconfirmed work inside it has grown beyond what one feedback point can check.

What makes it dangerous is that it reports success. The Scrum Guide never defines a failed sprint. The Sprint Goal is set by the team, the Definition of Done is a quality standard the team holds itself to, and the guide is explicit that “the Sprint Review should never be considered a gate to releasing value.” [5] None of that was a flaw when building was slow, because the customer saw everything soon anyway. With AI, generated code meets the Sprint Goal, passes the tests and satisfies Done. Every official signal says the sprint went well. Nobody outside the team has confirmed anything.

I argued in The Evaluation Constraint that AI made trying things cheap and left knowing whether they worked expensive, and in The Cognitive Load Ceiling that it can produce software faster than a team can understand it. The hollow sprint is what that looks like inside a delivery process: the knowing falls behind, and the process has no alarm that rings when it does.

One caution. The throughput gain is not universal. A 2025 randomized trial by METR found experienced developers working in mature codebases they knew well were slower with AI tools, even though they believed they were faster [7]. Integration-heavy, regulated systems, the kind I work on, are where gains are smallest. The argument does not need AI to make everyone faster. It needs only this: wherever throughput has jumped, the time-box has stopped limiting risk. You can check that in your own team by comparing how much changed between your last two sprint reviews with the same comparison two years ago.

The fork

So the old balance is broken. Where does the new one sit? There are two credible answers, and they point in opposite directions.

Scenario A: plan more. If implementation is cheap, the time spent defining requirements no longer competes so directly with building. Three days sharpening a specification used to cost three days of development; now it costs a small fraction of what it would take to generate, integrate and unwind the wrong system. Meanwhile, every wrong assumption gets built on faster, by agents that do not stop to ask. On this reading, the economically rational move is toward more upfront definition: settle requirements, interfaces and constraints before generating anything large. Practitioners already have a name for the shape this produces. In 2011 Dave West of Forrester called it Water-Scrum-Fall: upfront planning and downstream release gates wrapped around a Scrum middle [8]. It was meant as a criticism. AI makes it look like a rational design.

Scenario B: iterate more. If implementation is cheap, so is a prototype. A team can show a customer three working versions of a workflow in the time it once took to write one requirements document. Why spend days specifying what the customer wants when you can generate something and watch them react to it? If prototypes become nearly free, iteration itself becomes cheaper, and the rational move is to build more and earlier, and plan less.

Both arguments are sound, and both have evidence on their side. Scenario A matches what happens when teams generate large amounts of code on a misunderstood requirement. Scenario B matches what happens when product teams use prototypes to settle questions in an afternoon that used to take a sprint.

They cannot both be the right default. But they can both be right.

It depends on the decision

The fork dissolves once you stop asking it about the project as a whole and ask it about each decision inside the project. The missing variable is not the size of the project or the maturity of the team. It is one property of each decision: what happens when you reverse it.

A regenerable decision is one whose reversal is contained. A load-bearing decision is one whose reversal invalidates the decisions built on top of it.

Regenerable decisions include screen layouts, the order of steps in a form, wording, dashboards, internal module structure, an implementation choice behind a stable interface. Being wrong means regenerating one piece. For these, Scenario B is usually the better default: build, show, learn, regenerate. Their last responsible moment moves later than Agile ever allowed, because changing them is now almost free.

Load-bearing decisions are the ones everything else comes to depend on. In payments they are easy to name: what counts as a completed transaction; what happens when the switch times out after a debit has posted; how a late reversal settles; what is written to the ledger before a notification is sent; which regulatory controls apply. For these, Scenario A is usually the better default. Their last responsible moment moves earlier, to before the generation that depends on them, because AI builds on top of them so quickly.

A small example shows the difference. Suppose an agent builds a wallet’s reversal flow on the assumption that a timeout means the original debit failed. The screen that tells the customer “your payment did not go through” can be regenerated in minutes. But if the same assumption has already shaped the ledger entries, the reconciliation job, the notification logic and the settlement file, then correcting it is not a small change. The bank may in fact have completed the debit, and every component built on the opposite premise now disagrees with the bank. The code may be cheap to rewrite. The decision graph is not.

This is the core of the argument. AI did not settle the debate between planning and iterating. It split it in two. The single “last responsible moment” that Agile applied to every decision has become two moments moving in opposite directions. A team that keeps one rhythm for everything gets both wrong: it over-plans the regenerable work, wasting the cheapest thing it has, and under-plans the load-bearing work, letting agents build fast on premises nobody has confirmed. AI scales up whatever the team misunderstands between feedback points, and it does so most expensively on the decisions that carry weight.

The two-line version is something a team can carry into its next planning session:

Contained reversal: defer and iterate.
Cascading reversal: decide earlier.

In practice this is a spectrum rather than two clean boxes, and where a decision falls is itself a judgment call that can be wrong. A UI choice becomes load-bearing once an integration partner depends on it; a ledger detail can be contained if it sits behind a well-defined interface. Even so, “what happens if we reverse this?” is a far more useful question than “Agile or Waterfall?”, because it can be asked about each decision on its own, today, by people who know the domain.

Decide earlier does not mean specify upfront

There is an obvious objection here: isn’t “decide load-bearing decisions earlier” just Waterfall for the important parts? It would be, if deciding earlier meant writing a long requirements document. It does not have to.

Reversal cost tells you when a decision must be settled. Two other questions tell you how:

How uncertain is the decision? Some load-bearing decisions are well understood. Whether transaction state is authoritative in the wallet service or in the payment switch is consequential, but an experienced team can usually settle it in a design conversation and record it. Others are genuinely open. Whether to support one settlement model or three is just as load-bearing, but nobody knows the answer from a meeting room.
How cheaply can the uncertainty be resolved? For the open questions, the right response is rarely a three-week requirements phase. It is often a few thin, throwaway models or prototypes, built in days, shown to the people who know the business, and discarded once the decision is made.

So the full rule has three parts: reversal cost sets the deadline, uncertainty sets the effort, and the cheapest way to resolve that uncertainty sets the method. Important, uncertain decisions get resolved deliberately before downstream generation, and that resolution can itself be thoroughly iterative. What changes is not whether a team iterates, but what it iterates on: the decision first, then the system built on it.

It also explains why neither camp’s evidence is wrong. The teams who say AI makes them more Agile are mostly prototyping regenerable things. The teams who find themselves drifting toward upfront specification are mostly building systems where the expensive decisions are load-bearing. Fintech, healthcare and anything regulated sits heavily in the second group.

What this does to Agile’s commitments

Agile’s manifesto is short, and only part of it speaks to the balance between planning and iterating [9]. Two of its values change in specific ways once decisions are split.

“Responding to change over following a plan” is stronger than ever for regenerable decisions, where change is nearly free. For load-bearing decisions something subtler happens. The fastest way to change a generated system is no longer to edit its code but to edit its specification and regenerate. Responding to change increasingly means changing the plan; the plan stops being what change fights against and becomes the medium change travels through. “Working software over comprehensive documentation” shifts in the same way. The rejection of documents written to satisfy process still holds, but a precise statement of load-bearing rules is no longer a description of software someone will write later. It is the input software is generated from. I wrote about the engineering side of this in Why Architecture Is Shifting From Diagrams to Guardrails; the same shift applies to business rules.

The principles behind the manifesto follow the same split [10]. Welcoming late changes, letting designs emerge, and treating working software as the measure of progress all remain sound for regenerable decisions. For load-bearing ones they need a qualifier: late change means unwinding generated work, emergent design means inheriting whatever each generation step assumed, and running software proves little when it can run perfectly while encoding the wrong settlement model. None of this makes the manifesto obsolete. It treated every decision as one class, because at human pace there was no reason not to.

The customer side

If load-bearing decisions have to be confirmed before generation, someone has to confirm them. In most organizations that is the part of the system with the least spare capacity: the customer, the product owner, the domain expert, the compliance reviewer. Making Agile work in the AI era is mostly about this side of the table, and it is the part engineering leaders most often leave to chance.

Know your validation capacity. Every organization has a finite number of customers, product owners, domain experts and compliance reviewers able to confirm load-bearing decisions carefully. AI can multiply generation capacity far faster than it can multiply those people. Little’s Law, one of the sturdiest results in operations research, says that in a stable system the number of items waiting equals their arrival rate multiplied by how long each waits [11]. If agents produce load-bearing decisions faster than they are confirmed, the queue grows and so does the wait. Faster generation does not shorten that wait; it lengthens it. So plan against validation capacity, not against the team’s build capacity and not against the calendar: unconfirmed load-bearing decisions in flight should not exceed what the business can confirm.

Wire customer confirmation into the stop signal. The hollow sprint survives because every signal that ends a cycle is judged by the team. Each method has a place to change that without abandoning the method. In Scrum, state the Sprint Goal as a confirmed outcome rather than an output, and add a line to the Definition of Done: every load-bearing decision in this increment has been confirmed by the Product Owner or customer. In Kanban, which has no sprints but limits work in progress [12], add an explicit “awaiting confirmation” stage with its limit set to the business’s validation capacity, and keep items small enough that each carries only one or two load-bearing decisions. In XP, keep customer-owned acceptance tests as the definition of done, and keep the agents from writing the tests they are checked against.

Run a daily decision loop. Instruct agents to record the assumptions they make, not only the code they write. Each day, developers sort the log: regenerable assumptions they decide themselves; load-bearing ones go to a business representative in a short, fixed slot, and the answers go back into the specification so the same question is never asked twice. This is XP’s On-Site Customer, given a sharper job [2]. It also carries XP’s warning: when Angela Martin, Robert Biddle and James Noble studied the customer role on real projects, they found it so demanding that representatives were overloaded and the role was hard to sustain [13]. Agents ask more questions than developers did. The loop works only if the representative has the authority to decide without escalating, protected time that is part of the job rather than on top of it, and a triage step that shows them only load-bearing questions.

Spend prototypes where uncertainty is high. As the rule above implies, Scenario B is right for regenerable decisions, and it is also often the best way to resolve an uncertain load-bearing one: a new workflow, a pricing or settlement model, an onboarding journey. Have the product manager build the visible part with the customer in the room, keep the confirmed decisions, and throw the prototype away. But every prototype spends customer attention, so it draws on the same validation capacity.

Measure the constraint that matters. Velocity and story points measure building capacity. In AI-assisted teams where that capacity has expanded sharply, it may no longer be the constraint that matters most. The most important measure is decision latency: the time from an assumption being logged to it being confirmed or corrected by someone with business authority. If it is rising while the ceremonies stay the same, the process is no longer agile in any meaningful sense, whatever it is called. Two more measures support it: unconfirmed load-bearing decisions in flight, which should stay within validation capacity; and rework from overturned assumptions, the generated work thrown away because an unconfirmed premise turned out wrong. That last one is the direct cost of a hollow sprint, and it usually goes unseen because regeneration makes it feel cheap.

None of these practices is new. Customer acceptance tests, on-site customers, work-in-progress limits and queueing theory all predate this wave of AI. What is new is the reason to take them seriously. For twenty years they were optional, because slow building did their job for free.

The decision is the unit

So is Waterfall coming back? Not as a methodology. What is going away is the idea that a whole project needs a single delivery philosophy.

A single payments project can now contain Waterfall-like treatment for transaction semantics, ledger behaviour, settlement, data ownership, security boundaries and regulatory rules, and thoroughly Agile treatment for screens, workflows, copy, dashboards and internal implementation, all at the same time. The question “are we an Agile shop or a Waterfall shop?” stops being useful. The unit of methodology is no longer the project or the feature. It is the decision. The answer to the hollow sprint is not to return to Waterfall. It is to stop treating every decision as if it had the same reversal economics.

That also changes what a CTO should watch. When AI raises build throughput, the constraint moves to the next thing in line, and in most organizations that is the rate at which the business can confirm the decisions embedded in the work. Decision latency is the measure of that constraint, which makes it, not velocity, the number that tells you whether your delivery process is keeping up.

I should be clear about what this post is. It is an argument, not a measured result. I have not seen the daily decision loop or these measures tested at scale, and the measures above are how you would find out whether they work in your organization. The real cost also falls where engineering leaders have least control: on the business side, which has to give daily, protected time to confirming decisions. If an organization cannot provide that, the honest fallback is the unpopular one: deliberately build less per cycle than the team is capable of, so the batch stays within what the customer can absorb.

For a CTO, the questions are short:

Which decisions in your current roadmap are load-bearing, and have they been confirmed by someone with business authority?
When your process says the work is done, who decided that: the team, or the customer?
How long does a load-bearing decision wait before it is confirmed, and is that wait growing?
Are your sprint boundaries still controlling risk, or only the calendar?

Agile taught us to delay each decision until the last responsible moment. AI has not made that principle obsolete. It has made us ask, for every decision, when that moment actually is.

The future of software delivery may not be Agile or Waterfall. It may be knowing which decisions deserve each.

Sources

[1] Barry W. Boehm, Software Engineering Economics (Prentice Hall, 1981).

[2] Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999).

[3] Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003).

[4] Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2017), section on the Sprint.

[5] Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020), sections on the Sprint, Sprint Goal, Sprint Review and Definition of Done. scrumguides.org

[6] Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas, 2009).

[7] METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (July 2025). metr.org

[8] Dave West, “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today,” Forrester Research (2011).

[9] Kent Beck et al., Manifesto for Agile Software Development (2001). agilemanifesto.org

[10] Kent Beck et al., Principles behind the Agile Manifesto (2001). agilemanifesto.org/principles.html

[11] John D. C. Little, “A Proof for the Queuing Formula: L = λW,” Operations Research 9, no. 3 (1961): 383–387.

[12] The Kanban Guide, sections on WIP and flow. kanbanguides.org

[13] Angela Martin, Robert Biddle and James Noble, “The XP Customer Role in Practice: Three Studies,” Proceedings of the Agile Development Conference (2004).

The Evaluation Constraint

Sun, 02 Aug 2026 00:00:00 +0000

The Same Inputs, Different Companies

Take an engineering organization of sixty people: a couple of hundred services in production, an on-call rotation, a platform team, a primary framework two major versions behind, a data migration deferred twice, and a compliance deadline eleven months out. Decide how the sixty are distributed across all of it.

Now take a second organization with the same sixty people, the same budget, the same stack, the same market and the same backlog. Give it a different distribution.

Five years later these are not two versions of the same company. One has a platform that makes each new service cheaper than the last; the other has forty services that each cost full price to build and full price to keep alive. One absorbs a regulatory change in a quarter; the other discovers the change requires touching systems nobody fully understands, and spends three quarters finding out what they do. The gap did not come from talent, effort or process discipline. Both organizations worked hard and shipped continuously. The gap came from which allocation they found.

This is what strategy literature means by superior allocation — the observation that among the many ways an organization can distribute scarce resources, only a small number produce materially better long-run outcomes, and that finding one of those is the actual source of advantage rather than working harder inside whichever one you happen to have inherited.

The effect size is not subtle. McKinsey’s long-running study tracked roughly 1,500 companies over two decades and found firms in the top third by reallocation activity delivered around 10 percent in average annual shareholder returns against roughly 6 percent for the bottom third — compounding to a company worth about twice as much within twenty years [1]. The distribution behind that number is the part worth sitting with: a third of those companies moved about one percent of their capital between businesses year over year. Most large organizations re-approve last year’s allocation with minor adjustments, for decades.

That is not allocation. It is ratification.

Superior allocations exist and are rare. Almost every organization is operating in one it never chose, arrived at by accumulated default.

The argument below runs in one line, and it is worth seeing whole before it is taken apart.

Your Strategy Is Where Your Engineers Actually Are

Before going further it is worth dispatching a comfortable belief: that allocation is downstream of strategy — leadership decides direction, engineering executes, and capacity distribution is the plumbing in between.

Joseph Bower’s research at Harvard, beginning in 1970 and extended for three decades by Robert Burgelman, Clark Gilbert and Clayton Christensen, found close to the opposite [2]. A company’s realized strategy emerges far less from formal statements of corporate strategy than from the accumulated pattern of resource commitments made across every level of the firm. Strategy is not decided and then allocated. Strategy is what the allocations turn out to have been.

The clearest software demonstration is AWS. In 2003 two Amazon infrastructure engineers, Benjamin Black and Chris Pinkham, wrote a short paper describing infrastructure that was completely standardized, completely automated, and relied extensively on web services [3]. Bezos approved an experiment; Pinkham relocated to Cape Town and built EC2 there, deliberately away from Seattle. Amazon’s stated strategy was retail. The engineering capacity went to infrastructure anyway, and the strategy amended itself afterwards.

Two details matter more than the story’s familiarity. The version most people know is false — the claim that AWS came from renting out spare retail capacity has been denied by Black himself, who says every part was purpose-built. And it was not a lone bottom-up insight either: Andy Jassy was concurrently writing a vision document for the same business, presented to the executive team that September and approved for 57 hires. Two allocation processes ran at once, from opposite ends of the organization, and the strategy followed both.

For a CTO this is an uncomfortable diagnostic, and I include myself in it. Your technology strategy is not the deck you presented to the board. It is the sum of where your engineers spent last quarter. When the two disagree, the deck is the fiction — and it is usually the fiction being reported upward.

What Makes One Allocation Superior

If allocations differ so much in outcome, it is worth being precise about what actually varies between them, because the answer explains why judging them is hard.

Two allocations can produce nearly identical output this quarter and leave the organization in completely different positions in three years. The difference is not in what gets shipped. It is in what each allocation does to the organization’s future capability — its capacity to do the next thing, and the thing after that.

Platform investment increases future capability; each subsequent service costs less than the last. Technical debt consumes it; every deferred decision raises the price of the ones that follow. Architecture shapes it by fixing which future changes are cheap and which are structurally expensive, and knowledge concentration constrains it by tying the organization’s ability to act to specific people.

This is why superior allocation is genuinely difficult rather than merely uncommon. The variable that distinguishes a good allocation from a mediocre one is not visible in this quarter’s output. It sits in the future, in a counterfactual, in the cost of work that has not been attempted yet. Any organization can measure what it shipped. Almost none can measure what its choices did to what it will be able to ship.

Why Governance Doesn’t Find Superior Allocations

If superior allocations are rare and valuable, the obvious question is how an organization finds one. The obvious answer — better process at the point of decision — is where most organizations have invested, and it does not work, for reasons that are structural rather than a matter of execution quality.

For sixty engineers across even a handful of investment categories, the number of possible distributions is combinatorially enormous, and the number that are genuinely superior is vanishingly small by comparison. Finding one is therefore a search problem: it requires visiting many points in that space and being able to tell them apart.

Herbert Simon described the consequence sixty years before anyone was allocating engineering capacity [4]. Real decision-makers cannot evaluate all available alternatives, so they do not optimize — they satisfice, generating options until one clears an acceptability threshold, then stopping. Bounded rationality is not a criticism of managers; it is a description of what is physically possible. Which means the question is never whether an organization searches exhaustively, because none does. It is how much of the space it covers before its threshold is met, and how good that threshold is.

Now look at what the standard apparatus actually does. Investment committees, architecture review boards, portfolio dashboards, quarterly planning, OKRs — these are decision procedures. A decision procedure evaluates the candidates that arrive in the room. It has no mechanism whatsoever for generating the candidate nobody proposed. An organization can run an immaculate governance process, with the right thresholds and the right cadence and genuinely capable people, and spend a decade choosing among three options in a space containing thousands — never discovering that the superior allocation was one that was never tabled.

Governance improves the quality of evaluation. It does not search the solution space. Those are different jobs, and in most organizations only one of them has been staffed.

The default state is worse than this suggests. Peter Weill and Richard Woodham’s research on IT governance found that organizations tend to fall into recognisable archetypes — a monarchy where a small executive group decides everything, a feudal model where each unit decides independently, a federal blend of the two, or an anarchy in which decision rights were simply never assigned [5]. The uncomfortable finding is that anarchy is the most common state, not because anyone selected it but because it is what happens in the absence of a deliberate choice. Organizations are ungoverned by omission in exactly the way they are allocated by default. Both are the same failure: a structure nobody chose, inherited rather than searched for.

Two Generators

Search decomposes into generating candidates and evaluating them. The generation half is better understood than most engineering leaders realise, because Burgelman named its two modes decades ago [6].

The induced process generates candidates that fit the current strategy. It runs top-down — leadership articulates a direction and the organization produces options consistent with it — and it is what people mean when they say a CEO’s mindset trickles down. It reduces variation and exploits what the organization already knows.

The autonomous process generates candidates outside the current strategy, from people close enough to the frontline to notice a gap between the stated strategy and what the environment is doing. Black and Pinkham writing an infrastructure paper at a retailer is this. So is Amazon opening its storefront to third-party sellers, including direct competitors, which was contested internally and is now a majority of units sold.

Burgelman’s finding is the useful part: successful organizations run both at once, and strategic reorientations are usually preceded by experimentation and selection through the autonomous process. With only the induced process an organization searches a narrow band around where it already is; with only the autonomous one it generates variety it cannot integrate.

This also names the executive’s actual job in a way most job descriptions do not. Burgelman calls it strategic context determination: evaluating the adaptive potential of autonomous initiatives and amending corporate strategy only once one has proven reasonably viable. That is not deciding. It is evaluating — which is a different skill, and, as the next section argues, the one that has recently become scarce.

The Arm That Used to Be Expensive

Search has two arms and they are not symmetric in difficulty. Which one binds has changed, and almost every mechanism organizations currently rely on was built for the old answer.

For most of the history of software, generation was the expensive arm. Producing a serious candidate — a working prototype, a migration actually attempted, an architecture built far enough to judge — cost months. Evaluation was nearly free by comparison: by the time you had built the thing you understood it, because building it was how you came to understand it. Understanding arrived as a by-product of construction.

Look at what the industry built under that assumption. Reusable components, frameworks, package ecosystems, low-code platforms, and eventually code generation — a whole discipline aimed at making candidates cheaper to produce. The evaluation apparatus stayed thin because it did not need to be thick: code review, some architecture review, and the tacit judgment of whoever had built the last three systems.

AI inverted the ratio. Generation is cheap and getting cheaper. Evaluation costs what it always did, because understanding no longer arrives as a by-product of construction — the construction happens without it. What remains is an apparatus optimised for the arm that stopped being scarce.

Search consists of generation and evaluation. Generation used to be the binding constraint. It no longer is, and the mechanisms built for it have not been replaced.

I want to be careful with the primacy claim, because there are other plausible candidates for what limits allocation. Incentives determine which candidates get proposed. Politics determines which survive contact with the people whose budgets are affected. Information matters too. Each genuinely constrains allocation and I am not arguing otherwise.

The test I would apply is what happens when you relax the others. Fix the incentives and you get a wider candidate set you still cannot judge. Remove the political friction and decisions move faster in directions nobody has verified. Add information and you have fed a process whose bottleneck is downstream. Raise evaluation capacity, though, and the others become legible: an organization that can judge options can see that its candidate set is skewed, and can tell which objections are analysis and which are territory. Incentives shape what appears, politics shapes what survives, information feeds the judgment — and evaluation is the step none of them substitute for.

Where Evaluation Capacity Comes From

The evaluation half has no equivalent vocabulary, which is part of why it goes unmanaged. It deserves a name, because everything below depends on it:

Evaluation capacity is an organization’s ability to judge options it has not taken. It is the scarce input that determines whether allocation is search or ratification.

Stated that way the supply problem becomes tractable, because judgment about an option you have not taken cannot come from the option itself. It has not happened. It has to come from somewhere else, and as far as I can tell there are only four somewhere-elses: take a small piece of the option cheaply, have taken something like it before, find someone who took it and said what happened, or borrow judgment from someone who already has it. Buy it, remember it, borrow it, distribute it. Each buys a different kind of certainty at a different price.

Buying it is what an experiment does. The spike, the pilot, the limited rollout, the prototype whose purpose is information rather than delivery — each converts an unknown into evidence at a fraction of the cost of committing. It is the only source that produces evidence about this option in this system, which makes it the most precise of the four and, in most engineering organizations, the most underused, because work that produces a decision rather than a feature is hard to defend in a delivery-focused planning meeting.

Remembering it is what experience does, and it is really an experiment already paid for. An engineer who has been on the wrong end of a migration is carrying evidence about the next one that nobody has to purchase again. That makes experience the cheapest source at the point of use and the most expensive to acquire — and the most fragile, because it lives in people, is rarely written down, and leaves when they do. An organization whose judgment about architectural trade-offs sits in four heads has a search capability that two resignations can halve. Knowledge concentration is not a staffing inconvenience; it is a direct constraint on how many options the organization can consider.

Borrowing it is what external evidence does — the counterfactual someone else ran and published. When Amazon Prime Video’s monitoring team documented moving from distributed serverless components back to a monolith and reported roughly a ninety percent reduction in operating cost, every organization that read it acquired an evaluation input it never had to pay to generate [7]. The industry’s habit of publishing architectural post-mortems is, in aggregate, a shared evaluation commons, and it is why this source has grown faster than the other three. It is also the least transferable, for reasons the later discussion of open-loop decisions returns to.

Distributing it is what shared priors do, and this is the only source that scales without adding people. When leadership’s reasoning about trade-offs is legible enough that engineers three levels down apply it unaided — Netflix’s formulation is context, not control — the organization has spread its judgment rather than centralised its approvals, and can therefore evaluate in many places at once. This is what makes autonomy work when it works. It is not a values statement; it is a transmission mechanism, and an organization that cannot articulate its own reasoning has nothing to transmit.

Notice what the four have in common: none of them is a decision process. They are all ways of acquiring evidence about a road not taken. Which is why an organization can improve its governance indefinitely and not become better at allocation — it is refining how it chooses between candidates while doing nothing about how well it can tell them apart.

Encoded and Held

There is a second distinction cutting across those four sources, and it explains something engineering leaders argue about constantly without resolving.

Evaluation capacity is either encoded in artifacts or held in people. Encoded capacity is the architectural fitness function running in CI, the runbook, the architecture decision record, the review checklist, the deployment gate. Held capacity is the staff engineer who knows why the payment reconciliation service behaves the way it does at month end.

They fail in opposite directions.

This resolves a question that otherwise looks like a matter of taste. A process-oriented organization can hire inexperienced engineers successfully, because the encoded capacity carries the judgment they do not yet have. A people-oriented organization making the same hire does worse — not because the person is worse, but because there is nothing for them to inherit. Neither model is superior in general; they are strong and blind in opposite places.

The most interesting artifacts encode judgment about the future rather than the past. An architectural constraint expressed as an executable check is judgment someone wrote down once that now runs without its author. That is the strongest form encoded capacity takes, and its limit is the limit of the form: it evaluates what was anticipated and is silent about what was not.

Where to Spend It

Evaluation capacity is scarce, which means it has to be allocated too — and spreading it evenly across every decision is the most common way to waste it.

The rule that matters is reversal cost: what would it cost — in time, money and disruption — to undo this eighteen months from now if the assumption behind it turns out wrong. Low-reversal-cost decisions barely warrant evaluation; make them fast and correct cheaply. High-reversal-cost decisions warrant nearly all of it, because a wrong answer will still be constraining the organization long after everyone has forgotten the reasoning.

What makes this difficult is that reversal cost has almost nothing to do with how large a decision feels at the time. Technology decisions have wildly different lifespans, and the range spans two orders of magnitude.

Past the middle of that range, a decision usually stops being visible at all — re-litigating it would mean re-litigating everything built on top, so nobody does.

The mismatch is that most review processes calibrate scrutiny to cost at the moment of commitment, not to lifespan. Choosing a primary language for a new service can be nearly free — a config file and an afternoon of debate — while carrying a fifteen-year reversal cost. An expensive one-off infrastructure migration might carry a three-year one. Calibrating by immediate cost systematically under-evaluates exactly the decisions that deserve the most evaluation.

Reversal cost is not the whole picture, though. It asks what it takes to undo a decision; optionality asks what future choices the decision leaves available, and the two come apart more often than they coincide. A vendor contract can be cheap to exit and still foreclose an entire category of architecture, because the integration pattern it encouraged has propagated everywhere. A platform can be expensive to unwind and still be the thing keeping three directions open. Reversal cost is about the past commitment; optionality is about the shape of the future.

This is why platform work resists justification through delivery metrics. A platform’s return is not cheaper output this quarter. It is that a set of future decisions became affordable, and their consequences more predictable — which lowers the evaluation cost of everything built on top. Platform investment is evaluation-capacity infrastructure, and architecture that preserves optionality is the same purchase seen from another angle. Neither shows up in any measure of what shipped.

One more effect is worth noticing: lifespan is often emergent rather than chosen. A database engine picked provisionally in year one is load-bearing by year three, because forty services now assume its consistency guarantees. Decisions become expensive to reverse while nobody is watching, so the window in which evaluation is cheap closes silently.

The Economics of Searching Well

Search costs something, which means a CTO is choosing how much of a scarce resource to spend on finding better ways to spend a scarce resource. Three ideas from economics do genuine work here, and they are not decorative.

Scarcity is the permanent condition, not a temporary shortfall. Additional headcount moves the frontier of what is possible and immediately generates a larger set of things worth doing that still exceeds what is available — which is why “how do we get enough capacity” has no stable answer.

Opportunity cost is the only honest price of a candidate. Reviewed one at a time, almost every proposal clears the bar. The question that discriminates is not “is this worth doing” but “is this worth more than the next-best use of the same capacity” — and that alternative never names itself. Asking for it out loud is the cheapest search discipline available, because it forces a second candidate into existence at the moment the first is being approved. Without it, sequential local approval drifts somewhere nobody chose: every individual yes was defensible, and the accumulated pattern is an allocation no one would have selected deliberately.

Incentives determine which candidates exist at all, which makes them the most consequential of the three and the easiest to miss. Teams propose what they are rewarded for proposing. If promotion follows visible launches, the candidate set reaching any review board is biased toward new surface area and away from platform work, debt reduction and decommissioning — not through bad faith, but because people rationally generate the options that are good for them to have proposed. The bias runs both ways: there is a well-worn path for the person who shipped an ambitious platform and essentially none for the person who recognised early that a funded initiative should stop. An incentive structure is a filter sitting upstream of governance, quietly determining which regions of the space are ever visited. Fixing the review board while leaving the filter in place changes little.

To make any of this concrete, the split has to be measured rather than felt: a small number of tracked buckets — non-negotiable work to keep the business running, and elective investment across new capability, improvements to existing systems, and internal productivity.

The ranges above are indicative, not targets, and they move with domain, regulatory load and estate age — an AI-first product and a core banking platform have no business sharing a number. What matters is not landing on the right percentage but having one at all. A CTO who can state the current split, the intended split, and the direction of travel is in a different conversation from one who can only describe it qualitatively.

What AI Actually Changed

Now the central asymmetry can be stated, and it is the reason the last three years feel confusing rather than simply good.

AI is an extraordinarily powerful generation engine. It lowers the cost of producing a candidate — a prototype, a migration path, an alternative architecture, a working proof that something is possible — by an order of magnitude. In search terms it massively expands the number of points in the allocation space an organization can afford to visit. That is real, and it is the half everyone is discussing.

AI simultaneously degrades evaluation capacity, and that half is invisible in every metric currently in use.

The mechanism is the one I set out in The Cognitive Load Ceiling: AI generates code faster than teams build understanding of it. Understanding was already the binding constraint on how large and complex a system a given team could hold. AI did not lift that ceiling — it compressed the timeline on which organizations reach it. With AI-authored code now accounting for somewhere between a third and two-thirds of what many teams commit, every system built substantially by generation rather than by authorship carries an evaluation cost that has been deferred rather than paid. And evaluation capacity is precisely what the organization needs in order to judge its next allocation.

The industry data carries this signature once you know to look. DORA’s research finds that AI amplifies whatever organizational discipline already existed rather than substituting for it — exactly what a technology that multiplies generation while leaving evaluation untouched would do [8]. Teams with high evaluation capacity get more good candidates; teams without it simply get more candidates. The same work finds throughput and instability rising together in the same organizations, which is what a search process generating faster than it can judge looks like from the outside. And the persistent finding that a meaningful minority of developers do not trust AI output while shipping large volumes of it is not conservatism — it is a workforce accurately reporting that its evaluation capacity has not kept pace.

Stated in terms of the thing that actually matters: an organization generating faster than it can judge is still accumulating output, but it has lost the ability to tell which of that output is building future capability and which is quietly consuming it. Both feel identical in the quarter they happen.

AI made it cheap to try things and left it expensive to know whether they worked.

What AI Can and Cannot Evaluate

That is too blunt as stated, and the qualification matters more than the headline. AI is not uniformly weak at evaluation — it is weak at a specific kind, and the boundary is worth drawing, because much of the current enthusiasm for feeding operational data to a model and asking what to do next sits on the wrong side of it.

Why Architecture Is Shifting From Diagrams to Guardrails described this loop working at the architecture layer — build something small, instrument it, let production failures feed back into tests and constraints — and named its limit: the loop can be made more reliable but not fully reliable, and the boundary is the depth of human understanding of the domain the system represents.

That boundary generalises. Call the two sides closed-loop and open-loop decisions.

Closed-loop decisions produce observable, attributable outcomes — latency, error rate, cost per transaction, rework rate, incidents thirty days out. The thing you chose actually ran and production said what happened. AI is genuinely strong here and getting stronger.

Open-loop decisions have no telemetry, because the alternative was never built. Whether to enter a segment. Whether to abandon a platform. Whether the next three engineers go to the migration or the new product. There is no log file for the counterfactual, and no amount of instrumentation on what you did do will produce one.

Open-loop does not mean evidence-free, though. Borrowed evidence is exactly the third source described earlier, and aggregating it is something AI does very well — which genuinely raises the floor. Two limits survive. A published result came from a particular system, so whether it applies to yours is a separate judgment requiring understanding of yours; borrowed evidence relocates the question from “does this work” to “does this apply here,” which is the harder one. And organizations publish successes and instructive reversals, not the boring failures or the option nobody tried, so the corpus is a skewed sample and a model aggregating it inherits the skew without saying so.

AI’s oldest commercial application states the boundary cleanly. Predicting markets from data has always been high-error and works anyway, because the bets are numerous, diversifiable and repeatable, so being wrong on any one averages out. That tolerance disappears when you are making one bet, once, with a high cost of reversal and nothing to average against.

Prediction with a wide margin of error is acceptable for reversible decisions and unacceptable for irreversible ones.

Which is the uncomfortable shape of the current moment: AI raises evaluation capacity most for the cheap, reversible decisions that needed it least, and least for the expensive, one-way decisions where it was always binding. That does not make the reversal-cost discipline less important. It makes it the discipline that determines whether any of the new capability reaches the decisions that actually matter.

Readers with a machine learning background will recognise the shape of this. Cheap candidates, expensive judgments, and a rule for choosing which candidates are worth judging is the structure of active learning, with reversal cost acting as the acquisition function.

The analogy is useful and it breaks in three places, which is where the organizational version stops being derivative. Active learning assumes an oracle — a label can always be bought. For an open-loop decision the label may not exist at any price, because the counterfactual was never run. It assumes a fixed labelling budget, whereas evaluation capacity decays as people leave and reasoning goes unrecorded. And it assumes labels stay valid, while the conditions that made a past judgment correct keep moving.

The Hybrid Team Is a Search System

The common framing — AI as tooling that makes engineers faster — describes an efficiency gain and misses the structural change. A mixed human-and-agent organization is a search system with the two arms handled by different participants: agents generating candidates at a rate no human team could match, humans holding the capacity to judge which are worth keeping.

Three management problems follow, and they are the same problem. Review is evaluation applied at the code level, and agents fail differently from people — confidently and fluently, producing output that reads as correct because it is well-formed. If generation volume rises while review depth holds constant, evaluation capacity per unit of output is falling even though nothing visibly changed. Accountability cannot dissolve into the tool: “the AI did it” is no more valid in an incident review than “the linter did it,” so every class of consequential agent action needs a named human owner assigned before the agent has authority to act. And metrics have to be attributed rather than aggregated, because a deployment figure blending human and agent work measures two processes as one at exactly the moment the difference matters.

Governance as Routing

With evaluation capacity named, governance can be defined more usefully than “who is allowed to decide.”

Governance is not bureaucracy. Bureaucracy is what governance looks like when it is designed badly — uniform process applied regardless of stakes. Governance is decision architecture: the structure through which evaluation capacity is routed to the decisions that need it. Done well it is largely invisible, because low-stakes decisions move fast by design and only consequential ones slow down.

That framing sharpens what usually goes wrong. Decision rights are allocated by structure — seniority, position, team boundary. Evaluation capacity is distributed by understanding, which respects none of those. Governance failures are, very often, authority sitting somewhere other than where the understanding sits.

Knight Capital’s 2012 deployment failure — new trading code pushed to seven of eight production servers, a reused flag reactivating dormant functionality, roughly $440 million lost in forty-five minutes — was not an engineering failure. The engineers were competent and the code was ordinary. Nobody who understood what a partial deployment could do had authority at the moment it mattered. The failure was in routing.

This also settles the centralisation argument, which is usually conducted as a matter of philosophy and is really a matter of variance. Authority should sit where the variance is. If regional conditions genuinely differ — different regulators, different payment rails, different fraud patterns — the understanding required to judge those decisions cannot be centralised, and centralising them destroys evaluation quality regardless of how capable the central team is. If variance is low, decentralising duplicates cost and fragments standards for nothing. Amazon’s 2003 API mandate is the clean software case: one interface standard imposed centrally with no exceptions, because there is no useful variance in how services should expose themselves, and everything behind the interface left to the team, because there is enormous variance in what each service actually does. Centralise where variance is low; delegate where it is high.

Seen this way the governance domains stop being parallel checklists. Investment, risk, architecture, security, AI, vendor and compliance governance are seven attempts to route one class of decision each toward the place where it can actually be judged. Most implementations route toward hierarchy instead and assume comprehension coincides — which is an empirical question, and rarely asked.

The same lens sharpens the most familiar problem of all. Technical debt is not code; it is deferred understanding — the reasoning behind a shortcut nobody recorded, held by a person who has since forgotten it or left. It hurts because it consumes future evaluation capacity: every subsequent decision touching that system costs more to judge, which is to say it draws down future capability by exactly the mechanism the earlier section described. This is also why agent-generated code that no one ever had to reason through carefully is a debt instrument even when the code is objectively good.

When Resources Are Not Scarce

An obvious objection to all of this: what about organizations that do not face meaningful scarcity? A company with tens of billions in operating income can fund every candidate simultaneously and let the winners emerge. Does the constraint dissolve at that scale?

It does the opposite. Abundance does not remove the constraint. It removes the mechanism that was doing the evaluating for free.

Under scarcity the budget prunes automatically: a failing bet dies because you cannot fund it and payroll in the same quarter. That is a crude evaluation mechanism, but it is relentless and never forgets to run. Under abundance nothing prunes. The bet continues because continuing is affordable, and affordability is not information.

Meta’s Reality Labs division accumulated roughly $83.6 billion in cumulative operating losses between 2020 and 2025, including a $19.19 billion loss in 2025 against $2.21 billion of revenue [9]. The reason that was survivable is the reason it went on so long: Meta’s total 2025 revenue was roughly $201 billion, and the core advertising business absorbed the burn without existential consequence. A capital-constrained company would have received the signal in year two, involuntarily. Meta received it when leadership eventually directed cuts of up to 30 percent to Reality Labs spending and reallocated toward AI — a decision made deliberately, years after a scarcer organization would have had it made for them.

So the giant’s problem is not finding resources. It is that its automatic evaluation feedback has been switched off, and it now has to manufacture the signal that scarcity used to supply. Kill criteria, scheduled reassessment and named ownership are optional for a startup, because the bank account enforces them anyway. At scale they are not optional. They are the only remaining mechanism.

Recovering Evaluation Capacity

There is one more thing search requires, and it is the part most often mistaken for a separate discipline. Generating candidates and evaluating them once is not search — it is exploration. Search is what happens when the results of a commitment feed back and update the judgment applied to the next one. Revision is that feedback arm. Without it, an organization performs the motions of search and learns nothing from any of them.

Evaluation capacity decays, which is what makes the feedback arm fragile. The reasoning behind a commitment fades, the people who could reconstruct it move on, and an initiative persists by default — not because anyone decided it should continue, but because nobody retains the capacity to determine that it should not. You cannot revise what you no longer understand, which is why organizations so often keep funding things nobody would start today, and why every year of that consumes future capability nobody recorded as spent.

Three habits preserve it, and all three are cheap at the moment of commitment and expensive to retrofit afterwards.

Set the kill criterion when you approve, not later. A specific, named condition — a metric threshold, a competing option reaching a certain capability, a date by which a certain result should exist — decided while the room is still thinking clearly and before any sunk cost exists to bias the judgment.

It is also the only common practice that records a counterfactual. Operational data captures what an organization did, almost nothing about what it rejected — which is why an organizational record, fed to a model or read by a successor, describes the past without helping anyone judge the future.

Schedule the reassessment rather than waiting for a crisis. A commitment whose assumptions have quietly stopped holding does not announce itself. A fixed cadence is the forcing function a silent problem does not provide.

Name an owner for the reassessment, with the same clarity as the original approval. Approval processes always name someone. The recheck is usually left to “the team should reassess if things change,” which means nobody is on the hook, which means it does not happen.

The Uncomfortable Part

There is a tension here I do not think resolves cleanly, and it seems more honest to end on it than to manufacture a conclusion.

The most reliable way to build evaluation capacity has always been to do the work. Engineers develop judgment about architectural trade-offs by making architectural mistakes and living with them; they learn which migrations go badly by being on the wrong end of one. The path to senior judgment runs through a large volume of low-stakes, hands-on repetition — and that volume is precisely the work agents are now absorbing most completely.

So the organizations expanding their generation capacity fastest are, by the same action, eroding the mechanism by which their evaluation capacity has historically been renewed. Not immediately, and not visibly. But the engineers who will be judging allocations in 2032 are building their judgment now, on a smaller base of consequential experience than any previous cohort.

I do not have a clean answer to this. The obvious remedies — deliberate rotation, protected hands-on work, structured post-mortems — all amount to paying deliberately for something the technology appears to offer free, which is a hard argument to win in a planning meeting and will get harder as the visible gap between generation-rich and generation-poor teams widens.

What I am more confident about is the diagnostic. To tell whether an organization is searching or ratifying, do not look at how good its decisions appear. Ask how many allocations it seriously considered before choosing, and what it would have cost to evaluate one more. The answer to the second question is the constraint, and it is the one almost nobody measures.

Which brings the argument back to where it started. Two organizations, sixty engineers each, the same budget, the same stack, the same backlog, five years apart in outcome. After everything above, the difference between them is no longer mysterious and it was never about talent.

Both expanded their capacity to generate. Only one expanded its capacity to judge what it had generated — and so only one was ever really searching. The other ratified its way to a place nobody chose, one defensible decision at a time, and arrived with more code, more services, more shipped output, and less ability to do the next thing than when it started.

Superior allocation was never a better quarter. It is a larger stock of future capability: the ability to absorb the regulatory change, enter the adjacent market, survive the platform shift that has not arrived yet. Every organization can see what it shipped. The ones that compound are the ones that can still tell what their choices did to what they will be able to ship.

Sources

[1] Hall, S., Lovallo, D. and Musters, R. (2012). “How to put your money where your strategy is.” McKinsey Quarterly, March 2012, and subsequent extensions of the same dataset published through 2016.

[2] Bower, J. L. (1970). Managing the Resource Allocation Process. Boston: Harvard Business School Press. See also Bower, J. L. and Gilbert, C. G. (eds.) (2005), From Resource Allocation to Strategy, Oxford University Press.

[3] Black, B. (2009). “EC2 Origins,” blog.b3k.us; and Amazon executive accounts of the September 2003 AWS vision document.

[4] Simon, H. A. (1955). “A Behavioral Model of Rational Choice.” Quarterly Journal of Economics, 69(1), 99–118; Nobel Memorial Prize in Economic Sciences, 1978.

[5] Weill, P. and Woodham, R. (2002). “Don’t Just Lead, Govern: Implementing Effective IT Governance.” MIT Sloan CISR Working Paper. See also Weill, P. and Ross, J. W. (2004), IT Governance, Harvard Business School Press.

[6] Burgelman, R. A. (1983). “A Model of the Interaction of Strategic Behavior, Corporate Context, and the Concept of Strategy.” Academy of Management Review, 8(1), 61–70; and Burgelman, R. A. (1991), “Intraorganizational Ecology of Strategy Making and Organizational Adaptation.” Organization Science, 2(3), 239–262.

[7] Amazon Prime Video Tech Blog (2023). “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%.”

[8] DORA / Google Cloud, State of AI-assisted Software Development, 2025–2026 editions.

[9] Meta Platforms segment disclosures, FY2020–FY2025, as reported in company 10-K filings and quarterly earnings coverage.

This post continues a series on the mechanics of technology leadership. Related pieces: The Cognitive Load Ceiling, Why Architecture Is Shifting From Diagrams to Guardrails, The CTO Decision Stack.

The CTO Decision Stack in Startup and Enterprise

Sun, 12 Jul 2026 00:00:00 +0000

The third post in the CTO Decision Stack series. The seven layers don’t change between a ten-person startup and a ten-thousand-person enterprise. What changes is what each layer is optimizing for, given different constraints. A startup shipping a throwaway product to win a deal and an enterprise refusing to is not one of them being undisciplined. Both can be right, in their own context — and the recurring failure isn’t a bad decision at either end. It’s importing a tradeoff that was correct somewhere else.

A CTO who has spent a career at startups joins an enterprise and immediately tries to ship fast, skip the architecture review, and treat the first version as disposable. Three months in, a customer-facing outage traces back to exactly that posture, and it costs the company a contract renewal that took two years to win. A CTO who has spent a career at enterprises joins a startup and immediately stands up a formal RFC process, a dedicated platform team, and a multi-stage release pipeline. Eight months in, the startup runs out of runway, having shipped half as much as a leaner competitor with a fraction of the process.

Neither CTO made a technically wrong call in isolation. Both made a call that was correct somewhere else.

This is the actual subject of this post, and it’s worth being precise about what it isn’t. The first post in this series closed by noting that the stack behaves differently across organizational contexts, and named one axis of that difference: the startup’s risk is invisibility — decisions happening by default because nobody is positioned to make them deliberately — while the enterprise’s risk is disconnection — decisions made correctly in isolation by people who don’t know about each other. That axis is real, and it shows up below. But it isn’t the whole story.

The deeper difference is what each layer is optimizing for, given constraints that genuinely differ — not just how visible the optimization is. A startup choosing to build a deliberately throwaway product to win a deal isn’t a decision made invisibly by default. It can be fully deliberate and fully correct, for reasons specific to what a startup has and doesn’t have yet. An enterprise refusing the same call isn’t being slow out of habit. It’s protecting something the startup doesn’t have yet either.

The seven layers are constant. What’s not constant is the answer each layer produces. The map below shows where each layer’s tension actually sits before the post walks through all seven in detail — and where a tension recurs at a later layer, it’s named once and referenced back to, not redefined.

Layer 1: Corporate & Business Strategy

Risk Appetite and Reputational Exposure. An organization with a handful of customers and no public track record has comparatively little to lose from a visible failure. One with an existing customer base, existing contracts, and a brand built over years has a great deal to lose from the same failure. The same decision can carry a different expected cost depending on which of those is true, which means the rational threshold for “good enough to ship” genuinely differs — not because one company cares more about quality, but because the downside of being wrong is sized differently.

This is why a startup can rationally choose, at layer one, to build a deliberately disposable product to win a specific deal, prove a market exists, or simply survive to the next funding round. It’s the sacrificial architecture posture the second post in this series described, in Martin Fowler’s terms — building something now on the explicit understanding it will be discarded later. The posture is more available to a startup than it is anywhere else in a company’s life, precisely because the cost of the eventual public failure is low: few customers are exposed, there’s little brand to damage, and the capital clock is the binding constraint, so speed is worth more than durability against it.

The same move costs an enterprise more. An enterprise weighing a similarly disposable build for a new initiative isn’t weighing it against a clean slate — it’s weighing it against an existing customer base who will experience the rough edges, and frequently regulatory or contractual exposure a startup hasn’t accumulated yet. An enterprise that ships something throwaway under its existing brand isn’t taking the same bet a startup takes. It’s taking a worse version of that bet, because the downside is sized to the company it already is. This is why enterprises rationally over-invest in quality and durability at layer one for new initiatives, even ones that are, in every other respect, startup-shaped. The investment isn’t conservatism for its own sake. It’s pricing the bet correctly against an exposure a startup doesn’t carry.

Invisibility and Disconnection. The secondary tension at this layer is the one named in the introduction. A startup’s layer-one strategy is often founder intuition that’s never made explicit — frequently correct, rarely documented, hard to revisit when circumstances change because nobody can reconstruct what assumptions it depended on. An enterprise’s layer-one strategy is usually explicit and well-resourced, and its risk runs the other way: strategy decided in a room that doesn’t include anyone with current visibility into what the architecture can actually support, producing the disconnection the first post warned about between the technology SWOT and the business SWOT it’s meant to be checked against.

The Technology SWOT, Run Twice. The first post introduced the technology SWOT as the tool that surfaces what a business SWOT can’t see on its own — strengths, weaknesses, opportunities, and threats, evaluated from the technology side. The same four quadrants, run separately for a startup and an enterprise, produce almost mirror-image results, and the mirroring is the useful part.

This is where time horizon and reversibility — the two axes the first post used to open each layer of the stack — do real work. A startup’s decisions tend to have short time horizons and high reversibility: a bet that doesn’t pay off can usually be unwound within a product cycle or two, because little has been built on top of it yet. An enterprise’s decisions tend toward long time horizons and low reversibility, not because enterprises choose this, but because scale itself extends both: more has been built on top of any given decision, more depends on it staying stable, and unwinding it later costs more the longer it’s been load-bearing. The technology SWOT for each context isn’t really describing two different sets of capabilities. It’s describing the same four quadrants, reshaped by how long a decision has to live and how much it costs to take back.

Layer 2: Product Architecture

Resource Asymmetry. An enterprise building a new product rarely starts from zero. Identity and authentication, billing, observability, compliance tooling, a design system, a deployment pipeline — these frequently already exist, built and hardened by other teams, available to a new initiative at close to no marginal cost. This changes what’s architecturally rational. An enterprise can afford more structural rigor up front on a new product than the same product would justify as an independent startup, because the cost of building “properly” is dramatically lower when most of what “properly” requires is already sitting on the shelf.

A startup has no shelf. Every layer of the architecture is being built for the first time, by a team whose primary constraint is finding product-market fit before the runway runs out. Under-investing in architectural rigor at this stage is frequently the correct call — not a failure to plan ahead, but a recognition that the hours spent on structural cleanliness are hours not spent discovering whether the product needs to exist at all. The first post’s Stripe example — the early bet that developer experience was the moat — was exactly this kind of startup-stage architectural decision, made deliberately and well, by a small team that chose where to spend its limited rigor budget rather than spreading it evenly.

The risk in both directions is borrowing the other context’s answer. A startup that insists on enterprise-grade architectural rigor before it has product-market fit is spending a scarce resource — time — on a problem it doesn’t have yet. An enterprise that treats a new product’s architecture with startup-style looseness, assuming it’ll figure things out later, is declining resources it already owns for no real savings, and inheriting risk it didn’t need to take.

Rewrite Tolerance. Resource Asymmetry above is about the cost of building. This is about the cost of changing your mind once something is already built and already has users — a related but distinct constraint, because the two don’t move together.

A startup with a small, early customer base can treat its own architecture the way the first post’s Stripe example treated developer experience: as a bet that’s allowed to be wrong. If the bet doesn’t hold, the cost of rewriting is mostly internal — engineering time, not customer disruption — because there are few customers to disrupt. This is the sacrificial architecture posture from layer one, recurring here in its more literal, mechanical form: not just “we may discard this deliberately,” but “discarding this costs us comparatively little, so we can afford to let the architecture be wrong for a while before we know enough to make it right.”

An enterprise product running at real scale doesn’t have that option. A rewrite isn’t mostly internal anymore — it’s a migration, with customers who have to be moved and a failure mode that’s visible to people who didn’t ask to be part of the experiment. This is precisely the condition the second post in this series described Neal Ford’s evolutionary architecture as answering: guided, incremental change, checked against fitness functions, rather than a wholesale rewrite that bets everything on the new version before the old one is retired. Part of why the enterprise can’t simply abandon the bet is that the same debt that was invisible at startup scale — an ugly schema, a brittle integration nobody outside engineering ever saw — tends to surface at enterprise scale as something a customer, an auditor, or a support team notices directly; it hasn’t just gotten more expensive to unwind, it’s become externally visible. The failure, predictably, is a startup refusing to rewrite out of misplaced caution it can’t afford, or an enterprise attempting a startup-style wholesale rewrite of a system already carrying real customer load.

Layer 3: Technology Delivery

Speed versus Rigor. A startup’s fast-delivery culture — fewer review gates, lighter test coverage, a willingness to ship before everything is verified — is frequently a rational response to a runway clock. The cost of moving slowly, running out of money or losing a market window to a faster competitor, is usually higher than the cost of the technical debt incurred by moving fast, at least at the scale a startup is operating. This is a real trade-off, made consciously, not a quality failure.

An enterprise’s slower delivery cadence — more review, more sign-off, more staged rollout — is the mirror calculation. At enterprise scale, a production incident doesn’t affect a small early cohort; it affects existing customers, existing contracts, and frequently SLAs with real financial penalties attached. The cost of moving carelessly is much higher than the cost of moving more slowly, so the rational trade-off shifts toward rigor — gatekeeping that earns its cost, not bureaucracy for its own sake, though as the second post in this series noted, AI’s effect on implementation speed is reshaping what “moving carefully” actually requires, and an enterprise that hasn’t revisited its review process against that shift is paying for rigor that no longer matches what’s actually slow. The failure, in either direction, is a startup adopting rigor it can’t afford the time for, or an enterprise importing speed into a context where the cost of being wrong is sized for a much bigger company than the one taking the risk.

Build versus Buy. A dedicated post in this series already covered the mechanics of this decision — that AI makes building cheaper without changing the calculus for anything outside an organization’s core differentiation, and that the real question is who carries the operational burden once the thing exists. Startup and enterprise answer that question from opposite starting positions.

A startup building something it should have bought is usually doing it for a reason the second post named directly: the build looks fast and the demo works, and the support burden that should have informed the decision doesn’t show up until much later, by which point the team has no spare capacity to absorb it. The startup’s real constraint on buying isn’t preference — procurement-grade vendors price for enterprise budgets, leaving a startup to build what it can’t afford to license, whether or not building is the right call on the merits.

An enterprise facing the same decision can usually afford to buy almost anything; the constraint isn’t price, it’s process. Building, inside an enterprise, is often faster precisely because it routes around that process — not because building is cheaper in any absolute sense, but because it’s cheaper relative to the friction of buying in that specific organization. Spotify’s Backstage is a clean instance of exactly this dynamic: the internal developer portal that eventually became an industry standard started as an internal tool built to solve Spotify’s own service-discovery problem, and one part of its appeal at the time was structural rather than technical — open-source, internally-built software is generally easier to get signed off than a comparable commercial purchase, because the decision doesn’t draw the same scrutiny a new vendor contract would. What actually separates the two contexts runs deeper than either price or process, though — it’s who is positioned to operate the thing once it’s running. An enterprise buying software is rarely just buying the software; it’s buying into existing security, platform, and SRE functions that already know how to operate a third-party dependency safely at scale. A startup buying the same software has none of that scaffolding to plug it into. This isn’t a claim about what kind of thing is being purchased — plenty of startups buy tools that deliver real operational leverage, plenty of enterprises buy tools that still require real in-house capability to run well. It’s a narrower claim: an enterprise usually has supporting functions already built to absorb the operational ownership a purchase brings with it, and a startup usually doesn’t, and that asymmetry is what should actually drive the build-versus-buy call in each.

Layer 4: Engineering Organization

Process Affordability. A startup cannot afford a dedicated process function. There’s no spare capacity to run formal ceremonies, maintain an RFC process, or staff an architecture review board — the team is lightweight because lightweight is what the headcount allows, not necessarily because lightweight is philosophically preferred. Team structure accretes, ownership forms by default, and Conway’s Law — the first post’s observation that any organization designing a system produces a design that mirrors its own communication structure — produces a system shape nobody designed on purpose, simply because nobody had the bandwidth to design it on purpose. The startup’s small size means Conway’s Law is operating on a communication structure that’s mostly informal, so the architecture it produces is whatever a handful of people happened to talk through in the moment.

An enterprise starting a brand-new initiative faces the opposite temptation. The organizational muscle for process already exists and is already funded — sprint ceremonies, RFC templates, architecture review boards, a defined path for getting a new team stood up. Deploying that process on day one of a new product costs the enterprise comparatively little, because the infrastructure for it is sitting there. The risk is that the process was built for a mature, stable product, not a brand-new team still searching for its shape, and applying it uniformly can slow a new initiative down for no benefit the heavyweight process was actually designed to provide.

Invisibility and Disconnection, again — but here it’s disconnection, not invisibility, that does the damage. Where multiple teams exist at enterprise scale, each making a reasonable layer-four call about their own scope, the failure isn’t that the calls were wrong. It’s that none of the teams making them knew the other calls were being made. Amazon’s response to exactly this failure is one of the more explicit pieces of organizational engineering on record: a mandate that all teams expose their data and functionality only through service interfaces, with no other form of interprocess communication allowed.

The widely cited two-pizza team sizing was secondary to this. The actual countermeasure was the interface mandate itself — a structural rule built specifically to prevent disconnection between teams that each had legitimate, independent ownership of their own slice of the stack. Stripe’s own scaling guide names the underlying shift in plainer terms: what works for fifty engineers may not work for ten or a thousand.

Layer 5: People & Talent

This is where several of the tensions above converge. Resource asymmetry shapes who an organization can hire. Process affordability shapes how much governance it can run. Risk appetite shapes how much it’s willing to delegate before the consequences of delegating are fully understood. All three meet here, in decisions about who gets hired, where institutional knowledge ends up living, and how readily the organization can adopt AI without losing the judgment AI is meant to assist.

Resource Asymmetry and Risk Appetite, as in Layers 2 and 1, but together here. A startup’s hiring is opportunistic by necessity — generalists who can cover multiple roles, because there’s no budget for narrow specialists and no headcount to spare for a dedicated governance function. Decisions about how much engineering work to delegate to AI agents, and who’s accountable when that output fails, get made ad hoc by whoever’s closest to the work, because there’s no one available to own the question as a distinct layer-five responsibility, exactly as the first post described.

An enterprise can typically afford what the startup can’t: specialist hires, a dedicated AI governance committee, formal learning and development paths. But the existing machinery built for that resource advantage — leveling frameworks, compensation bands, hiring pipelines tuned for stable, well-understood roles — frequently doesn’t fit what a new, fast-moving initiative inside the enterprise actually needs. The enterprise has more resources at this layer and a real risk of misapplying them: importing a hiring and governance model built for a mature, low-risk product onto a team that needs to move and adapt the way a startup team would.

Organizational Memory. A related but separate question is where an organization’s knowledge actually lives, and the two contexts answer it almost opposite ways.

In a startup, knowledge lives in people, because there’s been no time and no spare capacity to put it anywhere else — why a decision was made, what was tried and abandoned, what a particular piece of the system actually does under load, all of it sits in the heads of whoever was there when it happened. This is efficient until it isn’t: a startup can lose a single engineer and lose a meaningful fraction of its institutional context in the same afternoon, because nothing was written down to survive their departure.

An enterprise’s knowledge lives in systems instead — documentation, onboarding material, architecture decision records, the formal processes the first post described as a layer-two artifact. Amazon’s own writing culture is an explicit, designed version of this: the six-page narrative memo required before any major decision exists specifically so the reasoning survives independent of whoever wrote it, and Amazon’s own account of why the practice works is direct about the goal — a good process doesn’t depend on a single scarce individual, and has a feedback loop built in regardless of who’s in the room. An enterprise can usually absorb the loss of any single person without losing the knowledge that person carried. The tradeoff is that building and maintaining those systems is itself a real cost, paid continuously, that a startup’s leaner approach simply doesn’t carry — until the day it needs to, and discovers the cost was deferred rather than avoided.

Adoption Friction versus Investment Capacity. AI adoption splits this layer in a direction that inverts the resource asymmetry rather than repeating it. A startup adopts AI tooling easily — no legacy process to reconcile it with, no governance committee to route through — but can’t invest deeply: no budget for a platform to manage agent output at scale, no spare time to build the fitness functions and guardrails the second post described as the real cost of adoption done well. It gets the easy half and has to skip the expensive half. An enterprise has the opposite problem: it can fund the expensive half outright — custom tooling, a staffed governance function, the observability investment that keeps AI-generated code traceable — but every new workflow still has to clear a security review and an approval chain sized for human-authored commits. This is the same process affordability advantage from layer four working against the enterprise rather than for it: the muscle that makes heavyweight process cheap to deploy also makes it expensive to bypass, even when bypassing it is exactly what fast AI adoption needs. Neither path is wrong — a startup’s fast, shallow adoption and an enterprise’s slow, deep one are both rational responses to what each can actually afford to do well.

The Supervision Paradox. The second post named this directly: the skills required to supervise what an agent produces are the same skills delegating to the agent erodes, making unmanaged delegation a one-way ratchet. The mechanism is identical in both contexts; only the clock differs. A startup’s small team delegates heavily from day one because there’s no spare headcount not to, and because the team is small, the erosion concentrates in very few people — the organization’s entire supervisory capacity can thin out within one team’s tenure, with no bench to fall back on. An enterprise has that bench, but trades it for the pipeline problem the second post raised: the entry-level work that used to build supervisory judgment is exactly the work AI now does fastest, and a large organization can run that substitution for years before the gap is visible, because enough senior engineers can still catch agent errors that nobody notices the layer beneath them isn’t being trained the same way. The startup’s version of the paradox is fast and visible. The enterprise’s is slow, and doesn’t surface until the engineers who can still catch a mistake leave faster than they can be replaced.

Layer 6: Infrastructure

The same resource gap that shapes who an organization can hire shapes what it can build on.

Resource Asymmetry, as in Layer 2 — and this is the layer where it’s most durable and least disputable. A startup provisions everything from scratch on commodity cloud, under real cost sensitivity, fragile under any load pattern nobody anticipated — not from carelessness, but because there’s no existing investment to inherit and no slack to over-provision against uncertainty. An enterprise building something new inherits infrastructure maturity for free: cloud commitments and the negotiating leverage that comes with them, an existing security and compliance posture, and — the clearest instance of this inheritance — observability. A failure in a brand-new enterprise product can often be traced with the same maturity as a failure in a ten-year-old one, because tracing infrastructure doesn’t care how old the product is, while a startup’s first real production failure is frequently also the first time anyone learns what the system does under load, debugged live with a customer watching. This is the enterprise equivalent of the layer-six economics the first post described in Dropbox’s decision to own its storage infrastructure once the cost curve justified it: a new enterprise initiative starts much further along that curve than a startup ever can.

The risk runs in two directions, both familiar by now. The platform team that owns the inherited infrastructure optimizes for cost and standardization while the product team optimizes for delivery speed, and the two can work against each other even in good faith. And the inheritance itself is tuned to the failure modes of the enterprise’s existing, mature systems — a genuinely new kind of product, with unusual load patterns or a different architecture, can fall into gaps the inherited stack was never built to see. The advantage is real. It isn’t automatically the right advantage for what’s actually being built on top of it.

What Infrastructure Makes Thinkable. There’s a second, deeper claim hiding underneath Resource Asymmetry. The point above was about who has more infrastructure right now. This one is about something infrastructure does that has nothing to do with quantity: it determines which architectures are available to choose from at all, and that availability changes over time, in both directions.

Neal Ford’s evolutionary architecture work makes the forward-pointing version of this directly: architects working before containerization existed couldn’t have built today’s default microservices patterns no matter how skilled they were, because the infrastructure those patterns depend on simply wasn’t there yet — the patterns weren’t undiscovered, they were unbuildable. A startup founded this year inherits that maturity for free. An enterprise’s core platform, built at an earlier point on the same curve, may still be carrying the constraints of whatever year it was actually built, unless it’s been actively modernized since.

The same idea runs in the other direction too, and Amazon’s own infrastructure has supplied the clearest recent illustration of it. Prime Video’s video quality monitoring team had built its system as a distributed, serverless set of microservices — the architecturally fashionable choice and, at the scale they started at, a reasonable one. As the service scaled to monitor thousands of streams simultaneously, the architecture’s own coordination overhead became the cost, not the actual analysis work. Moving the service to a monolith cut infrastructure cost by over ninety percent and increased scaling capacity at the same time — not because microservices are wrong, but because the architecture correct at the scale Prime Video started at stopped being correct at the scale it grew into, and nobody had revisited the choice until the cost made it impossible to ignore. Prime Video didn’t abandon microservices as a whole; one service was refactored because it was the better fit for what that service had become. The lesson isn’t that monoliths outperform microservices, any more than the earlier point was the reverse. Architectural decisions are conditional on scale, workload shape, and infrastructure economics — and all three change, in both directions, which is what the diagram above and Prime Video’s experience are each describing from opposite ends.

Layer 7: Developer Productivity

The infrastructure question has a close cousin one layer up: what an organization can build on shapes what its own engineers build with.

Process Affordability and Resource Asymmetry, as in Layers 4 and 2, pulling in opposite directions here. A startup’s tooling is whatever’s free and fast to adopt — there’s no capacity to invest in anything custom, so the developer experience is whatever the default setup provides, rarely a deliberate choice so much as the absence of one. An enterprise can lean on existing CI/CD, existing internal developer platforms, tooling investment built over years — a real advantage, but only when it actually fits the new initiative’s architecture the way the first post’s Google example required.

Local versus Global Optimization. The deeper reason that fit is so easy to get wrong is structural, not just a matter of checking carefully. A startup’s tooling decision optimizes for exactly one team — there’s only one team to optimize for, so the fastest available solution for that team is, by definition, the right answer. An enterprise’s platform team is solving a different problem entirely: not what’s fastest for any single team, but what’s good enough across dozens or hundreds of teams with different needs, none of which can be fully served by a solution tuned to any one of them. The heavyweight pipeline that feels like unnecessary friction to a new, fast-moving team isn’t usually a failure to optimize. It’s evidence of an optimization that was never aimed at that team specifically — a platform built to be tolerable everywhere rather than excellent anywhere, which is the correct objective at that scale and the wrong fit for a team that’s still small enough to be optimized for directly. The investment is real and well-funded either way. Whether it serves the team using it depends on whether anyone recognized which kind of optimization the team actually needed before applying the other one.

The Transition

The tensions above don’t resolve gradually as a company grows. There’s a specific stretch where a company is too big for the tradeoffs that made sense as a startup and not yet positioned to draw on the advantages that make sense as an enterprise — and that stretch is the hardest part of the journey, for a structural reason worth naming directly.

The startup-rational tradeoffs — ship fast, skip the architecture review, treat the first version as disposable, keep process light because there’s no one to run it — stop being rational the moment the constraints that justified them change. Reputational exposure grows as the customer base grows. The cost of a production incident rises as revenue starts depending on uptime. The capital clock that made speed worth more than durability stops being the most urgent constraint once there’s a real, paying customer base to protect. A company can cross this line without anyone deciding to.

But the enterprise-rational advantages — existing infrastructure to lean on, existing process muscle to deploy cheaply, existing specialist talent to hire — usually aren’t available yet either. The infrastructure hasn’t been built. The process functions don’t exist. The talent pipeline hasn’t been established. A company in this stretch is carrying enterprise-sized exposure with startup-sized resources, which is precisely the gap that produces the costliest version of every failure described above: the public outage that costs a renewal, the runway burned on process the team didn’t need yet, the throwaway build shipped under a reputation the company can no longer afford to risk.

It’s worth being honest about how long this stretch actually lasts. The framing so far — startup, then transition, then enterprise — makes it sound like a brief crossing. It isn’t, for most organizations that experience it. A scale-up with a few hundred people, a fast-growing product company, a regional fintech with real customers and real revenue but nothing like an enterprise’s inherited infrastructure or process muscle: for companies like these, the transitional condition isn’t a phase to get through. It’s the operating environment, for years, possibly for the company’s entire life if it never reaches the scale where the enterprise-side advantages actually arrive. The seven layers and the tensions running through them apply just as much here as at either extreme — arguably more, since this is the zone where the cost of getting the calibration wrong is highest.

Stripe’s own framing of this point holds for the whole stack, not just engineering organization: accept that nearly everything set up today will stop working at some point, so design for flexibility, not perfection. The tradeoffs that got a company here were not wrong. They were scoped to a set of constraints the company has since outgrown, while the constraints that would justify the next set of tradeoffs haven’t fully arrived.

The Collapse Pattern, Revisited

The first post described three breakdown patterns common to any organization: strategic decisions masquerading as technical ones, technical decisions resolved at the wrong layer, and layer collapse under delivery pressure. A fourth pattern is specific to context, and it has two mirror-image forms.

Borrowing the wrong context’s tradeoff. Neither failure here is a failure of execution. Both are a failure to notice that the tradeoff being applied was calibrated to a different set of constraints than the ones actually in play.

The visibility failures, still real, now correctly sized as one pattern among several rather than the whole story. The unstacked startup, where all seven layers are being decided invisibly by one or two people’s intuition, which works until the company outgrows what that intuition can personally span. The stacked-but-silent enterprise, where every layer has an owner making individually defensible calls, and the coordination cost of those calls never being compared is the kind of silo-driven inefficiency several research firms have separately estimated at somewhere in the range of a fifth to a third of total organizational capacity¹ — directionally consistent across sources even where the precise figure isn’t, and large enough that it rarely traces back to any single decision that was wrong.

Both forms of the fourth pattern share the same root: a company that cannot explain, after the fact, why it ended up where it did — not because no one was deciding, and not because the decisions were bad, but because the decisions were each correct against a frame that nobody checked against the company’s actual, current constraints.

One honest caveat belongs here. This post has argued, layer after layer, that startup and enterprise tradeoffs are each rational against their own constraints — and that framing does real work, but it isn’t a license to assume every decision is secretly optimal once you squint at it the right way. Constraints explain a great deal. They don’t excuse all of it. Founders stay attached to a call past the point it stopped serving them. Executives protect a structure for political reasons that have nothing to do with the constraints that originally justified it. Enterprises accumulate process nobody actually needs anymore and keep running it because removing it is its own kind of organizational labor nobody wants to spend. The diagnostic in this post is for telling apart a decision that’s correct for its context from one that’s wrong for any context — not for assuming the first category is the only one that exists.

Using the Stack Across Contexts

The first post’s diagnostic — for any significant decision, ask what layer it actually lives in, and whether it’s being evaluated at that layer — still applies without modification. What this post adds is a question that has to come before it, and the question is the same one at every layer: what do our actual constraints allow and require here, and is the tradeoff I’m reaching for one that was correct in a different context?

A startup CTO reaching for an enterprise’s rigor, and an enterprise CTO reaching for a startup’s speed, are making the same mistake in opposite directions: solving for a set of constraints they don’t actually have. The seven layers don’t change. What changes, predictably, is the answer each layer should give — and the CTO whose answer comes from the last company rather than this one will find a way to be wrong even while doing everything right.

“Startup” and “enterprise” have been the names used throughout this post, because they’re the names most CTOs already use for the two ends of this range. But the actual mechanism was never about which label applies. It’s that a given constraint — low reputational exposure, a runway clock, an inherited platform, an established process function — produces a given answer, regardless of what the company calls itself. A two-hundred-person scale-up with enterprise-grade reputational exposure and startup-grade resources is not a confusing edge case for this model. It’s the model working exactly as described, for an organization that happens to sit in the middle of the range rather than at either end.

Sources

Martin Fowler, sacrificial architecture — the concept of deliberately building a first version with the explicit intention of discarding it once it has served its purpose. martinfowler.com

Neal Ford, Rebecca Parsons, and Patrick Kua, evolutionary architecture — the framework for guided, incremental architectural change verified against fitness functions, including the argument that infrastructure availability (such as containerization) determines which architectural patterns are buildable at a given point in time. Building Evolutionary Architectures (O’Reilly).

Stripe’s engineering scaling guide — including the framing that practices suited to fifty engineers may not suit ten or a thousand, and the caution against building out an engineering organization faster than it can absorb. stripe.com/guides/atlas/scaling-eng

Amazon’s service interface mandate — the internal directive attributed to Jeff Bezos, requiring all teams to expose functionality only through service interfaces with no other form of interprocess communication allowed. The original 2011 internal Google memo by Steve Yegge that brought this account public was later taken down; it is preserved at multiple archival mirrors, including this course-hosted copy and this archived gist.

Amazon Prime Video, Video Quality Analysis architecture — the team’s move from a distributed serverless microservices orchestration to a monolith, reducing infrastructure cost by over 90 percent and increasing scaling capacity. The original article on primevideotech.com has since been taken down; the full text is preserved in this archived PDF.

Amazon’s Working Backwards process — the six-page narrative memo and PR/FAQ practice designed so that institutional reasoning survives independent of any single person, described in Colin Bryar and Bill Carr, Working Backwards: Insights, Stories, and Secrets from Inside Amazon (St. Martin’s Press, 2021). An excerpt describing the process in Amazon’s own words is published at aboutamazon.com.

Spotify’s Backstage — the internal developer portal originally built to solve Spotify’s own service-discovery problem, later open-sourced and donated to the Cloud Native Computing Foundation. backstage.io and Spotify Engineering

Dropbox’s Magic Pocket migration — the move of roughly 90 percent of Dropbox’s stored data off Amazon S3 onto self-built infrastructure between 2015 and 2016, disclosed in Dropbox’s 2018 S-1 filing as saving approximately $75 million in operating costs over the following two years. Reported in Data Center Knowledge and discussed, without external citation, in the first post of this series, The CTO Decision Stack.

Google’s internal developer tooling (Blaze/Bazel, Critique, Piper) is discussed at length, without external citation, in the first post of this series, The CTO Decision Stack.

Ali Ahmed Thawerani writes about the systems, culture, and scale decisions that shape how technology organisations develop. TECTONICS publishes at aathawerani.github.io.

Estimates of silo-driven coordination loss vary by source and methodology, but several independent estimates land in a similar band. McKinsey’s State of Organizations 2026 and related operations research describe fragmented, cross-functional friction as consuming a substantial share of productive capacity (McKinsey & Company). A cross-source synthesis citing McKinsey, Bain, PwC, Gartner, and Okta research puts the figure at roughly 20–30 percent of operating expenditure lost annually to rework, miscommunication, and fragmented processes (Crebos). ↩

AI Across the CTO Decision Stack

Sun, 14 Jun 2026 00:00:00 +0000

AI is not a layer-seven tool. It is a force that changes the cost structure, the failure modes, and the governance requirements of all seven layers at once — and most organizations are only managing it at the layer where it first became visible.

The CTO Decision Stack is a seven-layer model for evaluating technology decisions — from corporate strategy down through product architecture, technology delivery, engineering organization, people and talent, infrastructure, and developer productivity tooling. The CTO Decision Stack introduced the stack itself and The Cognitive Load Ceiling introduced the ceiling that runs through it: the idea that every major architectural shift in software history was, underneath its specific vocabulary, an attempt to keep a system within the cognitive reach of the team responsible for it — and that the ceiling doesn’t disappear when the architecture changes, it moves.

The previous post closed with a line that was a setup for this one, not a conclusion: AI does not belong to a single layer of the stack. This post takes that seriously, layer by layer — not by asking “how is AI used here,” which is the question that keeps the analysis trapped at layer seven, but by asking a sharper one: what does AI change about the criteria this layer is evaluated against, and what happens to the layers above and below when that change goes unacknowledged?

There is a reason this question is hard to answer cleanly, and it is worth naming up front. Three things are true simultaneously, and most discussions of AI in engineering organizations collapse them into one.

First, AI has genuinely lowered the cost of certain kinds of work — implementation, boilerplate, first-draft architecture, test scaffolding, migration scripting. This is real and should not be argued away.

Second, AI has not lowered the cost of understanding — and a meaningful fraction of what each layer of the stack actually does is understanding: understanding what the business needs, understanding what the architecture must absorb, understanding what the team can support, understanding who is accountable when something fails.

Third — and this is the part that gets lost — the gap between these two costs is itself the new variable the stack has to account for. When implementation gets cheap and understanding doesn’t, the gap between “how fast we can produce something” and “how well we understand what we produced” widens. That gap doesn’t sit quietly at one layer. It propagates — usually upward, usually invisibly, and usually on a delay long enough that by the time it’s visible, it looks like an unrelated problem.

Two ideas recur throughout the seven layers below, in different forms each time. One is this gap itself — between the cost of acting and the cost of understanding what was done. The other is a sharper version of it specific to people: the engineering skills required to supervise what an AI agent produces are the same skills that delegating to the agent erodes — a one-way ratchet unless something deliberately works against it. Neither idea is entirely new in isolation. What’s new is that AI causes both to operate simultaneously across every layer of the stack, rather than in isolated pockets.

This is, in other words, the cognitive load ceiling argument from earlier in this series, applied across the whole stack rather than just to architecture. The ceiling didn’t disappear when AI arrived. It moved — and at every layer of the stack, it moved to a different place, for a different reason, on a different timeline. Mapping where it moved, layer by layer, is the actual content of this post.

Layer 1: Corporate & Business Strategy

What AI changes: the half-life of the technology SWOT, and the assumptions a layer-one strategy is allowed to treat as stable.

“The CTO Decision Stack” described the technology SWOT as the tool that surfaces what the business view of strategy cannot see on its own. The implicit assumption behind that tool — behind any SWOT — is that the four quadrants change slowly enough that a periodic review is sufficient. Annually, perhaps semi-annually for a fast-moving company. That assumption was already under strain before AI. AI breaks it more directly, because the rate of change in at least one quadrant — opportunities and threats arising from what AI-assisted teams can now build — is no longer compatible with an annual cadence.

This isn’t a claim that strategy itself needs to move faster, which is a different and more dangerous idea — chasing a moving target by moving faster than it is a losing game, and that post was right that strategic decisions are defined by irreversibility, not speed. The claim is narrower: the inputs to the strategic review need to be refreshed more often than the strategic decisions themselves, so that when a layer-one decision is made, it’s made against a current picture rather than a stale one that happens to still be sitting in last year’s SWOT document.

There’s a second-order effect here that connects to a pattern The Inevitable Cycles described: the cycle by which yesterday’s differentiator becomes today’s commodity and tomorrow’s table stakes. Software houses go through this with delivery models — bespoke work becomes product, product becomes commodity, and the cycle restarts with a new layer of differentiation built on top of what’s now commodity. AI is compressing that cycle specifically for implementation capability. A custom integration, a bespoke internal tool, a differentiated workflow — categories of work that used to take a specialized team and represent real capability — are moving toward “anyone with AI assistance can build this” faster than the cycle previously ran. The layer-one question this raises isn’t “is our moat eroding” in the abstract. It’s: which of our current technology strengths are actually entries in last cycle’s SWOT that haven’t been re-evaluated against this cycle’s baseline of what’s now commodity-buildable?

The honest version of this for most organizations is uncomfortable: a capability that was a layer-one strength two years ago — “we have a team that can build X reliably, and most competitors don’t” — may now describe a capability that a much smaller team, AI-assisted, can approximate. Not replicate exactly, not match in depth, but approximate closely enough that the strategic value of the original capability has shifted from “we can do this and others can’t” to “we can do this well and others can do it adequately” — which is a different competitive position requiring a different strategy, even if nothing about the capability itself has changed.

There’s a second strategic shift worth naming separately, because it isn’t about the SWOT at all — it’s about a posture that wasn’t really credible before and now is. If a future rewrite is cheap enough, an organization can rationally choose, at layer one, to under-invest in architecture deliberately: ship the disposable version now, optimize for time-to-market, and treat the eventual rebuild as a planned cost rather than a risk to be designed against. This is a layer-one decision in the fullest sense — it’s about risk appetite and competitive timing, not implementation detail — and AI genuinely makes it more viable than it used to be, in the same way Martin Fowler’s sacrificial architecture made deliberate, planned disposability a respectable engineering posture rather than a failure to plan ahead.

The risk is not in choosing this posture. The risk is in choosing it at layer one and never saying so explicitly to the layers below. Fowler’s own version of the idea is careful on exactly this point: a sacrificial architecture still depends on modularity, so that what gets discarded is bounded and the discarding is graceful rather than wholesale. A layer-one decision to optimize for speed over durability is only as good as the layer-two decision that follows it about where the seams are — which kind of disposability this is, and what’s allowed to be thrown away versus what has to survive the sacrifice. Made well, “we are deliberately building something sacrificial” is a legitimate strategic bet. Left implicit, it becomes indistinguishable from simply not deciding — and by the time it’s visible, it looks exactly like the architecture-by-reaction failure described at layer two below, except now it started one layer higher, as a choice nobody framed as one.

Layer 2: Product Architecture

What AI changes: the relationship between architectural decisions and the cognitive load ceiling that those decisions were always implicitly managing — and the timeline on which that ceiling is reached.

This series has argued at length that every major architectural shift in the industry’s history — monoliths to microservices, layered architecture to Clean Architecture, ad hoc structure to DDD — was, underneath its specific vocabulary, a cognitive load management strategy. The architecture didn’t fail technically. It failed because the system outgrew the team’s collective ability to hold it in their heads, and the next architecture redistributed that load rather than eliminating it.

Layer two, in the first post’s framing, is about designing for tomorrow’s changes rather than today’s requirements — making bets about which capabilities the product will need and how the system should be structured to absorb them. What AI adds to this is a second axis of “absorb”: not just whether the architecture can absorb product change, but whether it can absorb the rate of code generation that AI-assisted teams now produce, without the comprehension gap between what exists and what the team understands widening faster than the architecture’s natural seams can contain it.

This is the architecture by reaction pattern described in Why Architecture Is Shifting From Diagrams to Guardrails, and it is worth being precise about what it is and isn’t, because the precision matters. Neal Ford’s evolutionary architecture — guided, incremental change, with fitness functions checking each change against the architectural characteristics that matter — is the disciplined version of a system that changes constantly. Architecture by reaction is what’s left when the guidance is missing: AI addresses the problem directly in front of it at each stage — decomposing when scale demands it, introducing caching when latency demands it, reintroducing shared state when consistency demands it — without reference to why an earlier architectural decision moved away from the pattern it’s now reintroducing. Each step is locally correct. The sequence regresses. It is, in other words, the failure mode evolutionary architecture exists to prevent — change without the fitness function that would have caught the regression — not a competing idea to Ford’s, and the credit for naming the cure belongs with him.

The practical implication is one Why Architecture Is Shifting From Diagrams to Guardrails has already named at the tooling layer — Architecture Decision Records, written so that the rejected options and their rationale are preserved, not just the decision taken. What’s worth stating at layer two specifically is that this is now a layer-two artifact, not a layer-seven one. An ADR that explains why a product architecture rejected shared state at a particular boundary is not documentation of a tooling decision. It’s the institutional memory that, paired with an actual fitness function checking for the regression, determines whether the architecture’s seams hold under AI-accelerated iteration or get quietly eroded one locally-correct change at a time.

There’s a further wrinkle specific to AI that the cognitive-load framing makes visible. AI-generated code is, by the nature of how these models are trained, locally coherent but globally undisciplined — any individual function or module looks reasonable, but the system-level properties that make an architecture an architecture (consistent dependency direction, enforced boundaries, the seams that make future decomposition possible) are not what the generation process is optimizing for. This means the layer-two question — where are the natural seams, and are the architectural boundaries aligned with them — now has a maintenance dimension it didn’t have before. The seams don’t just need to be designed. They need a fitness function checking them, in Ford’s sense — an automated, ongoing test of the architectural characteristic that matters, not a one-time review — somewhere AI-assisted generation will encounter it as a constraint, or the seams will erode at the rate AI generates code that doesn’t know they’re there.

The layer-two question, updated: are our architectural seams documented as intent, or encoded as constraints — and if generation outpaces the gap between those two, which one actually governs what gets built?

Layer 3: Technology Delivery

What AI changes: the answer to the question this layer has always asked — can we actually deliver this, on what timeline, with what team, and once it’s in production can we support it and explain it when it breaks — for two distinct decisions that both live here: which stack to build with, and whether to build at all.

Tech Stack Selection in the Age of AI Agents already covered the first in depth: AI coding capability is ecosystem-relative, calibrated to training data density rather than uniform across stacks, which makes stack choice an implicit choice about AI partner quality as much as a technical one — Python and TypeScript sit in the high-confidence core, with AI assistance shifting from asset toward liability the further a stack sits from it. That post also introduced the build-only-the-USP principle and the one-interface-file discipline for every external dependency. What’s worth adding here is that build-vs-buy is the same layer-three question as stack selection, asked one level up — both are ultimately asking who is going to own the operational reality of this thing once it exists, and AI distorts the answer to both in the same direction.

The naive read on build-vs-buy is that AI makes building cheaper, so the calculus should shift toward build. This is true for exactly one category — the core differentiated logic that is the actual reason the product exists, what’s sometimes called the USP. For everything else — the cross-cutting concerns every product has regardless of differentiation, and the domain-specific commodity services that exist because the problem is common enough that mature solutions already do it better than a bespoke build would — AI assistance doesn’t change the calculus much, because the comparison was never “can we build this” but “should the organization carry the operational burden of something that isn’t its differentiation.”

What AI does change is how visible the difference is at decision time. A build decision for something that should have been bought will, with AI assistance, look like it’s going well during implementation — the first version comes together fast, the demo works, the timeline looks favorable. The support burden — the part of the lifecycle layer three actually cares about, the “when something breaks at 2am” question the first post used as its litmus test — is largely unaffected by how fast the implementation phase went. AI has made the part of the build-vs-buy decision that’s visible at decision time less correlated with the part that determines whether the decision was right — exactly the same distortion happening to stack selection, where a fast first version in an AI-illegible stack can look like a good choice for months before the support burden becomes visible.

This connects to the structural discipline that post named explicitly: every external dependency — bought or built — should sit behind one interface file. Not as a tooling best practice, but as a layer-three risk management decision. If a build decision turns out to be wrong, the cost of reversing it is bounded by how many places in the codebase assumed the build’s specific shape. AI accelerates how fast those assumptions can spread through a codebase if they aren’t contained at a seam from day one — which means the cost of a wrong build-vs-buy decision is now growing faster than it used to, even as the cost of making the decision (in implementation time) has shrunk.

The layer-three question, updated: for this decision — stack or build-vs-buy — is the implementation-time estimate we’re using actually informed by AI’s effect on implementation, or has it quietly become our estimate for the whole lifecycle, including the support burden AI doesn’t meaningfully accelerate?

Layer 4: Engineering Organization

What AI changes: Conway’s Law gets a term in the equation it didn’t have before, and the implication runs in a direction most organizations aren’t expecting.

Conway’s Law says systems mirror the communication structure of the organizations that build them. The Cognitive Load Ceiling extended this directly: when a significant portion of a codebase is generated by AI operating without deep organizational context, the system stops mirroring the team responsible for it and starts mirroring something else — the statistical average of the training corpus, shaped by whatever architectural intent was actually encoded in the prompts and context at generation time. If that intent was thin, the system mirrors nothing coherent at all — not the team, not the corpus average, just an accumulation of locally-reasonable decisions with no consistent referent.

At layer four, this has a specific consequence for how ownership is assigned. “The CTO Decision Stack” described Amazon’s two-pizza team rule as fundamentally about ownership, not size — a team small enough to fully own a component, understand its behavior under load, and make architectural decisions about it without coordination overhead. That model assumes the component’s behavior is something the team’s collective understanding actually covers. If a meaningful share of a component was generated by AI working from context the team didn’t fully specify — and AI-generated code, per that post, defaults to locally coherent but globally undisciplined patterns absent explicit architectural guardrails — then “the team owns this component” can become true in the org chart while becoming false in practice: the team is accountable for a system whose actual structure reflects decisions nobody on the team made deliberately.

This is not a hypothetical drift. It’s the mechanism behind a pattern that’s become familiar fast: a component that “the team owns” but that, in practice, only two people on the team will touch — because those two people are the ones who’ve built up, through repeated exposure, an understanding of what the AI-generated parts of the system actually do that the rest of the team doesn’t have. The org chart says shared ownership. The reality is a knowledge bottleneck that looks like ownership until someone tries to make a change and discovers it isn’t.

The countermeasure isn’t “review AI output more” — that’s a layer-seven response to a layer-four problem, and it doesn’t scale: a team of five with AI assistance can generate the volume that used to require twenty, but still has five engineers’ worth of review capacity. The real countermeasure is encoding the architectural intent that would otherwise have circulated informally — the “we tried that and it didn’t work” knowledge a co-located team normally shares through hallway conversation — into specifications, fitness functions, and ADRs with their rejected-options sections intact. Why Architecture Is Shifting From Diagrams to Guardrails described this shift at the architecture layer as keeping the architecture coherent. At layer four, the same shift is what keeps ownership real: it’s the difference between the org chart saying a team owns something and the team’s actual collective understanding being verifiable rather than concentrated in whichever two people happen to remember.

The layer-four question: for the components our team structure says we own, is our collective understanding of those components something we could demonstrate — or does it currently live in the heads of whichever two people have been closest to the AI-generated parts?

Layer 5: People & Talent

What AI changes: this is the layer “The CTO Decision Stack” identified as carrying the hardest open question — governance of the human-AI boundary, currently being decided ad hoc at layer seven by individual engineers, when it’s a layer-five decision about composition, accountability, and quality control. A year on, the shape of that gap is clearer, and it has a name from outside this series that Why Architecture Is Shifting From Diagrams to Guardrails brought in: the supervision paradox, first named by Lars Faye.

The supervision paradox, in its sharpest form: the engineering skills required to supervise what an AI agent produces are the same skills that delegating to the agent erodes. The more you delegate, the less capable you become of catching what’s wrong — and the more you need that capability, precisely because more is being generated that could be wrong. This isn’t an argument against delegation. It’s an argument that delegation without a deliberate plan for where supervisory capability is maintained is a one-way ratchet — and layer five is where that plan either exists or doesn’t.

That post framed the layer-five development question as a skills shift: from implementation fluency toward specification precision, from code authorship toward architectural judgment, from debugging toward critical evaluation of agent output. What’s worth adding is how that shift actually has to happen, because it doesn’t happen by osmosis, and the obvious mechanisms for developing it are exactly the ones AI adoption tends to remove first.

Specification precision, architectural judgment, and critical evaluation of agent output are not abstract competencies. They’re built the way they’ve always been built — by doing the work, getting it wrong in ways that have consequences, and developing judgment from the gap between what you expected and what happened. The supervision paradox bites here specifically: if the most accessible entry-level work — the work junior engineers traditionally used to build these competencies — is now the work AI does fastest and most reliably, the organization has a pipeline problem it didn’t have before. Not “junior engineers are less necessary” — the opposite. The work that used to train the judgment senior engineers now need to supervise AI is disappearing from the pipeline at the exact moment that judgment is becoming more valuable.

This reframes the layer-five governance question. It’s not just “who is accountable when agent output fails” — though that question, as that post noted, remains formally unanswered in most organizations and shows up as informal gatekeeping by whoever happens to be willing to push back hardest. It’s also: where, in this organization, is the next generation of people who can do that pushing back actually being developed — given that the traditional development path runs through exactly the work AI is now absorbing?

There’s a connected governance question that Why Architecture Is Shifting From Diagrams to Guardrails makes concrete rather than abstract. That post described SpecOps — specification authoring as a first-class engineering surface, with the architect’s primary responsibility shifting from designing systems directly to authoring the governance system that constrains AI generation: specifications precise enough to function as constraints, ADRs with rejected-options sections, fitness functions that enforce boundaries. That’s a layer-two and layer-six activity in terms of what it produces. But who does it and how they’re developed is squarely layer five. An organization that has quietly let its senior engineers become full-time governance-system authors, while its junior engineers do AI-supervised implementation with no path toward governance-system authorship themselves, has made a layer-five decision about its future capability — almost certainly without recognizing it as one.

The layer-five question, in full: if something agent-generated fails in production tomorrow, who is accountable — and separately, five years from now, who in this organization will have the judgment to have caught it, given how they’re being developed today?

Layer 6: Infrastructure

What AI changes: the same cost-curve question The Inevitable Cycles described for cloud infrastructure, now playing out in real budget data — and a new category of infrastructure decision that didn’t exist before.

That first post’s layer-six example was the cloud-versus-self-hosted crossover: a managed service that’s negligible at small scale becomes “quietly expensive” as usage grows, until the economics of owning the infrastructure outright start to beat the economics of renting it. The same crossover is now visible one level up, in how organizations are reallocating software budgets entirely. YipitData’s March 2026 SaaS Scoreboard tracked this directly: among large AI spenders, tools like Canva, Replit, and Vercel saw year-over-year spend increases of 70–100%, driven by AI-powered features and platform expansion, while several established hosted tools in the same portfolios — Asana, Twilio, Atlassian — saw spend fall by 20–45% over the same period, as teams reallocated budget toward the newer capabilities.¹ The pattern isn’t simply “buy less of the old tool, buy more AI.” It’s two things happening at once: budget reallocating away from some hosted tools toward AI-native ones, and the hosted tools that survive doing so by becoming AI-plus-hosted hybrids, with usage-based AI credits layered on top of the seat-based subscription that used to be the whole bill.

This is that first post’s cost-curve question, but the curve being evaluated has changed shape. It used to be a clean two-sided comparison — managed service versus self-hosted. It is now a three-way calculation: keep the hosted tool as-is, pay for the AI-upgraded version of the same hosted tool, or replace it with an AI-native alternative entirely — and the cost structure of all three is shifting underneath the decision faster than annual procurement cycles are built to track, because AI credits are usage-based in a way seat licenses never were. Tech Stack Selection in the Age of AI Agents named the practical discipline that keeps any vendor crossover survivable regardless of which side of it an organization lands on: every managed service behind one interface file, so the eventual migration — hosted to AI-native, or seat-based to usage-based — is bounded to a single seam rather than a system-wide rewrite. That discipline was written for cloud services. It applies with at least equal force to whatever tool category is currently absorbing the AI-budget reallocation, because the same crossover, on a faster clock, is happening there too.

That cost-curve shape is itself an instance of something broader The Inevitable Cycles documented across infrastructure, delivery models, process, and architecture: every previous cycle eventually discovered the governance it had been deferring. A phase that’s cheap and pragmatic at small scale generates its own cost or complexity as it scales, and the response is some form of governance — infrastructure governance, process governance, boundary governance — that the cheap phase had been implicitly postponing. The specific triggers differed each time. The shape didn’t.

Every previous cycle eventually discovered the governance it had been deferring. AI appears to be entering the same phase.

AI-assisted development is in the early part of that arc, and it’s worth being precise about what “the same arc” means here — not a prediction that AI costs will spike the way cloud costs did, which is a narrower and more uncertain claim, but the broader and more observable one: a cheap, fast generation phase is producing a comprehension gap, the way cheap cloud produced a cost gap and lightweight process produced a coordination gap. Each of those gaps was eventually closed by governance — not by abandoning the cheap phase, but by adding the structure the cheap phase had been running without. There’s no reason to expect AI-assisted generation is exempt from that arc. The open question isn’t whether comprehension governance arrives, but how early an organization builds it relative to when the gap becomes expensive to close.

The second change at this layer is observability, and it connects directly to the institutional-memory argument from Why Architecture Is Shifting From Diagrams to Guardrails. That post made the case that production failures are specifications the system wrote for itself — evidence of behavior the design didn’t anticipate — and that the value of this evidence depends on being able to trace a failure back to its architectural cause, not just its immediate symptom. That tracing has always depended on a chain of why: why does this service call that one, why does this table have this column, why was this retry logic written this way. For human-authored code, that why exists somewhere — in a commit message, in someone’s memory, in an ADR if the team was disciplined. For AI-generated code, the why that existed at generation time was whatever was in the prompt and context — and unless that was captured, it doesn’t persist anywhere after the code is written. The code is the same either way. The traceability of the code is not.

This is the layer-six insight this framework specifically reveals: observability has always answered “what changed.” It now also has to answer “what reasoning was available when it changed” — and that can’t be reconstructed afterward by asking the person who made the change, if “the person” was an agent operating from context that no longer exists anywhere. A commit linked to a spec ID, an ADR ID, and a fitness function ID is traceable in the way the feedback loop Why Architecture Is Shifting From Diagrams to Guardrails described requires — production failure to architectural cause to updated specification. A commit that’s just a diff with an AI-generated description of what changed, with no link to why it was asked for, is the layer-six equivalent of a system with no seams: functional, untraceable, and accumulating a debt that won’t be visible until someone needs the why and finds it was never recorded. This is, in miniature, exactly the comprehension governance the arc above describes — the question is only whether it’s built before or after the gap it’s meant to close.

The layer-six question, in full: is our AI-versus-hosted-tool spend sitting behind a seam we could reverse in one place, or has it already spread into every workflow that assumed the current tool would stay the current tool — and separately, when we need to know not just what changed but what reasoning was available when it changed, does our infrastructure have an answer, or are we waiting for the gap to become expensive enough to force one?

Layer 7: Developer Productivity

What AI changes: the least, in terms of what this layer is for — “The CTO Decision Stack”’s framing, that developer productivity tooling exists to make the architecture legible to the people building it, not to make engineers faster as an end in itself, holds completely. What’s changed is that this is now the layer where the perpetual rewrite loop either starts or doesn’t.

The Cognitive Load Ceiling described that loop directly: AI accelerates code generation, comprehension debt accumulates faster than before, the system becomes unmaintainable sooner, a rewrite is initiated, AI accelerates the rewrite too, and the cycle restarts — each iteration faster and less understood than the last. The rewrite stops being a reset and becomes a treadmill. Crucially, that post argued this isn’t really about rewrites at all. It’s about whether the forcing function that used to make architectural discipline economically necessary still exists. Historically, the prohibitive cost of a rewrite was what compelled organizations to invest in the disciplines — modular boundaries, clean separation, domain alignment — that made rewrites unnecessary. As AI lowers that cost, the forcing function weakens, and with it the economic pressure to maintain the disciplines in the first place.

Layer seven is where this either gets caught or doesn’t, because layer seven is where the loop’s speed is set. A CI pipeline that only checks “does it build and pass tests” is optimizing for the thing AI has made cheap — fast iteration — without any check on the thing AI hasn’t made cheap, which is whether each iteration is making the system more or less comprehensible. A CI pipeline that includes fitness functions — the architecture-as-code constraints Why Architecture Is Shifting From Diagrams to Guardrails described, dependency rules that fail the build regardless of who or what generated the violating code — is the layer-seven mechanism that keeps the loop’s speed from outrunning the team’s ability to keep the system within reach.

This is the precise sense in which layer seven’s tooling decisions have layer-two and layer-six consequences that don’t stay at layer seven. A team that adopts AI coding assistance — a layer-seven decision, correctly evaluated as one — without also investing in the fitness functions and architectural constraints that would catch drift has made half of a decision. The half they made is visible immediately — faster PRs, quicker first drafts. The half they didn’t make is invisible until the comprehension gap it should have been closing has widened enough to surface as something else: the layer-four ownership bottleneck, the layer-six untraceable change, the layer-one strategic assumption that quietly stopped holding.

There is a version of cheap rewrites that isn’t the treadmill described above, and it’s worth distinguishing the two clearly. Martin Fowler’s sacrificial architecture — building something now on the explicit understanding that it will be deliberately discarded later, with the team that built it deciding when — is not the same thing as the perpetual rewrite loop, even though both involve rewriting and both are made more viable by AI. The difference is intent and modularity. A sacrificial architecture is planned: the team knows roughly what’s disposable, keeps the seams clean enough that the sacrifice can happen in pieces rather than wholesale, and treats the eventual rewrite as a milestone rather than an emergency. The perpetual rewrite loop is the same cheap-rewrite capability without that planning — full-system rewrites triggered by accumulated comprehension debt rather than a deliberate decision, each one as undisciplined as the system it replaces, because nothing about the rewrite itself enforces the modularity that would let the next sacrifice be partial instead of total. AI lowers the cost of both. Layer seven’s fitness functions are what determines which one an organization actually gets.

The layer-seven question, restated from that post’s framing but pointed specifically at this layer’s role in the loop: has adopting AI tooling here made our iteration loop faster without making our comprehension loop faster too — and if so, which one is currently setting the pace for the other?

The Collapse Pattern, Revisited

“The CTO Decision Stack” described three breakdown patterns: strategic decisions masquerading as technical ones, technical decisions resolved at the wrong layer, and layer collapse under delivery pressure. Looking across all seven layers above, a fourth pattern emerges that’s specific to AI — not a replacement for the first three, but a description of how AI tends to produce all three at once, through a single mechanism.

AI adoption decisions are made at layer seven, with layer-seven criteria, correctly — and then nothing else happens. The decision itself isn’t wrong; that first post was explicit that tooling decisions belong at the tooling layer. The failure is that adoption at layer seven creates open questions at every layer above it — does the technology SWOT still hold, do the architectural seams survive the new generation rate, does the build-vs-buy calculus actually shift or only appear to, does ownership still mean what the org chart says, does the governance model exist or is it de facto, can failures be traced to their causes, is the iteration loop outrunning the comprehension loop — and the layer-seven decision answers none of them, but gets treated as though it does, simply because it’s the decision that was actually made.

This is layer collapse running in a direction that post’s framing didn’t quite anticipate: not a strategic question answered with operational criteria, but an operational decision, correctly made, generating consequences that propagate upward through layers where the equivalent decision was never made at all. Six open questions, one closed one — and the gap between them is the same gap between acting and understanding that runs through this entire post.

Using the Stack for AI Decisions

The diagnostic from “The CTO Decision Stack” still applies without modification: for any significant AI-related decision, ask what layer it actually lives in, and whether it’s being evaluated at that layer. What this post adds is that for AI specifically, the diagnostic needs to be run seven times for every adoption decision, not once — because the adoption decision answers layer seven’s question and leaves the other six open by default, not by choice.

The organizations that will navigate this well are not the ones that adopted AI fastest, and not the ones that adopted it most cautiously. They’re the ones that, having made the layer-seven decision — which most organizations have already made, one way or another — went back through layers one to six and asked, deliberately, whether anything there needed to change in response. Most of the time, for most layers, the honest answer will be “not yet, but here’s what we’re watching for.” That answer is fine. What isn’t fine is the question never being asked — because the gap between implementation cost and understanding cost doesn’t go away when it’s not asked. It just accumulates somewhere else, on someone else’s timeline, until it arrives looking like a different problem entirely.

The CTO Decision Stack exists to make layers visible before their consequences arrive. AI is the fastest-moving test that visibility has faced — not because it’s more disruptive than previous shifts, but because it’s the first one where the cost of acting and the cost of understanding have moved in opposite directions at the same time. The implementation-understanding gap is the structural problem; the supervision paradox is its human manifestation, the same gap showing up in what people are and aren’t able to catch. Every layer of the stack was, in some sense, built to manage exactly that gap. This is just the first time all seven have had to manage it simultaneously.

Ali Ahmed Thawerani writes about the systems, culture, and scale decisions that shape how technology organisations develop. TECTONICS publishes at aathawerani.github.io.

YipitData, SaaS Scoreboard, March 2026, as reported in SpendHound, “14 Best SaaS Spend Management Software in 2026,” May 1, 2026. ↩

The CTO Decision Stack

Sun, 07 Jun 2026 00:00:00 +0000

Seven layers of decision-making — and why conflating them is how technical leadership breaks down

There is a category of technical leadership failure that does not announce itself as a failure at the time it happens.

A CTO makes a call about the database. It is the right call, technically. Clean, defensible, well-reasoned. Six months later, the engineering team is reorganized around it in ways that nobody planned. The product roadmap is constrained by it. The hiring strategy has implicitly shifted because of it. The company is now three layers deep into consequences that originated from a decision that was framed, evaluated, and made as a purely technical question.

This is not a story about a bad decision. It is a story about a decision made at the wrong layer — evaluated against the wrong criteria, with the wrong people in the room, without visibility into the implications it would carry upward.

The CTO role is structurally unusual in organizations. Unlike a CFO, who operates within a fairly well-understood set of financial abstractions, or a CPO, who owns a reasonably bounded product domain, the CTO sits at an intersection between corporate strategy, product thinking, operational delivery, organizational design, people leadership, infrastructure, and developer tooling. These are not the same type of problem. They do not respond to the same reasoning. They do not decay at the same rate or carry the same reversibility.

Most technical leaders know this in principle. The difficulty is that in practice, the layers collapse. A decision that should live at one layer gets resolved at another. Strategic questions get answered by whoever happened to be in the room for a technical discussion. Infrastructure choices calcify into product constraints. A technology choice gets evaluated on architectural merit alone, without anyone asking whether the team can deliver it or sustain it in production. Developer tooling decisions accumulate into organizational culture, invisibly, over years.

The CTO Decision Stack is an attempt to make the layers explicit — not as a hierarchy of importance, but as a map of where decisions actually belong, what they are optimizing for, and how they interact with each other.

The Seven Layers

The stack runs from the highest level of abstraction to the most operational. Each layer has its own time horizon, its own reversibility profile, and its own failure mode when it is confused with another layer.

They are not independent. Every layer has load-bearing relationships with the layers above and below it. A decision at one layer creates the environment within which decisions at adjacent layers must be made. This is what makes them a stack, not a list.

Layer 1: Corporate & Business Strategy

Time horizon: Years to decades. Reversibility: Very Low.

The top layer is the one technical leaders most often underweight — not because they do not care about business outcomes, but because decisions at this layer do not feel like engineering decisions. They feel like someone else’s problem.

They are not.

This layer operates at two altitudes that are distinct but inseparable. Corporate strategy sits above business strategy. Corporate strategy asks: what is the shape of the organization itself — its portfolio of bets, its approach to M&A, its decision about which capabilities to own versus acquire versus partner on? A CTO who has not engaged with these questions will find that the answers arrive anyway, embedded in decisions made by others, and discover too late that those answers have constrained everything below.

Business strategy sits just below it, and asks the question most technical leaders are more comfortable with: what does this specific product or business unit need to be, technically, to win in its market over the next several years?

But neither question can be answered in isolation from the environment the organization operates in. External forces shape the answer before the CTO gets to ask it.

Market dynamics determine what speed of evolution is required. A market that is moving fast with low switching costs demands different architectural choices than one that moves slowly with deep integration. A CTO building for a fast market who optimizes for stability is playing the wrong game. One building for a slow market who optimizes for speed is accumulating unnecessary complexity.

Talent pool and availability constrain what is actually buildable. A technically correct strategy that requires skills the market cannot supply is not a strategy — it is a fantasy. Stack choices, hiring models, and organizational design all feed back into what the layer-one strategy can credibly commit to.

Competition and coopetition define where differentiation is actually possible. Competing head-on against a well-resourced incumbent on their strongest capability is a different strategic position than identifying the adjacent surface they cannot serve. And coopetition — building on top of a competitor’s platform, contributing to shared infrastructure with rivals, participating in industry consortia — carries its own set of layer-one decisions about what to share and what to protect.

These forces are not layers in themselves. They are the environment within which layer-one decisions are made — the constraints that make some strategies viable and others academic. The CTO’s job at this layer is not to predict external forces, which is impossible, but to make strategic decisions that are robust to a range of plausible futures rather than optimized for a single assumed one.

This is precisely the role that enterprise architects were invented to fill — the bridge between corporate strategy and technology structure. In most organizations that role is either absent, underpowered, or disconnected from real decisions. The gap does not stay empty. It fills itself with accumulated accidents: technology choices that were never evaluated against strategy, architectural decisions that carry strategic consequences nobody intended, organizational structures that reflect the company as it was rather than the company it needs to become. The CTO who does not explicitly own layer one is not avoiding the work. They are delegating it to nobody — and discovering later that nobody did it.

The practical tool at this layer is a technology SWOT — distinct from and complementary to the business SWOT the executive team runs. The business SWOT analyzes market position, commercial strengths and weaknesses, competitive threats, and external opportunities. The technology SWOT runs the same analysis from the technology perspective and surfaces things the business view cannot see.

Technology strengths are the capabilities the organization has built that competitors would find hard to replicate: proprietary data assets, engineering culture, technical infrastructure that enables speed or reliability at scale. Technology weaknesses are the accumulated constraints that limit strategic options: architectural debt that makes certain product directions prohibitively expensive, skill gaps that make certain approaches unexecutable, operational fragility that caps the pace of change the organization can absorb. Technology opportunities are the external developments — new tools, new platforms, shifts in the talent market, emerging AI capabilities — that the organization is positioned to exploit before competitors do. Technology threats are the forces that could erode current advantages: commoditization of capabilities that were once differentiators, platform shifts that require architectural reinvention, AI tools that allow smaller competitors to close the capability gap faster than anticipated.

The business and technology SWOTs should be run together and compared explicitly. Where they diverge is where the most important layer-one conversations happen: a business opportunity that the technology SWOT reveals as unexecutable, a technology strength that the business has not yet found a way to monetize, a technology threat that the business has not yet registered as a strategic risk.

Strategic decisions are defined by their irreversibility, not their importance. A decision that cannot be undone in under six months is a strategic decision, regardless of how it was framed when it was made.

The questions that belong at this layer: what is the defensible technical moat, if any? Where does software differentiation matter and where is it commodity? What engineering capabilities need to exist in-house, and which can be bought, rented, or partnered for? Are there capabilities where coopetition produces more value than independent investment? What does the talent market allow us to credibly build?

The clearest illustration of a layer-one decision made correctly is Stripe’s early bet that developer experience was the moat. Not features, not pricing, not distribution — the quality of the API and the quality of the documentation. That was not an engineering decision. It was a corporate strategy decision about what the company would be. It shaped everything below it: the product architecture had to be clean enough that the API surface was genuinely pleasant to use, the engineering organization had to value craft in ways that could sustain a developer-first culture, and infrastructure had to prioritize reliability because an unreliable payment API is not a moat. A single strategic call at layer one propagated through every layer beneath it for years.

Layer 2: Product Architecture

Time horizon: Months to years. Reversibility: Low.

The second layer is where technical strategy becomes technical structure — where the business’s intent to build a specific kind of product is translated into the architectural decisions that will shape how that product can evolve.

This is the layer most CTOs feel most at home in. It is the layer of system design: how is the product decomposed, how do its components communicate, where are the boundaries drawn, what are the contracts between services, how is data modeled and owned, what are the consistency and availability properties the system needs to have. The primary criteria here are scalability, security, resilience, and the system’s capacity to absorb change without structural collapse.

But framing it as pure technical design misses what makes it hard.

Product architecture decisions are not evaluated against technical correctness. They are evaluated against a product roadmap that does not yet fully exist. The architect is making bets about which capabilities the product will need, in what order, at what scale. A decision that is correct for the product as it exists today may be deeply wrong for the product as it will need to exist in eighteen months. A system designed for a single-tenant model will not cleanly become multi-tenant. A system built around a monolithic data model will not cleanly decompose. A system optimized for read-heavy access patterns will not gracefully absorb write-heavy load.

The job of product architecture is not to design for today’s requirements. It is to design for tomorrow’s changes.

The failure mode at this layer is premature optimization in either direction. Too rigid, and the architecture cannot absorb the product evolution that is inevitable. Too loose — “we’ll figure it out when we get there” — and the product accumulates structural debt that makes each evolution more expensive than the last until some transitions become effectively impossible.

The questions that belong here: where are the natural seams in the product domain, and are the architectural boundaries aligned with them? Which parts of the system need to evolve independently, and are they actually independent? What are the data models that are most expensive to migrate, and are they designed to survive product changes? What are the external interfaces — to customers, to partners, to regulators — and are they stable even when internals change?

Netflix’s migration from a monolith to services is the canonical example of a layer-two decision made correctly — but only in retrospect. The decomposition was not driven by technical elegance. It was driven by a product requirement: different parts of the system needed to scale independently because different parts of the product experienced radically different load profiles. The recommendation engine, the streaming pipeline, and the user account service had nothing in common in terms of their scaling needs. The architecture had to reflect that, or the product could not evolve to meet it. The organizational restructuring that followed — separate teams, separate ownership, separate deployment pipelines — was not a consequence of the architecture. It was required by it.

Layer 3: Technology Delivery

Time horizon: Months to years. Reversibility: Low to medium.

The third layer is the one that separates the architect’s perspective from the CTO’s. An architect evaluating a proposed system design asks: is this scalable, is it secure, is it the right structure for the product we are building? These are the right questions for layer two. But the CTO has to put on a different cap and ask a different set of questions about the same decision: can we actually deliver this, on what timeline, with what team? And once it is in production — can we support it, debug it, explain it to a customer when something goes wrong?

These are not architectural questions. They are operational ones. And they belong at their own layer because they are evaluated against entirely different criteria, and because getting them wrong produces entirely different consequences from getting layer two wrong.

The technology stack decision lives here more than it lives at layer two. A CTO choosing between technology options is not primarily making an architectural choice — the architecture can often be expressed in multiple stacks equally well. They are making an operational and delivery choice: which stack allows the team to move at the speed the business requires? Which stack is supportable with the team that exists, and the talent that can be hired? Which stack is legible enough to an AI agent that the team can leverage AI assistance across the full delivery cycle — from initial development through to production support?

This last criterion is newer but increasingly decisive. A stack with deep AI tooling support — where the language, the ecosystem, and the common patterns are well-represented in AI training data — compresses delivery timelines in ways that a technically superior but AI-opaque stack cannot match. The choice of Python over Java for a given system may be architecturally neutral. Operationally, in a world where AI agents are doing a meaningful fraction of the implementation and support work, it is not neutral at all.

The CTO who evaluates a technology choice purely on architectural merit is answering the right question at the wrong layer.

The questions that belong here: how long will it take to deliver the first version, and the tenth version, with this stack and this team? When something breaks in production at 2am, how quickly can the on-call engineer understand what went wrong and why? Can an AI agent navigate this codebase reliably enough to assist with debugging, with code review, with generating test coverage? What is the support burden this technology choice places on the team — and is that burden sustainable at the scale the product needs to reach?

The failure mode at this layer is invisible to architects and visible to everyone else. An architecture that is technically correct but operationally brutal produces delivery timelines that look like team performance problems, support burdens that look like reliability problems, and attrition that looks like culture problems. None of these are the root cause. The root cause is a layer-three decision that was never made explicitly — because it was evaluated at layer two, against layer-two criteria, by people whose job is layer two.

Layer 4: Engineering Organization

Time horizon: Quarters to years. Reversibility: Medium.

The fourth layer is organizational: how is the engineering team structured, how is ownership assigned, how do teams coordinate, how are decisions made, how does the organization scale.

This layer is where the stack’s interactions become most consequential — because the engineering organization is the mechanism through which all other layers are realized. The best architecture is worthless if the organization cannot build it. The most operationally sound technology choice is worthless if the team structure creates coordination overhead that cancels out its delivery advantages. The most thoughtful infrastructure is worthless if the teams responsible for it do not have the context to operate it.

Conway’s Law is not an observation about technology. It is an observation about this layer.

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

This is not a historical curiosity. It is an active constraint on every architecture decision made at layer two. Teams build what they can communicate about. Boundaries emerge where communication is expensive. The architecture of the product reflects the topology of the organization that built it — and if those two things are not deliberately aligned, they will be accidentally misaligned in ways that compound over time.

The implication is directional: the engineering organization needs to be structured around the product architecture, not the other way around. This is harder than it sounds. Most organizations have existing team structures, existing reporting lines, existing ownership patterns. Changing them is slow and politically costly. The temptation is to fit the architecture to the org rather than the org to the architecture — and this temptation, consistently indulged, is how products become unmaintainable.

The failure mode at this layer is not structural incorrectness. It is structural lag — the organization that was correct for the product at one stage and has not been deliberately redesigned for the next stage. Teams that made sense when the product was a monolith but create friction now that it is decomposed. Ownership models that worked when the team was twenty people but break at a hundred. Coordination patterns that were fine for one product surface but add unbearable overhead now that there are three.

The questions that belong here: does team structure match the system’s architecture — or is it creating architectural pressure the system cannot absorb? Where are the coordination bottlenecks — and are they in the team structure, the ownership model, or the architecture? Is ownership of each component clear enough that the people responsible for it have the context to make good decisions about it?

Amazon’s two-pizza team rule is the most cited example of a layer-four decision — and one of the most misunderstood. The rule was not primarily about team size. It was about ownership. A team small enough to be fed by two pizzas is a team small enough to fully own a component: to understand its behavior under load, to be on call for it, to make architectural decisions about it without requiring coordination with another team. The size constraint was a proxy for the ownership constraint. Organizations that adopted the rule without adopting the ownership model got small teams with diffuse responsibility — which is worse than large teams with clear ownership, because the diffusion is harder to see.

Layer 5: People & Talent

Time horizon: Quarters to years. Reversibility: Medium.

The fifth layer is people: who is on the team, what capabilities they have, how they are developed, and — increasingly — how the boundary between human engineers and AI agents is governed.

This layer is distinct from the engineering organization layer above it. Layer four is about structure — how teams are arranged, how ownership is assigned, how coordination happens. Layer five is about the humans and agents within that structure — their skills, their composition, their development, and the governance model that determines how human judgment and AI capability are combined.

For most of the history of software engineering, the people layer was primarily a hiring and retention problem: recruit engineers with the right skills, keep them engaged, develop them over time. These concerns remain real. But the arrival of capable AI agents has added a dimension that most organizations have not yet explicitly addressed: the engineering team is no longer purely human, and the decisions about how to compose, govern, and quality-control a hybrid team are not being made at this layer — they are being made ad hoc, at layer seven, by individual engineers choosing which tasks to delegate to an agent and which to handle themselves.

That is the wrong layer for those decisions.

The questions that belong at layer five: what is the right composition of human engineers and AI agents for the work this organization needs to do? Which categories of work should remain primarily human — because they require judgment, accountability, or contextual understanding that agents cannot reliably provide — and which can be reliably delegated? What does quality control look like when a significant fraction of the codebase is agent-generated? How is accountability assigned for agent output — who owns it, who reviews it, who is responsible when it fails?

Governance of the human-agent boundary is the defining people challenge of this moment in software engineering. Organizations that have not made explicit decisions at this layer are making implicit ones — usually in the direction of maximum agent adoption at minimum governance, which produces speed in the short term and fragility in the medium term. Code that nobody fully understands, test coverage that was generated rather than reasoned about, architectural decisions embedded in agent output that no human reviewed as architectural decisions.

The question is not whether to use AI agents. It is who is responsible for what they produce — and whether that responsibility is explicit enough to be exercised.

The questions that belong here also include the development of human engineers in an AI-augmented environment. The skills that are most valuable are shifting: from implementation fluency toward specification precision, from code authorship toward architectural judgment, from debugging skill toward the ability to evaluate agent output critically. An organization that is not deliberately developing these capabilities in its human engineers is building a team that is increasingly dependent on agents it does not fully understand and cannot fully supervise.

Layer 6: Infrastructure

Time horizon: Months. Reversibility: Medium to high.

The sixth layer is infrastructure: cloud platform, data platform, networking, security posture, deployment model, observability stack.

This is the layer that generates the most tactical urgency. Infrastructure decisions carry immediate cost implications, immediate reliability implications, and immediate operational overhead. They are also, among the seven layers, among the most frequently conflated with strategic decisions — because the vendors selling infrastructure services have a strong incentive to frame them that way.

They are not strategic decisions. They are structural ones.

Infrastructure is not a strategy. It is the physical expression of an architecture. The choice of database engine is not a business bet. The choice of whether to own your data layer is.

The correct frame for infrastructure decisions is: does this choice give the architecture what it needs to deliver the product the business requires, at a cost structure the business can sustain, with an operational burden the organization can carry?

Notice what is not in that frame: vendor preference, engineer familiarity, and what competitors are using. These are inputs, not criteria. An infrastructure choice that satisfies the frame is a good one even if it is boring. An infrastructure choice that fails the frame is a bad one even if it is technically elegant.

The specific failure that is most expensive is infrastructure lock-in masquerading as a platform bet. Choosing a cloud provider is a reversible decision — painful and expensive to reverse, but possible. Choosing a cloud provider and then building every product capability directly on top of provider-specific services, without abstraction, makes the decision effectively irreversible. This is sometimes the right tradeoff. It is almost never made explicitly.

Dropbox’s decision to migrate off AWS and build its own storage infrastructure — Magic Pocket — is one of the few examples of a layer-six decision made with full layer-one and layer-two visibility. At Dropbox’s scale, storage was the primary cost driver of the business, and the cost curve of managed cloud storage made the unit economics increasingly difficult. The infrastructure decision was downstream of a business strategy question: can this company survive long-term on managed storage costs, or does it need to own the infrastructure to own the margin? Reaching that answer required the CTO to connect infrastructure economics to business strategy — not to evaluate the migration as a purely technical question.

Layer 7: Developer Productivity

Time horizon: Weeks to months. Reversibility: High.

The seventh layer is developer productivity: the tooling, processes, practices, and environment in which engineers work day to day. Build systems, local development environments, CI/CD pipelines, code review processes, deployment tooling, testing infrastructure, documentation practices.

This is the layer that is most frequently mismanaged in two opposite directions.

The first direction is neglect. Engineering leadership treats developer productivity as a maintenance concern rather than a strategic investment, defers improvements indefinitely under delivery pressure, and ends up with a development environment that is slow, fragile, and frustrating — which produces exactly the delivery pressure that supposedly justified not investing in it.

The second direction is over-investment. Engineering leadership treats developer productivity as the primary lever for organizational performance, invests heavily in tooling sophistication and process refinement, and ends up with a beautifully instrumented development environment that is building the wrong product efficiently.

Neither direction understands what this layer is actually for.

Developer productivity tooling is not about making engineers faster. It is about making the architecture legible to the people building it.

A well-instrumented CI pipeline that surfaces architectural violations is valuable not because it speeds up deployment but because it enforces the architectural contracts that the product’s integrity depends on. A local development environment that accurately mirrors production is valuable not because it improves individual productivity but because it reduces the gap between where decisions are made and where their consequences are visible. A test suite with genuine boundary coverage is valuable not because it speeds up delivery but because it is the mechanism by which architectural changes can be validated as safe.

Google’s internal developer tooling — Blaze, Critique, Piper — is the most extreme version of layer-seven investment in the industry, and it illustrates both the ceiling and the precondition. Google spent years and significant engineering resources building tools tightly coupled to its monorepo architecture. The productivity investment was real. But it only paid off because it was designed specifically around Google’s architectural choices. Teams that cargo-culted the tools without the architecture got the complexity without the benefit. The lesson is not that developer tooling investment is always worth it. It is that tooling investment is only worth it when it is directly expressive of the architecture it serves.

How the Layers Break Down

The stack is a decision-making framework, not a delegation model. All seven layers require the CTO’s attention. The question is not which layers the CTO works in — it is whether the decisions being made in each layer are being evaluated against the right criteria.

Three breakdown patterns appear consistently across engineering organizations.

Strategic decisions masquerading as technical ones. A platform migration evaluated purely on technical merit. A build-vs-buy decision evaluated on feature parity rather than organizational capability. A vendor selection evaluated on performance benchmarks rather than cost structure at scale. A technology stack choice evaluated on architectural elegance rather than operational deliverability and support burden. In each case, a decision that belongs at layer one, two, or three is being made with layer six or seven criteria — and the consequences accumulate upward invisibly until they become a business problem rather than a technical one.

Technical decisions resolved at the wrong layer. An infrastructure choice that constrains the product architecture, made without awareness of the constraint. An organizational structure that calcifies around a system design that has since changed. A developer productivity investment that optimizes for the current team structure rather than the target architecture. An AI adoption decision made at the tooling layer without reference to the governance model it requires at the people layer. In each case, a decision at one layer is made without visibility into its implications for adjacent layers.

Layer collapse under pressure. When organizations are under delivery pressure, the stack compresses. Strategic and architectural decisions get deferred in favor of operational ones. Technology choices get made by whoever is closest to the implementation, evaluated against implementation criteria. The organizational structure remains frozen while the architecture evolves around it. The people layer never gets explicitly designed — it accumulates by default. The collapse is not visible as a failure at the time — it looks like pragmatism, like keeping things moving. The debt it creates becomes visible later, when the organization discovers that it cannot make a particular architectural change because the organizational structure is in the way, or that it cannot pursue a strategic direction because an infrastructure choice made two years ago has made it prohibitively expensive.

A Note on AI

AI does not belong to a single layer of the stack.

Most organizations experience it first at layer seven — developer tooling, coding assistants, CI integration. But its consequences reach all the way up: to how teams are governed at layer five, to how technology is selected at layer three, to how architecture is designed at layer two, and ultimately to what kind of company this organization can credibly be at layer one.

Treating AI as a tooling decision is often the first and most visible example of layer collapse. The full implications of AI across each layer of the stack deserve a separate treatment — and that is where this series goes next.

The Stack in Context

The seven layers are constant. What varies is how they behave depending on organizational context — and the variation is large enough to warrant its own treatment.

The short version: the startup’s primary risk at each layer is invisibility — decisions being made without awareness that a layer exists. The enterprise’s primary risk is disconnection — layers operating without awareness of each other.

Both risks produce the same outcome: decisions made at the wrong layer, evaluated against the wrong criteria, with consequences that arrive later and look like a different problem than the one that caused them. How each context produces that outcome, and what to do about it, is where this series goes after AI.

Using the Stack

The decision stack is not a process. It does not tell you what to decide. It tells you where a decision belongs — which changes how it is evaluated, who should be in the room, and what counts as a good outcome.

The diagnostic is simple. For any significant decision the engineering organization is facing, ask: what layer does this decision actually live in? Then ask: is it being evaluated at that layer?

If a technology stack choice is being evaluated on architectural elegance rather than delivery speed, support burden, and AI fluency, it is being evaluated at the wrong layer — layer two criteria applied to a layer three decision. If a decision about organizational structure is being made without reference to the architectural boundaries the organization needs to maintain, it is being made at the wrong layer. If a decision about cloud vendor is being made as a strategic bet when it should be evaluated as an infrastructure tradeoff, it is being framed at the wrong layer. If decisions about AI agent governance are being made by individual engineers at the tooling layer rather than explicitly at the people layer, they are being resolved three layers below where they belong.

Most of the time, the problem is not the decision. It is the frame.

The CTO’s job is not to make decisions. It is to make sure decisions are made at the layer they actually belong to — with the right information, the right people, and the right criteria.

The stack also provides a map for communication. Different stakeholders in an organization have visibility into different layers. Engineers have the deepest visibility into layers six and seven. Product managers have the clearest view of layer two’s requirements. HR owns parts of layer five without owning the layer. The executive team lives in layer one. The CTO is the only person in the organization whose job requires fluency across all seven levels — and whose value comes precisely from the ability to translate between them: to carry the implications of a strategic decision downward into infrastructure choices, and to surface the implications of an operational constraint upward into product and business conversations.

Most technology failures are not failures of architecture, infrastructure, tooling, or people. They are failures of framing.

Decisions made at the wrong layer eventually create consequences that appear somewhere else — and look like a different problem than the one that caused them.

The CTO Decision Stack exists to make those layers visible before the consequences arrive.

Ali Ahmed Thawerani writes about the systems, culture, and scale decisions that shape how technology organisations develop. TECTONICS publishes at aathawerani.github.io.

Tech Stack Selection in the Age of AI Agents

Wed, 27 May 2026 00:00:00 +0000

A Third Variable

Historically, stack selection was driven by two things: the problem domain and the team’s existing expertise. Both remain relevant. But there is now a third variable that most teams are not accounting for explicitly.

The AI agent writing the code has strong opinions about what it can build well — and those opinions do not always align with what would be optimal for the domain.

AI coding capability is not uniform across stacks. It is ecosystem-relative.

An AI agent is not simply a language model applied to a codebase. It is a language model whose suggestions are calibrated to the density and quality of training examples it has seen — and that density varies enormously across stacks.

Python dominates that distribution. An AI agent generating FastAPI route handlers, SQLAlchemy models, Pydantic schemas, and Alembic migrations is not just producing correct Python. It is producing idiomatic Python — the specific patterns and library combinations that the ecosystem has converged on over years of collective practice. That is qualitatively different from an AI that knows the syntax but not which library to reach for, which patterns are now antipatterns, or which dependency combinations cause subtle production issues.

Vite and React sit in the same high-confidence tier on the frontend. The AI is operating close to the centre of its training distribution: component structure, state management patterns, API integration conventions — all rendered with high reliability.

This has a practical implication that is worth stating directly: your stack choice is also, implicitly, a choice about what kind of AI partner you will have for the next six months. The students at Habib University’s Kaavish exhibition who built Python + Vite prototypes were not making a conservative choice. They were making a strategically correct one — working where the tools are strongest rather than where the theory is most elegant.

There is a further dimension to this that the AI fluency argument alone does not capture: Python and TypeScript are also globally the most hireable stacks, with the deepest tutorial ecosystems, the largest communities, and the most abundant open-source examples. When a new engineer joins the team, onboarding them onto idiomatic FastAPI or React is weeks faster than onboarding them onto a niche framework with thin documentation. The AI and the hiring market are pointing in the same direction. That alignment is not a coincidence — both are responding to the same underlying signal about where collective expertise has concentrated.

Go, Rust, and Kotlin sit at an intermediate layer — well-represented for common patterns but with more variance at the edges. The further you move from the high-confidence core, the more the AI shifts from an asset into a liability — not useless, but less consistent in ways that compound.

The stack choice is the first architectural decision. It is also the decision that determines how much leverage everything else provides.

Build Only the USP. Buy Everything Else.

Speed at prototype stage comes from a simple principle: build only what makes your product worth using, and buy everything else.

Every software product has to solve a class of problems that have nothing to do with why users would choose it over an alternative. Authentication, file storage, email delivery, SMS, database hosting, queuing, monitoring — none of these are why a logistics product wins customers. No fintech product earns its market position because it built a better password reset flow. These are cross-cutting concerns: genuinely hard problems that every product has, solved reliably by specialised providers, with no competitive advantage to be gained from building them from scratch.

A second category sits just beyond: domain-specific commodity services. Payments via Stripe. Maps via Google Maps or Mapbox. Identity verification via a KYC provider. These feel like core functionality because they are domain-specific — but they are common enough across the domain that mature solutions already exist. A fintech prototype does not need to build its own payment processing. A logistics prototype does not need to build its own geocoding.

What remains after removing both categories is the core business value — the unique insight, the differentiated workflow, the algorithm or data model that is the actual reason the product should exist. This is the only thing worth building from scratch. This is what the prototype validates.

The cost curve will shift. As the product scales, what was negligible becomes significant. The economics of self-hosting gradually improve relative to the managed service cost — a pattern documented across software organisations at growth stage. When that crossover arrives, the managed service should be replaceable without touching the rest of the system.

That is only true if every managed service sits behind one interface file from day one. auth/provider.py. storage/provider.py. notifications/provider.py. When Supabase Auth’s pricing model changes at scale, the migration scope is one file. When email volume justifies a self-hosted mail server, the migration scope is one file. The rest of the codebase does not know and does not care.

Buy the cloud. Own the seam.

The Architecture of the Prototype That Survives

The prototype built with speed but no structural discipline tends to become the thing that blocks future progress — not because it failed, but because it succeeded. It is in production. Real users depend on it. And the choices that were fine for a learning exercise are now structural problems with no clean way out.

The disciplines below are not overhead. Each takes an hour or a day at prototype stage and saves weeks or months at migration stage.

Organise by domain, not by technical layer. An orders/ module, a drivers/ module, a payments/ module — rather than models/, routes/, services/ layers that scatter every feature across the whole codebase. The domain module is the unit of future extraction. Without it, there is no clean unit to extract.

Manage the schema from the first table. Use Alembic, Flyway, or Prisma Migrate from day one. The schema is the most expensive thing to change under real load. A migration history that starts at the first table is a foundation. A schema altered ad hoc is an archaeology problem.

Wrap every external dependency behind one interface file. Every third-party service — auth provider, payment processor, storage, email — sits behind a single file all callers use. This is the one structural decision that keeps every future replacement bounded to one file and one scope of work.

Delegate authentication entirely. Auth couples to the user model, the session model, and the permission model — all of which accumulate real data quickly. The prototype’s auth tends to become the production auth. Buying it from a provider is not a shortcut. It is the correct decision for the stage.

Add structured logging with a correlation ID before you have users. A JSON log event with a consistent shape, carrying a correlation ID that propagates through every downstream call, is almost free to add early and expensive to retrofit. It is also the specific precondition for safely validating a replacement service against real production traffic before switching over.

Run in containers from day one. Docker forces enumeration of every dependency the system has — runtime version, system packages, environment variables. The result is a system that can be deployed anywhere and can host transitional infrastructure without environment drift.

Separate configuration from code. Environment variables for all configuration. A .env.example that documents what is required without values. The gap between staging and production configs, under go-live pressure, is where secrets get committed to version control.

Test the Boundaries, Not the Implementation

TDD has a reputation problem at prototype stage. Writing tests before code feels like overhead when learning speed is everything. The resolution is not to abandon testing — it is to be precise about what to test.

Tests at prototype stage should cover boundaries, not implementation details. The internal workings of a module can be refactored freely as the domain is better understood. What cannot change without consequences is the contract a module exposes — the service interface between modules, the API contract between backend and frontend, the interface file wrapping an external vendor. These are the seams. The seams need tests. Everything else is optional until it proves itself worth testing.

This connects directly to AI-assisted development in a specific way. Given a well-defined Pydantic schema and a service function signature, an AI generates meaningful boundary tests — happy paths, edge cases, error conditions — faster than a human. Given an unstructured codebase, the same AI generates tests tightly coupled to implementation details: tests that break on every refactor, produce false confidence, and eventually get deleted. The template precedes the tests. Boundary discipline is what makes AI-generated tests worth having.

The tests that directly enable future migration are worth naming: a service interface test suite means that when you rewrite the implementation behind a module boundary — a new Go service, a self-hosted auth provider, a rewritten notification engine — you run the same tests against the new implementation and know immediately whether it behaves correctly. That is the confidence mechanism for safe replacement. Without it, every migration requires manual verification of every behaviour the old implementation had.

One anti-pattern to name explicitly: testing the framework instead of the domain. Tests that verify FastAPI routing mechanics or SQLAlchemy query behaviour are testing things the libraries already guarantee. The valuable tests are on domain logic — does the order state machine transition correctly, does the pricing calculation handle the edge cases the business cares about. The framework can be trusted. The domain logic cannot.

The practical starting point: one test file per module service interface, one per API endpoint group, one mock-based test per external dependency wrapper. That is the minimum that keeps migration options open.

The UI Gap Nobody Talks About

There is a dimension missing from almost every architectural template written for early-stage products: the frontend.

Backend architecture gets most of the attention. The frontend is treated as the presentation layer — a consequence of the real decisions, not a domain with its own architectural concerns. This is a mistake that becomes expensive exactly when the product starts to scale.

Frontend debt is cognitive rather than structural. Not coupling between modules or schema problems, but components that grew without boundaries, state in the wrong place, API calls inlined wherever first needed and then copied rather than centralised. The result is a frontend that resists change because there are no clean units to work with.

Three rules prevent this:

Organise by feature, not by type. A components/ folder containing both Button and OrderSummaryCard is not a components folder — it is a pile. OrderSummaryCard contains business logic, depends on a specific data shape, and belongs in features/orders/components/. Genuinely shared UI belongs in components/. Domain-specific code lives in its feature folder. This boundary is the frontend equivalent of the domain module.

src/
  features/
    orders/
      components/  # OrderList, OrderCard — orders-specific
      hooks/       # useOrders, useOrderStatus
      types.ts
    payments/
      components/
      hooks/
      types.ts
  components/      # Button, Modal, Input — shared, no business logic
  services/        # ALL API calls — never inline fetch in components
  hooks/           # shared hooks, no domain specificity

Centralise all API calls in a services layer. src/services/ owns every external call — typed functions that speak the domain language (getOrderById(id), not get('/api/v1/orders/{id}')), with consistent error handling. The AI’s instinct is to put the fetch call where the data is first needed. A template that encodes the rule changes what the AI generates.

Layer state management deliberately. Server state — data from the API — belongs in TanStack Query. It has its own caching and invalidation semantics that a global store does not handle well. UI state belongs at the component or feature level. Only genuinely global state — current user, authentication — belongs in a global store. Without this in the template, the AI reaches for the global store for everything.

Encoding It All in a Template

The disciplines above — domain modules, schema migrations, interface files, boundary tests, feature-based frontend structure — are the decisions that need to be made before the first line of code is written. Left unencoded, each one will be reinvented inconsistently across sessions as the AI fills the gaps with whatever seemed convenient at the moment.

The previous post in this series argued that architecture is shifting from diagrams to guardrails — from documentation that describes intent to constraints that enforce it. The practical form of that at prototype stage is a CLAUDE.md at the root of the repository: not a prompt, but an architecture. Every rule in the file is implicitly an ADR — a decision with a rationale that future engineers and AI agents can read rather than re-derive.

A minimal template for a Python + Vite stack, encoding everything covered above:

# Architecture Template

## Stack
- Backend: Python 3.12, FastAPI, SQLAlchemy 2.0, Alembic, Pydantic v2
- Frontend: Vite, React 18, TypeScript, TanStack Query
- Auth: Supabase Auth — never implement custom auth
- Database: PostgreSQL — all schema changes via Alembic migrations only

## Backend Module Structure
Organise by domain, not by technical layer.

src/
  auth/          # authentication, session management
  users/         # user profiles, preferences
  orders/        # order lifecycle
  payments/      # payment processing
  notifications/ # outbound communication

Each module: models.py, schemas.py, service.py, router.py
No cross-module imports except through explicit service interfaces.

## External Dependency Rule
Every third-party service behind one interface file.
src/payments/provider.py      — all Stripe calls go here, nowhere else.
src/notifications/provider.py — all SendGrid calls go here, nowhere else.

## Schema Management
Every database change through an Alembic migration. Never ALTER TABLE manually.

## Logging
Structured JSON via structlog. Every request carries a correlation_id.

## Configuration
All config via environment variables. No hardcoded credentials.
.env.example documents required variables without values.

## Frontend Structure
src/
  features/    # one folder per domain (orders/, payments/, users/)
  components/  # shared UI only — no business logic, no API calls
  services/    # ALL API calls here — never inline fetch in components
  hooks/       # shared hooks only

## Testing
One test file per module service interface.
One test file per API endpoint group.
One mock-based test per external dependency wrapper.
Test domain logic, not framework mechanics.

This file is written once. From that point, the AI follows it — not because it has judgment, but because it has instructions. The judgment was applied once, by a human, at the start.

Designing for Replaceability

Here is what connects every discipline above to the long-term arc of the product: the patterns used to migrate a system to enterprise grade each have a precondition, and those preconditions are exactly what good prototype architecture creates.

Three structural choices — made once, at the start — keep every migration option available later. Miss them and the only path forward is a full rewrite.

The seam is everything. Michael Feathers called the natural split points in a codebase seams — places where the system can be divided without modifying surrounding code. In a prototype, the domain module boundary is the seam. The Strangler Fig pattern — where new services are built alongside the old system and traffic is redirected one capability at a time — only works if a clean intercept point exists. The domain module, with its own router and service interface, is that intercept point. A codebase with no module boundaries has no seams. A codebase with no seams cannot be incrementally migrated. It can only be rewritten.

The interface file is the abstraction that already exists. Branch by Abstraction — for replacing a component deep inside the system — requires first introducing an abstraction and migrating all callers to use it. That is the expensive step. The external dependency interface file does this work at day zero. When the time comes to swap Stripe for a self-built payment service, or replace Supabase Auth with a self-hosted provider, the abstraction already exists and every caller already uses it. The same logic applies to cloud services: buying managed solutions behind interface files means the cost-curve replacement is always one file deep.

The feature boundary is what makes UI migration possible. Replacing a frontend section by section — while the rest continues running — requires that sections are independently identifiable and modifiable. In its coarser form, an entire page or user-type experience is the replacement unit: a new driver dashboard built as a separate application, calling the existing backend through its clean API surface, with traffic routing directing drivers to the new version while the customer experience is untouched. In its finer form, individual widgets within a page are replaced one at a time. Both require the feature-based frontend structure. A frontend where every domain’s code is scattered across shared folders requires untangling before it can be extended.

Three further patterns follow from the remaining disciplines without requiring their own names. The migration-based schema enables making schema changes on a live system in phases — add the new structure alongside the old, migrate data, remove the old — each phase independently deployable and reversible, no maintenance window required. The correlation ID in structured logs enables running old and new implementations simultaneously on real traffic and comparing outputs before committing to the switch — the precondition being that you can match a request across both systems. And for multi-sided products, keeping each user type in its own vertical slice means one side can be migrated completely while the other continues on the original system.

One anti-pattern deserves explicit naming: Feature Parity — the requirement that a replacement must reproduce every behaviour of the old system before any switch can happen. In the prototype-to-enterprise context this most often appears when a team takes over a solo-built prototype and treats every undocumented quirk as a feature to preserve. The correct target is outcome parity — the new implementation delivers the same results for users — not behavioural parity. Architecture Decision Records are the countermeasure: an ADR explaining why a workaround exists gives the replacement team permission to do better rather than obligation to replicate.

What this collection of disciplines adds up to is something Neal Ford and Rebecca Parsons called evolutionary architecture — systems designed to adapt through guided incremental change rather than periodic rewrites. The three mechanisms they identify map directly onto what the prototype disciplines create: appropriate coupling (domain module boundaries that let parts change independently), incremental change (deployable units small enough to be reversible, enabled by migration-based schemas and interface files), and fitness functions (the boundary test suite that verifies architectural properties — the interface contracts — hold after every change). The prototype built with these disciplines is not just easier to migrate. It is a system that can evolve continuously, absorbing change without accumulating the structural debt that eventually forces a rewrite. The migration patterns described above are not the destination. They are the evidence that the architecture is working as designed.

What the Prototype Disciplines Protect

The seam is the module boundary. Everything else follows from having drawn it deliberately.

Domain Gravity and the Migration

The disciplines above address what survives from the prototype. They do not address whether the prototype’s stack is the right substrate for the product’s second and third years.

Different domains have accumulated expertise and ecosystem depth in specific stacks, and that accumulation represents real leverage. Financial systems have decades of compliance tooling and institutional knowledge embedded in JVM ecosystems — Java and Kotlin won that domain not by preference but because the ecosystem was shaped by the actual demands of high-volume transaction processing and regulatory compliance. A fintech prototype that starts in Python should plan for the possibility that its transaction processing core will eventually need stronger type guarantees and richer compliance tooling.

Real-time systems have their own gravitational pull towards strong concurrency models. Elixir and Erlang exist because the telecom industry needed fault tolerance that most languages could not deliver architecturally. A product that starts as a Python messaging layer and grows into a real-time communication platform will at some point encounter constraints inherent to Python’s concurrency model, not to any specific implementation choice.

Machine learning has converged almost entirely on Python — not because it is fastest for numerical computation, but because the ecosystem of libraries, tooling, and practitioners is so concentrated there that building outside it means building without the compounding effect of that accumulated expertise. For ML-heavy products, Python is both the AI-fluent choice and the domain-correct choice. The prototype stack and the production stack are the same stack.

The migration in each case is not a correction of the original choice. It is a natural stage in the product’s maturation — pulled by specific, observed constraints rather than pushed by theoretical elegance. The disciplines of the prototype stage are what make each migration a bounded step rather than a crisis.

What This Looks Like End to End

A team building a two-sided logistics platform starts with Python + FastAPI + Vite + React. Before writing the first line of code, they create a CLAUDE.md defining the module structure, dependency rules, vendor wrapping policy, logging format, and frontend organisation. The AI agent reads this as context on every task.

The backend has domain modules: routes/, drivers/, customers/, notifications/. Supabase Auth handles authentication. Stripe handles payments. Google Maps handles geocoding. Each external service sits behind one interface file. Alembic migrations from the first table. Docker from day one. Correlation IDs in structured JSON logs. An ADR written for every non-obvious decision. One test file per module service interface, one mock-based test per external dependency wrapper.

The frontend has features/driver/, features/customer/, features/ops/. All API calls through src/services/. TanStack Query for server state. TypeScript types for every API response shape.

Six months later, twelve customers. The route optimisation engine takes eight seconds under load. The module boundary is already clean, the service interface already tested. A Go rewrite of that one module, validated against the existing test suite and confirmed with a parallel run on real traffic, takes three weeks. The rest of the system is untouched.

A year later, the driver experience needs a complete redesign. UI Composition: a new driver application built separately, calling the existing FastAPI backend through its clean API surface. The routing layer sends driver traffic to the new application. The customer experience is untouched.

Eighteen months in, expansion to a new market with compliance requirements that affect the customer product only. Extract Product Lines: the customer-facing backend migrates to a new stack with the required tooling. The driver product continues on the original system. The vertical slice discipline makes the boundary clean enough to migrate independently.

Two years in, real-time tracking volume exposes Python’s concurrency limits. The tracking/ module migrates to Elixir. Expand/Contract handles the schema migration without a maintenance window. The rest of the system does not change.

At no point was the original choice treated as permanent. At no point was anything rewritten for its own sake. The CLAUDE.md written before the first commit is the reason each migration remained a bounded step rather than a crisis.

The Right Stack at the Wrong Stage

The stack does not exist in isolation. It is part of a system that includes the team building on it, the AI tools assisting with that building, the domain it is solving problems in, and the stage of the product’s life.

The architecture template connects all these dimensions. It encodes the stack, the structural rules, and the conventions that give the AI a consistent context to work within. It also — as a byproduct of genuine discipline rather than premature optimisation — encodes the preconditions for the migration options that will be needed later.

The right stack at the wrong stage is a wrong choice. The wrong stack, built with the right disciplines, can still get you to the point where you can make a better decision — with real data, real constraints, and a codebase structured to support the change.

The right stack at the wrong stage is a wrong choice.

That is what separates products that compound from products that get stuck.

Ali Ahmed Thawerani writes about the systems, culture, and scale decisions that shape how technology organisations develop. TECTONICS publishes at aathawerani.github.io.

From Project to Product to Company — What the Transition Actually Requires

Sat, 16 May 2026 00:00:00 +0000

From Final Year Project to Startup

I spent part of today as a juror at Habib University’s Kaavish - final year project exhibition — walking out, I kept thinking about one thing.

How many of the projects I evaluated today are closer to a real business than their builders realise.

In a structural sense the foundations were solid. The problem domains were understood at a depth that only sustained engagement produces. The students had spent a year being accountable to real stakeholders — not a professor marking a rubric, but an organisation that actually cared whether the solution worked.

That kind of accountability is rare. It is also, not coincidentally, exactly what building a company feels like.

What follows is not an evaluation of what was built. It is an attempt to describe what the next step looks like — and why more students should be taking it.

What the Industry Already Knows

There is a reason companies invest in these programmes.

Industry partners who supervise final year projects are making a calculated observation: the students who spend a year solving a real problem, with real constraints, in a real organisational context, come out the other side with something that cannot be hired in through a job posting. They have domain depth. They have the scar tissue of a project that did not go exactly as planned. They have the experience of defending a position under pressure to people who are not obligated to be kind about it.

That is a foundation. The question that does not get asked enough — by the students themselves — is what to build on it.

The job market is one answer. It is not the only one. And for the students who spent a year genuinely caring about the problem they were solving, it may not even be the most interesting one.

Building your own thing is harder. It is also, if the problem is real and the understanding is deep enough, where the compounding begins. A job gives you a salary. A product built on genuine insight into a real problem gives you something that can outlast any single employer.

The Pattern Worth Noticing

The most consequential technology companies tend to start the same way — not with a unique idea, but with an unusually deep understanding of a specific problem, and the decision to take that understanding seriously.

Sualeh Asif grew up in Karachi and went on to MIT. While still a student there, he and three classmates built Cursor — an AI-powered coding environment — because they were frustrated with the tools developers already had. They made the problem personal before they made it a company. Cursor grew into one of the fastest-growing AI startups in recent memory, a valuation that places it among the most valuable developer tools companies in the world. Sualeh is 26.

Aaqib Gadit built Cloudways in Pakistan — a managed cloud hosting platform that made enterprise-grade infrastructure accessible to small businesses who could not afford the complexity that came with it. He focused on one problem, solved it with unusual care, and stayed close enough to his users to keep understanding what they actually needed. DigitalOcean eventually acquired Cloudways.

Neither of these started with an original idea. Both started with an unusually honest understanding of a specific problem — and the decision to stay with it long enough for that understanding to compound into something real.

That same starting point exists for many of the projects being built in universities right now.

The Space Is Never Empty. That Is Not the Problem.

Here is the assumption that trips up more early-stage projects than any technical challenge: that a good idea needs an empty space to exist in.

It does not. The space is never empty. Every problem worth solving already has someone working on it. The question is not whether competition exists. It is whether you understand your specific user well enough to find the detail that nobody else has handled yet.

Simon Sinek’s framing is useful here, though not in the way it usually gets applied. Start With Why is not about mission statements. It is about the prior question: why would a specific person choose your solution over what already exists? If you cannot answer that for one real person in one real situation, you do not yet have enough information to make good decisions about what to build.

Consider Bykea. It entered Pakistan’s ride-hailing market when Uber and Careem were already well established. Rather than competing on the same terms, it identified a specific user the existing platforms were not designed for — someone navigating dense urban traffic, needing an affordable short-distance ride, for whom a motorcycle was faster and cheaper than a car. That specificity was not a limitation. It was the entire strategy. Bykea did not try to serve everyone. It chose one user, understood that user’s actual day, and built around what that day required.

The Need Behind the Need

There is a further distinction worth making — between the problem a user will tell you they have and the problem that is actually costing them.

Users are good at describing symptoms. They are less reliable at diagnosing the underlying cause, because they have often adapted around it so completely that it no longer registers as a problem. It has become the way things are. The friction has been normalised. The workaround has become the workflow.

The most valuable products are rarely built on the problem users articulate. They are built on the problem that reveals itself only when someone pays close enough attention to how things actually work — not how they are supposed to work, not how the user describes them working, but what actually happens when a real person attempts to do a real thing in a real environment.

Careem did not discover that cash payments were necessary because someone asked for them. They discovered it because someone tried to pay with a card and could not. That moment — observed closely enough to be acted on — is where the insight came from. The same goes for building their own mapping system in a region where reliable street addresses did not consistently exist. Nobody filed a complaint about street addresses. The problem revealed itself only to someone paying close enough attention to how the experience actually worked. The need was always there. It took someone living close enough to it to see it.

This is what sustained engagement with a problem produces that no survey or user interview can replicate. The hidden need. The friction so embedded in the experience that the person experiencing it has stopped seeing it as friction. Finding that detail — and building something that addresses it — is where the most durable differentiation lives.

The students who spent a year embedded in a real domain, working alongside real organisations, have been closer to that kind of observation than most. The question is whether they were paying attention to it.

What a Company Cares About That a Demo Does Not Have To

A demo proves something can work. A company proves it keeps working — when the data looks different from what was expected, when users approach the problem from angles the design did not anticipate, when the conditions that felt stable turn out to be in motion.

The companies that endure are not the ones that predicted every change. They are the ones that built mechanisms to detect and respond to change as it happened. That distinction is structural. It is also designable — but only if it is thought about before the system is deployed, not after the first failure.

When inDrive entered Pakistan’s ride-hailing market, Uber and Careem were already established. Its core insight was not technical — it was structural. Instead of fixing prices algorithmically, inDrive let passengers and drivers negotiate directly.

That decision turned pricing into a feedback loop. Each ride became a data point — not captured after the fact, but embedded in the transaction itself. The market was not being predicted. It was being expressed.

That is why the model worked. It did not assume it knew the right answer. It created a mechanism for the right answer to emerge. Careem subsequently launched its own negotiation feature in direct response — the clearest possible signal that the late entrant had found something the market had been waiting for.

This is what a feedback loop means in a product context. Not ratings collected after the experience, but a system where real usage continuously shapes what happens next. The mechanism does not have to be complex. It has to be deliberate — designed in from the beginning, not added after the fact.

That deliberateness is what separates products that compound from products that stagnate. And it is as applicable to an AI pipeline as it is to a pricing model. Which is where the next section begins.

AI Is the Canvas. The Detail Is Still the Work.

Almost every project I evaluated today used AI in some form — LLMs, RAG pipelines, computer vision models, fine-tuned classifiers. And the starting point worth acknowledging is this: the barrier to building something real has never been lower. A working prototype that would have required a team of engineers and months of effort a decade ago can now be assembled in days. The cost of testing whether a problem is real, whether a solution resonates, whether the hidden need you identified actually exists, has collapsed. A student with a well-understood problem and access to current tools can put something in front of real users faster than most funded startups could five years ago. That changes the calculus of risk significantly — the excuse of not having enough resources to validate an idea is largely gone.

What impressed me was the fluency with which this generation of students has absorbed these tools. The ambition to apply them to genuinely hard problems — language preservation, accessibility, financial infrastructure, public health — was real and in several cases quite sophisticated.

The students who will build the most durable things are the ones who go one layer deeper: not just using the model, but understanding what it is actually doing well enough to know where it will hold and where it will not. A RAG pipeline that retrieves accurately from a curated corpus behaves differently on messy real-world data. An agent that navigates known scenarios encounters something different at the edges of its training distribution. The devil, as always, is in that detail — and the detail only reveals itself to someone who has thought carefully about the seams.

That deeper understanding is also what makes a feedback loop possible in an AI system — and a feedback loop is precisely what turns a capable pipeline into a differentiating product.

Just as inDrive embedded the market’s response into the transaction itself, an AI system can embed the user’s response into the pipeline — capturing when the output was useful, when it missed the mark, and how the context differed from what the model assumed.

In both cases, the system is not just producing an answer. It is learning from what actually happens when that answer meets the real world. In a market where the underlying models are increasingly commoditised, that mechanism is where the real differentiation lives.

What is equally underappreciated is that AI can teach about AI. The process of understanding which approach fits a given problem — whether a fine-tuned model serves better than a RAG pipeline, whether a classification algorithm is more appropriate than a generative one, whether the problem calls for computer vision or structured prediction — is itself a conversation that current tools can facilitate. The students who treat AI as a thinking partner in the design process, not just an implementation tool, will develop intuitions about these choices faster than any curriculum can deliver.

Building It Is Not the Same as Bringing It to the World

There is a generation of engineers ahead of you who built genuinely useful things that nobody ever found. Not because the product was weak. Because the path from a working product to a user who knows about it, chooses it, pays for it, and stays with it — is its own discipline, as demanding as the engineering itself.

The technical problem and the commercial problem are different problems. Solving one does not solve the other. And the commercial problem — how does this reach the people who need it, at a price that sustains the work, through a channel they actually use — is one that engineering training rarely addresses directly.

Previous generations of engineers largely had to discover this on their own. That gap in awareness was the norm. It is less excusable now, not because the challenge is smaller but because the knowledge is more accessible. There are more examples, more frameworks, more founders who have documented what they learned. The raw material for understanding commercialisation is available in a way it has never been before.

What that understanding actually requires, in practice, is thinking through a few questions that the product alone cannot answer.

Who pays for this — and is that the same person who uses it? In many of the projects built this year, the user and the economic buyer are different. A platform built for students may be paid for by an institution. A tool built for farmers may be funded by an agricultural development programme. Understanding that distinction changes how you price, how you sell, and what features matter most to whom.

How does someone discover this exists? A product that solves a real problem is still invisible until it reaches the person who needs it. The channel through which a potential user encounters and evaluates your solution is as much a design decision as the interface itself. Cloudways grew largely through word of mouth within communities of developers and small business operators — because the product was good enough that the people using it told others. That was not accidental. It was the result of understanding who the early user was well enough to build something they would naturally recommend.

What does it cost to serve one user, and does the price reflect that? The projects built this year were almost universally free at the point of use. That is appropriate for a capstone. It is not a sustainable default for a product. Understanding the economics of delivering value — what it costs, what a user would pay, where the margin lives — is the layer of thinking that turns a technically sound product into something that can sustain itself and the people building it. Sometimes the pricing model itself is the insight. inDrive did not just build a negotiation feature — it recognised that in a price-sensitive market, letting users and drivers agree on a fare directly was more trusted than any algorithm. The price became the product’s clearest signal of respect for its users.

None of this requires a business degree. It requires the same disposition that produced the product in the first place: curiosity about how things actually work, willingness to sit with the uncomfortable questions, and enough respect for the user to understand not just what they need but what they will actually do.

The Thing That Does Not Show Up in the Demo

The projects that stayed with me after today were not always the most technically sophisticated. They were the ones where the student had made the problem genuinely their own.

That is harder to describe than it is to recognise. It shows in how questions are answered — not whether they are answered, but whether the student reaches for their own understanding or for a prepared response. It shows in the honesty with which limitations are acknowledged. It shows in the specificity of what they would build next, and why.

That kind of ownership does not come from the project structure. It comes from caring about the problem independently of the deadline — thinking about it outside supervised hours, noticing its dimensions in daily life, having views about what the second version should look like before the first one is finished.

It is also the quality that matters most when the academic structure falls away and the only reason to keep going is that you believe the problem is worth solving.

Cursor was built by students who were genuinely frustrated with their own tools. Cloudways was built by someone who believed small businesses deserved infrastructure they could actually use. Careem was built by someone who grew up in Karachi and understood urban mobility in this part of the world at a level that no amount of research could replicate.

In each case, the problem was personal before it was a company. The passion came first. Acting on it came from trusting that the understanding was real.

What the Next Step Actually Requires

A project answers one question: can this be built? A product answers a harder one: will someone use this repeatedly, when nobody is asking them to? A company answers the hardest one: can this survive in the real world, when the conditions change and the original assumptions no longer hold?

Projects prove you can build. Products prove someone cares. Companies prove it survives.

For anyone who built a final year project this year — at any institution, on any problem — the questions worth sitting with are simpler than they might appear.

Do you know the specific person your solution is most useful for — precisely enough to describe a day in their life? Do you know what already exists for them, and exactly where it falls short? Do you have a mechanism by which your system will learn from what actually happens when real people use it? And do you understand what it costs to serve one user, who pays for it, and how they will find out it exists?

These are not business questions layered on top of engineering. They are the next layer of the same problem you have already been working on. The domain knowledge is already there. The year of engagement already happened. The foundation is already built.

The advantage you have right now is not just insight. It is time — the freedom to explore a problem before the world forces you to move on. That window is real, and it is finite.

What happens with it next is yours to decide. And that decision is where most projects either end — or begin.

TECTONICS is a series about how technology organisations actually move — the systems, culture, and scale decisions that determine whether they compound or collapse.

Why Architecture Is Shifting From Diagrams to Guardrails

Sat, 09 May 2026 00:00:00 +0000

The Cheaper Rewrite Is Not the Better Rewrite

The previous post in this series argued that AI has lowered the cost of rewrites without lowering the knowledge required to do them well — and that without architectural discipline governing the process, the result is a perpetual rewrite loop: each iteration faster, each iteration less understood than the last [1].

This post does not contradict that argument. It assumes it.

The previous post described a hard limit: cognitive load ceilings are real, and AI accelerates how quickly teams hit them. The question this post addresses is not how to remove that ceiling — it cannot be removed. It is how to move knowledge out of human cognition and into systems that can preserve, enforce, and evolve it. Specifications. Tests. Architecture as Code. Structured ADRs. These are not workarounds for the cognitive load problem. They are the engineering response to it — externalising what human working memory cannot hold so that AI can be constrained by it rather than unaware of it.

Three preconditions distinguish a rewrite that produces a genuinely better system from one that restarts the same problems faster. Each precondition raises a deeper question about the role of AI in its own governance — questions the industry is only beginning to ask seriously.

Why the Same Problems Keep Returning

Joel Spolsky’s 2000 “never rewrite” doctrine was an economic argument, not a technical one [2]. Rewrites were expensive not primarily because of engineering hours but because of institutional knowledge — the years of edge cases, discovered constraints, and behavioral understanding embedded in existing systems in ways that were difficult to extract and easy to lose.

AI has changed the engineering hour cost substantially. It has not changed the institutional knowledge problem. And it has introduced a new pattern that makes that problem harder to manage.

Call it architecture by reaction (a pattern named here — no established prior term exists for this specific dynamic): AI addresses the problem in front of it at each stage of a system’s evolution, without reference to the architectural decisions made in previous stages.

Consider a typical trajectory:

v1 — monolith, perfectly reasonable for MVP scale
v2 — scalability issues hit, AI decomposes into microservices
v3 — latency problems emerge, AI introduces caching and async messaging
v4 — data inconsistency surfaces, AI reintroduces shared state patterns to resolve it

Each step is locally correct. Globally, the system has regressed — the shared state in v4 recreates the coupling that the microservices decomposition in v2 was designed to eliminate. No single decision was wrong. The sequence, without accumulated memory of why earlier decisions were made, produced the same problem in a different form.

AI has no memory of v2’s rationale when it generates v4. The institutional knowledge that would say “we moved away from shared state at this boundary precisely because of consistency problems — do not go back” is not in the prompt unless someone put it there. The same structural mistakes recur not because AI lacks intelligence, but because intelligence without memory is just pattern matching.

This dynamic has a name in the practitioner literature. A widely-discussed critique of agentic coding identifies what it calls the supervision paradox: you need the engineering skills the agent erodes in order to oversee what the agent produces [3]. The more you delegate to AI, the less capable you become of catching what AI gets wrong — and the more you need that capability precisely because AI is generating more that could go wrong. This post does not disagree with that diagnosis. It proposes that the answer is not to delegate less, but to move the supervision from inside the developer’s head into the governance system — where it can operate at scale, persist across team changes, and accumulate rather than erode over time.

Architecture Decision Records (ADRs) are the established mechanism for preserving exactly this institutional memory [4]. An ADR captures not just what architectural decision was made but why — the context, the options considered, the trade-offs accepted, and the consequences anticipated. Fed to AI as context at the start of a rewrite, a library of ADRs is the closest available substitute for the accumulated experience AI lacks. The critical content is not the decision itself but the rejected options and their rationale — “we considered service decomposition at this boundary and rejected it because X” is the institutional memory that prevents the same mistake in the next iteration. Without it, AI has no way of knowing what was tried and failed, and will reproduce the same rejected approaches dressed in newer patterns.

The three preconditions below are not just preparation for a rewrite. They are the mechanisms by which institutional knowledge is preserved across AI-assisted iterations — making it available to the next rewrite, and the one after that. ADRs are the connective tissue between them.

Key Insight: AI has lowered the cost of producing code without lowering the cost of understanding it. A rewrite that proceeds without adequate knowledge of the existing system’s domain behavior and failure modes is not cheaper — it is a faster way to accumulate the same debt.

Precondition One: Requirements as Specifications

Most AI-assisted rewrites fail before a line of code is written. Not because the model is wrong — but because the requirements are.

The distinction that matters is between requirements as prose and requirements as specifications. Requirements written as prose describe intent in natural language — interpretable, ambiguous, dependent on human judgment for translation into implementation. AI tools reading prose requirements produce implementations consistent with one plausible reading, not necessarily the reading that reflects the domain constraints and behavioral expectations that matter in production. Prose requirements are instructions. Specification-grade requirements are constraints. AI follows instructions probabilistically. Constraints matter because violations can be detected and rejected automatically.

This principle has been formalised in the industry as Spec-Driven Development (SDD) — a methodology that elevates specifications to executable system truth, making architecture enforceable through continuous validation while AI generation materializes intent into code [5]. SDD’s core distinction, as articulated by Griffin and Carroll, is that traditional specifications are read by humans while SDD specifications execute as validation gates — if code diverges from the spec, the build fails. The industry is converging on this from multiple directions: practitioners building with AI agents have independently arrived at similar conclusions, finding that writing feature specifications in structured formats rather than natural language prompts substantially reduces AI’s tendency to generate plausible but contextually wrong output when given ambiguous instructions [6].

Requirements written as specifications are structured, verifiable, and precise enough to function as constraints on AI generation rather than guidance for it. They encode not just what the system should do but what it must not do, what invariants must hold, and what the consequences of violating those invariants are [7].

The objection that immediately arises: this exercise was already done when the first version was built. Why repeat it?

The answer is that it was done, but not in this form. The domain knowledge exists — in the original requirements documents, in production incident records, in the heads of engineers who built and maintained the system. What does not exist is that knowledge translated into a format that AI can consume as a constraint rather than guidance. And crucially, the domain has evolved since the first version. New edge cases have been discovered in production. New business rules have been added. Constraints have emerged from real usage that were not in the original specification.

The practical answer is to use AI to accelerate the translation process rather than relying on humans to author everything manually (proposed approach — no established prior source covers this specific workflow). The process is more tractable than it sounds:

Feed the existing requirements documents, production incident records, change request history, and any available domain documentation to AI. Ask it to identify gaps, ambiguities, and contradictions. Ask it to generate clarifying questions about what is unclear — specifically around invariants, failure modes, and boundary conditions. Have domain experts answer those questions. Feed the answers back. AI reformats the output as structured, verifiable specifications that can be used to constrain subsequent generation.

This is not a documentation exercise driven by human effort. It is an AI-assisted extraction and clarification process in which human expertise is the validator rather than the primary generator. The domain experts are answering targeted questions, not authoring documents from scratch. The difference in time and effort is substantial.

The result is a specification that encodes what the system must do precisely enough that AI can be held to it — and precisely enough that deviations from it can be detected automatically.

Key Insight: The quality of an AI-assisted rewrite is bounded by the quality of the requirements that govern it. AI can extract, clarify, and reformat existing knowledge into specification-grade constraints — but human validation of those constraints against real domain understanding is not optional.

What a specification-grade requirement looks like in practice deserves a concrete example. UML use case specification — with its actor, precondition, main flow, alternate flows, postcondition, and exception flows structure — has been the established standard for capturing behavioral intent precisely since the 1990s [8]. The format is well-understood by domain experts and captures branching behavior more naturally than flat invariant statements.

However, the standard UML use case format was designed for human-to-human communication, not human-to-AI constraint. It lacks three things that make a specification machine-consumable: a falsifiable invariant that AI can translate directly into a test assertion, a violation consequence that encodes the business cost of non-compliance, and linkage to the ADR and fitness function that enforce the decision architecturally.

The following format is a proposed concrete implementation of SDD principles — combining the established UML use case flow structure with YAML front matter for machine-readable metadata. SDD prescribes that specifications should be executable and authoritative; this format is one way of achieving that at the requirement level. No single established prior source prescribes this specific combination:

---
id: SPEC-017
title: Payment processing idempotency
type: safety-invariant      # safety | liveness | business-rule | performance
affects: [payment-service]
bounded-contexts: [payment]
verified-by: TEST-041
linked-adr: ADR-033
---

## Actor
Payment consumer (internal service or external client)

## Precondition
- Payment request contains a valid idempotency key
- Payment service is operational

## Main Flow
1. Consumer submits payment request with idempotency key K
2. System checks idempotency log for key K
3. Key not found — system processes payment and records outcome against K
4. System returns payment result

## Alternate Flow: Duplicate Submission
1. Consumer submits payment request with idempotency key K
2. System checks idempotency log for key K
3. Key found — system returns stored outcome, no new charge created
4. Idempotency log records duplicate attempt as no-op

## Exception Flow: Timeout During Processing
1. Consumer submits payment request with idempotency key K
2. System begins processing, timeout occurs before outcome recorded
3. Consumer retries with same key K
4. System detects in-progress state — waits for completion or rolls back cleanly
5. Returns consistent outcome — no duplicate charge under any scenario

## Postcondition
- Exactly one charge exists for any given idempotency key
- Idempotency log contains record of all attempts

## Invariant (machine-verifiable)
forall requests r1, r2: r1.idempotency_key == r2.idempotency_key
  => outcome(r1) == outcome(r2) AND charges_created == 1

## Violation Consequence
Duplicate charges. Regulatory breach. Chargeback liability.

## Out of Scope
Cross-service idempotency — see SPEC-018

Three fields in the YAML front matter make this more than a use case document. The type field allows AI to apply different validation strategies to safety invariants versus performance constraints. The verified-by link connects the specification directly to its test, so AI generating a fix for a failing test can immediately identify the specification it must satisfy. The linked-adr closes the loop to the architectural decision that enforces the boundary structurally — giving AI a connected graph of intent rather than an isolated document.

Precondition Two: Tests as Behavioral Contracts

The most expensive tests in an AI-assisted rewrite are not the ones that fail. They are the ones that pass — on code that looks correct but preserves the old system’s structural problems in new form.

The second precondition follows from the first. If requirements are specifications, tests are their executable form — the mechanism by which specification compliance is verified continuously rather than asserted once at the point of writing. A test suite that cannot survive an architectural change is not a safety net. It is an anchor.

The distinction that matters for a rewrite is between tests written against implementation and tests written against behavior. Tests written against implementation internals — specific classes, methods, internal data structures — are tightly coupled to the architecture of the system they were written for. Carrying them into a rewrite anchors the new implementation to the old architecture, defeating the purpose of the rewrite. Tests written against behavior — describing what the system does from the perspective of the actors that depend on it — travel across a rewrite cleanly and give AI a verifiable target without prescribing internal structure [9].

The practical implication: unit tests that test internal structure should largely be discarded. Integration and acceptance tests written at behavioral boundaries are the primary inheritance from the old system. Consumer-driven contract tests, which encode the behavioral expectations of each service consumer without prescribing how those expectations are satisfied, are particularly valuable in this context [10]. Property-based tests, which assert that invariants hold across entire categories of inputs rather than specific examples, encode behavioral contracts at a level of generality that constrains AI generation effectively and surfaces edge cases that example-based tests miss [11].

What is missing from this picture — and should not be — is the production system itself as a source of test evidence (proposed workflow — the Meta paper [12] covers AI-assisted test generation but the specific practice of using production logs to identify redundant tests alongside missing ones is an extension proposed here).

Production logs, distributed traces, and incident records contain the most accurate description of how a system actually behaves under real conditions. They reveal execution paths that tests do not cover, edge cases that design-time reasoning did not anticipate, and behavioral patterns that exist in production but have no corresponding assertion in the test suite. AI can read this evidence and act on it systematically:

Analyse production logs and traces to identify execution paths with no corresponding test coverage — and generate candidate behavioral tests for those paths
Identify tests in the existing suite that assert behavior that production logs show never actually occurs — candidates for removal as they test assumptions rather than reality
Surface behavioral patterns that appear consistently in production failures and generate property-based tests that encode the invariant being violated

This is not speculative. AI-assisted test generation tools are already moving in this direction. The key shift is treating the production system as a continuous source of specification evidence — a record of what the system actually does and what it actually fails to do — rather than relying solely on design-time test authorship [12].

The test suite that emerges from this process is smaller, more behaviorally accurate, and more useful as AI generation guidance than a test suite authored entirely at design time. It also forms the foundation of the feedback loop — each production failure that reveals a missing behavioral contract can be encoded as a new test, and each test added after a failure closes the loop between what the system actually does and what the specification says it should do.

Key Insight: Production logs and traces are the most accurate specification of system behavior available. AI can read them to identify missing behavioral contracts, remove tests that assert fictional behavior, and generate property-based tests that encode the invariants production failures reveal.

Precondition Three: Architecture as Code

The first two preconditions constrain what the system does. This one constrains what the system is allowed to become.

Architecture documentation that lives in a wiki is not architecture governance. It is archaeology — a record of decisions that may or may not reflect what the system currently does, consulted when something breaks and someone needs to understand why.

The third precondition addresses how architectural intent is preserved and enforced in a world where AI generates code faster than human review can evaluate it. Documentation describes. Architecture as Code enforces. The difference is not cosmetic — it is the difference between a rule someone might read and a constraint the build will not pass without satisfying.

Architecture as Code is the established term for this approach [13]. Rather than documenting architecture as diagrams and prose that drift from reality the moment development begins, Architecture as Code treats architectural decisions as version-controlled, executable artifacts — constraints that can be evaluated programmatically, validated automatically, and enforced continuously in the CI pipeline.

The tooling landscape for this is mature. Structurizr allows C4 architecture models to be defined in code and kept alongside the codebase they describe [14]. ArchUnit encodes dependency rules as executable tests — for example, asserting that no class in the domain package imports from the infrastructure package, and failing the build if that rule is violated [15]. Dependency Cruiser provides equivalent capability for JavaScript and TypeScript ecosystems [16]. Custom linting rules can encode naming conventions, interface contracts, and module boundary constraints. Together these form an architectural specification that is not a document — it is a set of constraints that run on every commit.

AI doesn’t violate architecture. It obeys whatever architecture you forgot to encode. This is why encoding matters more than reviewing. A dependency rule that exists only in a team norm will be violated the first time AI generates code under time pressure without that norm in its context. A dependency rule encoded as an ArchUnit test will fail the build regardless of what AI generated, who reviewed it, or how much pressure the team was under.

The question of whether humans are required deserves a direct answer. AI can detect violations of encoded rules automatically and reliably. What it cannot yet do reliably is judge whether the rules themselves are correct — whether the boundary drawn between two bounded contexts reflects the actual domain structure or an outdated assumption, whether a dependency rule encodes a meaningful architectural intent or an arbitrary historical constraint. The enforcement of rules once defined can be fully automated. The definition of the right rules still requires human architectural judgment.

Whether AI can validate that the architecture is consistent with the requirements is an open and important question. In principle — if requirements are written as specifications and architecture is encoded as executable constraints — AI can evaluate whether the structural rules are consistent with the behavioral requirements. In practice, the translation between a behavioral specification and an architectural rule is still a judgment that current AI cannot make reliably. This is an active area of development, not a solved problem. For now, that translation requires a human who understands both the domain and the architectural intent.

The 80-90% similarity risk deserves explicit acknowledgment. If AI generates code against the same domain, similar requirements, and a structurally similar architectural specification, there is a genuine risk that it produces something architecturally close to what it would have produced without the preconditions — because the preconditions narrow the solution space toward correct behavior without necessarily producing a different structure. The architectural specification must be written to encode the improvements the rewrite is meant to achieve, not merely to describe the old architecture more precisely. If the old architecture had a coupling problem between two bounded contexts, the new specification must encode a rule that prohibits that coupling — making the old structure architecturally invalid rather than merely undesirable. Without this deliberate encoding of improvements, AI will gravitate toward familiar patterns and the rewrite will produce a structurally similar system dressed in newer code.

Reference architectures address this risk more directly than custom specifications alone. A reference architecture is a pre-defined architectural template for a specific class of problem — a known good structural solution encoding proven patterns, boundary definitions, technology choices, and integration approaches for a well-understood domain or system type [17]. Examples include Microsoft’s Azure Reference Architectures for cloud workloads, the AWS Well-Architected Framework for distributed systems, and domain-specific reference architectures for healthcare data platforms or financial transaction processing. Where a custom architectural specification mostly encodes what is not allowed — prohibiting the structural problems of the old system — a reference architecture encodes what should be present: which service boundaries are appropriate, which communication patterns are proven, which integration approaches have accumulated the most operational evidence.

Providing a reference architecture as context to AI during generation meaningfully shifts its output distribution away from average training data patterns toward known good structural decisions. This is the practical realisation of your instinct about AI behaving as a junior architect: a junior architect given a reference architecture will apply it faithfully in the common cases it covers, producing better-than-average structural decisions without requiring the depth of experience that would generate those decisions from scratch.

The nuance — and it is important — is that junior architects given a reference architecture struggle precisely in the cases where it does not quite fit: where the specific domain has requirements the reference architecture’s authors did not anticipate, and where judgment is required about when to follow the template and when to deviate. AI behaves identically. It applies a reference architecture well in the cases it covers and produces structurally questionable output in the edge cases it does not — without signalling that it is doing so. The human architect’s role in this model is specifically to identify where the reference architecture does not fit the domain and to encode those deviations explicitly, rather than relying on AI to exercise correct judgment about them independently.

Reference architectures also carry known anti-patterns — structural decisions that look reasonable but have failed repeatedly in practice for this class of system. Encoding these as constraints alongside the reference architecture’s positive guidance gives the Architecture as Code specification a head start on the feedback loop: teams can encode known failure modes preemptively from the reference architecture’s accumulated experience, rather than discovering them through production failures and adding fitness functions after the fact.

The instinct to encode known good domain structure predates AI by decades. Silverston’s Data Model Resource Book did it at the data layer with pre-built ERDs for core business domains [18]; Arlow and Neustadt’s Enterprise Patterns and MDA did it at the domain model layer with reusable UML archetype patterns [19]. Both embodied the same principle: here is the known good structure for this class of problem, available to accelerate design without requiring every team to rediscover the same solutions. What changes with AI is not the value of that accumulated knowledge but the mechanism of its consumption — from a human reading a reference book to AI consuming structured constraints and applying them directly during generation.

Key Insight: Architecture as Code shifts architectural governance from design-time documentation to continuous automated enforcement. Reference architectures, encoded as executable constraints, shift AI’s output distribution from average patterns toward known good structural decisions — making the similarity risk significantly smaller. But the cases where the reference architecture does not fit the domain still require human judgment to identify and encode explicitly. AI enforces rules. Humans must ensure the rules are the right ones.

What a fitness function looks like in practice deserves a concrete example. Architectural fitness functions are an established concept from Ford, Parsons, and Kua [20]. The specific format below — with YAML metadata linking each fitness function back to its ADR and specification — is a proposed extension of the established concept, designed to make the governance chain machine-navigable rather than dependent on human knowledge of which rule enforces which decision:

---
id: FF-019
title: Payment domain must not import from infrastructure layer
enforces-adr: ADR-042
enforces-spec: SPEC-017
tool: ArchUnit           # ArchUnit | DependencyCruiser | custom-lint
severity: build-fail     # build-fail | warning | metric
threshold: 0             # zero violations permitted
---

## Rule (ArchUnit Java example)
@ArchTest
public static final ArchRule paymentDomainIsolation =
  noClasses()
    .that().resideInAPackage("..payment.domain..")
    .should().dependOnClassesThat()
    .resideInAPackage("..infrastructure..");

## What This Catches
Any class in the payment domain package importing from infrastructure —
database clients, HTTP clients, messaging adapters, framework annotations.

## What This Does Not Catch
Intent drift — whether the boundary itself is still the right one.
That requires periodic human architectural review.

## Conditions for Relaxing
Only with a corresponding ADR update explaining why the boundary
is being changed and what replaces the isolation guarantee.

Three fields in the metadata make this format more than an automated test. The enforces-adr and enforces-spec links mean the fitness function is not a free-floating rule — it is the enforcement arm of a documented decision with documented rationale. When it fails, AI can look up why the rule exists before generating a fix, rather than treating the violation as a style preference to be worked around. The conditions for relaxing field is the most important: it prevents AI from simply disabling or weakening the rule when it blocks generation, by requiring a corresponding ADR update that documents why the architectural boundary is being changed.

Keeping Everything Current as AI Writes Code

The three preconditions address the starting conditions for a well-governed rewrite. A harder problem is maintaining those conditions as the rewritten system evolves — keeping requirements, tests, and architectural constraints current as AI continues to generate code after the rewrite is complete.

The drift problem is structural. AI generates decisions faster than humans can document them. Without active intervention, the gap between the specified architecture and the actual architecture widens continuously.

Three practices mitigate this effectively:

Architecture as a definition of done. Every pull request that changes architectural structure — introduces a new dependency, crosses a module boundary, adds an external integration — should require a corresponding update to the architectural specification. Making this a gate on merge rather than a post-hoc obligation is the difference between a living specification and a documentation graveyard.

Structured ADRs as machine-consumable memory. Traditional ADRs — lightweight Markdown documents storing title, status, context, decision, and consequences — were designed for human readers [4]. For AI consumption they need to be enriched. The format below is a proposed extension of Nygard’s original ADR format — adding machine-readable fields, structured rejection rationale, fitness function linkage, and explicit conditions for revisiting that no established prior format includes:

---
id: ADR-042
title: Payment service owns its own data store
status: accepted          # proposed | accepted | deprecated | superseded
date: 2024-03-15
supersedes: []
superseded-by: []
affects: [payment-service, order-service]
tags: [service-boundary, data-ownership, consistency]
fitness-functions: [FF-018, FF-019]
---

## Context
[narrative prose describing the problem]

## Options Considered
- Option A: Shared database
  rejected-because: [structured rationale]
- Option B: Event-driven sync
  rejected-because: [structured rationale]
- Option C: Service owns its data — SELECTED

## Decision
[prose]

## Consequences
[prose]

## Conditions for Revisiting
[explicit statement of what would need to change for this decision
to be reconsidered — e.g. "reconsider if team grows beyond 15 engineers"]

Three fields make this format significantly more valuable than prose ADRs for AI consumption. But before explaining them, the framing matters: the most valuable part of an ADR is not the decision. It is the memory of what failed.

The rejected options and their rationale are the institutional memory that prevents AI from reproducing the same approaches in the next rewrite. The fitness-functions link connects rationale to enforcement, so when a fitness function fails AI can look up why the rule exists before generating a fix. The conditions for revisiting field encodes the judgment about when a superseded decision might become relevant again — preventing AI from applying outdated decisions in contexts where circumstances have changed enough to warrant reconsideration.

AI-assisted architecture extraction. Tooling can infer the actual architecture of a codebase from its structure — generating dependency graphs, identifying coupling hotspots, surfacing module boundary violations, and comparing the actual architecture against the specified one [21]. Used in the CI pipeline, this provides continuous validation that the specified and actual architectures remain aligned. Divergences surface as build failures rather than as gradual invisible drift.

Periodic architectural review as a structured practice. Fitness functions catch rule violations. They do not catch intent drift — the gradual divergence between what the architecture was designed to achieve and what the business now requires of it. This requires human judgment applied periodically: reviewing whether bounded contexts still reflect the domain, whether dependency rules still encode the right constraints, whether the fitness functions are testing the right properties. In an AI-assisted environment this review should happen more frequently, not less — the pace of change is higher and the signals of drift are subtler.

One failure mode of this governance model deserves naming directly, because it is the most insidious. Specifications do not prevent drift. They relocate it. A stale specification is more dangerous than missing documentation — because it is enforced. When a specification drifts from the domain it was written to represent, the governance system does not weaken. It continues enforcing with the same confidence, against constraints that are no longer correct. The system will fail exactly as specified, even when the specification is wrong. AI generation without constraints produces chaos. Constraints without understanding produce systems that fail more quietly. The periodic architectural review is not optional overhead — it is the mechanism that distinguishes a living governance system from an increasingly authoritative record of outdated decisions.

The Feedback Loop: From Production Failures to Architectural Improvement

Production failures are not incidents to be resolved. They are specifications the system wrote for itself — evidence of behavior the design did not anticipate and the test suite did not encode. Every failure that produces only a fix and no updated specification is institutional knowledge discarded.

The preceding sections address how to govern a rewrite and maintain that governance over time. They do not fully address the hardest challenge: using the failures that production systems generate as input for architectural improvement rather than local fixes.

When a production system fails, the failure is a symptom. The architectural cause — a boundary violation, a dependency assumption, a domain concept that has drifted from its implementation — is typically not visible in the failure signal. An alert that fires because payment processing is slow does not say “this is caused by a bounded context boundary eroded in the last rewrite.” A timeout under load does not say “this is caused by coupling between the order domain and inventory domain introduced when AI generated code without reference to the domain model.”

Translating failure symptoms into architectural causes requires a human who understands both the failure and the system’s architectural intent. This is exactly the category of understanding that architecture by reaction erodes over time. The less institutional knowledge the team has accumulated, the harder it becomes to diagnose failures as architectural problems rather than implementation bugs.

What can be structured is the process:

Every significant production incident should include an architectural review step — a deliberate question of whether the failure reveals a structural issue the fitness functions did not catch. Failures that reveal architectural issues should produce not just a fix but an updated fitness function — a new automated check that would have caught the structural problem earlier. Requirements that production failures expose as incomplete should be updated as specifications. Tests that production failures reveal as missing should be generated from the failure evidence and added to the suite.

This is how the feedback loop accumulates rather than degrades — not by automating away the need for architectural judgment, but by encoding the results of that judgment into the specifications, tests, and fitness functions that govern future generation. Each iteration of the loop, if run deliberately, leaves the system better specified than it was before the failure. Each iteration run carelessly — patching the symptom, leaving the cause unaddressed — leaves the system slightly less understood.

The honest answer to whether this loop can be made reliable is: more reliable, not fully reliable. The boundary of its reliability is the depth of human architectural understanding available to operate it. That understanding is the one resource AI cannot generate on demand — and it is the one resource that architecture by reaction systematically erodes.

Key Insight: The feedback loop between production failures and architectural improvement accumulates knowledge when failures produce updated specifications, new fitness functions, and additional behavioral tests. It degrades when failures produce only local fixes. The difference is not tooling — it is whether the team has retained enough architectural understanding to diagnose the cause rather than just treating the symptom.

What This Means for Engineering Leaders

Three practices distinguish organizations that navigate AI-assisted rewrites well from those that restart the same cycle faster.

Use AI to extract and reformat institutional knowledge, not to replace it. The domain knowledge required for specification-grade requirements already exists — in requirements documents, incident records, change histories, and the experience of engineers who built and maintained the system. AI can extract it, surface gaps, ask clarifying questions, and reformat it into machine-consumable specifications. Human domain expertise is the validator of that output, not the primary author of it. The investment is in structuring the extraction process, not in authoring from scratch.

Treat the CI pipeline as the primary architectural governance mechanism. Human architectural review cannot operate at the speed AI generates code. Fitness functions, dependency rules, and structural tests in the CI pipeline can. Every architectural rule encoded as an automated check is a unit of governance that operates continuously without consuming human review capacity [22]. The investment compounds — each rule added after a production failure means that failure cannot recur undetected.

Build the feedback loop deliberately and protect the judgment required to operate it. Production failures are the most valuable source of architectural information available. Capturing that information — as updated specifications, new fitness functions, refined behavioral tests — is the mechanism by which the governance model accumulates knowledge rather than degrading. But the loop requires human architectural judgment to translate symptoms into causes. That judgment erodes when generation outpaces comprehension. Protecting it — through deliberate comprehension investment, through architectural reviews that prioritize understanding over velocity — is the leadership decision that determines whether the loop runs well or runs empty.

Know when a rewrite is justified and when it is not. The governance model described in this post is not free. Writing specification-grade requirements, designing behavioral test suites, encoding architectural constraints, and maintaining structured ADRs represents real investment. That investment is justified when the expected system lifespan is long, when regulatory or compliance exposure is high, when the domain is complex and domain knowledge hard to replace, or when the rewrite is intended to produce a materially different architecture rather than cleaner code. It is not justified when the system is genuinely short-lived, when the domain is simple and well-understood, or when the cost of the governance model exceeds the cost of the architectural debt it prevents. The threshold question is not “should we govern our AI-assisted rewrite?” but “does the expected value of this system warrant the investment in governing it properly?” A system expected to run for five years with a team of ten engineers warrants the full model. A prototype expected to be replaced in eighteen months does not.

Know when an organization is not ready to rewrite yet. The preconditions are not just preparation for a rewrite — they are diagnostic criteria for rewrite readiness. An organization that cannot articulate its domain invariants with enough precision to write verifiable specifications is not ready. An organization whose test suite consists entirely of implementation-coupled unit tests is not ready — the behavioral contracts that a rewrite needs as a target do not exist. An organization with no ADRs has no institutional memory to feed to the AI governing the rewrite. In each of these cases, the right investment is not to begin the rewrite but to build the preconditions first. The governance model built during that investment will serve not just the rewrite but every iteration of the system that follows it.

Address the test pyramid explicitly before a rewrite begins. A rewrite inherits a test suite that was written for a system it is about to discard. Not all of that suite travels. Unit tests that test implementation internals — specific classes, methods, internal state — should be discarded. They are anchors to the old architecture and will constrain the new one. Integration tests written at behavioral boundaries should be kept and reviewed for continued relevance. Acceptance tests and contract tests that encode behavioral expectations at system and service boundaries are the primary inheritance — they are the executable specifications that tell AI what the new system must do without prescribing how it must be built. The rule of thumb: if a test would fail because you changed how something works internally but not what it does externally, discard it. If a test would fail only because the system stopped doing something users or dependents rely on, keep it.

Redefine what architects do. This is the point most leadership conversations about AI and architecture avoid. The governance system described in this post does not reduce the need for architects — it changes what they are for. Before AI, the architect designed systems and enforced discipline through review and team norms. In an AI-assisted organisation with a mature governance system, the architect’s primary responsibility is authoring the governance system itself — what the SDD literature calls SpecOps: treating specification authoring as a first-class engineering surface, with the same quality practices, version control, and continuous improvement applied to production code [23]. In practice this means writing specifications precise enough to constrain generation, defining the ADR structure that preserves institutional memory, encoding fitness functions that enforce architectural intent, diagnosing production failures as architectural causes rather than implementation bugs, and judging when conditions for revisiting a decision have genuinely been met. This is a more abstract job than designing systems directly — and a more powerful one. A well-designed governance system enforces architectural intent at the speed AI generates code. No architect reviewing pull requests manually ever could.

The operationalization of this approach is already visible in production tooling. Addy Osmani’s open-source Agent Skills project encodes the workflows and quality gates that senior engineers actually use — spec before code, test before merge, ADRs in the ship checklist — as structured markdown skills that AI agents can consume as persistent context governing every development decision [24]. This is governance-system authorship made practical: the architect defines the skills, the agent operates within them. The question for engineering leaders is not whether architects are still needed. It is whether the architects on their teams have been given the mandate, the tools, and the time to author governance systems rather than just review code.

Conclusion: The Loop Can Be Made Better. It Cannot Be Made Automatic.

There is one thing this post should say directly that it has so far only implied: externalising knowledge does not remove the cognitive load ceiling. It moves it.

Before — the ceiling was in the code. Teams hit it when they could no longer hold the system in their heads. Now — the ceiling is in the governance system. Teams hit it when they can no longer reason confidently about the specifications, fitness functions, ADRs, and feedback loops that govern the code. That is harder — but it fails differently. Cognitive overload in code is invisible until the system breaks in production. Cognitive overload in governance surfaces as failing fitness functions, broken tests, and violated constraints — signals that are detectable, versionable, and correctable before failure propagates. The governance ceiling is not lower. It is more visible. And visibility is what makes it manageable.

The feedback loop can be made more reliable. It cannot be made automatic. At every point — translating failure symptoms into architectural causes, validating that fitness functions test the right properties, judging when an ADR’s conditions for revisiting have been met — human architectural understanding is required. That understanding is now directed not at the code but at the governance system. The architect’s job is to keep that system honest.

The question is not whether to build guardrails. It is whether the people building them understand that the guardrails themselves are now the system.

Sources & Further Reading

[1] Aathawerani, A. (2026) — The Cognitive Load Ceiling: What AI Is Doing to Software Architecture — and Why the Rewrite Is No Longer the Last Resort The preceding post in this series, establishing the cognitive load ceiling framework and its disruption by AI-assisted development.

[2] Spolsky, J. (2000) — Things You Should Never Do, Part I Joel on Software. The landmark essay establishing the economic — not technical — case against rewrites, grounded in the institutional knowledge cost of discarding working systems.

[3] Faye, L. (2025) — Agentic Coding is a Trap larsfaye.com. A practitioner critique of agentic coding workflows identifying the supervision paradox — that delegating code generation to AI erodes the engineering skills required to supervise what AI produces, creating a compounding vulnerability as delegation increases.

[4] Nygard, M. (2011) — Documenting Architecture Decisions Cognitect Blog. The original proposal for Architecture Decision Records as lightweight, version-controlled documents capturing architectural decisions and their rationale — the conceptual foundation for the structured, machine-consumable ADR format described in this post.

[5] Griffin, L. & Carroll, R. (2026) — Spec Driven Development: When Architecture Becomes Executable InfoQ. Introduces Spec-Driven Development as a methodology in which specifications become executable system truth, architecture is enforceable through continuous validation, and human authority shifts upward from implementation to intent.

[6] acai.sh (2025) — Specsmaxxing acai.sh. A practitioner account of the benefits of writing feature specifications in structured formats rather than natural language prompts — demonstrating that structured specifications substantially reduce AI’s tendency to generate contextually wrong output. Independent practitioner convergence on the spec-as-constraint principle that SDD formalises.

[7] Wiegers, K. & Beatty, J. (2013) — Software Requirements, 3rd Edition Microsoft Press. Comprehensive treatment of requirements engineering with specific guidance on writing verifiable, unambiguous specifications that function as constraints rather than guidance.

[8] Cockburn, A. (2000) — Writing Effective Use Cases Addison-Wesley. The definitive practical guide to UML use case specification, establishing the actor/precondition/main flow/alternate flow/postcondition/exception flow structure — the established foundation on which the hybrid specification format in this post builds.

[9] Freeman, S. & Pryce, N. (2009) — Growing Object-Oriented Software, Guided by Tests Addison-Wesley. Establishes the distinction between tests written against behavior and tests written against implementation, with practical guidance on designing tests that survive architectural change.

[10] Richardson, C. — Consumer-Driven Contract Testing microservices.io. Describes the consumer-driven contract testing pattern, which encodes behavioral expectations at service boundaries in a form that constrains implementation without prescribing structure.

[11] Hughes, J. (2019) — How to Specify It: A Guide to Writing Properties of Pure Functions Midlands Graduate School lecture notes. Practical guide to property-based testing, covering how to identify and express behavioral invariants that hold across entire categories of inputs rather than specific examples.

[12] Alshahwan, N. et al. (2024) — Automated Unit Test Improvement Using Large Language Models at Meta arXiv:2402.09171. Documents Meta’s production experience using LLMs to improve existing test suites at scale, including identification of missing coverage and generation of additional behavioral tests from production evidence.

[13] Keeling, M. (2017) — Design It! From Programmer to Software Architect Pragmatic Bookshelf. Introduces architecture as a first-class engineering practice with executable, version-controlled artifacts, providing the conceptual foundation for Architecture as Code approaches.

[14] Brown, S. — Structurizr: Architecture as Code structurizr.com. The leading tool for defining C4 architecture models as code, enabling architecture diagrams to be generated from version-controlled definitions that live alongside the codebase they describe.

[15] Kůdela, P. — ArchUnit User Guide ArchUnit. Documentation for ArchUnit, which encodes architectural dependency rules as executable tests that run in the standard test suite and fail the build on violation.

[16] Brugts, S. — Dependency Cruiser GitHub. Open source tool for validating and visualising dependencies in JavaScript and TypeScript projects, providing Architecture as Code enforcement equivalent to ArchUnit for JVM ecosystems.

[17] Bass, L., Clements, P. & Kazman, R. (2012) — Software Architecture in Practice, 3rd Edition Addison-Wesley. The foundational academic treatment of software architecture patterns and reference architectures, defining reference architectures as pre-defined structural solutions to well-understood classes of problems.

[18] Silverston, L. (2001) — The Data Model Resource Book, Volumes 1 & 2 Wiley. A library of pre-built, reusable ERDs for core business domains and industry-specific models — an early embodiment of the reference architecture instinct at the data layer.

[19] Arlow, J. & Neustadt, I. (2004) — Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML Addison-Wesley. A catalog of reusable archetype patterns — UML model components for common business entities like Customer, Product, and Order — operating at the domain model layer.

[20] Ford, N., Parsons, R. & Kua, P. (2017) — Building Evolutionary Architectures: Support Constant Change O’Reilly Media. Introduces architectural fitness functions as automated mechanisms for continuously validating architectural properties, enabling organizations to detect structural drift before it becomes unmanageable — the established concept on which the proposed fitness function format in this post builds.

[21] Tornhill, A. & Borg, M. (2022) — Code Red: The Business Impact of Code Quality IEEE/ACM International Conference on Technical Debt. Empirical study demonstrating that automated code health analysis can identify coupling hotspots and structural decay patterns — providing the evidence base for AI-assisted architecture extraction as a continuous governance practice.

[22] Humble, J. & Farley, D. (2010) — Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Addison-Wesley. The foundational text establishing the CI/CD pipeline as a continuous quality governance mechanism — the conceptual basis for treating the pipeline as the primary enforcement layer for architectural constraints in an AI-assisted development environment.

[23] Krishnan, H. (2026) — Spec-Driven Development: Adoption at Enterprise Scale InfoQ. Extends the SDD framework to enterprise adoption, introducing the concept of SpecOps — specification authoring as a first-class engineering surface with the same quality practices and version control applied to production code.

[24] Osmani, A. (2026) — Agent Skills addyosmani.com. An open-source collection of production-grade engineering skills for AI coding agents — spec before code, test before merge, ADRs in the ship checklist — as structured markdown that agents consume as persistent governance context.

The Pipeline Is Not the Problem

Sat, 02 May 2026 00:00:00 +0000

The Pipeline Is Not the Problem

How SDLC policies succeed or fail — and why most of them become compliance theater within 18 months

Morpheus does not offer Neo a better version of the Matrix. He offers him the truth about it.

That distinction matters more than it seems. The Matrix was not broken. It was functional, consistent, and convincing. People lived inside it, went to work inside it, built careers inside it. The problem was not that it failed. The problem was that it was not what it appeared to be.

There is a pattern that repeats itself in software organizations with uncomfortable regularity — and it has the same shape.

A team — usually a good one, usually after a painful incident or an audit — invests serious effort into designing a real SDLC policy. They think carefully about stages. They define quality gates. They integrate security tooling. They document risk classification. They write it all down, get it approved, and roll it out.

Eighteen months later, the policy exists. The pipeline runs. The compliance boxes get checked.

And the engineers have learned exactly which parts to route around, which gates are safe to ignore, and how to make the metrics look healthy without the underlying reality being healthy.

Most organizations take the blue pill at this point — not out of negligence, but because the system looks like it is working. The dashboards are green. The audits pass. Nobody is asking hard questions, because the surface is clean.

If you have ever:

Approved a PR you did not fully understand
Reclassified a security finding to unblock a release
Watched a failing pipeline get bypassed “just this once”
Sat in a post-incident review where everyone agreed the process had been followed and nobody could explain why the incident happened anyway

You already know this system.

This is not a story about bad engineers. It is a story about a category error — the belief that a well-designed process, once installed, will sustain itself. That the pipeline is the problem, and therefore the pipeline is the solution.

It is not.

The Category Error

When organizations design SDLC policy, they are solving for two different problems simultaneously — and most of the time they do not realize it.

The first problem is technical: what stages should exist, what tools should run at each stage, how severity should be classified, how database changes should be managed, how releases should be governed. This problem is tractable. It has better and worse answers. It responds to careful design.

The second problem is social: whether the people inside the system will treat the policy as a shared contract or as an obstacle to route around. Whether a failing pipeline will be fixed or bypassed. Whether a reviewer will apply genuine judgment or perform a ritual. Whether a risk classification will be honest or optimistic.

The technical problem is where organizations spend most of their design energy. The social problem is what determines whether the policy actually works.

These are not the same problem. A policy that solves the first without addressing the second is not half a solution. It is an expensive way to produce compliance theater.

The easiest way to understand your system is not to read the policy. It is to observe what happens when following the policy conflicts with shipping on time.

This is where most systems quietly fail.

Why Pipelines Fail to Enforce Culture

A CI/CD pipeline is not a neutral technical artifact. It is a representation of what an organization believes matters — and, more importantly, of how much the organization trusts the people building the systems it runs.

When a pipeline is designed primarily as a control mechanism — to catch engineers doing the wrong thing — it produces a specific cultural response. Engineers begin to relate to it adversarially. The pipeline becomes something to satisfy, not something to learn from. When it fails, the question is not “what does this tell us?” but “how do we get this green?” When it slows delivery, the question is not “is this friction worth it?” but “can we skip this?”

This adversarial posture is not irrational. It is the natural response to a system that treats its users as compliance subjects rather than decision-makers.

It would be easy to argue that strong pipelines do enforce behavior — after all, you can block deployments, fail builds, and enforce rules mechanically. But what they enforce is compliance, not intent. And compliance without intent is exactly how systems drift into theater.

The failure mode looks like this in practice:

A security scan flags a high-severity finding on a feature branch. The developer doesn’t understand the finding, cannot fix it quickly, and has a sprint deadline. The PR sits. A senior engineer reviews it, doesn’t understand the finding either, approves it anyway, and makes a mental note to address it later. The note is never revisited. The finding gets promoted through the pipeline. At release time it is flagged again, reclassified as a known risk, and documented. The documentation goes into a folder that nobody reads.

The policy worked exactly as written. Every gate fired. Every log entry was made. The finding traveled from development to production with full auditability and zero meaningful intervention.

This is compliance theater. It is not a failure of the policy’s technical design. It is a failure of the social contract the policy assumed but never built.

This is the red pill moment most engineering organizations never take. The blue pill is not ignorance — it is the active choice to keep living inside a system that looks like it is working. Morpheus was not describing a broken world. He was describing a comfortable one. The pipelines pass. The dashboards are green. The audit evidence is filed. And somewhere underneath all of it, the system is hollow — quietly, consistently, invisibly hollow — until something breaks in production and nobody can explain why, because the process that was supposed to prevent it had been theater for months.

What Policies Assume Without Saying So

Every SDLC policy contains a set of implicit assumptions about the humans who will operate within it. Most of these assumptions are never written down — because to the people writing the policy, they seem obvious.

They all reduce to one thing: that people will act with integrity under pressure. That reviewers will apply genuine judgment rather than perform a ritual. That developers will write tests that validate behavior rather than satisfy a threshold. That risk will be classified honestly rather than optimistically.

None of these are guaranteed by policy text. All of them depend on things the policy cannot directly control: shared understanding, psychological safety, genuine ownership, and the organizational signals that tell engineers whether honesty is rewarded or penalized.

The most dangerous assumption of all is the one about incentives. A policy tells engineers what they are supposed to do. The incentive structure around them tells them what they are actually rewarded for. When those two things diverge — when the policy says “classify risk honestly” and the culture says “be optimistic so we can ship” — the incentive wins. Every time.

And this is the part no policy document admits.

Forward-Only Is a Culture Decision Dressed as a Technical One

Consider a specific design choice that appears in well-designed SDLC policies: the forward-only principle.

The rule is straightforward. When something breaks, you fix it forward. No reverts. No “we’ll just roll back and figure it out later.” The code goes forward, the database migrations go forward, the releases go forward.

On the surface this looks like a technical constraint. It is not. It is a cultural stance.

Forward-only development assumes that the team will invest in making changes safe before they are made, not after. It assumes that regression tests will be written with genuine intent. It assumes that database migrations will be designed to be incrementally safe, not just functionally correct. It assumes that engineers will declare architectural impact honestly before it is reviewed, not retroactively justify it afterward.

Without those assumptions being socially true, the forward-only rule produces a different outcome: teams that cannot revert accumulate forward-fixes that are poorly understood, stacked on top of each other, each one carrying the technical debt of the emergency it was meant to resolve. The principle that was designed to enforce discipline becomes the mechanism by which undisciplined decisions are permanently baked into the system.

The same pattern holds for every structurally significant policy decision. Mandatory impact analysis is only as good as the honesty of the engineers declaring it. Severity classification is only as good as the judgment of the engineers applying it. Architectural validation is only as good as the understanding of the engineers reviewing it.

Policy gives these decisions a structure. Culture gives them a substance. Without both, you have a form without a function.

A quality gate works when the people on both sides of it share an understanding of what it is for.

On one side is the developer who has written code, declared its risk, included tests, and submitted a merge request. On the other side is a reviewer who is being asked to validate that the change is what it claims to be — correctly implemented, honestly classified, adequately tested, safe to integrate.

This is not a mechanical check. It is a judgment call, made by a person who must understand the change well enough to evaluate it fairly. The policy can specify what the reviewer must check. It cannot specify whether the reviewer will develop the understanding necessary to check it meaningfully.

This has an important implication: the quality gate is only as strong as the shared context between the person who wrote the change and the person reviewing it. When that context is thin — because the reviewer is unfamiliar with the affected domain, because the change is large, because the team is under delivery pressure, because the code was generated by an AI tool that neither person fully understands — the gate fires without doing useful work.

The ritual is performed. The substance is absent.

Healthy SDLC cultures invest continuously in the shared context that makes gates meaningful. This means code ownership that is real, not nominal. It means reviewers who are genuinely qualified to review the things they are asked to review. It means teams that are small enough to maintain shared understanding of the systems they own. It means the time to actually do the review, not the expectation that review will happen in the margins around other work.

These are organizational commitments. They cannot be mandated by a pipeline.

DevSecOps and the Alert Processing Trap

Security integration in CI/CD suffers from a specific version of this problem that is worth naming directly.

The technical design of DevSecOps is tractable. Run fast, signal-oriented security checks on feature branches. Run full SAST, SCA, and authenticated DAST at integration. Classify findings by genuine severity. Block only what actually warrants blocking.

The design philosophy behind this is sound: security controls exist to support decisions at each stage of the pipeline, not to generate artifacts that satisfy an auditor. A CRITICAL finding that blocks a pipeline must be critical enough that a reasonable engineer would agree it should block. A MAJOR finding that is logged but not blocking must be tracked with genuine intent to resolve, not filed and forgotten.

The failure mode — and it is extremely common — is that organizations implement the technical structure without implementing the decision discipline it requires. The backlog grows. The findings are triaged. The system records activity. The risk accumulates. The security posture degrades continuously while the compliance posture remains technically intact. Every finding is documented. None of them are fixed.

This is not a tooling problem. The tools are working as designed. It is a culture problem: the organization has optimized for producing security evidence rather than for being secure.

The distinction matters because they produce different behaviors at every decision point. An organization optimizing for evidence asks “does this finding need to block the pipeline?” and answers that question based on whether blocking it will delay the release. An organization optimizing for security asks “does this finding represent real risk?” and answers based on the actual threat. These are different questions, and they produce different answers, and the difference accumulates over time into a materially different security posture.

No CI/CD policy can mandate the second question if the culture is asking the first.

The Metrics Trap

Organizations that instrument their SDLC policies carefully — tracking pipeline pass rates, mean time to resolution, security finding counts, coverage percentages — will eventually discover that their metrics are healthy and their systems are not.

This is not a paradox. It is the predictable outcome of measuring outputs rather than intent.

A pipeline pass rate tells you whether pipelines are passing. It does not tell you whether the tests that pass them are meaningful, whether the findings that don’t block them are being resolved, whether the risk classifications are honest, or whether the architectural gates are being applied with genuine understanding.

A coverage percentage tells you what fraction of the codebase is touched by tests. It does not tell you whether those tests would catch a real regression, whether the edge cases that matter are covered, or whether the tests were written to validate behavior or to satisfy the metric.

A mean time to resolution for security findings tells you how quickly findings are closed. It does not tell you whether they were closed by remediation or by reclassification.

The logs were correct. The decisions were not.

Metrics are not the problem. The problem is treating metrics as a proxy for the thing the metrics are supposed to measure. When a team understands that it will be evaluated by the metric rather than the underlying reality, optimizing for the metric becomes the rational strategy. The measurement becomes the goal. The goal becomes invisible.

This is Goodhart’s Law operating in an SDLC context, and it is one of the most reliable failure modes in engineering governance.

The solution is not to abandon metrics. Removing them doesn’t produce a healthier culture — it produces ambiguity, which usually turns into bias or politics. The solution is to demote metrics from authority to evidence. Use them to understand performance. Use judgment to reward it.

The earliest sign of policy decay is not failure. It is silent reclassification — when teams start quietly downgrading severity to keep flow moving. By the time it is visible, it has been happening for months.

The metrics that reveal this are not the ones most organizations track. Track reopened bugs, not tickets closed. Track incidents caused by “known risks” that were documented and not fixed. Track the time between detection and actual remediation, not closure. Track how many times pipelines are bypassed. These expose reality instead of rewarding appearances.

And recognize that building a system where people genuinely engage with metrics as signals — rather than gaming them as targets — has a cost. It requires slower short-term delivery, more friction in planning, more uncomfortable conversations. If an organization is not willing to pay that cost, it will get compliance theater instead. That is not a failure of tooling or policy design. It is a choice.

What Actually Sustains a Policy

If pipelines cannot enforce culture, and metrics cannot substitute for judgment, and policy text cannot guarantee honesty — what actually determines whether an SDLC policy works over time?

Three things, consistently, in practice.

First: the policy must be legible to the people operating within it. Not legible in the sense that they can read it, but legible in the sense that they understand why each element exists — what risk it addresses, what failure it prevents, what the organization would look like without it. A developer who understands why forward-only development matters will make different decisions than one who sees it as an arbitrary constraint. A reviewer who understands why impact analysis exists will apply it differently than one who sees it as a checkbox. Legibility requires investment in explanation, not just documentation. It requires the organization to treat policy education as an engineering discipline, not an onboarding formality.

Second: the incentive structure must be aligned with the policy, not merely adjacent to it. This means that honest risk classification is rewarded, not penalized. That a developer who raises a genuine concern about a change’s safety is supported, not pressured. That a team that slows down to address a real architectural problem is respected, not seen as blocking delivery. That post-incident reviews result in policy improvements rather than blame allocation. Incentive alignment cannot be mandated. It is expressed through the hundreds of small decisions leaders make about what they visibly value, what they tolerate, and what they hold people accountable for.

Aligning incentives with policy will slow delivery in the short term. Some releases will be delayed. Some concerns will be uncomfortable to raise and more uncomfortable to act on. If an organization is not willing to accept that cost, the incentives will drift back toward throughput — and the policy will become decoration. This is not a cultural failure. It is a predictable system outcome. Once engineers learn that risk can be reclassified to unblock delivery, that behavior is extremely difficult to reverse. Behavior learned under pressure becomes the system’s default. Policy updates don’t erase it. The system does not reset when you update the policy. It remembers what was rewarded.

Third: the policy must evolve. An SDLC policy written at a point in time reflects the organization’s understanding of its risks and constraints at that moment. Six months later the team is different, the product is different, the threat landscape is different, the tooling has changed. A policy that does not update becomes progressively less accurate as a representation of what the organization actually needs — which means it becomes progressively less legitimate in the eyes of the people operating within it. Policies that stop evolving start to be ignored. The mechanism for updating a policy is not a quarterly review meeting. It is the post-incident review that asks “what in our process failed to prevent or catch this?” and the engineering retrospective that asks “what in our pipeline is generating friction without generating value?” It is the ongoing, institutionalized question of whether the policy is actually working — asked by the people who know, which is the engineers running it.

The Policy as a Living System

A well-designed SDLC policy is not a document. It is a system — and like any system, its behavior depends on the interactions between its components, not just on the properties of the components themselves.

The components are the technical elements: the stages, the gates, the tools, the severity classifications, the governance structures. These can be designed carefully, and careful design matters. A policy with sensible staging, honest severity enforcement, forward-only discipline, and layered security integration is genuinely better than one without these things.

But the interactions that determine the system’s actual behavior are social: the trust between developers and reviewers, the honesty with which risk is declared, the seriousness with which findings are addressed, the organizational will to maintain the policy as it ages.

An organization that gets the technical design right but neglects the social interactions will produce a system that looks functional from the outside and is hollow at the center.

An organization that understands the social interactions — that invests in legibility, aligns incentives, creates the conditions for honest judgment, and treats the policy as something that must continuously earn its legitimacy — will find that the technical design becomes self-reinforcing. Engineers will propose improvements because they understand what the policy is for. Reviewers will apply genuine judgment because they feel the weight of the responsibility. Metrics will reflect reality because there is no incentive to make them lie.

The pipeline is not the problem. The pipeline is the expression of an underlying agreement about what quality means, what risk is acceptable, and what it means to take collective ownership of the systems you build.

That agreement is not written in YAML. It is not enforced by a CI runner. It is built, maintained, and continuously renewed by the people inside it — or it quietly ceases to exist while the pipelines keep passing and the findings keep getting filed and the systems keep degrading.

What This Means in Practice

The diagnostic test is simple. When your pipeline fails, what happens next?

Do engineers investigate the root cause — or look for the fastest way to get it green? The answer tells you whether your pipeline is a quality system or a compliance system.

If you are responsible for engineering outcomes, this leads to a small number of non-negotiable decisions:

You must decide whether delivery speed or decision integrity is your real priority. Your system will optimize for whichever one you reward under pressure. Both cannot be equally first.

You must treat pipeline failures as signals, not obstacles. A failing pipeline is the system working. A bypassed pipeline is the system being dismantled, one exception at a time.

You must accept that some releases will be delayed if you want honest risk classification. If every release must go out on time, risk will be hidden, not managed.

You must remove metrics that are being gamed — not just add better ones. Keeping a metric because the dashboard looks good is how systems drift into theater and stay there.

You must invest in shared context, or your quality gates will become rituals. There is no automation substitute for a reviewer who genuinely understands what they are reviewing.

And you must be visible about what you reward. If engineers are recognized for raising real concerns that delay delivery, others will raise them. If they are pressured or penalized, the concerns will stop — but the risks will not.

Culture is not built by what you write down. It is built by what you enforce when it hurts.

A Final Observation

The organizations that have the most sophisticated SDLC policies are not always the ones with the healthiest engineering cultures. Sometimes they are the ones with the most elaborate compliance theater — because the sophistication of the policy became a substitute for the harder work of building the conditions under which it could actually function.

The organizations with the healthiest engineering cultures often have policies that are simpler than you would expect. Not because they have not thought carefully about risk — but because they have thought carefully about what their people can sustain, what their teams can genuinely own, and what their systems can actually enforce. They have calibrated the policy to the culture rather than the culture to the policy.

That calibration is where the real design work happens.

Pipelines don’t fail quietly.

They succeed quietly — while everything underneath them gets worse.

The question is always: what kind of organization is the pipeline designed to serve?

This is part of TECTONICS — a series on how technology organizations actually move. Systems, culture, and scale.

Previous: The Cognitive Load Ceiling: What AI Is Doing to Software Architecture

The Cognitive Load Ceiling: What AI Is Doing to Software Architecture — and Why the Rewrite Is No Longer the Last Resort

Mon, 23 Mar 2026 00:00:00 +0000

The Architecture That Was Supposed to Last

Every generation of software engineers believes it has found the architecture that will not need replacing. Waterfall gave way to layered architectures, which gave way to service-oriented architectures, which gave way to microservices, which are now giving way to modular monoliths. Each transition arrives with genuine conviction that this time, the underlying structure is sound enough to endure. And each time, that conviction eventually erodes — not through technical failure, but through something more fundamental.

The pattern is consistent: a new architecture solves a real and pressing problem. Teams adopt it with enthusiasm. The system grows. The overhead of understanding, navigating, and extending it increases steadily. At some point the architecture stops serving the team and starts burdening it. A reckoning follows — a rewrite, a decomposition, a consolidation — and the search for the next architecture begins.

What is rarely examined in these transitions is the root cause. Organizations do not abandon architectures because they were wrong. They abandon them because the team’s cognitive load ceiling was reached. The architecture outgrew the team’s collective ability to hold it in their heads.

Now a new force has entered this dynamic. Artificial intelligence — in the form of code generation tools, AI-assisted review, autonomous agents, and LLM-based system components — is simultaneously being positioned as the solution to software complexity and quietly introducing a new class of complexity that has no established name. Three questions follow from this that no engineering leader can afford to defer. Does AI actually follow the architectural disciplines the industry spent decades developing? If it does not, do those disciplines still matter? And when AI-assisted codebases eventually become unmaintainable — as they will — is the rewrite still the expensive last resort it once was, or has AI turned it into something more dangerous: a silver bullet that restarts the problem faster than before? An engineering leader might be forgiven for exclaiming “I’m too old for this” — but the more important question is not whether the pace is overwhelming. It is whether the discipline, the judgment, and the accumulated experience that comes with being old enough to know better can be brought to bear on a tool that has none of those things yet.

What Cognitive Load Actually Means in Software

The concept of cognitive load originates in educational psychology. John Sweller introduced Cognitive Load Theory in 1988 to describe the limits of working memory when processing new information [1]. Sweller identified three distinct types. Intrinsic load is the inherent complexity of the subject matter — the irreducible difficulty of the problem being solved. Extraneous load is complexity introduced by poor structure, unnecessary friction, or avoidable confusion — overhead layered on top of the real problem. Germane load is the productive effort directed toward building lasting mental models — the cognitive work that actually leads to understanding rather than just familiarity.

These distinctions translate directly into software engineering. Intrinsic load corresponds to the genuine complexity of the domain: business rules, regulatory constraints, edge cases, and interdependencies that exist regardless of how the system is structured. No architectural choice eliminates this. Extraneous load corresponds to accidental complexity: indirection that adds no value, inconsistent naming conventions, unclear ownership, over-abstraction, and architectural ceremony that generates friction without generating insight. Germane load corresponds to the productive effort engineers invest in building accurate mental models of the system — understanding not just what the code does, but why it is structured the way it is, and what the consequences of changing it might be.

Matthew Skelton and Manuel Pais formalized this connection in Team Topologies (2019), arguing that cognitive load should be treated as a first-class architectural constraint [2]. Their central claim is deceptively simple: teams have a finite cognitive capacity, and system design must actively manage how that capacity is allocated. When a team’s cognitive load exceeds its ceiling, delivery slows, defects increase, and morale deteriorates — not because the engineers are less capable, but because the system has exceeded what any human team can reliably reason about.

This reframes the central question of software architecture entirely. The question is not: which architecture is technically superior? The question is: which architecture best fits within the cognitive constraints of the teams that must build, operate, and extend it, at the scale they currently face?

The answer has always changed as organizations grow. It is now changing again, in ways more disruptive than any previous shift, because of AI.

It is worth noting that this framing is not entirely new. Fred Brooks identified the same underlying constraint in 1975, long before cognitive load theory existed as a formal concept. In The Mythical Man-Month, Brooks argued that conceptual integrity — a unified, coherent vision of what a system is and how it behaves — is the most important consideration in system design [2a]. What he was describing, in the vocabulary available to him, was a system that remains within the cognitive reach of the people responsible for it. Sweller formalized the mechanism in 1988. Skelton and Pais operationalized it in 2019. The constraint itself has been present since the first system outgrew the mind of the person who built it.

Key Insight: Complexity does not disappear when you change architecture. It redistributes. Every architectural decision is ultimately a decision about where cognitive load lives and who carries it.

AI does not remove the cognitive load ceiling. It preserves the constraint, but compresses the timeline on which it is reached.

How Architecture Has Always Responded to the Ceiling

The history of software architecture is, at its core, a history of successive attempts to manage cognitive load — without ever quite naming it that way. Understanding what these attempts achieved, and where each one ultimately failed, is necessary context for understanding what AI is now changing.

The Monolith and Its Limits

The monolith is the default starting point not because teams lack imagination but because it is cognitively efficient at small scale. A single codebase, a single deployment unit, a shared data model — the entire system is transparent and navigable. Onboarding is fast. Debugging is local. The system fits inside the team’s collective working memory.

The ceiling arrives as the codebase grows and the team expands. The same transparency that made the monolith cognitively efficient becomes a liability. Changes in one area affect others in non-obvious ways. No individual engineer can hold the full system in working memory. The release cycle slows because the risk surface of any change is too large to reason about confidently. The monolith did not fail technically. It failed cognitively.

Microservices and the Redistribution Problem

Microservices offered a compelling response: decompose the system into independently deployable services, each small enough to be owned and understood by a single team. Sam Newman’s foundational work articulates this promise — small services enable team autonomy, independent deployability, and targeted scaling [3]. DORA research consistently demonstrates that teams with high deployment autonomy achieve better delivery performance and faster recovery from incidents [4].

The problem is that microservices do not reduce cognitive load. They redistribute it. Each team’s local load decreases because their service is small and well-scoped. But system-level cognitive load grows substantially. Distributed tracing, service mesh configuration, API contract management, eventual consistency, and inter-service failure modes introduce complexity that did not exist in the monolith. Martin Fowler’s concept of the “microservices premium” captures this precisely: the overhead is only justified when the organizational benefits outweigh the operational costs, and many teams adopt microservices before reaching the scale where that trade-off is favorable [5].

The modular monolith re-emerged as a pragmatic recalibration — a single deployable unit with rigorously enforced internal module boundaries that preserves the cognitive benefits of co-location while introducing domain separation. The underlying lesson was not about deployment topology. It was about cognitive ownership: a team must be able to hold its system responsibility in working memory, and the architectural unit should be sized accordingly.

Clean Architecture: Discipline as Cognitive Relief

Clean Architecture and its relatives — Hexagonal Architecture, Ports and Adapters — addressed a different cognitive problem: the entanglement of business logic with infrastructure that makes systems resistant to change and difficult to reason about in isolation. Robert C. Martin’s dependency rule placed the domain model at the center, insulating it from frameworks, databases, and external systems [6].

The cognitive intent was sound. When infrastructure concerns bleed into domain logic, engineers must hold both the business problem and the infrastructure detail in working memory simultaneously — a compounding of intrinsic and extraneous load. Separating them cleanly reduces that burden. The problem is that the architecture introduced its own extraneous load: a proliferation of interfaces, adapters, and mapping layers that required engineers to navigate multiple abstraction levels to trace a single operation. For teams under delivery pressure with unstabilized requirements, the ceremony generated more cognitive overhead than it relieved. The YAGNI principle — You Aren’t Gonna Need It — periodically reasserted itself as a corrective, collapsing architecture back toward the actual complexity of the problem being solved [7].

The discipline was right. The dose was frequently wrong.

Domain-Driven Design: Alignment as Cognitive Strategy

Domain-Driven Design, introduced by Eric Evans in 2003, targeted the deepest source of extraneous load in large software systems: the divergence between how the domain experts understood the business and how the software represented it [8]. Bounded contexts, ubiquitous language, and aggregate design were tools for alignment — reducing the translation overhead that occurs when engineers must constantly map between technical structures and domain concepts.

In complex, long-lived domains, DDD delivered on this promise. Vaughn Vernon’s practical work documents organizations where domain-aligned architecture substantially reduced the effort required to implement domain changes [9]. The ceiling arrived through scale: context mapping across dozens of bounded contexts became its own discipline, ubiquitous language drifted as teams changed, and aggregate boundaries became contested as domains evolved. Full DDD adoption was frequently abandoned, but its vocabulary — bounded contexts, the principle that software structure should mirror domain structure — tended to survive and continue shaping better architectural decisions.

The Common Thread

What connects monoliths, microservices, Clean Architecture, and DDD is not the specific patterns they introduced. It is the underlying problem they were all trying to solve. Each was, in essence, an attempt to keep the system within the cognitive reach of the teams building it. Each succeeded in its original context. Each eventually produced its own overhead that pushed cognitive load toward a new ceiling. The ceiling did not disappear. It moved.

This matters because AI is now being applied to systems built under all of these disciplines — and in many cases, is generating new code without inheriting the discipline at all.

Key Insight: Every major architectural shift in software history was a cognitive load management strategy with a different name. The patterns differed. The underlying problem was always the same.

AI and Architectural Discipline: Does Any of This Still Apply?

This is the question the industry is not asking clearly enough. The debate about AI in software development has focused heavily on productivity — how much faster code gets written, how many engineers a team can replace or augment. The more consequential question is architectural: does AI follow the disciplines the industry spent decades developing, and if it does not, do those disciplines still matter?

There is a useful frame for this in an unlikely place. In Lethal Weapon, Martin Riggs is extraordinarily effective — fast, capable, gets results in any given scene. He is also completely unpredictable and operates without regard for the procedural rules that exist to protect the system around him. Roger Murtaugh, his partner, keeps the precinct functional, manages the consequences of Riggs’s methods, and carries the institutional knowledge of why the rules exist. His famous line — “I’m too old for this” — is not an admission of weakness. It is the recognition of an experienced engineer watching someone brilliant operate without understanding the cost of what they are breaking. AI in software development is Riggs. The engineering team is Murtaugh. The architecture is the precinct that has to hold together after the scene ends. The problem is not that Riggs is ineffective. The problem is that he does not know he is too old for this — because he has never been old for anything.

What AI Actually Produces

Large language models used for code generation are trained on the aggregate corpus of publicly available code. That corpus contains Clean Architecture implementations and layered spaghetti with equal frequency. It contains well-bounded DDD contexts and monolithic data models with domain logic scattered across service classes. It contains thoughtful dependency inversion and circular imports. The model has no inherent preference for any of these. It reproduces patterns proportional to their representation in training data, shaped by the context and instructions it receives at generation time.

In practice, this means that AI-generated code defaults to the most common patterns in its training data — which are not the most disciplined patterns. Without explicit, sustained prompting that encodes architectural intent, AI tools produce code that is locally coherent but globally undisciplined.

This distinction matters more than it might initially appear. Local coherence means that any individual function, class, or module looks reasonable in isolation — readable, idiomatic, plausibly structured. Global coherence means that the system as a whole maintains consistent dependency direction, enforced boundaries between domains, and long-term evolvability as requirements change. AI optimizes aggressively for the former. Architecture requires the latter.

A function looks reasonable. A class looks reasonable. The module structure, the dependency graph, the boundary between domain and infrastructure — these are architectural properties that emerge from hundreds of small decisions made consistently over time. They are properties of the system as a whole, not of any individual unit within it. AI tools operating without architectural guardrails do not make those decisions consistently, because consistency across decisions over time is not what they are optimized for.

Research on LLM code generation quality supports this. Studies examining the architectural properties of AI-generated code find that it tends to violate separation of concerns, accumulate implicit dependencies, and produce structures that are difficult to extend as requirements change — not because the generated code is wrong at the unit level, but because it is optimized for local correctness rather than systemic coherence [10].

Conway’s Law in an AI-Assisted World

Melvin Conway observed in 1968 that organizations design systems that mirror their communication structures [11]. This has proven durable across every architectural era: the system you build reflects the team that built it, its boundaries, its shared understandings, and its blind spots. It is why organizational design and system design cannot be treated as independent problems.

AI introduces a disruption to this dynamic that has not been fully reckoned with. When a significant portion of a codebase is generated by AI tools operating without deep organizational context, the system no longer mirrors the team that is nominally responsible for it. It mirrors the statistical average of the training corpus — plus whatever architectural intent was encoded in prompts and context at generation time. If that intent was thin or inconsistent, the system mirrors nothing coherent at all.

The implication for engineering leaders is direct: Conway’s Law does not become irrelevant in an AI-assisted organization. It becomes harder to manage, because the “communication structure” that shapes the system now includes the implicit assumptions baked into AI models that the team did not author, cannot fully inspect, and may not be aware of.

A system that no longer reflects the structure of the team responsible for it becomes harder for that team to reason about — which is precisely another name for increased cognitive load.

Are the Disciplines Still Relevant?

The disciplines — Clean Architecture, DDD, the principles underlying microservices decomposition — remain relevant as intent, but AI has fundamentally changed their relevance as enforcement mechanisms. The reasons the disciplines were developed have not disappeared. Domain logic still becomes entangled with infrastructure if boundaries are not enforced. Systems still become unmaintainable if domain concepts are not aligned with code structure. Cognitive load still accumulates when ownership is unclear and dependencies are invisible. The problems these disciplines were designed to solve are permanent features of software at scale.

What AI changes is their relevance as enforcement mechanisms. Architectural discipline has always depended on consistent human judgment applied across thousands of small decisions over time. Code review, pair programming, architectural decision records, and team norms were the enforcement layer. AI-assisted development, operating at the speed and volume it enables, produces decisions faster than those enforcement mechanisms can process. A team of five engineers using AI assistance can generate the volume of code that previously required twenty engineers — but it still has five engineers’ worth of review capacity, architectural judgment, and institutional knowledge.

The disciplines do not become obsolete. They become harder to maintain at the pace AI enables — and more important to maintain precisely because of that.

This means the enforcement model must shift — from code-level judgment applied by engineers in review, to system-level constraints encoded into the platforms, scaffolding, and tooling through which AI generates code in the first place.

Key Insight: AI follows architectural disciplines only as faithfully as the context it receives encodes them. Without explicit, maintained architectural intent in every generation context, AI defaults to average patterns — and average patterns do not scale.

The Rewrite Is No Longer the Last Resort

For two decades, the software industry operated under a doctrine best articulated by Joel Spolsky in 2000: never rewrite your software [12]. The argument was compelling and largely correct. Rewrites are expensive. They take longer than estimated. They discard working code alongside broken code. They lose the accumulated institutional knowledge embedded in existing behavior, including the behavior that nobody documented because it was discovered the hard way. The Netscape rewrite became the canonical cautionary tale. Subsequent decades added more.

The doctrine held because the underlying economics held. A rewrite of a significant system required assembling a team, rebuilding domain understanding from scratch, replicating years of edge case handling, and delivering nothing to users for months or years. The cost was prohibitive enough that organizations tolerated enormous amounts of technical debt rather than face it.

It is worth pausing on what that cost drove the industry to build. The entire trajectory of architectural thinking described earlier in this article — microservices, Clean Architecture, Domain-Driven Design, modular decomposition — was motivated, in significant part, by the desire to make the catastrophic rewrite unnecessary. If components are small, bounded, and independently deployable, individual pieces can be replaced without touching the whole. If domain logic is insulated from infrastructure, the infrastructure can change without rewriting the domain. If bounded contexts enforce explicit boundaries, one part of the system can evolve without cascading changes into others. Incremental replaceability was the architectural answer to the rewrite problem. The rewrite was not just expensive — it was the failure state that disciplined architecture was specifically designed to prevent.

AI has now disrupted both sides of this equation simultaneously. It has weakened the architectural disciplines that were designed to keep the rewrite at bay — by generating code faster than those disciplines can be enforced, and by accumulating comprehension debt that erodes the incremental replaceability those disciplines were meant to preserve. And it has lowered the cost of the rewrite itself: a rewrite that once required eighteen months and a dedicated team can now be substantially accelerated, as AI tools can parse existing codebases, identify patterns, generate new implementations, and assist in migrating behavior. The “never rewrite” doctrine, which was always an economic argument rather than a technical one, is no longer as defensible as it was. Both the prevention and the cure have changed at once.

This is genuinely good news for a specific problem. Codebases that have accumulated decades of technical debt, that are built on frameworks no longer maintained, or that are architecturally incompatible with current deployment requirements are now more tractable to address. The prohibitive cost that locked organizations into legacy systems has decreased.

The New Trap

But the rewrite’s reduced cost does not change what it actually produces — and this is where the silver bullet framing becomes dangerous.

A rewrite addresses the existing comprehension debt in a system. It does not address the organizational conditions that produced that debt. If those conditions include heavy reliance on AI code generation without architectural discipline, without strong code ownership practices, and without investment in the mental models engineers hold of the systems they operate — then the rewrite restarts the debt clock at zero, with all of the same conditions in place to run it back up, faster than before.

There is an additional dynamic specific to AI-assisted codebases that makes this worse. When an AI tool generates code that a team does not fully understand, and that codebase later becomes unmaintainable, the rewrite decision is made against a baseline of low comprehension. The team is rewriting a system they never fully understood. The institutional knowledge that a human-authored codebase accumulates over time — the edge cases discovered, the constraints learned, the decisions made and their rationale — is thinner in an AI-assisted codebase where generation outpaced comprehension from the start.

Empirical research on software rewrite outcomes consistently identifies the same root cause of failure: teams underestimate the implicit knowledge embedded in existing systems, not because that knowledge is hidden but because it was never fully articulated [13]. AI-assisted codebases are at elevated risk of this failure mode precisely because the generation process does not require articulation of intent, and the review process — under pressure — often does not demand it either.

Herb Caudill’s analysis of software rewrite case studies identifies the rewrites that succeeded as sharing one property: the team doing the rewrite had deep knowledge of both the domain and the failure modes of the existing system [14]. AI reduces the cost of the rewrite. It does not substitute for the knowledge required to do it well.

Can AI Fix What AI Broke?

Before reaching for the rewrite, the obvious question is whether AI can remediate the architectural problems it helped create. The answer is partial, and the boundary between what AI can and cannot do here matters enormously for how engineering leaders should plan.

AI tools are capable of identifying certain categories of architectural problems with genuine utility. Static analysis tools augmented with LLM reasoning can surface dependency violations, coupling hotspots, naming inconsistencies, circular imports, and deviations from documented patterns. When given explicit architectural rules — dependency direction constraints, module boundary definitions, naming conventions — AI-assisted review can enforce those rules at a scale and consistency that human review alone cannot match. Tools that combine static analysis with LLM-based reasoning, such as CodeScene’s code health analysis, demonstrate that automated architectural assessment is not merely theoretical [16].

What AI cannot reliably do is identify architectural problems that require understanding intent. The most consequential architectural issues in a degraded codebase are not the ones that violate explicit rules — those are detectable. They are the ones that violate implicit boundaries: coupling that looks acceptable in isolation but undermines a domain boundary that was never formally encoded, abstractions that were designed for a requirement that has since changed, service responsibilities that have drifted from their original purpose in ways that no static rule captures. Detecting these problems requires knowing why the architecture was designed the way it was — the rationale behind the boundaries, the domain model the structure was meant to reflect, the constraints that shaped early decisions.

That rationale lives in human memory, architectural decision records, and commit history. In AI-assisted codebases where generation outpaced documentation and comprehension, that rationale is often thin or absent. The AI attempting to remediate the architecture is working without access to the intent that would make its fixes meaningful rather than merely locally coherent. It can detect that two modules are tightly coupled. It cannot determine whether that coupling violates a meaningful domain boundary or reflects a legitimate relationship — because that judgment requires understanding the domain, not just the code structure.

The deeper problem is self-referential. When AI attempts to fix architectural issues in code it or similar tools generated, it brings the same pattern-matching tendencies that produced the issues in the first place. Without explicit, richly encoded architectural context guiding the remediation, AI-assisted fixes tend to resolve local symptoms while leaving systemic causes intact — or introducing new structural problems of a different kind. The result is an architecture that has been tidied but not understood, which is precisely the condition that makes the next degradation faster and harder to detect.

AI-assisted architectural remediation is a real and valuable tool for well-defined, rule-based violations in codebases with strong architectural documentation. It is not a substitute for the human judgment required to address intent-based architectural decay. When the decay is primarily of the latter kind — which it will increasingly be in codebases built rapidly with AI assistance and insufficient architectural governance — remediation has meaningful limits, and the rewrite conversation becomes unavoidable sooner than it would in a human-authored codebase with comparable symptom severity.

The Doctrine Needs Updating, Not Discarding

Spolsky’s “never rewrite” was a heuristic for an economic environment that no longer exists. The updated doctrine is not “always rewrite with AI” — it is more precise than that:

A rewrite is now economically viable in more situations than before. It remains cognitively viable only when the team has sufficient understanding of the existing system’s domain behavior and failure modes to avoid replicating its mistakes. AI changes the cost of the rewrite. It does not change the knowledge required to do it well. And in codebases where AI-assisted development has accelerated comprehension debt accumulation, the rewrite may be more affordable and less tractable at the same time — a combination that has not previously been common in software engineering.

Key Insight: AI has lowered the cost barrier of the rewrite without lowering the knowledge barrier. Treating it as a silver bullet for AI-generated technical debt is precisely the scenario most likely to produce the next generation of legacy systems — built faster, understood less, and facing the same ceiling sooner.

There is a broader systemic risk here that deserves naming directly: the perpetual rewrite loop. Historically, the high cost of rewrites acted as a forcing function — it compelled organizations to invest in architectural discipline, because the alternative was too expensive to contemplate. As that cost drops, so does the forcing function. If rewrites become cheap enough to reach for routinely, organizations lose the economic incentive to maintain the architectural disciplines that prevent systems from becoming unmaintainable in the first place. The result is a loop: AI accelerates code generation, comprehension debt accumulates faster, the system becomes unmaintainable sooner, a rewrite is initiated, AI accelerates the rewrite, and the cycle restarts — each iteration faster and less understood than the last. The rewrite ceases to be a reset and becomes a treadmill. This is not a hypothetical risk. It is the logical endpoint of treating AI as a substitute for architectural judgment rather than a tool that operates within it.

Breaking that loop requires treating the rewrite not as a generation problem but as a knowledge problem. Three preconditions distinguish a rewrite that produces a better system from one that restarts the same cycle faster. First, requirements must be rewritten as specifications — not inherited verbatim from the old system, but revisited, clarified, and structured with sufficient precision that AI can be held to them as verifiable constraints rather than loose guidance. Second, automated tests must encode behavior, not implementation — tests written at the right level of abstraction give AI a target that doesn’t anchor it to the old architecture, allowing a genuinely better structure to emerge. Third, architecture must be documented as machine-interpretable intent — not as a description of what was built, but as a specification of what should be built, precise enough to be encoded into the tooling that governs AI generation and validated continuously as the codebase evolves. Each of these preconditions is operationally deep enough to deserve its own treatment. How to write requirements that function as AI specifications, how to validate that AI-generated code conforms to architecture, and how to keep architecture documentation current as AI writes code at pace — these are the practical questions that follow from this article’s argument, and they will be addressed in a subsequent piece.

What Leadership Looks Like Now

For engineering leaders, the convergence of cognitive load theory, architectural history, and AI’s dual impact points toward three practices that distinguish organizations that will navigate this period well.

Treat cognitive load as a measurable architectural input, not a cultural side effect. Skelton and Pais argue that team cognitive load should be explicitly assessed before assigning system responsibilities — not estimated informally, but evaluated through structured conversations about system comprehension, change confidence, and time spent navigating versus building [2]. This discipline becomes more important as AI tools make it easier to produce code faster. Velocity is not a proxy for comprehension. A team that ships rapidly with AI assistance but cannot confidently reason about what it has built is not high-performing — it is accumulating comprehension debt that will surface as architectural fragility under pressure.

Encode architectural intent explicitly and maintain it continuously. AI tools follow architectural discipline only as faithfully as the context they receive encodes it. This means that architectural decisions — dependency rules, boundary definitions, domain language, ownership contracts — cannot remain implicit in team norms and individual judgment. They must be encoded in the tools and contexts that shape AI generation: system prompts, linting rules, architectural fitness functions, and code review criteria that specifically evaluate architectural coherence rather than just functional correctness. Ford, Parsons, and Kua’s concept of architectural fitness functions — automated checks that validate architectural properties over time — becomes significantly more valuable in an environment where generation volume can outpace human review [15].

Evaluate rewrites on knowledge, not cost. The economic case for rewrites has strengthened. The knowledge case has not changed. Before committing to an AI-assisted rewrite, engineering leaders should be able to answer: does the team understand the existing system’s domain behavior well enough to replicate it intentionally? Does it understand the failure modes well enough to avoid them? If the answer to either question is no, the rewrite is not yet viable regardless of its cost — and the prerequisite investment is in comprehension, not generation.

Conclusion: The Ceiling Didn’t Disappear. It Moved.

Software architecture has never been primarily a technical discipline. It has always been a human capacity discipline — an ongoing negotiation between the complexity of the systems we need to build and the cognitive limits of the people who build them. Every significant architectural shift in the industry’s history has been, at its core, an attempt to keep that negotiation from becoming a rout.

AI has changed the terms of that negotiation in ways that are genuinely new. It has expanded what small teams can build and accelerated what large teams can ship. It has introduced tools that reduce extraneous cognitive load on routine development work in ways that are measurably real. These are meaningful gains, and dismissing them in favor of a purely cautionary narrative would be intellectually dishonest.

But AI has also introduced comprehension debt at a scale and speed that existing architectural governance is not equipped to detect. It has disrupted Conway’s Law in ways that make organizational and system alignment harder to maintain. It has made the disciplines that manage cognitive load harder to enforce at the pace it enables. And it has lowered the cost barrier on rewrites without lowering the knowledge barrier — creating the conditions for a new generation of legacy systems built faster, understood less, and hitting their cognitive ceiling sooner than any that came before.

The organizations that navigate this well will not be those that adopt AI most aggressively or resist it most cautiously. They will be those that understand what AI actually does to the cognitive load ceiling — where it genuinely lifts it, where it quietly raises it in disguise, and where it has rendered old assumptions about cost and discipline obsolete without rendering the underlying problems obsolete along with them.

What makes a partnership survive difficult terrain is rarely that both partners make the right calls. The reckless partner is not simply reckless — beneath the chaos is a genuine desire to get the job done, to solve the problem in front of them, to protect what matters. That does not make the recklessness harmless. It makes it harder to argue against, because the intent is real. And the responsible partner, over time, is not simply responsible — exposed long enough to the velocity and the results, they begin to absorb the habits of the reckless one. Not out of negligence but out of pressure, out of the intoxicating evidence that it seems to be working, out of not wanting to be the person who slows everything down. Both partners drift. Both make decisions they later regret. What holds them together is not a clean record of good judgment. It is the commitment to carry the consequences side by side.

There is a question that the responsible partner eventually asks — quietly, without accusation, but with the full weight of someone who has been covering for everyone else for a long time: when is anyone going to cover me? It is the question engineering teams are beginning to ask about AI adoption. They have covered for code they did not fully author. They have covered for architectural drift they did not fully cause. They have covered during incidents at 2am when systems built faster than they were understood finally broke in ways nobody anticipated. They have absorbed the cognitive load, the comprehension debt, and the consequences — while the velocity was celebrated and the shortcuts were encouraged. The question of who covers the team is not a complaint. It is the most important organizational accountability question in AI-assisted software development, and most leadership conversations about AI have not yet seriously asked it.

The relationship between engineering teams and AI is arriving at that kind of moment. The decisions that led here were made under real pressure by people doing their best with what they had. Some of those decisions will turn out to be wrong. The comprehension debt will surface. The architectural drift will become visible. The rewrites will come. What determines whether organizations survive those moments is not whether they placed the perfect bet on AI early. It is whether they have built the discipline, the shared understanding, and the genuine accountability — in both directions — to face the consequences of imperfect decisions together. To cover each other. To keep moving.

The ceiling has not disappeared. It has moved. And in some places, it has become harder to see.

That is precisely when it matters most to look for it — together.

Sources & Further Reading

[1] Sweller, J. (1988) — Cognitive Load During Problem Solving: Effects on Learning Cognitive Science, 12(2), 257–285. The foundational paper introducing Cognitive Load Theory and distinguishing intrinsic, extraneous, and germane load as distinct components of working memory burden.

[2] Skelton, M. & Pais, M. (2019) — Team Topologies: Organizing Business and Technology Teams for Fast Flow IT Revolution Press. Establishes cognitive load as a first-class constraint in team and system design, with practical frameworks for assessing and managing cognitive load across engineering organizations.

[2a] Brooks, F.P. (1975) — The Mythical Man-Month: Essays on Software Engineering Addison-Wesley. The foundational work arguing that conceptual integrity — a unified, coherent vision of the system — is the most important consideration in system design. An early articulation of what cognitive load theory would later formalize: that systems must remain within the cognitive reach of the people responsible for them.

[3] Newman, S. (2015) — Building Microservices: Designing Fine-Grained Systems O’Reilly Media. The definitive practitioner guide to microservices architecture, covering service decomposition, inter-service communication, and the organizational conditions under which microservices deliver value.

[4] Google Cloud / DORA — State of DevOps Reports Annual large-scale industry research on software delivery performance, consistently demonstrating the relationship between team autonomy, deployment frequency, and organizational outcomes.

[5] Fowler, M. — Microservices Premium martinfowler.com. Articulates the overhead cost of microservices architecture and the threshold at which that overhead becomes justified by organizational benefits.

[6] Martin, R.C. (2017) — Clean Architecture: A Craftsman’s Guide to Software Structure and Design Prentice Hall. Presents the dependency rule and clean architecture principles, drawing on Cockburn’s earlier work on hexagonal architecture and ports-and-adapters.

[7] Beck, K. & Fowler, M. — YAGNI (You Aren’t Gonna Need It) martinfowler.com. Articulates the Extreme Programming principle against speculative generality, arguing that structure introduced ahead of demonstrated need consistently produces higher costs than deferring it.

[8] Evans, E. (2003) — Domain-Driven Design: Tackling Complexity in the Heart of Software Addison-Wesley. The foundational text introducing bounded contexts, ubiquitous language, and the aggregate pattern as tools for aligning software structure with domain complexity.

[9] Vernon, V. (2013) — Implementing Domain-Driven Design Addison-Wesley. Practical guidance on applying DDD in real-world systems, with case studies demonstrating both the benefits of full adoption and the organizational investment it requires.

[10] Yetiştiren, B., Özsoy, I., Ayerdem, M. & Tüzün, E. (2023) — Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT arXiv:2304.10778. Empirical study evaluating the code quality of major AI generation tools across validity, correctness, security, reliability, and maintainability metrics — finding consistent code smell accumulation and technical debt in AI-generated code, with maintainability issues present across all tools studied.

[11] Conway, M.E. (1968) — How Do Committees Invent? Datamation, 14(4), 28–31. The original statement of Conway’s Law, observing that organizations design systems that mirror their communication structures — a dynamic that AI-assisted development disrupts in ways not previously encountered.

[12] Spolsky, J. (2000) — Things You Should Never Do, Part I Joel on Software. The landmark essay establishing the “never rewrite” doctrine, grounded in the economic and knowledge costs of discarding working systems — costs that AI has partially but not wholly changed.

[13] Erlikh, L. (2000) — Leveraging Legacy System Dollars for E-Business IT Professional, 2(3), 17–23. IEEE Computer Society. Documents the consistent underestimation of implicit knowledge embedded in legacy systems, a failure mode elevated in AI-assisted codebases where generation outpaces comprehension.

[14] Caudill, H. (2019) — Lessons from 6 Software Rewrite Stories Medium. Comparative analysis of software rewrite outcomes identifying deep domain and failure-mode knowledge as the distinguishing property of successful rewrites.

[15] Ford, N., Parsons, R. & Kua, P. (2017) — Building Evolutionary Architectures: Support Constant Change O’Reilly Media. Introduces architectural fitness functions as automated mechanisms for continuously validating architectural properties, a practice of increased importance when AI generation volume can outpace human architectural review.

[16] Tornhill, A. & Borg, M. (2022) — Code Red: The Business Impact of Code Quality — A Quantitative Study of 39 Proprietary Production Codebases IEEE/ACM International Conference on Technical Debt (TechDebt), pp. 11–20. Peer-reviewed empirical study across 39 production codebases demonstrating that low-quality code contains 15 times more defects and takes on average 124% longer to resolve issues — establishing automated code health assessment as a measurable, business-relevant signal for architectural decay.

Designing for Scale Before Scaling: A Practical Reading of Conway's Law

Sun, 15 Mar 2026 00:00:00 +0000

Where Organizational Structure Meets Delivery Economics

“Organizations design systems that mirror their own communication structure.”
— Melvin Conway, 1967

Conway wrote that sentence nearly sixty years ago, and engineering teams are still learning it the hard way. Not in architecture reviews. Not in retrospectives. In production, at 2am, when a revert cascades into three new incidents, or when a customer upgrade fails because two teams integrated the same shared schema in incompatible ways and nobody noticed until it was far too late.

Conway’s Law is not a philosophical observation you cite in a tech talk and then ignore. It is a diagnostic instrument. It will tell you, with brutal accuracy, exactly where your organization is lying to itself.

In a previous post on Practical Git Branching for FinTech, I laid out a concrete branching model for multi-customer financial systems — how release branches protect delivery stability, how customer isolation preserves contractual commitments, and how the structure of your Git workflow must reflect the realities of on-prem deployments, schema evolution, and regulatory versioning.

That post answered the question: what does a sound delivery structure look like?

This post asks the question that should come before it: why does your delivery structure need to look like that — and does your current structure honestly reflect your organizational reality?

The answer runs through Conway’s Law. Not as philosophy. As a diagnostic.

The Question Nobody Asks Before It’s Too Late

When an engineering team starts struggling — with integration conflicts, unstable releases, endless hotfixes, or customer-specific regressions — the instinct is to reach for process. Add a staging branch. Create a feature freeze window. Gate things more tightly.

Sometimes those interventions help. Often, they obscure the real problem long enough that it metastasizes.

The question that actually matters is not “which Git branching model should we use?” It is: where does complexity actually live in our organization — and is our delivery structure honest about that?

In multi-customer FinTech systems specifically, there are two completely different kinds of complexity that constantly get conflated, and conflating them is the root cause of most branching dysfunction in the wild.

Development coordination complexity asks: how many teams integrate simultaneously? How large are the parallel workstreams? How tightly coupled are the modules? How mature are the internal API contracts? How often do teams step on each other?

Delivery and release complexity asks: how many customers are on different versions? What are the contractual version commitments? How divergent are customer-specific configurations? How constrained are database upgrade paths? What does the regulatory audit trail require?

These two forces are not just different in degree. They are orthogonal in nature. You cannot solve delivery complexity by adding more development branches, and you cannot solve coordination complexity by tightening your release governance. Teams that don’t make this distinction clearly will end up building a branching strategy that attacks the wrong problem — and they will feel busy and rigorous while doing it.

If you misidentify where your real complexity resides, your branching model will fight your architecture instead of supporting it.

What Conway’s Law Actually Tells You About Your Branches

Here is how to use Conway’s Law as a diagnostic: look at your Git graph and ask yourself whether its complexity maps to a real communication complexity in your organization.

If you have one cohesive product team with clear ownership, regular communication, shared context, and strong CI/CD pipelines — and your branch diagram looks like a subway map — that is a red flag. Not because complex branching is always wrong, but because structural complexity you cannot justify with organizational reality is debt in disguise. It is ceremony that provides the feeling of rigor without delivering it.

In that scenario, your multiple staging branches and integration gates are not protecting you. They are hiding the fact that your team hasn’t truly resolved what “done” means, or what “the product” is at any given moment. The branches are a coping mechanism for a clarity problem.

Conversely, if you have a genuine multi-team coordination problem — multiple squads working in parallel on shared infrastructure, tight release windows, significant domain overlap — and your trunk is a single unguarded main branch with no integration discipline, that is also a structural lie. You are pretending coordination complexity doesn’t exist, and eventually a merge conflict at 4pm on a Friday before a major customer release will make the lie undeniable.

The point is not “use trunk-based development” or “don’t use trunk-based development.” The point is that your branching strategy should be an honest representation of your organizational structure. No more complex than it needs to be. No simpler than reality demands.

Take your current branch model and draw it out. Then draw your organization’s communication structure — who talks to whom, how frequently, about what. If the two diagrams don’t roughly correspond in complexity and topology, your branching model is lying about something. The question is what.

When Development Is Not the Hard Part

Consider a product maintained by a single cohesive team with shared ownership, continuous integration discipline, and clear domain boundaries. This environment does not suffer from high coordination entropy. There are no parallel squads colliding daily, no large-scale merge storms, no need for multi-team synchronization layers.

In this setting, adding integration buffers does not reduce risk. It diffuses responsibility. It creates a second “almost-main” baseline that introduces ambiguity about what the product actually is at any given moment.

Trunk-based development is structurally aligned with this reality:

Short-lived feature branches
Immediate integration into a single authoritative baseline
Fast conflict discovery
Clear source of truth at all times
Reduced cognitive overhead for everyone on the team

Simplicity, when it matches organizational reality, is not a shortcut. It is a force multiplier.

The key word is matches. Trunk discipline is not appropriate because it is fashionable. It is appropriate when development coordination complexity is genuinely low — and in a single-team product, it almost always is.

Why Trunk-Based Development Makes Sense for Single-Team FinTech Products

Let’s be concrete about why this matters specifically in financial systems.

In financial-grade systems, the most dangerous surface is not your code — it is your persisted state. Database schemas. Transaction records. Authorization policies. Downstream integration contracts. These things do not roll back cleanly. A schema migration that runs in one environment and fails in another is not just a bug. It is a potential data integrity incident. In regulated systems, it can be a compliance event.

When you integrate continuously into a single trunk, migration conflicts surface immediately. Contract violations between services are detected within minutes of the offending commit. Security scanning evaluates the actual integrated system, not a feature branch that only exists in developer environments. The CI/CD pipeline validates the thing that will actually ship — not a local approximation of it.

Compare this to a model where feature branches live for days and conflicts are discovered late in the cycle. In that model, the cost of a database migration conflict is not a five-minute fix. It is a multi-day archaeological exercise involving schema diff tools, version-specific migration scripts, and at least one very uncomfortable call with a customer’s DBA.

Integration latency is not just an inconvenience. In FinTech, it is direct exposure to state-level risk that compounds with every hour conflicts go undetected.

There is also an underappreciated cultural benefit. When main is always the authoritative representation of the product — not one of several competing baselines — there is no ambiguity about what “the product” is at any moment. Engineers cannot hide behind “it works on my branch.” Either the integrated system is healthy or it isn’t. This forces the kind of engineering honesty that financial systems require.

Where Real Complexity Emerges: Multi-Customer Delivery

Now shift the lens to what the previous post addressed directly.

In a multi-customer financial system, customers upgrade at different times. Each may receive a different feature set based on contractual commitments. Regulatory posture must be preserved per version. Post-delivery customizations may exist in customer environments. Schema evolution must remain upgrade-safe across every version in the field.

This is not development complexity. This is delivery governance complexity. And it cannot be solved by adding more development branches.

This is precisely why the branching model from the previous post is structured the way it is. Release branches are not bureaucratic overhead — they are contractual artifacts. Customer isolation branches are not fragmentation — they are version commitments made tangible. The structure exists because delivery risk in financial systems is asymmetric: a failed customer upgrade, a schema migration inconsistency, or version drift between environments carries consequences that no amount of elegant code quickly undoes.

The branching model must reflect where risk truly lives. In multi-customer FinTech, risk does not primarily live in development integration. It lives in delivery.

Where the Real Risk Actually Lives: Release Governance

Here is the part that teams often get backwards. They introduce complex development branching to manage delivery risk — and in doing so, they delay the feedback loops that would actually help them manage it.

In multi-customer FinTech, delivery risk is real and unavoidable. Your customers upgrade at different times. Some have customizations layered on top of your core product. Some operate under regulatory frameworks that require version-specific audit trails. Some have DBAs who need to sign off on every schema change before it touches their environment. This complexity exists, and no amount of trunk discipline eliminates it.

But the right tool for that problem is not more development branches. It is explicit release governance. In practice, this means a clear separation of three concerns:

Trunk is where you build. It represents the current integrated state of the product — a state you would be comfortable deploying if a customer asked for it. Every commit is validated. Every migration is tested against upgrade paths. Every feature flag is accounted for. Main is sacred not because of ceremony, but because every customer release is eventually cut from it.

Release branches are where you commit. When a customer release is due, you cut a release branch from a known-good integration point on trunk. That branch represents a contractual commitment. It receives only critical fixes, applied forward from trunk. It does not receive new features. It is not a development environment — it is a delivery artifact.

Customer branches are where you isolate. In cases where a customer requires post-delivery customization or where their upgrade path diverges significantly, a customer isolation branch preserves that state explicitly. It is not where you build new things — it is where you honor existing commitments while the main product moves forward.

Development complexity is managed through trunk discipline and CI/CD maturity. Delivery complexity is managed through release governance and customer isolation. These are separate concerns, and the moment you try to solve one with the tools designed for the other, you create structural debt that will surface at the worst possible moment.

Separating Development Flow from Delivery Flow

A clean architecture makes this separation explicit, and it is what makes the overall model coherent rather than ad hoc.

Development optimizes for clarity and speed: continuous integration into a single trunk, immediate validation of database migrations, immediate detection of integration conflicts, security baseline established at integration, main always representing the current product state.

Delivery optimizes for stability and traceability: releases cut from specific validated integration points, customers receiving controlled versioned snapshots, upgrade paths tested explicitly before promotion, post-delivery isolation preserved where required by contract or regulation.

When these two concerns are conflated — when teams attempt to manage delivery risk through development branching — you end up with a workflow that is simultaneously too rigid for development and too loose for delivery. The branches multiply, ownership blurs, and the actual delivery risk remains unaddressed beneath layers of process.

Feature Variance Across Customers: A Delivery Problem, Not a Development One

One of the hardest practical questions in multi-customer systems is what to do when a feature is not intended for every customer. The instinct is often to reach for branching — a customer-specific branch, a conditional merge, a separate integration path. This instinct is wrong, and expensive at scale.

Feature variance across customers is not a development branching problem. It is a release governance problem. The correct architectural solutions are configuration-driven behavior, feature flags, or controlled release cuts from earlier integration points on trunk.

The trunk represents product evolution. Release branches represent contractual commitments to specific customers at specific points in that evolution. When these concerns are kept separate, the system remains stable without fragmenting development. When they are conflated, you end up maintaining multiple divergent codebases that converge on merge complexity rather than product clarity.

Multiple Products, Independent Trunks

When an organization operates multiple independent products, each with its own team, the model scales naturally. Each product maintains its own trunk, its own integration discipline, and its own release cadence. Cross-product coordination happens at architectural boundaries — through versioned APIs and explicit contracts — not inside Git.

The temptation as organizations grow is to manage cross-product complexity through shared branching structures. That approach compounds badly. Branching complexity does not compensate for unclear system boundaries. It amplifies them.

If two products cannot be maintained on independent trunks without constant cross-product branch dependencies, that is a signal that the product boundaries themselves are not real — that what has been administratively divided is architecturally unified. No branching strategy fixes an architectural boundary problem. The fix is clarifying that boundary at the code and data level.

Independent trunks scale horizontally. Shared branching hierarchies scale by becoming progressively more painful until the architectural investment that should have happened earlier is finally unavoidable.

Scaling Trunk Discipline as Teams Grow

The natural objection to this model is scale: what happens when the team is no longer small?

Trunk-based development does not collapse under scale. It evolves through reinforcement. What changes as teams grow is not the branch model — it is the reinforcement around it.

Phase 1 — Single team: Integration cost is low. Communication is immediate. Conflicts are resolved socially as much as technically. Trunk absorbs changes continuously. Simplicity is an advantage; adding integration layers adds only ceremony.

Phase 2 — Multiple teams, single product: Trunk discipline does not disappear — it hardens. Stronger CI pipelines. More granular ownership boundaries. Domain-driven modularization. Clear API contracts between internal components. Mandatory code review depth. Stricter risk classification. The branch structure remains simple. The system architecture becomes more explicit.

If trunk begins to feel unstable as teams multiply, the problem is almost always architectural coupling — not the branch model itself. Trunk-based development at scale demands clear service boundaries, modular code ownership, and automated validation maturity. When those exist, trunk remains stable even as the organization grows. When they don’t, no branching complexity compensates.

Designing for Scale Before Scaling — And Why Most Teams Get This Backwards

Here is the uncomfortable truth about engineering organizations that struggle at scale: most of them scaled their Git workflow long before they scaled their architecture. Their branching complexity is not a reflection of organizational sophistication — it is a monument to accumulated avoidance.

When trunk integration becomes painful, the natural response is to add a buffer. When that buffer creates its own friction, add another layer. Before long, you have a branching hierarchy that requires a diagram to explain, an onboarding guide dedicated entirely to “how we do Git,” and senior engineers spending meaningful time just figuring out where to merge things.

Conway’s Law is merciless here. Branching complexity does not fix unclear domain boundaries — it amplifies them. Every extra branch is a place where ownership becomes ambiguous. Every integration layer is an opportunity for “who’s responsible for that?” to become an unanswerable question at the worst moment.

The organizations that scale well do it through architecture, not through Git ceremony. As coordination complexity genuinely increases — as teams multiply, as domains diverge, as parallel workstreams become real — the correct response is:

Make domain boundaries explicit in the code. Module ownership should be unambiguous. Internal APIs should be formal, not informal. Shared state should be minimal and clearly governed. When boundaries are real, trunk integration stays stable even as the team grows, because changes to one domain don’t silently break another.

Deepen CI/CD, don’t widen branching. A mature CI/CD pipeline — one that runs comprehensive migration testing, contract validation, security scanning, and regression testing on every commit — eliminates most rationale for staging buffers. The staging function moves into automation, where it belongs.

The evolution path is clear:

Stage	Response
Small team	Simplicity
Growing team	Reinforced simplicity
Large organization	Architectural segmentation

At no point is the answer “add more permanent branches.” Branching complexity should follow demonstrated organizational necessity — not anticipate it prematurely. Premature complexity becomes structural debt, and structural debt in delivery pipelines compounds faster than technical debt in code.

The Economic Frame: Why This Is a Capital Allocation Question, Not a Tooling One

Engineering leaders in FinTech sometimes resist thinking about software development structure in economic terms. That resistance is expensive.

Every structural decision in your delivery pipeline has a cost and a yield. Integration latency has a cost: the longer conflicts go undetected, the more expensive they are to resolve. Fragmented baselines have a cost: cognitive overhead multiplied across every engineer who needs to understand where things actually stand. Unclear release state has a cost: compliance exposure, customer confusion, and the engineering time spent answering “wait, what version is this customer actually on?”

Database migration failures in production have a cost that is easy to underestimate until you have lived through one: direct customer downtime, potential data inconsistency, compliance review, customer success escalations, and a rebuild of trust that takes months. Preventing one of those with better integration discipline and more explicit release governance is an extremely high-ROI investment.

Conversely, premature branching complexity also has a cost. Every permanent integration layer is an ongoing tax on developer velocity and cognitive bandwidth. Every merge ceremony that exists without clear organizational justification is waste — not disciplined waste, just waste.

The economically rational structure for a single-team FinTech product with multi-customer delivery obligations is not complicated to state:

Trunk discipline for building — one authoritative baseline, continuous integration, forward-fix culture
Release branching for distribution — controlled snapshots, contractual commitments, upgrade-path validation
Customer isolation where necessary — post-delivery preservation of contractual state without fragmenting development

Nothing more. Nothing less. The goal is minimal structural complexity commensurate with actual organizational reality.

A Subtle but Important Shift in Perspective

Most teams design branching models around what might go wrong. They add gates and buffers reactively, in response to past incidents or imagined future complexity.

A more resilient approach is designing around where things actually are:

Where does state persist?
Where are version commitments made?
Where does coordination truly exist?
Where does operational risk concentrate?

In the systems this series has been describing, the answer is consistent: development risk is low, delivery risk is high. So the correct response is to optimize development for clarity and speed, and optimize delivery for governance and traceability.

That is what the branching model from the previous post implements in practice. This post has argued why it is the right model — not because of aesthetic preference for simplicity, but because it honestly reflects where complexity lives in the organization.

Closing Thought

The goal is not to defend trunk-based development as an ideology. The goal is to align the delivery model with organizational reality — today and as the organization grows.

Today, if development complexity is low and delivery complexity is high, the structure should reflect that honestly. Tomorrow, as development complexity genuinely increases, the model evolves — through stronger architecture, deeper automation, explicit domain separation, and temporary orchestration when necessary. Not through permanent branching layers that accumulate as artifacts of decisions made under pressure.

Simplicity is not fragile.
It is scalable — when reinforced intentionally and when it honestly mirrors the organization that maintains it.

Structure is not aesthetics.
In FinTech, it is economics.
And economic misalignment compounds faster than code complexity ever will.

The Inevitable Cycles: Why Software Houses Keep Returning to Square One

Mon, 12 Jan 2026 00:00:00 +0000

There and Back Again — from Cloud to On-Prem, Projects to Products

Software organizations do not scale by following a single best practice indefinitely. Decisions that enable speed and survival in early stages—cloud-first infrastructure, project-driven delivery, lightweight processes, and generalist roles—often become sources of friction as teams, customers, and systems grow. What appears to be a return to “square one” is rarely regression; it is a recalibration driven by new economic, operational, and organizational realities. Much like a journey there and back again, experienced software leaders recognize that sustainable growth depends on knowing when to revisit earlier choices—not to repeat them, but to apply them with greater discipline and intent.

The diagram below summarizes the recurring cycles discussed throughout this article.

Five recurring cycles in software organization evolution

Cloud vs On-Prem Infrastructure Evolution

The first place this cyclical pattern becomes visible is infrastructure. Few decisions feel as definitive—or as emotionally charged—as the choice between cloud and on-prem. Yet across startups, scale-ups, and mature software houses, infrastructure strategy repeatedly follows the same arc: cloud first, then self-hosted, and eventually back to cloud again. This pattern is not anecdotal; it is repeatedly observed in academic research and industry surveys examining long-term cost structures, operational complexity, and organizational maturity.

Phase 1 — Startup Mode: Cloud-First by Necessity

In the earliest stage, infrastructure decisions are driven almost entirely by survival. Small teams—typically between two and twenty engineers—default to cloud-hosted tooling such as GitHub or GitLab SaaS, managed CI/CD pipelines, hosted issue trackers, and fully managed databases.

This choice is pragmatic rather than strategic. Cloud platforms eliminate upfront capital expenditure, require minimal DevOps maturity, and allow teams to focus on shipping features instead of running systems. Industry analyses consistently show that startups favor cloud infrastructure because it converts capital expenses into operating expenses and dramatically reduces time-to-market [1].

At this stage, unit economics and long-term total cost of ownership are secondary concerns. Speed, optionality, and survival dominate decision-making.

Cloud, here, is less a strategy and more a survival hack.

Phase 2 — Growth Mode: When Cloud Becomes “Quietly Expensive”

As organizations grow into the 20–200 engineer range, the economics begin to shift. What once felt frictionless starts to reveal hidden costs. CI minutes grow exponentially, storage and artifact repositories expand rapidly, and per-user SaaS pricing compounds across teams. Compliance, data residency, and security requirements introduce constraints that were irrelevant in the startup phase.

This is typically the point where finance begins questioning infrastructure spend: Why is our tooling cost growing faster than revenue?

In response, engineering teams often start self-hosting parts of the stack—Git servers, CI runners, artifact repositories—because steady, predictable workloads make on-premise or self-managed infrastructure appear financially attractive. This perception is supported by both academic and industry research. Fisher (2018) [2] demonstrates that while cloud solutions are cheaper in early years, on-premise infrastructure can be significantly less expensive over long time horizons, with total costs dropping to nearly 56% of cloud costs after ten years for stable workloads.

Industry cost analyses and practitioner reports reinforce this finding, particularly where utilization is high and elasticity offers limited benefit [3][4].

At this stage, moving away from the cloud is often seen as a sign of maturity—a correction to early convenience-driven decisions.

Phase 3 — Scale Mode: Operational Complexity Takes Over

As software houses scale further—beyond 200 engineers or across multiple business units—the dominant constraint shifts again. This time, it is no longer primarily about infrastructure cost.

Operational complexity becomes the real bottleneck.

Self-hosted systems proliferate: version control, CI/CD, wikis, ticketing platforms, monitoring stacks, identity systems. Each requires upgrades, backups, disaster recovery planning, security patching, and dedicated operational ownership. Over time, specialized teams emerge whose primary responsibility is simply keeping internal platforms running, while critical knowledge becomes concentrated in small silos.

At this scale, cognitive load and organizational risk outweigh raw infrastructure savings.

This is where the pendulum swings back. Mature organizations increasingly return to cloud platforms—not to reduce costs, but to simplify governance and reduce operational drag. Large-scale surveys and enterprise studies show that most organizations eventually adopt hybrid models, combining on-prem and cloud workloads to balance cost efficiency, compliance, and operational resilience [5].

Cloud, at this stage, is no longer about speed. It becomes a governance and complexity management tool.

Key Insight: The recurring cloud-to-on-prem-and-back cycle reveals a deeper truth: infrastructure cost is rarely the root problem—organizational complexity is.

As teams grow, the “right” infrastructure choice changes—not because earlier decisions were wrong, but because scale fundamentally alters the optimization landscape [6].

Project-to-Product Evolution

A second, equally persistent cycle appears in how software houses deliver value. Many organizations begin by building bespoke solutions for individual customers, evolve toward productization to gain leverage, and eventually find themselves constrained by the very products that once enabled their growth. This pattern is not anecdotal; it is well documented in both academic research and industry practice examining how software firms transition from customer-specific development to market-oriented product models.

Phase 1 — Project-Driven Beginnings

Most software houses start as project-driven organizations. Early teams build exactly what customers ask for, optimize for delivery speed, and tie revenue directly to individual engagements. This approach provides immediate benefits: fast cash flow, deep customer understanding, and highly adaptable engineering teams.

Academic research describes this phase as customer-specific software development, where solutions are tightly coupled to individual clients rather than a broader market [7]. For young companies, this model is not a weakness—it is a rational response to uncertainty, allowing teams to learn quickly and establish credibility.

The limitations emerge gradually. Each project largely starts from zero, reuse is minimal, and scale is achieved primarily by adding people. Engineering leverage remains low, and margins are constrained by delivery capacity.

Phase 2 — Productization for Leverage

As similar projects repeat, patterns begin to emerge. Teams identify common components, shared architectures take shape, and internal frameworks evolve into platforms. Over time, this reuse becomes intentional, and a product is born.

This transition—from bespoke projects to product software—is formally described in the software engineering literature as productization [7][8]. Empirical case studies show organizations moving through identifiable stages: independent projects, reuse across projects, product recognition, and eventually product platforms [7]. As companies progress through these stages, they introduce software product management practices such as roadmapping, release planning, and market-driven requirements.

The benefits are significant. Productization enables reuse, predictable delivery, improved margins, and sales scalability. This is the point at which many software houses begin operating as product companies rather than service providers.

Industry perspectives reinforce this shift. Mik Kersten’s Project to Product frames this evolution as a move away from funding individual projects toward optimizing value streams, enabling organizations to scale delivery without scaling headcount at the same rate [9].

Phase 3 — Product Maturity Becomes Rigidity

Over time, mature products tend to harden. Architectures stabilize, customization paths narrow, and change becomes slower and more expensive. What once enabled scale begins to constrain flexibility.

At this stage, customers increasingly seek differentiation, faster turnaround, and workflows tailored to their specific needs. Instead, they often hear: That’s not supported—you’ll need to adapt your process to the product.

Research on evolving software product lines highlights this tension explicitly. As products mature, customization becomes more complex and costly, particularly when variability was not designed into the architecture early on [10]. Consulting research reaches a similar conclusion: firms that over-standardize often struggle to balance customization value against the operational cost of complexity [11].

The outcome is predictable. Some customers drift away, and new software houses emerge offering bespoke solutions once again. The cycle restarts—not because productization failed, but because no single delivery model optimizes for both scale and differentiation indefinitely.

Key Insight: Products optimize for scale. Bespoke solutions optimize for differentiation.

No single model wins forever.

The project-to-product cycle is not a linear maturity path with a final destination—it is a recurring recalibration driven by changing market, customer, and organizational constraints.

Process Evolution

The cyclical nature of software organizations becomes especially visible in how delivery processes evolve. Over the past several decades, teams have repeatedly shifted from structured, plan-driven models to lighter, iterative approaches—only to later reintroduce structure in new forms. This evolution is not random; it reflects how organizations respond to changing scale, risk, and coordination challenges [12][13].

Phase 1 — Structured Processes for Predictability

Early large-scale software efforts favored highly structured, sequential models such as Waterfall. These approaches emphasized upfront planning, documentation, and formal handoffs in an attempt to control complexity and risk. Historically, this model was particularly attractive to regulated industries and large institutions, including government and defense organizations [14].

At smaller scales, this structure often proved heavy-handed. Long feedback cycles delayed learning, and teams struggled to adapt to changing requirements. As markets accelerated and software became more customer-facing, the limitations of rigid, upfront planning became increasingly visible.

Phase 2 — Agile and DevOps as a Reaction to Rigidity

Agile methodologies emerged as a direct response to the constraints of plan-heavy processes. By prioritizing working software, short feedback loops, and close collaboration, Agile promised speed, adaptability, and higher customer satisfaction. Later, DevOps extended this thinking by integrating development and operations, reducing deployment friction, and improving delivery throughput [12][15].

Large-scale industry studies, including DevOps maturity and performance research, show that these practices deliver substantial benefits when adopted effectively. Teams report faster deployment cycles, improved reliability, and stronger alignment between technical and business outcomes [15].

However, as Agile and DevOps scaled across entire organizations, new problems surfaced. Coordination across multiple teams, regulatory compliance, dependency management, and long-term planning reintroduced complexity. What began as a lightweight process often accumulated layers of ceremony, tooling, and governance—ironically recreating some of the rigidity Agile originally sought to eliminate.

Phase 3 — Hybrid Models and the Return of Structure

At scale, many organizations do not abandon Agile—but they adapt it. Hybrid delivery models emerge, blending Agile practices with traditional planning and governance mechanisms. Research and industry case studies consistently show large enterprises combining Waterfall-style stage gates with Agile execution to manage risk, especially where legacy systems or regulatory constraints exist [16][17].

Professional bodies such as the Project Management Institute (PMI) explicitly acknowledge this trend, noting that successful organizations are not choosing between Agile and Waterfall permanently, but intentionally blending them based on context [16]. Peer-reviewed research reinforces this view, identifying hybrid models as an increasingly common and effective response to competing demands for predictability and flexibility [18].

The result is a familiar pattern: organizations move from rigid structure to flexibility, then reintroduce structure—this time informed by experience and adapted to scale.

Key Insight: Process evolution in software organizations is not a linear progression toward a “best” methodology.

Processes are adopted to solve today’s dominant problems—speed, quality, coordination—but each solution introduces new constraints at scale. As those constraints grow, organizations adjust again, often revisiting earlier ideas in modified form.

What looks like regression is usually recalibration.

Role Evolution Cycle

As software organizations scale, the way roles are defined and organized evolves in predictable—and recurring—patterns. Early teams favor generalists who do everything. Growth introduces specialization to reduce risk and increase reliability. At larger scales, however, specialization itself becomes a bottleneck, driving organizations back toward integrated, cross-functional or platform-oriented team models. This evolution is not linear; it is cyclical, shaped by tooling maturity, organizational friction, and delivery constraints [19][20].

Phase 1 — Generalists by Necessity

In early-stage software teams, roles are fluid. Developers write code, deploy it, debug production issues, and often interact directly with customers. This generalist model is not ideological—it is practical. Small teams lack the scale to support specialized roles, and modern tooling lowers the barrier to participating across the delivery lifecycle.

Industry commentary on role evolution notes that early engineers are often “full-stack by default,” covering wide functional areas out of necessity rather than preference [21]. At this stage, autonomy is high, coordination overhead is low, and speed matters more than formal role boundaries.

Phase 2 — Specialization to Manage Scale

As systems grow more complex and uptime expectations increase, organizations introduce specialization. Dedicated roles emerge: DevOps engineers, SREs, QA specialists, security engineers, and release managers. Each role addresses a real scaling pain—deployment failures, operational instability, quality regressions, or compliance risk.

Google’s Site Reliability Engineering (SRE) model is a canonical example of this phase. SRE reframed operations as an engineering discipline, introducing explicit reliability targets, automation, and error budgets to manage production risk at scale [19]. Similarly, DevOps practices formalized responsibilities that were previously implicit, creating clearer ownership and accountability.

Academic research on Agile and DevOps transitions supports this pattern, showing that role differentiation often accompanies process and tooling maturity as organizations attempt to stabilize delivery and reduce operational risk [22].

Phase 3 — Specialization Becomes Friction

Over time, specialization introduces its own costs. Handoffs multiply, feedback loops slow, and ownership becomes fragmented. Developers wait on other teams to deploy, debug, or provision environments. Throw it over the wall dynamics quietly reappear—this time between internal specialists rather than departments.

Industry analyses of DevOps and role maturity repeatedly note this inflection point. As organizations add more specialized roles, coordination overhead increases and local optimizations begin to harm end-to-end flow [20][23]. The very roles created to improve delivery now constrain it.

This pressure drives a structural shift.

Phase 4 — Recomposition into Cross-Functional and Platform Teams

To reduce friction, organizations reorganize again—this time recomposing roles into cross-functional product teams or platform teams that internalize operational responsibility. Instead of central DevOps or SRE teams acting as gatekeepers, platforms provide paved roads, and product teams regain autonomy within guardrails.

This shift aligns with the rise of T-shaped engineers—individuals with deep expertise in one area and sufficient breadth to collaborate effectively across disciplines [24][25]. Modern automation, cloud platforms, and AI-assisted tooling further lower the cost of recombining responsibilities, enabling teams to operate with fewer handoffs than before.

Historical analyses of role evolution explicitly document this pendulum: specialist-heavy models solve scaling problems, then give way to integrated team structures once coordination becomes the dominant bottleneck [20][24].

Key Insight: Role evolution in software organizations is a balancing act between autonomy and stability.

Organizations oscillate between generalists and specialists not because one model is superior, but because each solves a different scaling problem—and creates the next one.

What appears to be a return to earlier role models is usually a recomposition informed by better tooling, clearer boundaries, and hard-earned experience.

Technical Debt Accumulation Curve

Among all the cycles software organizations experience, technical debt is the most persistent—and the most misunderstood. Teams knowingly incur it to move fast, struggle under its weight as systems grow, and eventually face a reckoning: invest in sustained remediation or attempt a risky rebuild [26][27].

Phase 1 — Intentional Debt in the Name of Speed

The concept of technical debt was originally articulated by Ward Cunningham to describe the trade-off between rapid delivery and long-term code quality. Like financial debt, it allows teams to move faster in the short term, with the expectation that the cost will be paid back later [26].

In early-stage products and startups, this trade-off is often rational. Delivery pressure, limited resources, and uncertain requirements incentivize shortcuts: hard-coded assumptions, minimal abstractions, deferred refactoring, and sparse documentation. Empirical research confirms that startups accumulate disproportionately higher levels of technical debt due to these constraints [28].

At this stage, debt is largely invisible. Velocity remains high, and the system still fits in the team’s head.

Phase 2 — Growth Turns Debt into Drag

As the codebase grows and teams expand, technical debt stops being theoretical. Changes take longer, defects increase, and onboarding new engineers becomes expensive. What was once a local shortcut becomes a systemic constraint.

Recent empirical studies show that technical debt grows non-linearly as projects evolve, significantly increasing future development effort and complexity [27]. Longitudinal analyses of issue trackers and repositories reveal that technical debt items often remain unresolved for long periods, accumulating interest in the form of slower delivery and higher defect rates [29].

At this stage, organizations typically respond with refactoring initiatives, architectural cleanups, or modernization programs. These efforts reduce debt temporarily—but rarely eliminate it entirely.

Phase 3 — Rewrite Temptation and the Point of No Return

When incremental remediation no longer feels sufficient, teams begin discussing the ultimate reset: a rewrite from scratch.

History shows that this moment recurs across generations of software companies. The late 1990s Netscape rewrite, famously chronicled by Joel Spolsky, established the industry’s early doctrine: never rewrite your software [30]. Subsequent decades reinforced this cautionary stance as many large-scale rewrites failed spectacularly—often due to underestimated scope, shifting requirements, or organizational fragmentation [31].

Yet the story is not one-sided. Some organizations have successfully rewritten major systems under specific conditions: strong executive alignment, disciplined scope control, and long-term investment. Case studies from companies such as Basecamp, Adobe, and Microsoft (VS Code) demonstrate that rewrites can succeed—but only when treated as strategic, organization-wide commitments rather than engineering side projects [32].

Empirical and consulting research suggests that most rewrites fail not because rewriting is inherently wrong, but because technical debt is a symptom of deeper organizational and process issues that rewriting alone does not solve [33].

Phase 4 — Debt Re-accumulates Under New Pressures

Even successful rewrites do not end the cycle. New architectures introduce new assumptions. Market pressure returns. Teams optimize for speed again.

McKinsey research estimates that technical debt accounts for 20–40% of the value of the entire technology estate, with a majority of CIOs reporting that debt continues to rise year over year [34]. This creates renewed pressure for shortcuts—and the cycle begins again.

Technical debt, in practice, is not a problem to be solved once. It is a force to be continuously managed.

Key Insight: Technical debt behaves like a lifecycle, not a defect.

Teams incur it intentionally to deliver value quickly, suffer its consequences as systems scale, and periodically attempt to reset through refactoring or rebuilds. The pattern repeats not because teams fail to learn—but because growth, competition, and time-to-market pressures never disappear.

The real differentiator is not whether an organization accumulates technical debt, but whether it builds the discipline to service it continuously.

Conclusion: Cycles as a Source of Strength

Software organizations do not struggle because they revisit earlier decisions; they struggle when they expect growth to be linear and permanent answers to exist. The patterns explored here—shifting infrastructure strategies, moving between projects and products, evolving processes, redefining roles, and accumulating technical debt—are not signs of confusion or failure. They are predictable responses to changing constraints as organizations scale.

Each phase in these cycles solves a real problem. Cloud platforms enable speed before cost and governance matter. Productization creates leverage before differentiation becomes critical. Agile and DevOps improve flow before coordination and control dominate. Specialized roles stabilize systems before silos slow them down. Technical debt accelerates delivery before it compounds into drag. None of these choices are inherently wrong. They become problematic only when treated as final destinations rather than context-dependent tools.

At its core, this is a story of continuous improvement rather than straight-line progress. Agile, in its original sense, is not a set of ceremonies or frameworks but a mindset grounded in feedback, learning, and adaptation. Organizations that endure are not those that avoid cycles, but those that move through them deliberately—recognizing when yesterday’s strengths have become today’s constraints, and adjusting without thrashing or denial.

In evolutionary terms, survival favors not the strongest or the most sophisticated, but the most adaptable. Software houses that persist are rarely the ones with the most advanced tooling or the most rigidly enforced processes. They are the ones that develop judgment—knowing when to standardize and when to customize, when to centralize and when to empower, when to pay down debt and when to accept it consciously.

Much like There and Back Again, the journey matters less for where it begins or ends than for what is learned along the way. Bilbo returns from his first adventure not simply changed, but prepared—better equipped to recognize danger, make decisions, and navigate uncertainty when the next challenge arrives. Software organizations follow the same path. Each cycle, when navigated intentionally, leaves them wiser and more capable than before.

Progress in software is rarely about finding the right final state. It is about building the ability to return—again and again—with greater understanding, sharper judgment, and the resilience to face whatever comes next.

Sources & Further Reading

[1] Sosuv Consulting — Selecting the Best Option for Startups: On-Premises vs Cloud Solutions
Explores why startups overwhelmingly choose cloud early on and why those decisions are often revisited as organizations scale.

[2] Cameron Fisher (2018) — Cloud versus On-Premise Computing
American Journal of Industrial and Business Management.
A detailed total cost of ownership (TCO) analysis showing how cloud solutions can be cheaper initially but significantly more expensive than on-premise infrastructure over long, stable usage periods.

[3] Computer Weekly — Reverse cloud migrations: Why some enterprises are shifting their IT back on-premise Reports on IDC survey data showing a significant percentage of enterprises planning partial or full cloud reversals.

[4] Campus Technology (September 2024) — Are Organizations Moving from Cloud to On-Premises?
Cites a Citrix study indicating that many organizations are reconsidering cloud-first strategies.

[5] Terrazone — On-Prem vs Cloud: Total Cost of Ownership (TCO)
Comparative analysis emphasizing scenarios where predictable workloads favor self-managed infrastructure.

[6] IDC (Industry Surveys) — Hybrid Cloud Adoption Trends IDC research showing most enterprises operate hybrid environments as they mature.

[7] Leenen et al. (2012) — Transforming to Product Software: The Evolution of Software Product Management Processes Springer / Utrecht University.
Foundational academic study on software productization stages.

[8] Artz, van de Weerd, Brinkkemper (2010) — Productization: Transforming from Developing Customer-Specific Software to Product Software Classic academic framing of the project-to-product transition.

[9] Mik Kersten (2019) — Project to Product
Industry perspective on shifting from project funding to value-stream optimization.

[10] Empirical Software Engineering (2022) — Visualizing the Customization Endeavor in Product-Based Software
Academic research on customization challenges in mature software products.

[11] Strategy+Business (Booz Allen Hamilton) — Smart Customization: Profitable Growth Through Tailored Business Streams
Research on balancing customization value against complexity costs.

[12] Xorbix — The Evolution of Software Development Methodologies
High-level overview of Waterfall → Agile → DevOps evolution.

[13] Lehman, M. M. — Laws of Software Evolution Foundational theory describing software systems and processes as feedback-driven systems.

[14] Wikipedia — Waterfall Model
Documents institutional use and later evolution toward iterative models.

[15] Google Cloud / DORA — State of DevOps Reports
Large-scale industry research on DevOps maturity and organizational evolution.

[16] Project Management Institute (PMI) — Blending Agile and Waterfall Professional guidance on hybrid delivery models.

[17] Deloitte (via PMI case studies) — Hybrid Agile-Waterfall Delivery Enterprise case studies showing hybrid process adoption.

[18] IEEE (2022) — The Waterfall Model with Agile Scrum as the Hybrid Agile Model Peer-reviewed study supporting hybrid methodology adoption.

[19] Google — Site Reliability Engineering
Foundational material on the emergence of SRE as a scaling response.

[20] DORA / Google Cloud — DevOps Role & Maturity Research Surveys documenting recurring organizational and role evolution patterns.

[21] Ciro Rizzo — The Evolution of the Software Engineering Role
Industry view on how engineering roles have expanded and recombined.

[22] Jovanović et al. — Agile Transition and Adoption Frameworks Systematic mapping study of role and process changes during Agile adoption.

[23] Waydev / ThoughtWorks — DevOps & Platform Team Maturity Industry analysis of over-specialization and recomposition into platform teams.

[24] Alex Kondov — The T-Shaped Engineer Perspective on the shift back toward generalist skill sets.

[25] Wikipedia — T-shaped Skills
Documents evolving skill models in organizations.

[26] Wikipedia — Technical Debt
Foundational overview of Ward Cunningham’s metaphor.

[27] Gupta et al. (2025) — Measuring the Impact of Technical Debt on Development Effort
Empirical study quantifying technical debt impact.

[28] Klotins et al. (2023) — Exploration of Technical Debt in Start-ups
Study showing higher debt accumulation in startups.

[29] Runeson et al. (2023) — Lifecycle of Technical Debt
Longitudinal analysis of debt accumulation and remediation.

[30] Joel Spolsky (2000) — Things You Should Never Do, Part I
Landmark essay on rewrite risks.

[31] Morphis Insights — Rewrite Code from Scratch? Case studies of large-scale rewrite failures.

[32] Aaron Hardy (2019) — We Decided to Rewrite Our Software Adobe’s successful rewrite case study.

[33] Herb Caudill (2019) — Lessons from 6 Software Rewrite Stories
Comparative analysis of rewrite outcomes.

[34] McKinsey & Company — The Cost of Technical Debt Estimates technical debt at 20–40% of total technology estate value.

A Practical Git Branching Strategy for Multi-Version Product Organizations

Fri, 02 Jan 2026 00:00:00 +0000

Why Git Branching Is a Strategic Decision

Managing Git branching in product organizations — especially in fintech and other regulated domains — is not a tooling choice. It is a systems-level decision that directly influences delivery speed, stability, auditability, and engineering culture.

As products mature, teams must support:

Multiple customers on different versions
Customer-specific behavior and regulatory requirements
Parallel product development and production support
Emergency fixes under strict SLAs
Long-term product evolution without fragmentation

This creates a fundamental challenge:

How do you evolve a single product while supporting multiple customer realities — without breaking either?

This post outlines a practical Git branching strategy that addresses this challenge at an organizational level.

The Core Problem Most Teams Face

Most engineering teams start with good intentions but end up in one of these extremes:

Over-simplified branching
Works early, collapses under scale and multiple customers.
Over-engineered branching
Becomes slow, fragile, and intimidating for developers.

The real challenge is balancing:

Product-centric development
Customer-specific delivery needs
Long-term maintainability
Operational confidence during releases

A Systems View of Git Branching

At a systems level, a Git repository is a control plane for your product.

Your branching strategy should clearly separate:

Product evolution (where innovation happens)
Release stability (what customers rely on)
Customer isolation (who gets what, and when)

This separation reduces cognitive load, enables parallel workstreams, and makes failures containable rather than systemic.

Think of branches as organizational boundaries, not just technical ones.

Product-Centric First, Customer-Centric Second

A key mindset shift is recognizing that:

Products should be the primary axis — customers are consumers of product versions, not owners of codebases.

Many organizations maintain separate repositories per customer. While this feels customer-centric, it leads to:

Duplication of effort
Diverging logic
Inconsistent security posture
Painful upgrades

A product-centric branching model keeps one source of truth, while still allowing controlled customer customization where absolutely necessary.

Scaling Without Chaos

As teams and customers grow, branching must support:

Parallel feature development
Controlled releases
Emergency fixes without disruption
Predictable promotion paths (development → release → production)

A scalable strategy minimizes long-lived divergence and makes merges intentional events, not daily firefighting exercises.

At scale, clarity beats cleverness.

Cultural Impact: Why Developers Either Love or Hate Git

Branching strategies silently shape engineering culture.

A good strategy:

Makes the right path obvious
Reduces fear of breaking production
Encourages ownership and accountability
Supports junior and senior developers equally

A bad one creates tribal knowledge, gatekeeping, and hesitation.

Git should enable flow, not demand heroics.

Governance Without Bureaucracy

In regulated industries like fintech, governance is unavoidable — but it does not need to be heavy-handed.

A well-defined branching strategy enables:

Auditable change history
Clear release ownership
Controlled hotfix paths
Clean integration with CI/CD and approval workflows

Governance should emerge naturally from structure, not manual policing.

Where This Strategy Fits Best

This approach works particularly well for organizations that:

Build core fintech platforms or products
Serve multiple enterprise customers
Need controlled but frequent releases
Aim to mature from project-led to product-led delivery

Trunk-Based Development as the Foundation

At the center of this model is trunk-based development. .

All product development flows through a single, continuously evolving branch:

main

The trunk represents the future of the product. It is where features are integrated, tested, and prepared for release.

Feature branches are intentionally short-lived and merged back into main frequently. This minimizes long-term divergence and keeps integration friction low.

The trunk is not frozen for customers — it exists to preserve momentum and clarity in product evolution.

Release Branches: Separating Stability from Innovation

To support customers running different versions, the product lifecycle is anchored by release branches.

Release branches represent stable snapshots of the product and are created intentionally when a version is ready for delivery.

They serve to:

Freeze scope
Stabilize quality
Support certification and compliance
Act as a base for customer deployments

Once created, release branches accept only fixes — not new features. Product innovation continues on main without disrupting delivery timelines.

Customer Branches: Controlled Customization Without Fragmentation

Enterprise customers often require:

Custom workflows
Regulatory adaptations
Integration-specific behavior
Temporary patches

Customer-specific changes must not leak into the core product by default.

For this reason, customer delivery happens on customer branches, derived from a specific release version.

This approach ensures:

Product evolution remains clean
Customer requirements are isolated and explicit
Customizations are auditable and reversible

Only changes with clear product value are later generalized and merged into main.

Scenario-Based Views (How the Strategy Behaves)

The following scenarios illustrate how this branching strategy behaves in real-world situations. These are conceptual flows, not procedural steps.

Scenario 1: Standard Product Development and Release

This scenario shows how new product features flow from development into a stable release.

What this illustrates:

Feature work merges into main
Main continues to evolve independently
A release branch is cut at a defined stabilization point
Customers receive stable, versioned releases

Scenario 2: Customer-Specific Customization

This scenario demonstrates how customer-specific behavior is isolated without affecting the product roadmap.

What this illustrates:

Customer branches are created from a release
Custom behavior remains isolated
The core product remains unaffected
Product evolution continues independently

Scenario 3: Product Bug Fix Propagation

This scenario shows how a product fix is applied and propagated across versions.

What this illustrates:

Fixes are applied to the product first
Stability improvements flow forward
Customers inherit fixes without manual rework

Scenario 4: Customer Upgrade to a New Product Version

This scenario demonstrates a clean and controlled customer upgrade.

What this illustrates:

Upgrades start from a clean new release
Only required customer-specific changes are reapplied
Historical complexity is intentionally discarded

Exceptional Scenarios: Handling Reality Without Breaking the System

No branching strategy operates in a perfectly controlled environment.
In long-lived product organizations, especially in fintech, exceptions are part of business-as-usual (BAU).

The goal is not to eliminate exceptions, but to ensure they do not clutter the product, distort the roadmap, or fragment the codebase over time.

Exceptional scenarios fall into two broad categories:

BAU-driven operational exceptions
Product-level decisions required to safeguard long-term scalability

BAU Exceptions: Operational Reality at Scale

These scenarios arise from day-to-day production support and customer operations.

Emergency Fixes That Are Also Product-Relevant

There are cases where:

A customer faces a production issue requiring immediate resolution
The root cause exists in core product logic
The fix is relevant beyond a single customer

In such situations, the fix must be treated as a product fix, not a customer patch.

The guiding principles are:

The fix ultimately belongs to the product
Customer urgency does not override product integrity
Temporary isolation may be necessary, but permanent divergence is not

Emergency paths must always converge back into the product flow to avoid silent forks.

Product Fixes That Break Customer-Specific Features

Product fixes, when rolled out to customers, can occasionally break:

Customer-specific workflows
Custom integrations
Regulatory adaptations

This does not invalidate the product fix.

Instead:

The product fix remains intact
Customer branches are adjusted to restore compatibility
The product is not reshaped to preserve isolated customer behavior by default

This preserves forward momentum while respecting customer commitments.

Product Fixes That Are Not Relevant for Certain Customers

Some customers may continue operating on very old product versions due to:

Compliance certification cycles
Contractual or operational constraints
Risk tolerance within their organizations

In such cases:

Not every product fix is automatically applicable
Fixes are evaluated for relevance and feasibility
If a fix can be safely adjusted, it may be backported
Otherwise, the limitation is documented and accepted

This avoids the illusion that all versions must evolve equally.

Product Safeguard Exceptions: Protecting Long-Term Clarity

These scenarios are less about immediate operations and more about preventing long-term product clutter.

New Product Features Not Supported on Older Versions

As products evolve, new features may depend on:

Architectural changes
Data model evolution
Platform capabilities not present in older releases

Supporting every historical version indefinitely is neither realistic nor healthy.

A clear support policy is required, for example:

Only the latest version and the previous two versions (N-2) are supported
Customers on older versions must upgrade to access new functionality

This creates a sustainable balance between customer flexibility and product evolution.

Customer Features Promoted to Product Features

Some customer-specific features prove to be broadly valuable.

When this happens:

The feature is reassessed from a product perspective
Assumptions tied to a single customer are removed
The feature is generalized, hardened, and documented
It is then introduced into the product through normal product development flow

This transforms customer-driven innovation into intentional product value, rather than accidental complexity.

The Discipline Behind Exceptional Scenarios

Exceptional scenarios should follow one unifying rule:

Exceptions may solve immediate problems, but they must not redefine the system.

Healthy systems ensure that exceptions are:

Explicit
Intentional
Time-bound
Reconciled with the product roadmap

When exceptions become frequent, informal, or permanent, the branching strategy is no longer scaling — it is eroding.

Strong product organizations absorb operational pressure without changing their shape.

Organizational Outcomes of This Strategy

Branching strategies silently shape engineering culture.

A well-designed model:

Makes the right path obvious
Reduces fear of breaking production
Encourages ownership and accountability
Supports predictable delivery

Poor branching models create hesitation, tribal knowledge, and dependency on a few senior engineers.

Git should enable flow, not demand heroics.

Closing Thoughts

This Git branching strategy is not about complexity — it is about clarity.

It enables organizations to:

Scale product development
Support diverse customer needs
Maintain delivery confidence
Protect long-term product evolution

In a follow-up post, I’ll focus on practical implementation, including branch naming, workflow rules, and CI/CD alignment.

TECTONICS: Systems, Culture & Scale

Fri, 26 Dec 2025 00:00:00 +0000

This space is a record of how technology organizations actually move.

TECTONICS explores the systems, culture, and scale dynamics that shape outcomes — from architecture and platforms to leadership decisions and organizational trade-offs.

This is not a tutorial blog.
It is a reflection on what works, what fails, and why.

systems

A Requirement Rather Than a Reality

The Hollow Sprint

The Evaluation Constraint

The CTO Decision Stack in Startup and Enterprise

AI Across the CTO Decision Stack

The CTO Decision Stack

Tech Stack Selection in the Age of AI Agents

From Project to Product to Company — What the Transition Actually Requires

Why Architecture Is Shifting From Diagrams to Guardrails

The Pipeline Is Not the Problem

The Cognitive Load Ceiling: What AI Is Doing to Software Architecture — and Why the Rewrite Is No Longer the Last Resort

Designing for Scale Before Scaling: A Practical Reading of Conway's Law

The Inevitable Cycles: Why Software Houses Keep Returning to Square One

A Practical Git Branching Strategy for Multi-Version Product Organizations

TECTONICS: Systems, Culture & Scale

culture

A Requirement Rather Than a Reality

The Hollow Sprint

The Evaluation Constraint

The CTO Decision Stack in Startup and Enterprise

AI Across the CTO Decision Stack

The CTO Decision Stack

From Project to Product to Company — What the Transition Actually Requires

The Pipeline Is Not the Problem

Designing for Scale Before Scaling: A Practical Reading of Conway's Law

The Inevitable Cycles: Why Software Houses Keep Returning to Square One

A Practical Git Branching Strategy for Multi-Version Product Organizations

TECTONICS: Systems, Culture & Scale

scale

A Requirement Rather Than a Reality

The Hollow Sprint

The Evaluation Constraint

The CTO Decision Stack in Startup and Enterprise

Tech Stack Selection in the Age of AI Agents

From Project to Product to Company — What the Transition Actually Requires

Why Architecture Is Shifting From Diagrams to Guardrails

The Pipeline Is Not the Problem

The Cognitive Load Ceiling: What AI Is Doing to Software Architecture — and Why the Rewrite Is No Longer the Last Resort

Designing for Scale Before Scaling: A Practical Reading of Conway's Law

The Inevitable Cycles: Why Software Houses Keep Returning to Square One

A Practical Git Branching Strategy for Multi-Version Product Organizations

TECTONICS: Systems, Culture & Scale

architecture

Why Architecture Is Shifting From Diagrams to Guardrails

Blog

TECTONICS

Systems, Culture & Scale

Culture

A Requirement Rather Than a Reality

Oct 29, 2026

Software engineering was named in 1968 as an aspiration, not a description: a discipline the field decided it needed because too much was falling through the cracks. Vibe coding is interesting not because it uses AI, but because it can separate producing code from the human responsibility to understand it, a responsibility that review, testing, traceability and change control all depend on. How much discipline a system needs depends on how long it lives and what it touches. Fintech products sit at the far end of both, and there the discipline is written into the standards. Vibe coding still has a place, at the start, as a way of seeing requirements, but the prototype is not a signed baseline: what is worth freezing is the load-bearing decisions, not every screen. Spec-driven development can hold those decisions, but only if the spec keeps being maintained; a tool is not the discipline itself.

Read

The Hollow Sprint

Oct 9, 2026

Agile was an answer to uncertainty at a time when building software was expensive: plan little, build small, learn from what the customer sees. AI has made build capacity and decision capacity diverge. A team that keeps its old rhythm ends up running hollow sprints: on schedule, every ceremony intact, with more and more unconfirmed decisions inside them. Cheaper building could justify more upfront planning or even more iteration, and both are right, for different kinds of decision. AI moves the last responsible moment in two directions at once. The unit of methodology is no longer the project. It is the decision.

Read

The Evaluation Constraint

Aug 2, 2026

Two engineering organizations with the same headcount, the same budget and the same stack will diverge enormously over five years, and the divergence is not talent or effort. It is which allocation of capacity they found. Superior allocations exist, they are rare, and finding one is a search problem — which means the arm of that search AI just made cheap is not the arm that was ever binding.

Read

The CTO Decision Stack in Startup and Enterprise

Jul 12, 2026

The third post in the CTO Decision Stack series. The seven layers don't change between a ten-person startup and a ten-thousand-person enterprise. What changes is what each layer is optimizing for, given different constraints — capital, reputational exposure, existing assets, and time horizon. A startup shipping a throwaway product to win a deal and an enterprise refusing to is not one of them being undisciplined. Both can be right. The recurring failure isn't a bad decision at either end. It's importing a tradeoff that was correct somewhere else.

Read

AI Across the CTO Decision Stack

Jun 14, 2026

AI is not a layer-seven tool — it's a force that changes the cost structure, failure modes, and governance requirements of all seven layers of the CTO Decision Stack at once. This post walks the stack layer by layer, tracing how a single tooling adoption decision leaves six other layers with open questions nobody asked.

Read

The CTO Decision Stack

Jun 7, 2026

Most technical leadership failures are not failures of the wrong decision. They are failures of the wrong layer — the right question answered at the wrong altitude, by the wrong people, against the wrong criteria. The CTO Decision Stack maps seven distinct layers of decision-making, from corporate strategy to developer productivity, and shows why conflating them is how organizations accumulate consequences they cannot trace back to a cause.

Read

From Project to Product to Company — What the Transition Actually Requires

May 16, 2026

Most final year projects successfully prove something can be built. The harder questions — will someone use this repeatedly, and can it survive when conditions change — are what the next step requires. This post maps the transition from project to product to company: what it takes to find the hidden need, build the feedback loop, understand the landscape, and bring something real to the world.

Read

The Pipeline Is Not the Problem

May 2, 2026

Most SDLC policies don’t fail because they are poorly designed. They fail because they assume the system will sustain itself. Pipelines stay green, audits pass, and metrics look healthy — while the underlying system quietly degrades. The problem isn’t the pipeline. It’s the gap between what the process enforces and what the culture rewards.

Read

Designing for Scale Before Scaling: A Practical Reading of Conway's Law

Mar 15, 2026

A structural perspective on scaling fintech systems using Conway's Law. Exploring how organizational structure, branching strategy, and delivery mechanics must align before growth introduces irreversible complexity.

Read

The Inevitable Cycles: Why Software Houses Keep Returning to Square One

Jan 12, 2026

There and Back Again — from Cloud to On-Prem, Projects to Products. An exploration of why software houses repeatedly cycle through infrastructure, delivery models, processes, roles, and technical debt as they scale.

Read

A Practical Git Branching Strategy for Multi-Version Product Organizations

Jan 2, 2026

A product-centric Git branching strategy that supports multiple customer versions, controlled customization, and scalable delivery without sacrificing engineering velocity.

Read

TECTONICS: Systems, Culture & Scale

Dec 26, 2025

This space is a record of how technology organizations actually move.

Read

Guides

Posts by Category : {{ page.title }}

{% for post in site.categories.guides %}

{% endfor %}

Jekyll

Posts by Category : {{ page.title }}

{% for post in site.categories.jekyll %}

{% endfor %}

Guides

Posts by Category : {{ page.title }}

{% for post in site.categories.sample_category %}

{% endfor %}

Scale

{% for post in site.categories.scale %} {% include blog_card.html %} {% endfor %}

Systems

{% for post in site.categories.systems %} {% include blog_card.html %} {% endfor %}

Change Log

# Change Log All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). **Note that references to the Font-Awesome-Pro repository refer to a GitHub repository that is by invitation only. You will get a 404 - Not Found if you do not have access** --- ## [5.1.0](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.1.0) - 2018-06-20 **Minor version upgrade notice: there are some backward-incompatible changes to this release. See the [UPGRADING.md guide](https://github.com/FortAwesome/Font-Awesome/blob/master/UPGRADING.md) for more information.** ### Added * New Emoji, Design, and Travel category pack * Another group of requested and commissioned icons * Version 4 shim for Web Fonts with CSS * New simplified download and NPM packages * @fortawesome/fontawesome-free and @fortawesome/fontawesome-pro NPM packages that match what's available in the CDN and .ZIP files * Brand icons rev, nimblr, megaport, mailchimp, hornbill, wix, weebly, themeco, squarespace, aws, shopware * API method toHtml() for converting abstract objects to HTML * API method counter() to generate Layers Counters * API method watch() to configure MutationObserver and watch DOM for icon changes and additions ### Changed * Relocating sponsor data to a separate sponsors.yml * Updated teamspeak brand icon * No more default exports in the CommonJS/ES packages (anything installed from NPM) * Greatly improved performance and rendering of CSS pseudo-elements with SVG and JavaScript * Configuration of SVG with JavaScript can now be done with attributes on the script tag * SVG with JavaScript pseudo-elements now match syntax (font-family, font-weight) of Web Fonts with CSS ### Fixed * Tree shaking of all NPM packages by default * Alignment of the book-open and dice-six icon * Correcting creative-commons * Incorrect license on the fontawesome-common-types package * Improve ligatures that share a base name with another ligature * Correcting solid style of the digital-tachograph icon * Prevent duplicating classes in some scenarios with SVG with JavaScript * Duplicate insertion of CSS when insertCss() method was called * Missing TypeScript definitions for the free-brands-svg-icons package --- ## [5.0.13](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.13) - 2018-05-10 ### Added * 68 icons to Free and 165 to Pro of the most requested icons in Font Awesome --- ## [5.0.12](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.12) - 2018-05-03 ### Added * A long time ago in a galaxy far, far away some icons were added ### Fixed * Renamed the r brand to r-project to prevent ligature collision with the "r" glyph --- ## [5.0.11](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.11) - 2018-05-01 ### Added * 16 new user icons * Full set of Creative Commons symbols * Regular style comment-dots used for v4 comment-alt in shim * Top 6 brand icons: r, ebay, mastodon, researchgate, keybase, teamspeak ### Changed * Revised slider icons FortAwesome/Font-Awesome#11872 * Make desktop typeface easier to find in apps that support ligature previews ### Fixed * Remove errant XML entity from the lastfm-square icon FortAwesome/Font-Awesome#12847 * Correcting paths in cloud icons FortAwesome/Font-Awesome-Pro#920 --- ## [5.0.10](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.10) - 2018-04-10 ### Added * New java brand icon FortAwesome/Font-Awesome#386 ### Changed * Updating depth of dna icon * Updating pied-piper, adding pied-piper-hat ### Fixed * Correcting path errors on readme icon FortAwesome/Font-Awesome#12754 * Light style of lamp icon FortAwesome/Font-Awesome#12725 --- ## [5.0.9](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.9) - 2018-03-27 ### Added * New Chat icon pack and category * New Charity icon pack and category * New Moving icon pack and category * New icons hands and hand-holding ### Changed * Updated flipboard, readme, and houzz brand icon * Making all solid icons in the medical icon pack free * Updated hand-holding-box and hand-receiving in the Light style ### Fixed * Missing box-sizing CSS property for fa-layers-counter --- ## [5.0.8](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.8) - 2018-03-01 ### Fixed * OTF font files missing ligatures for Pro styles FortAwesome/Font-Awesome#12486 FortAwesome/Font-Awesome-Pro#1034 --- ## [5.0.7](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.7) - 2018-02-26 ### Added * New Logistics category * New Medical category * Individual SVG files available from the Font Awesome CDN * Additional search terms ### Changed * Apple brand icon update FortAwesome/Font-Awesome#12337 * Disable mutation observers with fontawesome.noAuto() is called * License information now references https URL scheme ### Fixed * Missing TypeScript names FortAwesome/react-fontawesome#83 * Adding categories metadata FortAwesome/Font-Awesome#12034 * TypeScript improvement for fontawesome.layer() * Correcting a melting, wobbling, weird-looking whistle --- ## [5.0.6](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.6) - 2018-01-25 ### Fixed * @fortawesome/fontawesome-pro-light missing submodules --- ## [5.0.5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.5) - 2018-01-25 ### Added * New Sports category * New Chess category * Added brand icons for flipboard, php, quinscape, and hips ### Fixed * Sass and Less mixin fa-icon() now uses ems instead of percentage * Corrected misspelling of "Alternate" in category labels * Improved TypeScript definitions for @fortawesome/fontawesome * Server-side rendering was failing due to DOM-specific object access * SVG attributes "data-fa-processed" renamed to "data-fa-i2svg", only applies if rendered with i2svg() method --- ## [5.0.4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.4) - 2018-01-10 ### Changed * Updating all NPM package READMEs ### Fixed * Improving TypeScript exports and fixing some incorrect definitions * TypeScript error when importing entire style Fort-Awesome/Font-Awesome#12072 * Pseudo-elements erasing text contents in parent container Fort-Awesome/Font-Awesome-Pro#11995 * fa-layers-text misalignment when using Bootstrap Fort-Awesome/Font-Awesome#11871 --- ## [5.0.3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.3) - 2018-01-08 ### Added * Adding elementor, youtube-square brand icons * Adding window-minimize to the Free subset * TypeScript support for all NPM packages ### Fixed * Corrected uneven spacing in university, address-book, address-card, id-badge, id-card, mouse-pointer, phone-volume, portrait, user-alt, user-circle, user-md, user-plus, user-times, user , users * Corrected uneven spacing in brand icons behance-square, dashcube, discourse, ember, erlang, fort-awesome, js-square, laravel, mix, patreon, palfed, phoenix-framework, node-js, skyatlas, stack-exchange, stripe, viber, weixin, yahoo , yoast --- ## [5.0.2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.2) - 2017-12-19 ### Added * Adding amazon-pay, cc-amazon-pay, korvue, ethereum brand icons * Adding stopwatch to Free version ### Changed * Ligatures now support capital case, all caps, and title case ### Fixed * NPM packages now behave the same way as CDN and browser-specific packages FortAwesome/Font-Awesome-Pro#727 FortAwesome/Font-Awesome-Pro#896 FortAwesome/Font-Awesome-Pro#891 * Icon doesn't change when pseudo-element content changes FortAwesome/Font-Awesome-Pro#839 * Invalid XML in sprites FortAwesome/Font-Awesome-Pro#927 * Incorrect version in Sass and Less variable files --- ## [5.0.1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.1) - 2017-12-08 ### Added * Adding font-awesome-flag, lock-open, redo-alt, sync-alt, undo-alt to the Free version * New NPM packages `fontawesome-free-webfonts` and `fontawesome-pro-webfonts` * Adding old icon names to search terms for renamed icons * Extensive metadata added to the `advanced-options` directory * Adding stripe-s brand icon * Adding typo3 brand icon ### Changed * Updated dropbox brand icon to match new branding guidelines * Updated firefox brand icon * Updated strava brand icon * OTF font file now include a space character ### Fixed * OTF font file now supports different styles in Windows * OTF font file "j" character now has correct space on the right * Modifying the `class` attribute on an existing `` will now precede other link and style definitions * BREAKING `fontawesome.text` and `fontawesome.icon` now use `styles` param instead of `style` * Updated sizing for twitter, discord, youtube * Class fa-li now respects line-height and has new recommended markup (see included docs) ### Fixed * Duplicate `style` tags being added in the head FortAwesome/Font-Awesome-Pro#858 * Error with icon composition/masking that caused a confusing error message * An error when using pseudo elements and the element is empty (Array.reduce error) * Icons not being replaced with SVG if the text content is not empty --- ## [5.0.0-rc4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc4) - 2017-10-27 ### Added * Ligature support in the OTF font * Vue.js brand icon * Sass and Less brand icons * Autoprefixer brand icon * Individual icon imports in icon packages FortAwesome/Font-Awesome-Pro#808 ### Changed * Better poo eyes * Renamed HTML status classes to `fontawesome-i2svg-active`, `fontawesome-i2svg-pending`, `fontawesome-i2svg-complete` * HTML status class for active is added only after the first batch of icon replacements occur * Added mention of newer versions of iOS in documentation FortAwesome/Font-Awesome-Pro#810 ### Fixed * Performance and missing features with mutation observer (should fix FortAwesome/Font-Awesome-Pro#813) * Incorrect handling of icon class and style attributes when using autoReplace = 'nest' FortAwesome/Font-Awesome-Pro#809 * Pseudo elements not added or removed when class mutations occur FortAwesome/Font-Awesome-Pro#821 --- ## [5.0.0-rc3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc3) - 2017-10-13 ### Added * Node.js brand icon FortAwesome/Font-Awesome-Pro#779 * React brand icon FortAwesome/Font-Awesome-Pro#780 * OSI brand icon FortAwesome/Font-Awesome-Pro#748 * Add a class to the html element when icon replacement is complete FortAwesome/Font-Awesome-Pro#778 * Add support for symbols in API including ability to name the symbol * Use CSS pseudo elements (:before and :after) to make trigger SVG replacements ### Changed * Switched the locations of fork and knife in utensils-alt FortAwesome/Font-Awesome-Pro#466 * Updated the AWS brand icon FortAwesome/Font-Awesome-Pro#735 * Updated Apple App Store icon FortAwesome/Font-Awesome-Pro#728 ### Fixed * Do not throw an error if icon is missing when calling icon() method in API * Ensure that unicode values do not change between releases * Version field is missing in fontawesome-pro-brands/package.json FortAwesome/Font-Awesome-Pro#781 * Repeated commenting out of fa-layers when i2svg is called FortAwesome/Font-Awesome-Pro#788 * Title not showing up correctly for SVG FortAwesome/Font-Awesome-Pro#786 --- ## [5.0.0-rc2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc2) - 2017-09-22 ### Added * Brand icons: accusoft, ns8, uniregistry ### Fixed * Link to the npm package in the docs FortAwesome/Font-Awesome-Pro#729 * Incorrect reference to fontawesome-pro.js in docs --- ## [5.0.0-rc1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc1) - 2017-09-15 ### Changed * New Bitbucket logo FortAwesome/Font-Awesome-Pro#720 * Modifed the star icons to match use case better FortAwesome/Font-Awesome-Pro#710 * Switched names of css3 and css3-alt to reflect correct branding ### Fixed * Correct whitespace with the Visa logo FortAwesome/Font-Awesome-Pro#719 * Improve OTF support by passing through FontForge FortAwesome/Font-Awesome-Pro#565 * Fonts with "undefined" name FortAwesome/Font-Awesome-Pro#711 * Shims will only function if using old prefix of "fa" FortAwesome/Font-Awesome-Pro#692 * Added missing "youtube" icon to categories --- ## [5.0.0-beta7](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta7) - 2017-09-11 ### Added * Ability to nest the `` FortAwesome/Font-Awesome-Pro#624 * Define icons as symbols and leverage SVG sprites FortAwesome/Font-Awesome-Pro#629 * Added alternative CSS3 logo FortAwesome/Font-Awesome-Pro#682 ### Changed * Power Transforms now execute inside the SVG instead of on the root element * Filenames have changed to reflect a better division between Font Awesome Free and Pro ### Fixed * More improvements to the version 4 shim FortAwesome/Font-Awesome-Pro#673 FortAwesome/Font-Awesome-Pro#678 FortAwesome/Font-Awesome-Pro#686 FortAwesome/Font-Awesome-Pro#687 FortAwesome/Font-Awesome-Pro#692 * Animation support for inline SVG now works as expected FortAwesome/Font-Awesome-Pro#662 --- ## [5.0.0-beta6](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta6) - 2017-09-01 ### Added * Ability to flip horizontal and vertical with CSS classes fa-flip-horizontal and fa-flip-vertical * New film-alt icon that allows for layering other icons * Microsoft brand ### Changed * New YouTube branding FortAwesome/Font-Awesome-Pro#646 ### Fixed * Fixed a bunch of shim-related issues * Cogs off center FortAwesome/Font-Awesome-Pro#663 * Corrected icons/categories.yml with canonical names --- ## [5.0.0-beta5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta5) - 2017-08-25 ### Added * Full parity with Font Awesome 4! 616 total core icons in each style * 297 total brand and logo icons * Separate CSS file to accompany the SVG Framework FortAwesome/Font-Awesome-Pro#627 * Alternative to the dots icon FortAwesome/Font-Awesome-Pro#608 * Made window icons consistent FortAwesome/Font-Awesome-Pro#611 ### Fixed * Production builds not correctly being detected FortAwesome/Font-Awesome-Pro#631 --- ## [5.0.0-beta4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta4) - 2017-08-18 ### Added * 590 total core icons in each style * 291 total brand and logo icons ### Fixed * Reduced the size of JS file from 66 to 22 kb * Regression caused by with web font alignment FortAwesome/Font-Awesome-Pro#460 --- ## [5.0.0-beta3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta3) - 2017-08-15 ### Added * 583 total core icons in each style ### Fixed * Documentation improvements and fixes FortAwesome/Font-Awesome-Pro#586 * Vertical alignment of TTF and OTF fonts FortAwesome/Font-Awesome-Pro#460 * The "fa_500px" icon should be named "fa500px" FortAwesome/Font-Awesome-Pro#578 --- ## [5.0.0-beta2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta2) - 2017-08-11 ### Added * 570 total core icons in each style * 291 total brand and logo icons * NPM (ES6, CommonJS, AMD) packages for use with other JavaScript libraries and tools FortAwesome/Font-Awesome-Pro#574 * Added a guide to choosing which implementation is best for you FortAwesome/Font-Awesome-Pro#532 ### Changed * Showing a missing icon is now configurable FortAwesome/Font-Awesome-Pro#569 ### Fixed * Composition framework now works in browsers that do not support transform-origin FortAwesome/Font-Awesome-Pro#564 --- ## [5.0.0-beta1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta1) - 2017-08-04 ### Added * 524 total core icons in each style * 289 total brand and logo icons * New composition framework FortAwesome/Font-Awesome-Pro#537 * Animated indicator if you use an icon that does not exist ### Changed * Basic linting for Sass and Less files * Add JavaScript guard block to prevent leaking errors * Add support for automatic accessibility to SVG Framework Layers ### Fixed * Regression where stacks and pulled and bordered were not working in SVG Framework * SVG sprite example had confusing inline styles FortAwesome/Font-Awesome-Pro#549 * Make getting started page more consistent between examples FortAwesome/Font-Awesome-Pro#544 * Added missing sizes fa-[6-10], xs, sm FortAwesome/Font-Awesome-Pro#546 * Title tag missing in SVG sprites FortAwesome/Font-Awesome-Pro#536 --- ## [5.0.0-alpha7](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha7) - 2017-07-28 ### Added * 451 total core icons in each style * 281 total brand and logo icons * Less support is back! * OpenType (.otf) file formats for web fonts ### Changed * Changes the fa-spin animation to go from 0deg to 360deg to eliminate hitch FortAwesome/Font-Awesome-Pro#522 * Improved mutation handling FortAwesome/Font-Awesome-Pro#517 ### Fixed * fa-fw now works correctly with the SVG framework FortAwesome/Font-Awesome-Pro#530 * Removed execute bit on some icon files FortAwesome/Font-Awesome-Pro#520 --- ## [5.0.0-alpha6](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha6) - 2017-07-21 ### Added * 410 total core icons in each style * 270 total brand and logo icons * All new Font Awesome 4 shim file * Beginnings of a public JS API FortAwesome/Font-Awesome-Pro#512 ### Changed * Added Firefox ESR and Chrome for Businesses to browser compatibility FortAwesome/Font-Awesome-Pro#506 ### Fixed * Ensure that SVG title attributes are unique * Fixed incorrect viewBox sizes FortAwesome/Font-Awesome-Pro#492 * Fix chart-area alignment in the solid style FortAwesome/Font-Awesome-Pro#508 * Add missing xmlns attributes in some SVGs FortAwesome/Font-Awesome-Pro#509 --- ## [5.0.0-alpha5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha5) - 2017-07-14 ### Added * 228 total brand and logo icons * New transform framework for sizing, moving, rotating, and flipping icons * New icon counters * New layers framework * New text overlays * Auto-comments with the original source icons alongside SVG replacements ### Changed * Autoprefixer to correctly add browser prefixes for supported browsers * Removed browser-specific CSS properties in Sass source files (now relies on autoprefixer) ### Fixed * The rotation on checkmark icons * Other icon feedback from previous weeks * Correct fixed width settings to 1.25em (based on the new 16px grid) * Icons displaying as block instead of inline-block in IE and older Safari --- ## [5.0.0-alpha4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha4) - 2017-07-07 ### Added * 93 brand icons --- ## [5.0.0-alpha3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha3) - 2017-06-30 ### Added * 95 additional icons; including file types, directional, and some existing and new brand icons ### Fixed * Wrong content type in generated CSS FortAwesome/Font-Awesome-Pro#458 * Removal of query string from static resources FortAwesome/Font-Awesome-Pro#458 * SVG font ID's are incorrect in webfont implementation FortAwesome/Font-Awesome-Pro#474 --- ## [5.0.0-alpha2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha2) - 2017-06-27 ### Added * How/When to upgrade from FA4 to FA5 FortAwesome/Font-Awesome-Pro#454 ### Fixed * Links to SVG files broken in the example files FortAwesome/Font-Awesome-Pro#456 * Misnamed icon names in examples FortAwesome/Font-Awesome-Pro#445 * Mangled HTML in the Getting Started example FortAwesome/Font-Awesome-Pro#442 * Bad grammar and typos FortAwesome/Font-Awesome-Pro#443 * fas-arrow-to-top is identical to fas-arrow-to-right FortAwesome/Font-Awesome-Pro#423 * Vertical alignment issues with webfont implementation FortAwesome/Font-Awesome-Pro#444 * Add browser compatibility tables to demo FortAwesome/Font-Awesome-Pro#435 * Remove MAC OS feces from builds FortAwesome/Font-Awesome-Pro#437 * TTF naming issues that prevent correct usage/installation FortAwesome/Font-Awesome-Pro#450 * Correct CSS for SVG framework stacking, was reversed from normal FortAwesome/Font-Awesome-Pro#452 --- ## [5.0.0-alpha1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha1) - 2017-06-23 ### Added * 300+ more icons * Brands pack * New JavaScript based SVG Framework * New SVG Sprites based framework * Source SVGs * Documentation with a convenient build-in web server ### Changed * New directory structure

Upgrading Guide
# Upgrading Guide See the [CHANGELOG.md](/assets/bower_components/font-awesome/CHANGELOG/) for detailed information about what has changed between versions. This guide is useful to figure out what you need to do between breaking changes. As always, [submit issues](https://github.com/FortAwesome/Font-Awesome/issues/new) that you run into with this guide or with these upgrades to us. ## 5.0.x to 5.1.0 ### New packages available for browser-only integration **If you were previously using @fortawesome/fontawesome you need to switch to one of the new packages.** Our Free and Pro CDN provide access to JS, CSS, sprites, and separate SVG files. We've now made these files conveniently available through NPM. * [@fortawesome/fontawesome-free](https://www.npmjs.com/package/@fortawesome/fontawesome-free) * @fortawesome/fontawesome-pro (private package, requires Pro subscription) If you are familiar with the paths and options available with the CDN these packages should be familiar. Information about [Font Awesome Pro subscriptions](https://fontawesome.com/pro) can be found in your [Font Awesome awesome account](https://fontawesome.com/account/services). ### Renamed packages The following packages have been renamed as part of 5.1.0 of Font Awesome. _All packages are in the [@fortawesome NPM scope](https://www.npmjs.com/search?q=scope:fortawesome&page=1&ranking=optimal)_ | Old package(1) | New package | |---------------------------|------------------------| | fontawesome-free-webfonts | fontawesome-free | | fontawesome-pro-webfonts | fontawesome-pro | | fontawesome-free-solid | free-solid-svg-icons | | fontawesome-free-regular | free-regular-svg-icons | | fontawesome-free-brands | free-brands-svg-icons | | fontawesome-pro-solid | pro-solid-svg-icons | | fontawesome-pro-regular | pro-regular-svg-icons | | fontawesome-pro-light | pro-light-svg-icons | (1) Old packages have now been deprecated. They are still available but will only receive high priority patch release fixes. **You'll need to update your package.json file with the renamed packages and new versions.** ### No more default imports Recently we spent a good deal of time supporting TypeScript to enable us to create the Angular Font Awesome component. During that adventure we [were](https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html) [convinced](https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad) that we were going to remove default exports from all of our components, libraries, and packages. This is complete with the umbrella release of `5.1.0` of Font Awesome. What does that mean? ~~Old way:~~ ```javascript import fontawesome from '@fortawesome/fontawesome' import solid from '@fortawesome/fontawesome-free-solid' import faTwitter from '@fortawesome/fontawesome-free-brands/faTwitter' import FontAwesomeIcon from '@fortawesome/vue-fontawesome' library.add(solid, faTwitter) ``` New way: ```javascript import { library, dom } from '@fortawesome/fontawesome-svg-core' import { fas } from '@fortawesome/free-solid-svg-icons' import { faTwitter } from '@fortawesome/free-brands-svg-icons' import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome' library.add(fas, faTwitter) // Kicks off the process of finding tags and replacing with

Mouse Wheel ChangeLog
# Mouse Wheel ChangeLog ## 3.1.13 * Update copyright notice and license to remove years * Create the correct compressed version * Remove the obsolete jQuery Plugin Registry file ## 3.1.12 * Fix possible 0 value for line height when in delta mode 1 ## 3.1.11 * Fix version number for package managers... ## 3.1.10 * Fix issue with calculating line height when using older versions of jQuery * Add offsetX/Y normalization with setting to turn it off * Cleans up data on teardown ## 3.1.9 * Fix bower.json file * Updated how the deltas are adjusted for older mousewheel based events that have deltas that are factors of 120. * Add $.event.special.mousewheel.settings.adjustOldDeltas (defaults to true) to turn off adjusting of old deltas that are factors of 120. You'd turn this off if you want to be as close to native scrolling as possible. ## 3.1.8 * Even better handling of older browsers that use a wheelDelta based on 120 * And fix version reported by `$.event.special.mousewheel` ## 3.1.7 * Better handle the `deltaMode` values 1 (lines) and 2 (pages) * Attempt to better handle older browsers that use a wheelDelta based on 120 ## 3.1.6 * Deprecating `delta`, `deltaX`, and `deltaY` event handler arguments * Update actual event object with normalized `deltaX `and `deltaY` values (`event.deltaX`, `event.deltaY`) * Add `deltaFactor` to the event object (`event.deltaFactor`) * Handle `> 0` but `< 1` deltas better * Do not fire the event if `deltaX` and `deltaY` are `0` * Better handle different devices that give different `lowestDelta` values * Add `$.event.special.mousewheel.version` * Some clean up ## 3.1.5 * Bad release because I did not update the new `$.event.special.mousewheel.version` ## 3.1.4 * Always set the `deltaY` * Add back in the `deltaX` and `deltaY` support for older Firefox versions ## 3.1.3 * Include `MozMousePixelScroll` in the to fix list to avoid inconsistent behavior in older Firefox ## 3.1.2 * Include grunt utilities for development purposes (jshint and uglify) * Include support for browserify * Some basic cleaning up ## 3.1.1 * Fix rounding issue with deltas less than zero ## 3.1.0 * Fix Firefox 17+ issues by using new wheel event * Normalize delta values * Adds horizontal support for IE 9+ by using new wheel event * Support AMD loaders ## 3.0.6 * Fix issue with delta being 0 in Firefox ## 3.0.5 * jQuery 1.7 compatibility ## 3.0.4 * Fix IE issue ## 3.0.3 * Added `deltaX` and `deltaY` for horizontal scrolling support (Thanks to Seamus Leahy) ## 3.0.2 * Fixed delta being opposite value in latest Opera * No longer fix `pageX`, `pageY` for older Mozilla browsers * Removed browser detection * Cleaned up the code ## 3.0.1 * Bad release... creating a new release due to plugins.jquery.com issue :( ## 3.0 * Uses new special events API in jQuery 1.2.2+ * You can now treat `mousewheel` as a normal event and use `.bind`, `.unbind` and `.trigger` * Using jQuery.data API for expandos ## 2.2 * Fixed `pageX`, `pageY`, `clientX` and `clientY` event properties for Mozilla based browsers ## 2.1.1 * Updated to work with jQuery 1.1.3 * Used one instead of bind to do unload event for clean up ## 2.1 * Fixed an issue with the unload handler ## 2.0 * Major reduction in code size and complexity (internals have change a whole lot) ## 1.0 * Fixed Opera issue * Fixed an issue with children elements that also have a mousewheel handler * Added ability to handle multiple handlers

Fizzy UI utils
# Fizzy UI utils UI utility & helper functions Used in [Flickity](http://flickity.metafizzy.co), [Isotope](http://isotope.metafizzy.co), [Masonry](http://masonry.desandro.com), [Draggabilly](http://draggabilly.desandro.com) ## Install Bower: `bower install fizzy-ui-utils --save` npm: `npm install fizzy-ui-utils --save` ## API ``` js // fizzyUIUtils is the browser global var utils = fizzyUIUtils; // ---- ---- // utils.extend( a, b ) // extend object utils.modulo( num, div ) // num [modulo] div utils.makeArray( obj ) // make array from object utils.removeFrom( ary, obj ) // remove object from array utils.getParent( elem, selector ) // get parent element of an element, given a selector string utils.getQueryElement( elem ) // if elem is a string, use it as a selector and return element Class.prototype.handleEvent = utils.handleEvent; // enable Class.onclick when element.addEventListener( 'click', this, false ) utils.filterFindElements( elems, selector ) // iterate through elems, filter and find all elements that match selector utils.debounceMethod( Class, methodName, threhold ) // debounce a class method utils.docReady( callback ) // trigger callback on document ready utils.toDashed( str ) // 'camelCaseString' -> 'camel-case-string' utils.htmlInit( Class, namespace ) // on document ready, initialize Class on every element // that matches js-namespace // pass in JSON options from element's data-options-namespace attribute ``` --- [MIT license](http://desandro.mit-license.org/). Have at it. By [Metafizzy](http://metafizzy.co)

@fortawesome/free-regular-svg-icons - SVG with JavaScript version
# @fortawesome/free-regular-svg-icons - SVG with JavaScript version > "I came here to chew bubblegum and install Font Awesome 5 - and I'm all out of bubblegum" [![npm](https://img.shields.io/npm/v/@fortawesome/free-regular-svg-icons.svg?style=flat-square)](https://www.npmjs.com/package/@fortawesome/free-regular-svg-icons) ## Installation ``` $ npm i --save @fortawesome/free-regular-svg-icons ``` Or ``` $ yarn add @fortawesome/free-regular-svg-icons ``` ## Documentation Get started [here](https://fontawesome.com/get-started/svg-with-js). Continue your journey [here](https://fontawesome.com/how-to-use/svg-with-js). Or go straight to the [API documentation](https://fontawesome.com/how-to-use/font-awesome-api). ## Issues and support Start with [GitHub issues](https://github.com/FortAwesome/Font-Awesome/issues) and ping us on [Twitter](https://twitter.com/fontawesome) if you need to.

jQuery Easing Plugin
# jQuery Easing Plugin What is it? A jQuery plugin from GSGD to give advanced easing options. More info [here](http://gsgd.co.uk/sandbox/jquery/easing) For CDN please use CloudFlare [`https://cdnjs.cloudflare.com/ajax/libs/jquery-easing/1.4.1/jquery.easing.min.js`](https://cdnjs.cloudflare.com/ajax/libs/jquery-easing/1.4.1/jquery.easing.min.js) to help my host. Thank you. # AMD or CommonJS usage ```js // CommonJS var jQuery = require('jquery'); require('jquery.easing')(jQuery); // AMD define(['jquery', 'jquery.easing'], function (jQuery, easing) { easing(jQuery) }) ``` # Building and testing * Clone the repo * `npm install` * Make changes * Test against files in `/examples` * Build minified version with `npm run build`

jQuery
# jQuery > jQuery is a fast, small, and feature-rich JavaScript library. For information on how to get started and how to use jQuery, please see [jQuery's documentation](http://api.jquery.com/). For source files and issues, please visit the [jQuery repo](https://github.com/jquery/jquery). If upgrading, please see the [blog post for 3.3.1](https://blog.jquery.com/2017/03/20/jquery-3.3.1-now-available/). This includes notable differences from the previous version and a more readable changelog. ## Including jQuery Below are some of the most common ways to include jQuery. ### Browser #### Script tag ```html ``` #### Babel [Babel](http://babeljs.io/) is a next generation JavaScript compiler. One of the features is the ability to use ES6/ES2015 modules now, even though browsers do not yet support this feature natively. ```js import $ from "jquery"; ``` #### Browserify/Webpack There are several ways to use [Browserify](http://browserify.org/) and [Webpack](https://webpack.github.io/). For more information on using these tools, please refer to the corresponding project's documention. In the script, including jQuery will usually look like this... ```js var $ = require("jquery"); ``` #### AMD (Asynchronous Module Definition) AMD is a module format built for the browser. For more information, we recommend [require.js' documentation](http://requirejs.org/docs/whyamd.html). ```js define(["jquery"], function($) { }); ``` ### Node To include jQuery in [Node](nodejs.org), first install with npm. ```sh npm install jquery ``` For jQuery to work in Node, a window with a document is required. Since no such window exists natively in Node, one can be mocked by tools such as [jsdom](https://github.com/tmpvar/jsdom). This can be useful for testing purposes. ```js require("jsdom").env("", function(err, window) { if (err) { console.error(err); return; } var $ = require("jquery")(window); }); ```

Outlayer
# Outlayer _Brains and guts of a layout library_ Outlayer is a base layout class for layout libraries like [Isotope](http://isotope.metafizzy.co), [Packery](http://packery.metafizzy.co), and [Masonry](http://masonry.desandro.com) Outlayer layouts work with a container element and children item elements. ``` html

...
``` ## Install Install with [Bower](http://bower.io): `bower install outlayer` [Install with npm](http://npmjs.org/package/outlayer): `npm install outlayer` ## Outlayer.create() Create a layout class with `Outlayer.create()` ``` js var Layout = Outlayer.create( namespace ); // for example var Masonry = Outlayer.create('masonry'); ``` + `namespace` _{String}_ should be camelCased + returns `LayoutClass` _{Function}_ Create a new layout class. `namespace` is used for jQuery plugin, and for declarative initialization. The `Layout` inherits from [`Outlayer.prototype`](docs/outlayer.md). ``` var elem = document.querySelector('.selector'); var msnry = new Masonry( elem, { // set options... columnWidth: 200 }); ``` ## Item Layouts work with Items, accessible as `Layout.Item`. See [Item API](docs/item.md). ## Declarative An Outlayer layout class can be initialized via HTML, by setting an attribute of `data-namespace` on the element. Options are set in JSON. For example: ``` html
...
``` The declarative attributes and class will be dashed. i.e. `Outlayer.create('myNiceLayout')` will use `data-my-nice-layout` as the attribute. ## .data() Get a layout instance from an element. ``` var myMasonry = Masonry.data( document.querySelector('.grid') ); ``` ## jQuery plugin The layout class also works as jQuery plugin. ``` js // create Masonry layout class, namespace will be the jQuery method var Masonry = Outlayer.create('masonry'); // rock some jQuery $( function() { // .masonry() to initialize var $grid = $('.grid').masonry({ // options... }); // methods are available by passing a string as first parameter $grid.masonry( 'reveal', elems ); }); ``` ## RequireJS To use Outlayer with [RequireJS](http://requirejs.org/), you'll need to set some config. Set [baseUrl](http://requirejs.org/docs/api.html#config-baseUrl) to bower_components and set a [path config](http://requirejs.org/docs/api.html#config-paths) for all your application code. ``` js requirejs.config({ baseUrl: 'bower_components', paths: { app: '../' } }); requirejs( [ 'outlayer/outlayer', 'app/my-component.js' ], function( Outlayer, myComp ) { new Outlayer( /*...*/ ) }); ``` Or set a path config for all Outlayer dependencies. ``` js requirejs.config({ paths: { 'ev-emitter': 'bower_components/ev-emitter', 'get-size': 'bower_components/get-size', 'matches-selector': 'bower_components/matches-selector' } }); ``` ## MIT license Outlayer is released under the [MIT license](http://desandro.mit-license.org).