The architectural ceiling: your stack decides how far the two dials can move

In the previous post, I proposed two dials for judging AI-built code — maximize Deterministic Coverage, minimize Supply Chain Risk — and ended with a warning: you can only move them as far as your architecture allows. This post is about that ceiling — why it exists, which properties of a foundation set it, and what to do if yours is low.

One rule up front: I'm not going to name languages or frameworks. Naming them starts a syntax argument you've already had, and it dates the post the day a new release ships. The properties are what matter. Argue the properties, and you can map your own stack onto them honestly — you'll know your answer before the end.

The dials stop moving before the discipline runs out

Here's the pattern to watch for. A team takes the two dials seriously. They adopt schema-first generation, they review every new dependency, and for a quarter the numbers improve — then they stall, far from healthy territory.

The easy reading is that the team lost focus. The more common truth is that the foundation is fighting them. Tell a team to reduce dependencies when their language needs a heavy framework just to serve a basic HTTP request, and the dial cannot move — the framework and its transitive tree are the floor. Tell them to raise Deterministic Coverage on a foundation where every service is structured differently, and the generator's output never quite fits; it gets hand-edited, and hand-edited code isn't deterministic anymore.

The dials don't measure your team's discipline. They measure what your architecture lets discipline achieve. That's the Primacy of Initial Design doing what it always does: the choices made before the first feature set the budget for everything after — and no amount of measurement moves a number the design has capped.

Property 1: a foundation that's a predictable target lifts Deterministic Coverage

Deterministic generation works when the generator's output lands in a codebase that expects it. The foundations that make this easy share a description: strict typing, one obvious way to structure a handler or a service, and formatting that's built in and non-negotiable. On a foundation like that, generated code is indistinguishable from the code your best engineer writes — same shape, same layout, byte-for-byte stable across runs. The boilerplate layer gets built instantly, and nobody has to touch it.

On a permissive foundation — several competing idioms, project structure as a matter of taste, formatting as a debate — the generator has no stable target. Its output is always slightly foreign, someone "cleans it up," and the coverage dial slides back with every edit. The ceiling isn't the generator's quality; it's the number of acceptable shapes the foundation allows.

Property 2: a production-grade standard library lowers Supply Chain Risk

The risk dial counts trust boundaries — distinct external modules you must scan, patch, and trust but don't control. A foundation whose standard library covers production work — an HTTP server, JSON, cryptography, concurrency — lets a secure backend exist with a dependency count you can review in an afternoon. The graph stays flat because the basics never leave code you own.

A foundation that needs a framework for those basics starts every service with that framework's whole transitive tree. Before the first feature ships, the trust-boundary count is already three digits, and the team's most disciplined dependency review can only slow its growth. The foundation set that floor, and no review process can lower it.

The developer whose experience matters most is now the agent

For two decades, stack choices optimized for developer experience: familiarity, ergonomics, the size of the hiring pool. That was rational when humans typed every line. It stops being rational as agents write a growing share — the "developer" spending all day in your codebase is increasingly a model, and the question becomes what people have started calling agent experience, or AX: how good is this foundation as a working environment for an agent?

An agent doesn't care that your team already knows the framework, and it draws nothing from a large hiring pool. What it thrives on is the two properties above plus a third: a fast, deterministic feedback loop. A strict compiler that says exactly what's wrong, one canonical idiom so style is never a guess, builds and tests quick enough to verify every small step — each of these converts directly into more correct iterations per minute. A deep standard library helps twice over: fewer external APIs to learn is also less context to load, so the agent works from what it already knows instead of documentation it has to fetch.

If we aren't writing the code ourselves anymore, our comfort with the stack stops being a selection criterion. The best technical properties win, because the agent — unlike us — collects the full benefit of them on every task. And the hiring-pool argument, long the strongest card in the old weighting, loses a little value every quarter that agents write more of the code.

Once human ergonomics stop dominating the decision, raw runtime efficiency gets its vote back too. A 2017 study by Pereira et al. (SLE 2017) benchmarked 27 languages across ten problems for energy, execution time, and memory; the spread between the most and least efficient was roughly seventy-five-fold on energy. When engineers had to write every line, paying that premium in exchange for productivity was often a fair trade. When an agent writes the code either way, the premium buys nothing — it's pure cloud bill, and pure carbon.

What other ecosystems win — and the weighting I'm choosing anyway

The opposing view here is credible, so it deserves its full weight. Permissive, framework-centric ecosystems win real things: bigger hiring pools, broader library coverage, faster-moving communities, and near-total ownership of some domains — frontend and machine-learning tooling among them. If your product lives in those domains, or hiring speed dominates every other constraint you have, your weighting will differ from mine, and reasonably so.

My weighting is chosen for the economics of AI-era backend engineering: when generators write the foundation and models write the novel logic, the properties that compound are predictability and a small audited surface. I'd rather have a smaller hiring pool working above a generated, low-dependency foundation than a larger one paying interest on a framework tree. That's a judgment call, and yours may land elsewhere — but make the axes explicit, because defaulting to the familiar stack is also a weighting, just an unexamined one.

The speed objection has the timescale wrong

The pushback every architect hears: "this discipline trades speed for safety, and we need speed." The claim mistakes which speed matters.

Sprint velocity — raw speed to a working v1 — genuinely favors the unconstrained approach; a model plus a framework demos beautifully. Lifecycle velocity — speed to production, and speed to change the system safely a year later — runs the other way. The audits of a wide dependency tree, the patching tax, the debugging of guessed edge cases all land after the demo, as drag on every release that follows. A schema-driven generator matches the model's sprint speed on boilerplate — the code appears just as instantly — and then charges nothing downstream.

You raise the fleet's average one new service at a time

If your current stack scores poorly on both properties, the wrong conclusion is a rewrite — that trade is almost never worth it. The criteria are for the decisions you haven't made yet: the next new service, the component being split out of the monolith, the platform choice in next year's plan. Applied there, they cost nothing, and each new service raises the fleet's average instead of fighting the old ceiling. (The same logic as build vs. buy: you don't need to fix the past if the next decision is cheap to get right.)

Where this is headed: the stack becomes an AI-economics line item

Foundation choice used to be settled by familiarity and hiring, then never revisited. As more of the codebase comes from generators — deterministic and probabilistic — the foundation's properties start showing up in money: token spend on boilerplate a generator should have written, audit hours on trust boundaries the standard library should have covered. I expect AX to get benchmarked the way DX used to get debated — "how well does this stack support generated code, and how little does it need from outside?" joining the standard questions in platform reviews — and the due-diligence question from the previous post ("how much of your executing code do you own?") to grow a follow-up: "and what ceiling did your stack choose for that number?"

Take it into your next platform review

• Pull up the dependency graph of your newest service. How many of those trust boundaries exist because the foundation couldn't do something basic on its own?
• Estimate what share of your foundation code a deterministic generator could emit today. If the answer is "very little," is that your team's discipline — or the stack's ceiling?
• When did your organization last choose a backend foundation deliberately, with the axes written down — rather than by momentum? If the answer is "never," that decision is being made anyway, by default.