The projects that live in a developer’s backlog for years share a specific shape. They are not hard in the “I don’t know how to do this” sense. They are hard in the “I know exactly what to do and it would take three weekends I don’t have” sense. Simon Willison captures this precisely in a recent post about a project that sat in his mental queue for eight years before he shipped it in roughly three months of AI-assisted work. That gap between wanting and building is worth examining carefully, because most commentary on AI coding tools focuses on the wrong part of it.
The Activation Energy Problem
When I started building Discord bots in earnest, the projects I kept stalling on were not the ones that required new knowledge. They were the ones that required scaffolding. You know the type: a feature that means writing a new command handler, a data model, a storage layer, validation logic, a test suite, documentation, and maybe a migration script. None of those pieces is difficult in isolation. Put them together and you have maybe twelve hours of mechanical work standing between you and a feature that would take five minutes to describe.
This is the activation energy problem. It is not about capability; it is about the ratio of tedious overhead to interesting problem. A developer with eight years of relevant experience knows exactly what code needs to be written. The question is whether writing it is worth the cost.
LLMs change that ratio significantly. Not by being smarter than you about the domain, but by collapsing the overhead. If you can describe a data model and get back a working schema, a typed interface, and a basic CRUD layer in thirty seconds, the calculus on starting a new feature changes. The interesting-to-tedious ratio flips.
Simon has written about this distinction before, and it is central to understanding where AI coding tools actually add value. The useful frame is not “AI writes code I couldn’t write” but rather “AI writes code I wouldn’t write because the overhead isn’t worth it”. That is a different claim, and a more honest one about what these tools actually do.
What Eight Years of Wanting Actually Means
Eight years is a long time for a project to sit unbuilt when the person who wants to build it is also the person who has the expertise to build it. This is not procrastination in the ordinary sense. It is a resource allocation problem. Developer time is genuinely scarce, and a project that is not urgent and not technically novel will lose to almost anything else in the queue.
The interesting shift with AI assistance is not speed in the naive sense. A competent developer using Claude or GPT-4 does not necessarily write features ten times faster. What changes is the minimum viable investment required to start. Getting from zero to a working prototype used to require a certain floor of consecutive hours. That floor has dropped substantially for certain project types.
Simon’s three-month timeline is worth noting. This was not a weekend hack. It was sustained work, presumably with careful review, iteration, and integration. What AI assistance did was make it possible to sustain momentum on something that had previously never reached escape velocity. That is a qualitatively different kind of acceleration than raw throughput.
The Shape of Projects AI Helps Most
Not every stalled project is equally well-served by AI assistance. The gains are largest for projects that fit a specific profile:
High scaffolding, known domain. If you understand the problem deeply but the implementation requires a lot of structural code you have written variations of before, AI assistance is highly effective. You are essentially externalizing a pattern you already hold mentally.
Well-specified subproblems. LLMs work better when you can describe what you want with precision. Projects that decompose into clear, well-bounded subtasks tend to get good AI output. Projects that require holding a complex invariant across many files simultaneously still require more supervision.
Low novelty in the stack. If you are building with mature frameworks and common patterns, the model has good training signal. Building something that requires deep knowledge of a niche library or unusual architectural constraint is harder; the model is more likely to hallucinate plausible-looking but incorrect code.
Simon’s work tends to involve Datasette, sqlite-utils, and Python tooling he knows extremely well. This is almost ideal territory for AI assistance: mature ecosystem, well-documented patterns, and an author who can immediately recognize when the output is wrong.
The Review Cost Is Real
There is a version of the “AI accelerates everything” narrative that skips over the verification work. Willison has been consistently honest about this in his writing: AI-generated code requires careful review, and the cost of that review is non-trivial. The net benefit depends heavily on whether you understand the domain well enough to spot subtle errors quickly.
This is why the “eight years of wanting” framing matters. He is not describing a situation where AI enabled a non-expert to build something beyond their abilities. He is describing a situation where an expert finally had a tool that made it worth their time to build something they had always known how to build. The expertise is doing work that is easy to undercount.
For systems programming work, this distinction is sharper. I have used LLMs to write Rust code in domains where I have some fluency, and the output is often structurally plausible but subtly wrong in ways that take real time to find. The unsafe blocks look reasonable. The lifetime annotations compile. The logic is off. Reviewing AI-generated systems code requires the same deep knowledge that writing it would have required; you are just reviewing instead of typing.
For higher-level work in well-trodden frameworks, the review cost is lower because the failure modes are more obvious. A Django view that does the wrong thing usually makes it obvious quickly. A memory-unsafe Rust function may not.
Three Months Is the Honest Number
The optimistic take on AI-assisted development tends to compress timelines in the telling. You hear about weekends, not quarters. Simon’s three-month figure is more informative precisely because it is not a weekend success story. It represents a realistic account of what it takes to ship something non-trivial with AI assistance: sustained effort, verification work, course corrections, and the kind of domain expertise that makes all of it possible.
What changed was not the skill required or the quality of the output. What changed was the minimum energy required to start and keep going. For a project that had been blocked on that threshold for eight years, that turns out to be enough.
The broader implication is that developer backlogs contain a lot of projects in this category: known, scoped, worth doing, but perpetually losing the resource allocation race. AI assistance does not eliminate the work. It changes the activation energy calculation in a way that lets some of those projects finally reach the top of the queue.