Simon Willison published a post this week about a gap that most experienced developers know well: the distance between projects you know you want to build and projects you actually build. His framing, eight years of wanting followed by three months of building with AI, points to something specific about how AI assistance works for developers who already know what they’re doing.
The popular narrative treats AI as a code generator, a way to type less. For developers who already know what they’re building, that framing misses the point. The constraint has never been typing speed or even raw implementation time; it has been the cost of starting.
Activation energy and the perpetual backlog
Any developer past a few years has a backlog of wanted projects: features they know how to implement, tools they have wished existed, improvements they have mentally designed. These items accumulate not because the developer lacks skill but because acting on each one requires activation energy. Scaffolding a new project, reading enough of an unfamiliar API to proceed, writing the boilerplate that precedes the interesting logic, navigating the inevitable first-hour problems before any real work begins.
This cost is real. For a solo developer or a small team, it gets weighed continuously against competing priorities. The item on the backlog is valuable, but starting it costs an hour of annoying groundwork, so it loses the prioritization fight this week and next week and eventually sits there for years.
Simon Willison has been building Datasette since late 2017, alongside a constellation of surrounding tools: sqlite-utils for programmatic SQLite manipulation, shot-scraper for automated screenshots, his LLM command-line tool for interacting with language models from the terminal, and an ecosystem of plugins on top of all of them. His publication rate, including hundreds of TIL posts and regular releases across multiple projects, is notable for a solo developer. Even at that pace, deferred work accumulates: things requiring a detour into parts of the stack he finds less natural, or infrastructure he has been postponing because the upfront cost never quite justified itself.
What changed over the past few months is that the per-task activation energy dropped enough, across enough categories of work, to make the backlog clearable.
Where friction actually lives
When I work on my Discord bot, the pattern is category-specific. Core message handling, command routing, Claude API integration, all of it flows easily because I have been through it repeatedly. What kept getting deferred were features that required diving deep into the Discord interaction model, building permission layers, or working through complex embed structures. None of it is beyond me. All of it carries a high density of small decisions that each require a documentation lookup, minor individually but collectively enough to make the task feel slow and worth postponing.
AI assistance compresses that specific tax. The lookup happens inline. The boilerplate pattern comes back correct, or nearly correct, on the first attempt. The context-switching cost between editor and documentation drops substantially. Work I had been categorizing as annoying to start started getting started.
Simon has written about a parallel version of this with JavaScript. He works primarily in Python, and JavaScript-heavy work has historically carried real friction for him. Features requiring client-side logic kept getting pushed back. With AI assistance, particularly using Claude, he found he could move through that work without the usual resistance. A whole category of previously deferred features became tractable.
The friction gradient shifted. Some categories of work that were net-negative in the prioritization calculus became worth starting.
Three months and a long list
Eight years of deferred work in three months sounds dramatic until you model it. If you have eighty features and improvements you have wanted to build, each taking a day of somewhat annoying work, and AI assistance makes each one take two to three hours, you can work through a substantial backlog over a few focused months. The items were available the whole time; the calculation on investing time in them changed.
Simon’s LLM tool is a useful lens here. The plugin ecosystem covers connections to different model providers, data stores, and utilities. Each plugin follows similar structural patterns: a Python package with standard boilerplate, a connection to a specific API, consistent configuration handling. This is a category that accelerates well with AI assistance because the patterns repeat and the main variable is the target API. Building out that ecosystem faster is not about typing speed; it is about the scaffolding and boilerplate cost dropping per plugin.
The TIL posts follow a similar logic. The investigation that precedes writing them, working through an unfamiliar API or tool until you understand it well enough to explain it, accelerates when you have an AI system you can interrogate alongside the documentation. Simon publishes these at a rate that would be unsustainable without some form of assistance compressing the exploration phase.
The quality question
AI-assisted code raises a reasonable concern about what accumulates over time. Code generated in bulk by language models can be inconsistent and carry silent assumptions that become problems months later.
The answer depends on how the assistance is used. AI used to generate large autonomous blocks produces exactly the quality you would expect: variable, carrying the model’s implicit decisions without the developer’s structural thinking. AI used to accelerate a developer who maintains the architectural decisions produces code that reflects that developer’s judgment, written faster.
Simon has been explicit in his writing that he reads and understands everything he ships. His projects remain extensible and coherent after years of development, including recent high-velocity phases. The mode he describes is faster progress on his own ideas, where he remains the decision-maker rather than becoming a reviewer of generated code.
This distinction matters more than most AI productivity discussions acknowledge. The same tools, used differently, produce very different outcomes. Velocity means something different when the developer is driving versus when the model is driving and the developer is auditing.
What the backlog actually contains
The items that sit for eight years on a developer’s list are not all low-priority. Some of them lost the prioritization fight repeatedly not because they were unimportant but because their activation energy was high relative to the alternatives. The friction gradient made them appear less valuable than they were.
As that gradient shifts, what gets built changes. Projects and features that were genuinely worth building get built. The distortion, where high-friction valuable work consistently loses to low-friction less valuable work, starts to correct.
There is also a selection effect worth acknowledging. The items that survived eight years of deferral are probably the real ones. Short-lived enthusiasm for a project tends to fade before the activation energy barrier becomes a long-term pattern. What sits on the list for years is what the developer genuinely cares about building. When those items start moving, the output has a different character than code written to fill a sprint.
Eight years of deferred work in three months is a productivity story, but it is also a story about developer attention being allocated closer to its actual priorities for the first time. That is a more durable shift than faster typing, and its effects will show up in codebases and open source ecosystems over the next few years in ways that are hard to predict from where we are now.