Eight Years of Wanting, Three Months of Having: What AI Changes About the Side Project Backlog
Source: simonwillison
Simon Willison published a post this week about a project he had wanted to build for eight years and finally completed in three months with AI assistance. Willison is the creator of Datasette and the llm CLI tool, and he has been writing carefully and skeptically about AI coding tools for longer than most developers have been paying serious attention to them. His experience is worth examining not as a productivity story, but as an economics story.
The Activation Energy Problem
The standard framing around AI coding tools focuses on speed: you write code faster, you ship features faster. That part is true, but it captures the less interesting half of what changes. Speed improvements at the margin matter most for work you were already committed to doing. What shifts more substantially is the threshold between a project that lives on your mental backlog and one that actually gets started.
Chemistry has a concept called activation energy: the minimum energy required to initiate a reaction, regardless of whether the overall reaction releases or consumes energy. Long-deferred software projects have an analogous property. The eight-year project isn’t stuck because the end state is unappealing or poorly understood. It’s stuck because the initial investment required to actually begin, to get a working skeleton, handle the environment setup, read the documentation for the three libraries you haven’t used before, write the scaffolding you know you need but find tedious to produce, exceeds what you’re willing to allocate on a Tuesday evening when you’re already tired from the work you were paid to do.
AI assistance attacks this specific problem directly. The parts of a project that are hardest to start are often not the parts that require the most expertise; they’re the parts that require the most patience. Wiring things together, writing the boilerplate, handling the initial configuration, generating the test fixtures. These tasks are fully within a senior developer’s ability and fully below their interest threshold. AI handles them without complaint.
What Specifically Gets Cheaper
The productivity gains from AI assistance are not uniformly distributed across a project. Understanding where they concentrate explains why long-deferred projects benefit disproportionately.
Scaffolding and cold start: The code you need to write before you can write the interesting code. Project structure, initial interfaces, request/response wiring, configuration handling. This category sees the most direct benefit. Willison’s llm tool illustrates the workflow:
# Describe what you need, get working scaffolding
llm "Write a Python class that wraps the Datasette API, with methods for querying tables and executing SQL"
# Pipe in existing context
cat schema.sql | llm "Generate SQLAlchemy models for this schema"
# Use a system prompt to anchor the style
llm -s "Write minimal, well-typed Python. No unnecessary abstractions." "Implement a pagination helper for this endpoint"The key is that you’re not abdicating the architecture. You’re specifying what you want and getting a working first draft, which you read, understand, and revise. Willison has been consistent about this distinction: he reads the code AI generates before committing it. The alternative, accepting output without review, is what he and others have called vibe coding, and it produces a different kind of result: fast prototypes with poorly understood internals.
Unfamiliar library surfaces: If a project requires a library or API you haven’t worked with before, the traditional path is documentation reading, example hunting, and trial-and-error iteration. AI collapses this into an example-first learning path. You describe the desired behavior, get code that uses the library correctly, and read that code to understand the library’s conventions. This doesn’t mean you skip understanding the library; it means you learn it through working examples rather than abstract documentation.
Structural repetition: Once a project establishes a pattern, implementing the tenth variation of that pattern is not interesting work. It’s the kind of labor that accumulates into a project feeling “mostly done but a slog to finish.” AI handles this category particularly well because the pattern is already established in the context it has access to.
The Multi-Model Economics
Willison’s llm tool supports routing between models, and the routing decision matters more than it might seem. Frontier models like Claude Opus are expensive and capable; smaller models are cheap and fast. The developers who extract the most value from AI assistance tend to route deliberately:
# Heavy reasoning, architectural questions
llm -m claude-opus-4-6 "I'm designing a plugin system for Datasette. Here are my constraints: ..."
# Boilerplate generation, structural variations
llm -m claude-haiku-4-5-20251001 "Generate the same pattern as above for these five additional endpoints"
# Quick lookups
llm -m gpt-4o-mini "What's the correct syntax for a SQLite window function?"Using a frontier model for every line of generated scaffolding is wasteful and, more practically, it introduces latency that breaks the flow of work. Using a cheaper model for complex architectural reasoning introduces errors you’ll spend time debugging. The skill is in matching model capability to task complexity.
Three Months as a Unit
The three-month timeline in Willison’s title is worth sitting with. This is not a weekend project. Three months of sustained work on something is a real project, with scope, decision points, and the kind of complexity that requires holding context across sessions. What the timeline suggests is that AI assistance didn’t only lower the startup cost; it maintained enough momentum to complete something of meaningful scope.
There is a related phenomenon around project scope. When the marginal cost of adding a feature drops, you add more features. The project completed in three months is probably not the minimal version of the eight-year-old idea. It’s likely a more complete version, because completeness became affordable. The eight-year mental model had time to accumulate feature wishes; AI assistance made it possible to ship most of them.
This pattern shows up in Willison’s published work consistently. His tools tend to be feature-complete in ways that suggest the build cost was not the limiting factor at any particular decision point. He shipped Datasette with plugin support, a rich metadata system, and an extensive configuration API at a stage when most solo projects would have shipped a much thinner slice.
The Backlog Drains
If Willison’s experience generalizes, something interesting is happening at the level of what projects get built at all. Senior developers carry large mental backlogs: tools they’ve been meaning to write, experiments they’ve been meaning to run, infrastructure they know would be useful. Most of these never clear the activation energy threshold. They get bumped for the next urgent thing, indefinitely.
AI assistance is systematically lowering that threshold. The projects getting built are not replacements for projects that would have been built anyway. They are projects that would have remained on the shelf. The output is additive.
For my own work on this bot, the parallel is concrete. Several features sat in the backlog for months, not because they were architecturally challenging, but because each required enough setup and context-gathering that I kept deferring them. Smaller activation energy means the queue moves. The ideas I had been “meaning to get to” started clearing.
Willison’s eight-year number is not a metaphor for “a while.” It describes a specific and recognizable experience: knowing exactly what you want to build, having the skill to build it, and not building it anyway because the cost of starting exceeds what any given week makes available. That the number is now three months instead of eight more years is a concrete measurement of what changed, and it’s the more important half of the AI-assisted development story.