Simon Willison has been writing about AI-assisted development more carefully and consistently than almost anyone. His posts trace a real pattern: not the hype cycle, but the practical experience of a working developer figuring out what these tools actually change. His recent piece, Eight years of wanting, three months of building with AI, sits at the intersection of two things worth taking seriously: the personal backlog problem every developer accumulates, and the question of what AI assistance changes about that backlog.
The “eight years of wanting” framing is the honest part. Most developers have a list like this. Projects that are fully specified in their heads, where the domain knowledge is there, where the motivation exists, but where something in the execution cost keeps the project perpetually deferred. Sometimes that something is an unfamiliar technology stack. Sometimes it is the volume of boilerplate required before anything interesting compiles. Sometimes it is the specific kind of tedium involved in writing several hundred lines of integration glue that you understand completely but would rather not type.
AI-assisted development gets described primarily as a speed improvement for coding. That framing misses what is actually happening in cases like Simon’s. The project was not deferred because he lacked the skill to build it over, say, six months of conventional work. It was deferred because six months felt like too much relative to everything else competing for that time. The AI did not make him faster at writing code he already knew how to write; it changed the ratio of interesting-work to tedious-work until the project became worth starting.
That distinction matters because it changes what you should expect from these tools. If you measure AI coding assistance by how much faster an experienced developer can write Python they already know well, you will see modest gains. That is not the interesting case. The interesting case is the project that moves from “not worth starting” to “worth doing in a concentrated sprint.”
What Simon’s Tooling Looks Like in Practice
Simon’s approach to AI tools is well-documented. He built the LLM CLI tool specifically to make language models accessible from the terminal and embeddable in shell pipelines, which says something about how he works: he wants AI in the flow of his existing tools, not in a separate interface he has to switch to. He is primarily a Python developer, and a considerable amount of his AI-assisted work involves using models to handle the JavaScript and frontend work that sits outside his daily practice.
His approach is conversational rather than generative-and-deploy. He interrogates the model, verifies outputs, iterates. The three-month figure reflects that kind of engagement: a sustained collaboration with AI tooling, not a single prompt that produced a working application. That matters for interpreting the claim. He is not saying AI made him 8x faster. He is saying AI made a project that was never going to happen, happen.
The Specific Categories Where Cost Structure Changes
There are particular classes of work where LLMs change the economics meaningfully.
One is unfamiliar stack navigation. When a project requires serious engagement with a framework or language the developer does not use daily, the learning overhead used to be substantial. A model with broad training across that stack can serve effectively as a pair programmer with working familiarity in that domain, compressing the ramp-up from weeks to hours. The verification cost does not disappear; you still need to understand what is being generated and catch the confident errors that LLMs reliably produce. But the cost of a reasonable first draft in unfamiliar territory drops considerably.
A second is integration work. Writing code that connects systems not designed to talk to each other involves reading documentation, adapting example code to your actual use case, handling edge cases in data formats and protocol behavior, and producing a lot of scaffolding before anything testable exists. LLMs have broad exposure to the patterns involved in this kind of work, the boilerplate is mechanical, and the developer’s judgment is most needed for architectural decisions rather than for producing the connecting tissue between them.
A third, less discussed category is the activation energy for starting at all. There is a specific psychological cost to opening a blank file for a project that has been mentally shelved for years. Having a conversational interface where you can describe what you want and get back something concrete, even imperfect, changes the dynamics of that first session. The project becomes a thing you are working on rather than a thing you are thinking about building.
The Evaluation Constraint
Something Simon has noted across his AI writing deserves more emphasis: AI assistance works well for projects where you, the developer, can evaluate the output. This sounds obvious but it is the actual binding constraint. If you are building in a domain you do not understand, AI code generation gives you text you cannot effectively review. If you are building in a domain you understand well but find costly to execute, it gives you real leverage.
This is why the eight-year backlog project is a meaningful test case. A project deferred for eight years by an experienced developer is almost certainly one the developer understands thoroughly. The conception is fully formed. The evaluation criteria are clear. The uncertainty is not “what should this do” but “when am I going to find the cycles to do it.” AI assistance directly addresses that specific constraint without requiring you to outsource the judgment calls that actually matter.
What the Gap Reveals
The broader implication, which Simon’s writing points toward without always stating directly, is that AI tools are changing the relationship between conception and implementation for experienced developers. The gap used to be gated by time, and time was gated by execution cost. When execution cost drops for certain classes of work, the bottleneck shifts. You spend more time on architectural decisions and iteration on design, and less time on implementation machinery. That is a meaningful change in how software development works for this category of developer and this category of project.
The counterpoint is worth naming. Three months is still three months. Projects get built in three months without AI all the time. The question is whether those are the same three months, spent on the same mix of work. The claim is that the mix changed: more judgment calls, more design iteration, less time on the mechanical parts of implementation. Whether that is better depends on what you value, but for solo and small-team projects where the bottleneck has always been execution rather than ideas, it represents a real shift in what is worth attempting.
What makes accounts like Simon’s credible is the precision of the framing. He is not claiming AI let him build something he could not have built. He is claiming it let him build something he would not have built, in a timeframe that made it worth attempting. That is a precise and honest description of a specific effect, and it is distinct from both the hype that AI makes developers 10x faster and the dismissal that it only autocompletes boilerplate. The honest territory is somewhere between those positions, and the eight-year backlog is as good a place as any to find it.