In 1994, Peter Deutsch published the Fallacies of Distributed Computing — eight assumptions that every developer building distributed systems makes, discovers are wrong, and pays for in production. The network is reliable. Latency is zero. Bandwidth is infinite. Each assumption sounds true. Each leads to system failures that could have been avoided.
Thirty years later, we're making the same category of mistakes with generative AI.
The trough of disillusionment for AI-assisted development has begun. Byron Cook, VP and Distinguished Scientist at Amazon, founder of AWS's Automated Reasoning Group (300+ scientists, 15+ teams), says it plainly: "Generative AI is sliding into the trough of disillusionment." The headlines are shifting. The "summer of vibe coding" is over.
The disillusionment isn't caused by AI being useless. AI-assisted coding delivers real productivity gains. The disillusionment is caused by false assumptions about WHERE the gains come from and WHAT changes when generation gets fast. Teams expected 10x engineering. They got 10x code generation and 1x everything else. The gap between expectation and reality is the trough.
This series names the eight assumptions, explains why each one fails, and presents the resolution — not from theory, but from domains that hit the same wall and climbed out.
The Eight Fallacies
1. Faster code generation means faster engineering.
You made one sub-system 10x faster. Seven others didn't change. The system doesn't get faster — it breaks at the interfaces. The CPU-memory wall tells you exactly what happens and what fixes it.
2. If the output looks correct, it is correct.
AI-generated code is optimized for plausibility, not correctness. It compiles, passes tests, and reads well — while violating properties nobody tested. Plausible is not correct. The gap is where production failures live.
3. You can verify AI output with another AI.
Guardrails, LLM-as-judge, AI code review — the verifier has the same failure modes as the thing it's verifying. Wrapping a non-deterministic system with another non-deterministic layer doesn't converge on reliability. It doubles the cost while preserving the fundamental problem.
4. Dropping human review removes the bottleneck.
Removing a gate without replacing it isn't optimization — it's removing the brakes. There are three models of review. Only the third one works at AI speed: humans review specifications, machines verify code.
5. Better context prevents hallucination.
RAG improves the input. Nobody's checking the output. Better context gives the AI better facts to work with — and better facts to wrap a violation in. Context and verification are complementary. Neither is sufficient alone.
6. AI-generated code is an asset.
Every line of code is something to maintain, test, debug, secure, and understand. More code faster means more liability faster. The right unit of progress isn't code volume — it's capability delivered with minimum code.
7. Specifications are a new artifact you have to create.
The specifications already exist in your codebase — type signatures, API contracts, database schemas, module boundaries. Parnas told you to create them in 1972. You did. The only new thing is enforcing them mechanically.
8. More AI agents means more productivity.
Adding agents without specifications is like scaling a distributed system without protocols. More actors making invisible decisions means more inconsistency, not more throughput. The coordination mechanisms from distributed computing solve this — because it's the same problem.
The meta-pattern
Every fallacy stems from one root assumption: generating the output is the hard part.
It isn't. It never was. Understanding the output, verifying it, maintaining it, coordinating the actors that produce it, and preserving the rationale for why it's shaped the way it is — those are the hard parts. They always were. AI made the easy part faster. The hard parts didn't change.
The resolution across all eight fallacies is the same architectural principle: recognize the specifications that already exist in your system. Enforce them mechanically. Verify the output against declared properties. Use specifications as coordination protocols for agents.
The teams that fix these assumptions first will emerge from the trough ahead of everyone else. The teams that don't will spend years in it — learning the same lessons one production incident at a time.
The schedule
One fallacy per day for the next eight business days. Each post is self-contained — you can read any one without the others. Each ends with one action you can take this week.
Links below will activate as each post is published. Follow to get the next fallacy in your feed tomorrow morning.
This series draws from Parnas (1972), Altshuller's TRIZ (1946), Byron Cook's automated reasoning at AWS, Adam Bender's software engineering research at Google, and evidence from aviation, nuclear operations, financial trading, microprocessor design, and Google's monorepo. Each fallacy was discovered independently across domains. The convergence is the evidence.
For the architectural tools that implement the resolution: Stave (open-source cloud security reasoning engine, 2,662 safety invariants) and iam-explain (IAM policy verification CLI).