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.1 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. ↩