Six weeks ago I wrote The Best Architecture Is the One You Delete about a sibling law called Liberato’s Law — the reverse corollary that says the simple system replacing N complex ones requires building all N first. That essay was about the backward direction: complex → simple. This one is about the forward direction, which is older, better known, and just got rewritten underneath us.
Last week I shipped a one-week spike to a customer. Five years ago, the same exploration would have been a month of prototyping and a quarter of engineering. Five tickets. One migration. One command-line tool. One new LLM-facing tool. One skill. One end-to-end test. Demo-ready. Customer-facing. Actually working.
The speedup is not the interesting part. The speedup is the topic of every blog post and every keynote and every LinkedIn take from every engineering manager who is trying to convince themselves their job still matters. I am not here to be the nine hundredth voice telling you AI coding is fast.
The interesting part is that the spike is now cheap enough to run on purpose — and that changes what Gall’s Law is for. It used to be a founding principle. It is now a scalpel. Scalpels require discipline that founding principles don’t.
Gall’s Law, Briefly, Because You Already Know It
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
— John Gall, Systemantics, 1975
Fifty years ago. Still correct. Still quoted in every architecture review. Still ignored by every rewrite team. Joel Spolsky wrote the definitive commentary in 2000 using Netscape as the cautionary tale, and that was twenty-six years ago, and the essay is still on every “top 10 classic software essays” list, and the industry has read it and nodded and gone back to rewriting.
Nothing has happened since 1975 to falsify Gall’s Law. Every working system you interact with today — the one that handles your bank transactions, the one that routes your flight, the one that compiles this document — evolved from something smaller that worked. No exceptions. You will never find one. People have looked.
What Nobody Tells You About Gall’s Law
The “simple system that worked” was never cheap. It was cheap relative to the complex system you were tempted to design from scratch, which is why Gall framed it as the only viable starting point. But “cheap relative to a quarter of wasted engineering” still meant weeks to months of real engineering time. You could not run Gall’s Law casually. You could not run it on a Tuesday afternoon because you were curious about something.
Gall’s Law was how you started a project. It was the first thing, not a tool you used later.
This is the constraint every Gall’s Law commentary in fifty years has quietly accepted. Yes, start simple. But starting is expensive. You get one shot at starting simple per project — maybe two if you catch yourself early and are willing to admit, in front of the people paying for the project, that the first one was a practice run.
The math has changed.
The Cost Structure Collapsed
The simple-version-that-works is now a one-week spike. Friday to Friday.
Last week that was: a schema migration to add two time-series tables to an existing SQLite-backed catalog; a command-line importer that reads parquet files the customer drops on a shared folder and populates those tables; one new LLM-facing tool to query the tables with arbitrary SQL; a skill file teaching the language model how to run nine data-quality rules and present findings with inline charts; and an end-to-end test that exercises the whole loop against three days of synthetic data.
Five tickets. One week. Working, not mocked. Customer-facing, not demo-only. The simple-version-that-works exists. Gall would approve. Netscape would weep.
The speedup is not magical. It is the compound effect of infrastructure that already existed — a catalog tool family, a markdown chart renderer, a skill system, a migration runner — and an AI that can wire those pieces together with roughly the speed of thought-into-code. Nothing in the spike is novel. Everything in the spike is composed from pieces I have built over the last eighteen months, with increasing help from large language models.
Here is the claim: Gall’s Law did not change. The cost of running it did. The law is still “start simple.” What changed is that “simple” now costs a coffee break when the platform underneath is right. Which means you can run Gall’s Law — on purpose — at any point in a project, for any area of uncertainty, without waiting for the planets to align.
That is genuinely new. Fifty years of software engineering never had this option.
The ‘Works’ Part Is Still the Constraint
Gall said the simple system has to work. He was specific about it. Not appear to work. Not pass tests. Not demo smoothly. Actually work.
And here is the thing about “works”: you cannot tell from the inside. You wrote it. You tested it. You know the edge cases because you designed them. You are the wrong person to judge whether the thing works, because working is a property of the interaction between the system and somebody who has to use it — and the only person who has to use it, in every system that matters, is the customer.
The customer is the working-ness oracle. You can build the simple system in a week now. You cannot know whether it works until someone on the other side of the transaction uses it for real. This is not new to Gall’s Law — it is what Gall meant by “worked” all along. We used to elide it because the cost of building was so high that the cost of being-used-by-a-customer was a rounding error by comparison. You spent three months building. Of course you were going to let the customer touch it eventually. Of course the feedback loop mattered. The whole project waited for it.
Now building is cheap, and the customer’s engagement is the only expensive thing left.
The new move is: you run Gall’s Law to produce the simple version in one week, and then you spend the rest of your project waiting for the customer to teach you what “works” actually means. The spike is the classroom. The customer is the teacher. You cannot abstract her. You cannot predict her. You cannot design her. You can only build her a room and wait for her to walk in.
The New Failure Mode
When the simple system was expensive, it had built-in gravity. You wouldn’t ship it carelessly because it cost real time, and you knew you would have to defend every decision in the next architecture review, and you remembered the shortcuts you took because they had hurt. The expensive simple version was self-disciplining because it had been expensive. The cost was the discipline.
Now it’s cheap. And cheap things have no gravity.
Here is what I think is happening to AI-assisted teams right now, across the industry, in rooms that nobody is writing blog posts from: they are shipping probes as products. The spike works. The demo goes well. The customer is happy. Nobody notices that the spike was supposed to be temporary, because the spike has the exact same shape as a finished system — it runs, it handles the inputs, it produces the outputs. The difference between a probe and a product is not visible from the outside. It is only visible in the intent of the people who built it, and intent is exactly the thing that cheap building tends to erase.
This is the fastest hidden debt in the history of software engineering, and it is being accumulated right now, this quarter, in every AI-assisted codebase that does not have a specific, written, dated, public record of which parts were shipped as probes and which parts were shipped as final.
The industry does not yet have a vocabulary for this failure mode. The old names don’t quite fit. It is not technical debt, because the code isn’t wrong — it’s correct-but-provisional. It is not legacy code, because it is six weeks old. It is not a prototype, because it is in production and customers are using it. It is probes calcified into products, and the calcification happens because nobody wrote down “this was temporary” while the temporary-ness still showed.
Managed Gall’s Law
The new discipline is this: when you run Gall’s Law on purpose — when you ship a one-week spike knowing it is a probe — you write, in public and with dates, every single thing the probe is not doing, along with what the proper version would require and how much it would cost. You put all of it in a single ticket. You attach that ticket to a milestone that cannot be bypassed. The milestone opens when every entry in the ticket has been addressed, and not before.
I call this a ledger. Other names exist, most of them worse. “Technical debt tracker” is accurate and boring. “Shortcut register” is accurate and vaguely criminal. “Tech debt ledger” is fine. The name does not matter. What matters is: the thing exists, it is public, it is dated, it is specific, and there is a structural reason the project cannot proceed past a certain point without it being worked through.
This week’s spike has a ledger. Eight entries. S1 through S8. Each one names a shortcut (“profile ingest is a manual command-line tool, not a scheduled runnable”), explains why it is wrong (“production needs a success-marker watcher, cursor tracking, run history in the audit store”), describes what the proper fix would look like (“a scheduled ingestion runnable following the existing patterns for dedup and poison tracking”), and estimates the cost (“two to three days”). It is one ticket. It sits under a milestone whose entire purpose is to hold it. No other work lands in that milestone. When the proper rewrite begins — months from now, after the customer has taught us what “works” means — the first thing that happens is the ledger gets read, and every entry gets removed, and only then does other work begin.
The ledger is what gives the cheap spike its gravity back. Without the ledger, the spike is a thing that worked and is therefore indistinguishable from a finished product. With the ledger, the spike is a thing that worked and is publicly on record as incomplete in these eight specific ways, with a plan for each.
This is the discipline AI-native engineering demands. It did not exist before because it was not necessary before. When the simple version cost a quarter, the cost was the discipline — nobody shipped something expensive and then forgot it was a probe. Now the cost is a week, and the discipline has to be explicit. It has to be written down. The gravity has to be manufactured.
Why This Matters Beyond One Week
Nothing I did this week is unusual. Any AI-assisted engineer with a reasonably mature platform can ship a week-long spike like this. Many are. The industry is accumulating spike debt right now at a rate nobody is measuring, because the old debt vocabulary does not fit and the new vocabulary has not been invented yet.
The vocabulary I am proposing is: probe, ledger, gate.
A probe is a deliberately incomplete simple-version-that-works, shipped to expose the customer to a solution shape so that their engagement can teach you what the problem actually is.
A ledger is the public, dated, specific record of how the probe is incomplete and what the complete version would require — one entry per shortcut, each with a why-it’s-wrong and a what-the-fix-looks-like.
A gate is a structural barrier — a milestone, a sign-off, a cycle boundary — that cannot be bypassed without the ledger being worked through.
Run Gall’s Law on purpose. Ship the probe. Keep the ledger. Hold the gate.
If you are building with AI and you are not doing this, you are accumulating the fastest hidden debt in the history of software engineering. You will discover it somewhere between month three and month nine, when the probe that everyone forgot was temporary reveals itself, all at once, in a critical incident that nobody can explain because the people who built it have moved on to the next three spikes.
If you are building with AI and doing this, you have the most powerful problem-space exploration tool that has ever existed. Gall’s Law used to be how you started a project. Now it is a scalpel you can pick up any time you don’t know what to build next. The ledger is how you hold the scalpel without cutting yourself.
The Prescription
Fifty years ago Gall told us you cannot design complex systems from scratch. This week I ran his law on purpose, for the third time in this project, and shipped something I know is wrong in exactly eight ways — all of which are written down, dated, and scheduled for removal before any production work begins on top of them.
That is what discipline looks like when the law you have always respected becomes a tool you can finally afford to use.
AI did not invalidate Gall’s Law. AI made it cheap enough to wield.
Which means the thing you have to wield is: the ledger.
There is an encyclopedia where software principles get the roast they deserve — Gall’s Law in a boardroom, Liberato’s Law in a prison, YAGNI at a buffet, Zawinski’s Law at a nightclub. And a mythology where these ideas have been arguing with each other for a hundred and fifty episodes. This week’s data-quality spike is also told as a story in The Ledger — same events, different register, more scrolls.
See also:
- Gall’s Law — The founding document. 1975. Still correct.
- Liberato’s Law — The reverse direction. Complex → simple. What you have to earn.
- The Best Architecture Is the One You Delete — The companion essay, six weeks ago, on Liberato’s Law
- The Rewrite Trap — Why ignoring Gall’s Law keeps firing the only people who understand the code
- Software Dies of Obesity, Not Starvation — The arithmetic of unchecked growth
- The Discovery Tax — The normal way Liberato’s Law gets paid
- YAGNI — Adjacent but different. YAGNI says don’t build what you don’t need. This essay says: do build it, ship it, and write down that it’s a probe.
- The Ledger — The mythology companion. Same week, dialogue form, three Lizard scrolls, one Squirrel arc beat.