Every architecture is a receipt
Two-digit years and NAT were trades made at the prices of their day. AI changed the prices. Code got cheap, and attention, review and context didn't. Six bets on what changes next, and how sure I am about each.
On 15 October I wrote down the architecture for a new app I’m building: one TypeScript codebase, one container image, one Postgres database. “No microservices, no Redis, no Kubernetes,” the plan says. I even passed on C#, the language I read fastest, because a C# back end under a React front end would mean two stacks and two deployments.
One line in the plan explains all of it: “Hrih’s review time sets the pace.” (Yes, the plan talks about me in the third person. An agent wrote it.)
Agents write most of the code, and I read it. So the big technical choices in that plan spend what’s cheap, code an agent can write, to save the thing I’m short of: my attention. The rules about who can see what live in one domain/ module that every route calls, so they’re “enforced in one place and tested in one place.” Further down, under risks, the plan just says it: “Agents write fast; checking is the bottleneck.”
Once I’d noticed that, I started seeing the same move all over the history of software. Most of the architectures we argue about are bets on which resource runs out first. When that resource stops running out, the right shape changes, and the old shape usually stays anyway, like a receipt in a drawer for something you don’t remember buying.
None of this is new to economists. Lionel Robbins defined their whole field in 1932 as the study of choices about “scarce means which have alternative uses.” I’m just pointing it at software.
Two digits for the year was the right call
Start with the most famous mistake in software. For decades, programs stored years as two digits, so 1999 was 99 and 2000 would be 00. Fixing it cost a fortune. Gartner estimated $300 to $600 billion worldwide. (IDC, more modestly, said $297 billion between 1995 and 2001.)
Then, in December 1997, the Journal of Accountancy reported a calculation by two professors writing in the Journal of Systems Management. Over the 30 years when two-digit years were the norm, “a typical organization saved over $1 million per gigabyte of total data storage.” Invested well, that saving could have produced “a fifteenfold return,” which they thought was more than enough to pay for the fix.
I love this, because it turns the most famous bug in history into a loan. In 1970 a megabyte of memory cost about $730,000 in the dollars of the day, space on an 80-column card was tight too, and two bytes per date across millions of records was real money. The professors’ math is hindsight, of course, since it assumes someone in 1970 was planning for 1999. That’s sort of the point: they optimized for the price in front of them. The bill came due in 1999, and by 2000 the same megabyte cost about $1.56. That’s not a mistake, exactly. It’s a trade made at one price and paid back at another.
The price of a megabyte of RAM in US dollars of the day, on a log scale, at selected years from Stanford’s DAM series (John C. McCallum’s data to mid-2024, then retail prices). Two-digit years were designed near the top of this curve and fixed near the bottom. The uptick at the end is 2024 to 2026.
The internet has one too. RFC 791 fixed IPv4 addresses at 32 bits in September 1981, about 4.3 billion of them, and Vint Cerf has said he thought of IPv4 as an experiment. When addresses started running short, RFC 1631 introduced NAT in May 1994 as a short-term fix.
IANA handed out its last blocks of IPv4 addresses on 3 February 2011. Google first saw more than half of its users arrive over IPv6 in March 2026, 30 years after IPv6 was specified, and the short-term fix is still running in your home router.
Text has one as well. In the early 1990s Unicode was designed around 65,536 characters of two bytes each, and four-byte characters were resisted partly because they wasted memory and disk. When 65,536 turned out not to be enough, Unicode 2.0 added surrogate pairs in 1996, and Windows and Java, which had bet on two bytes, still work in UTF-16 today.
Fossil stories need checking, though, because the good ones get repeated until they’re wrong. Poul-Henning Kamp called C’s zero-terminated strings “The Most Expensive One-byte Mistake” in ACM Queue in 2011, and the usual story is that ending a string with a zero byte saved memory over storing its length.
Dennis Ritchie’s own account is different. B, C’s predecessor, dropped the length count that BCPL kept at the start of a string to avoid the limit an 8- or 9-bit count put on a string’s length, and because a count seemed “less convenient than using a terminator.” It was still a trade against small machines, just not the one in the story.
Follow the scarce thing
You know this history, so I’ll go quickly. The interesting part is what each era was short of.
Machine time. In 1960, an IBM 7090 leased for about $63,500 a month. At those prices people waited for the machine, never the other way round: you handed in your cards and came back for the output. MIT’s CTSS, demonstrated in November 1961, let several people share one computer at once, because computers were too expensive to leave waiting for anybody.
The famous chart for the end of this era is Barry Boehm’s, from Datamation in May 1973. Hardware was about 84% of a system’s cost in 1955, and software was heading for 90% by 1985. It was reprinted for decades.
When Derek Jones went back to the sources in 2023, the chart turned out shakier than its fame: the data came from US Air Force command-and-control systems, the 1985 end was a forecast, and in 1982 Harvey Cragon published a paper called “The myth of the hardware/software cost ratio.” The direction was right, though. People were becoming the expensive part.
Hardware’s share of a system’s cost, redrawn from Derek Jones’s fitted curve of Boehm’s 1973 chart. The dashed part was still a forecast when Boehm published it, and the data came from US Air Force systems, not the whole industry.
One person’s head. In 1972 David Parnas published the paper that gave us information hiding. Read it today and what stands out is how openly he trades. He admits his way of splitting a program into modules “will prove to be much less efficient,” because of all the extra calls between them, and picks it anyway. What he gets in return is code where “difficult design decisions or design decisions which are likely to change” sit behind an interface, and where “separate groups would work on each module with little need for communication.”
Machine time was getting cheaper and programmers weren’t. Eric Raymond later wrote the trade down as Unix’s Rule of Economy: “Programmer time is expensive; conserve it in preference to machine time.”
Abundance has a cost too. Niklaus Wirth complained in 1995 that “Software expands to fill the available memory,” crediting Parkinson.
The team. Mel Conway’s 1968 observation was that organizations are “constrained to produce designs which are copies of the communication structures” they already have. It holds up better than most laws with names. A 2016 review of 142 studies found that kind of mirroring a “prevalent pattern but not universal.”
Fred Brooks did the arithmetic in 1975: n people have n(n−1)/2 possible conversations, so a team of 50 has 1,225. Amazon’s answer was the two-pizza team, small enough to keep the lines of communication few, with each team owning its own service.
Uptime and operations. Then the cloud turned machines into something you rent by the hour. S3 launched in March 2006, EC2 that August at $0.10 an hour, and Lambda in November 2014, with no servers to manage and billing in 100-millisecond units. The scarce thing had become the people who keep servers running, and the cloud sold us their time.
Netflix’s move, the one that made microservices famous, belongs here too. In August 2008 a database corruption stopped DVD shipping for three days, and Netflix spent the next seven years getting rid of single points of failure, finishing in January 2016 with hundreds of microservices in the cloud. What Netflix was short of was uptime.
- Scarce
- Time on the computer itself.
- The shape it produced
- Batch jobs, then time-sharing: MIT’s CTSS let several people share one machine from 1961.
- One number
- An IBM 7090 leased for about $63,500 a month in 1960.
- What changed next
- Hardware fell below half of a system’s cost around 1965, on Boehm’s curve.
Each era is named for what was scarce. The years are rough and they overlap; several of these resources were tight at once.
A few of the stories in this genre are too good to be true. Database normalization wasn’t invented to save disk: Codd’s 1971 list of goals is about insert, update and delete anomalies, and storage isn’t on it. Unix commands probably aren’t short because Teletypes were slow. Nobody has found a primary source for that, and Multics already had ls. And Conway’s paper doesn’t contain the famous line about four groups building a four-pass compiler. That one is a later retelling.
Buying someone else’s scarcity
If an architecture is a bet on what’s scarce, the worst architecture is a good answer to a scarcity you don’t have.
Richard Gabriel described the first half of this in 1990, in an essay whose title still starts fights: worse is better. He argued that Unix and C spread because early Unix and C compilers “require few machine resources to run,” and because “It is better to get half of the right thing available so that it spreads like a virus.” They fit the machines people actually had. (Gabriel, to his credit, never settled whether he was right. “I still can’t decide,” he wrote later.)
The second half is what happens when you copy the shape and skip the scarcity. Segment ended up with more than 140 services and “3 full-time engineers spending most of their time just keeping the system alive.” In 2018 it folded them into one service.
Istio did the same to its own control plane in 2020, merging Pilot, Galley, Citadel and the sidecar injector into a single binary called istiod. The parts were always released together, and most installations were run by a single team. As the announcement put it, microservices “have to be right sized.”
Then, in 2023, Amazon’s Prime Video team wrote that moving one monitoring service “to a monolith reduced our infrastructure cost by over 90%.” Hacker News read the fine print. Most of that saving came from Step Functions charging per state transition, and it all still runs on AWS. (Sam Newman read it as a story about “pricing models of functions vs long-running VMs,” which is a scarcity story too.)
Martin Fowler had warned about this in 2015, in a post on what he called the microservice premium: “don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.”
Scarcity doesn’t explain everything, though. In a 2021 survey of 591 developers and hiring managers, mostly in Germany, “60% of our hiring professionals agreed that trends influence their job offerings,” and 20% of respondents admitted knowingly picking a trending technology that wasn’t ideal for the job.
To be fair to them, when they rated what drove their choices, requirements still came out well ahead of trends. A 2013 study of programming language adoption went further and found that “intrinsic features have only secondary importance,” behind libraries, existing code and what people already knew.
So here’s my honest version of the idea. Scarcity sets the shape. Skills, switching costs and fashion explain why a shape hangs around after its reason is gone. So before you copy someone else’s architecture, ask what they were short of, and check that you’re short of it too.
What’s scarce in 2026
So what’s cheap now, and what isn’t?
Writing code got cheap, fast. In September, Epoch AI estimated that the price of a given level of model capability has been falling about 47% per quarter, or 13 times a year. (That’s the price for someone who “relentlessly searches for the most cost-effective model,” so your mileage will vary.) Andreessen Horowitz tracked one example: output at GPT-3’s level cost $60 per million tokens in 2021 and $0.06 in 2024.
There’s a catch, and everything below depends on it. Price per token is falling, but tokens per task are climbing. A 2026 study found that agentic coding tasks use about 1,000 times the tokens of code reasoning and chat, and that the same task can vary up to 30-fold in tokens from one run to the next. Running the newest frontier models is getting more expensive, by 3 to 18 times a year according to a group at MIT. Code is cheap per line, and a merged change can still be expensive.
What didn’t get cheaper is the part where a person decides whether the code is right.
Herbert Simon saw this coming in 1971, decades before anyone had an inbox. He wrote that “a wealth of information creates a poverty of attention.” Two pages later he proposed a test, and I think every AI tool in a software pipeline should have to pass it: a new subsystem reduces the demand on people’s attention “only if it absorbs more information previously received by others than it produces.”
An agent that turns a one-line ticket into a 600-line pull request has produced far more than it absorbed, unless something else checks that pull request for you. That was the problem behind my last article, Who teaches the reviewer?, and it’s why my new app’s plan says my review time sets the pace.
Context is scarce in the same way. Anthropic’s engineers describe an agent’s context as “a finite resource with diminishing marginal returns,” and when Chroma tested 18 models in 2025, “model performance consistently degrades with increasing input length.” Simon Willison wrote the job description in one line last December: “Your job is to deliver code you have proven to work.”
And one old scarcity came back. The AI build-out has made memory expensive again. TrendForce forecast contract DRAM prices up 90 to 95% in a single quarter at the start of 2026, and retail DRAM went from $1.57 per gigabyte in January 2024 to $4.72 in March 2026.
Two prices on a log scale, endpoints only. Tokens: the cheapest output at GPT-3’s level, per million tokens, from Andreessen Horowitz (November 2024). Memory: retail DRAM per gigabyte, from Stanford’s DAM series. The units differ; the directions are the point.
Six bets, and what would prove me wrong
A theory that explains everything after the fact is easy to write, so here are six things this one predicts, how sure I am about each, and what would change my mind.
1. Fewer hops. If an agent’s context and a reviewer’s attention are the scarce things, the unit of design shifts from “what one team can own” to “what one agent can hold and one person can check.” In 2019, Team Topologies told us to “limit the size of services or products to the cognitive load that the team can handle.” I think the same rule now applies with a different subject, and that it favors modular monoliths, because a change that crosses a function call is easier to make and to check than one that crosses a network hop. If you hand an agent a change that spans three services, it has to piece the contract between them together from three codebases, and no compiler tells it when it gets that wrong. (Typed contracts like protobuf or OpenAPI close some of that gap, which is bet 3 doing bet 1’s job.)
The evidence is circumstantial. SWE-bench Pro, a 2025 benchmark with 1,865 tasks, found “sharp declines as file count increases.” On ITBench, agents resolved only 11.4% of site-reliability scenarios, and a 2026 study of agents doing root-cause analysis found that “Failed investigations drift toward unrelated services.”
There’s evidence the other way too. FeatBench found agents doing worse as repositories grow, whatever their shape. And modular monoliths are hard to keep modular: Shopify’s retrospective on its own tooling concluded that its domains “do not reflect the way Shopify’s code actually functions.” Nobody has tested the hop itself. (I came close to testing it for this article, with one app built twice. Maybe next time.)
How sure: a hunch. What would prove me wrong: a benchmark where agents make cross-service changes as reliably as the same changes inside one process.
2. DRY bends, and review pays for it. Hunt and Thomas’s 1999 rule says “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” That’s about knowledge, not keystrokes, but in practice a lot of duplication got avoided because writing it out twice was tedious. Agents don’t find anything tedious, and they duplicate a lot. A 2026 study of 617 pull requests in one open-source project found the agents’ code about 1.87 times as redundant as the humans’, and GitClear’s 2025 report headlines “4x more code cloning.”
The worrying part is review. The same study found reviewers reacting in more neutral or positive ways to the agents’ pull requests, and concluded that the “surface-level plausibility of AI code masks redundancy.” We’ve known since 2009 that inconsistent changes to cloned code cause real faults. DRY also gave you one place to check.
How sure: it’s happening, and it isn’t fine. What would prove me wrong: agents keeping duplicated code consistent for months, not just on the day they write it.
3. Types, contracts and schemas come back as guardrails. This is the bet with the best evidence. In a 2025 study from ETH Zurich and Berkeley, “on average 94% of compilation errors result from failing type checks” in model-generated TypeScript, and constraining the model to type-correct output cut compilation errors by 75% on one benchmark and 52% on another. (Those were open models of up to 34 billion parameters on small benchmarks, so treat it as a mechanism, not a forecast.)
In August 2025 TypeScript became the most used language on GitHub by monthly contributors, and GitHub links that to AI, carefully, calling it “correlative evidence.” Bertrand Meyer, who gave us Design by Contract in 1986, argued last November that vibe coding faces “two overwhelming obstacles,” and proposed pairing AI with formal specification and proof.
How sure: strong, on the mechanism. What would prove me wrong: agent-written code producing as many defects in typed codebases as in untyped ones.
4. Old patterns come back. In 1976 Carnegie Mellon demonstrated Hearsay-II, a speech-understanding system built around a “blackboard”: a shared workspace where independent experts posted partial answers and a scheduler decided who worked next. Fifty years later, multi-agent systems are being built the same way. A 2025 paper from Google and UMass, “inspired by the blackboard architecture,” reported 13% to 57% relative improvements in end-to-end success, and Anthropic has its subagents write their output to a filesystem to avoid a “game of telephone.” The scarcity is the same one. Each of Hearsay-II’s experts understood one level of a spoken sentence, and each agent holds one context window, so both need a shared place to put what they know.
A simplified view of both. Hearsay-II’s knowledge sources posted hypotheses about sounds, syllables, words and phrases, and a scheduler picked which one ran next. The 2026 side is a generic setup, not any one product. Switch the year and only the labels change.
My provocation, labelled as one: agent orchestrators and MCP gateways are starting to look like the enterprise service bus of the early 2000s. I have no data for that, only a feeling and some vendor pages.
How sure: some evidence for the blackboard, and a hunch for the ESB. What would prove me wrong: shared-workspace designs losing to agents passing messages directly, on the same tasks.
5. Some components are wrong on purpose now. Earlier architectures assumed that a component either works or fails. Networks fail too, but they fail loudly, with a timeout or an error. A model fails plausibly: it returns a well-formed answer that’s wrong. Martin Fowler calls this “a non-deterministic abstraction.” Spam filters had a version of this for years. What’s new is that the component writing your code has it too.
The practical answer is evals, which are tests for things that are only right most of the time. Anthropic’s advice is to make maintaining them “as routine as maintaining unit tests,” and Hamel Husain wrote the line I’d frame: “Your pass rate is a product decision, depending on the failures you are willing to tolerate.”
How sure: strong, as a framing. What would prove me wrong: evals staying a research-team habit instead of living in the repository next to the unit tests and running on every change.
6. Practices we couldn’t afford come back. This is the fossil story in reverse. Formal verification was always too expensive for most code, because writing proofs took experts a long time. Martin Kleppmann argued last December that AI “will totally change the economics of formal verification.” Property-based testing is getting the same treatment: in a 2025 study, an agent wrote Hypothesis tests for 100 Python packages, 56% of the bugs it reported were real, and three fixes were merged, one of them in NumPy.
Even documentation is back. Liz Fong-Jones said this year that “AGENTS.md files need to be sprinkled all over to steer the agents.” Engineers asking for more documentation. I’ll take it.
How sure: early signs. What would prove me wrong: formal verification still being something almost nobody does in two years, when agents can write the proofs.
1Fewer hops
SWE-bench Pro: “sharp declines as file count increases.” Nobody has tested the hop itself.
Would prove me wrong: Agents make cross-service changes as reliably as the same changes inside one process.
2DRY bends, and review pays for it
Agents’ code was 1.87 times as redundant as humans’; GitClear reports “4x more code cloning.”
Would prove me wrong: Agents keep duplicated code consistent for months, not just on the day they write it.
3Types and contracts as guardrails
94% of compilation errors were type-check failures; type-constrained output cut them by 75% and 52%.
Would prove me wrong: Agent-written code produces as many defects in typed codebases as in untyped ones.
4Old patterns come back
A blackboard-style agent system reported 13% to 57% relative gains in 2025. The ESB comparison has no data.
Would prove me wrong: Shared-workspace designs lose to agents passing messages directly, on the same tasks.
5Components that are wrong on purpose
Evals are tests for things that are right most of the time: “as routine as maintaining unit tests.”
Would prove me wrong: Evals stay a research-team habit instead of living next to the unit tests and running on every change.
6Practices we couldn’t afford come back
Agent-written property tests: 56% of the bugs reported were real, and a fix was merged in NumPy.
Would prove me wrong: Formal verification is still rare in two years, even when agents can write the proofs.
Dots: how much evidence there is today, out of four.
The six bets, with how sure I am about each and what would change my mind. The sources are in the text above.
Write down what’s scarce
The practical part is two lines in your architecture decision records.
Michael Nygard’s ADR format from November 2011 has a title, the context, the decision, its status and its consequences. It’s a good format, and it leaves out the thing this whole article is about. Here are the two lines for my new app’s architecture:
Scarce: my review time. Agents write most of the code, and I check it.
Revisit when: reviewing turns out to be slow.The first line says what the decision spends and what it saves. The second says when the bet stops being true, so whoever reads it in 2031 can tell whether they’re looking at a good decision or a receipt.
The funny thing is that both lines already existed, just not together. The decision note says, under consequences, “Revisit if reviewing turns out to be slow.” The first line was sitting in a different document, the build plan: “Hrih’s review time sets the pace.”
A thought to add?
A good question, another perspective, or something this made you think about. There’s room for it here.
Loading the conversation…