Simon Willison's Reading List Is a Vibecoding Syllabus

A Lobste.rs thread asking 'what blog posts influenced your thinking the most?' pulled a reply from Simon Willison that's worth reading even if you've never opened a terminal in your life. He picked three essays, none newer than 2018, and each one maps almost too neatly onto the problems AI-assisted developers hit every day.

The three essays

• [The Law of Leaky Abstractions](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) (Joel Spolsky, 2002) — 'all non-trivial abstractions, to some degree, are leaky.' Willison says it taught him to always dig into the layer underneath whatever he's working on, because eventually that layer will leak.
• [Migrations: the sole scalable fix to tech debt](https://lethain.com/migrations/) (Will Larson, 2018) — argues that swapping a service, a database engine, or a framework isn't a rare heroic event, it's a core, repeatable engineering skill, and the only thing that actually scales against accumulating debt.
• [The Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) (Charity Majors, 2017) — makes the case that moving back and forth between hands-on engineering and management, rather than picking one track forever, produces stronger people at both.

Why a 2002 essay is suddenly relevant again

Spolsky's point was about TCP/IP, SQL, and C++ string classes, but the shape of the argument fits AI-assisted development better than almost any framing written since. When a model generates a function, a migration script, or a smart contract, it hands you a working abstraction — until it doesn't. The moment it leaks (a race condition the model didn't model, a gas-cost assumption that doesn't hold on an L2, an ORM call that silently N+1s), the person who has to fix it needs to understand the layer underneath the generated code, not just the prompt that produced it. 'Vibecoding' without that underlying literacy isn't faster development, it's deferred debugging.

Larson's migrations essay lands the same way. Codebases that lean on AI-assisted generation accumulate structure fast — new services, new schemas, new integration points — and that structure needs the same disciplined migration path as anything hand-written. The essay's real argument is that treating migrations as routine infrastructure, with clear derisk-enable-finish phases, beats treating each one as a special project. That's arguably more true, not less, when an AI pair-writes a chunk of the diff: the temptation to let debt pile up because 'the model can just regenerate it later' is exactly the trap Larson is warning against.

Majors' pendulum essay is the odd one out on the surface, but it's directly relevant to how small AI-native teams and solo builders actually work. When one person is founder, engineer, and product manager in the same week, the pendulum isn't optional career advice, it's the operating model. Majors' point that hands-on time keeps management judgment sharp translates cleanly: staying close to the code your AI tools are generating is what keeps your product judgment sharp, too.

The takeaway

None of these essays mention LLMs. That's arguably the most useful thing about Willison's list: the fundamentals that separated good engineers from struggling ones in 2002 and 2018 — understanding what's underneath your tools, treating change as routine rather than exceptional, staying hands-on — are the same fundamentals that separate good AI-assisted developers from ones who are quietly building a debt pile they don't understand.