The backlog is the developer’s natural state. Not a failure mode, just an accounting artifact: ideas accumulate faster than hours exist to build them. Most developers carry a mental list of projects they’ve wanted to build for years, sometimes more than a decade, that simply never reached code because the cost of starting was always higher than the value of shipping on any given weekend.
Simon Willison’s recent post about eight years of wanting followed by three months of building with AI landed with a specific kind of resonance. Willison co-created Django, has been building Datasette since 2017, and maintains a sprawling ecosystem of Python tools around SQLite. His work produces deep backlogs almost by design: every feature interaction surfaces three more ideas. You can see clearly what needs to exist; finding the sustained time to make it exist is the actual problem.
The standard advice is to prioritize ruthlessly and ignore the rest. That works for maintaining forward progress, but it also means most ideas never get built. Eight years is a long time for a list to sit unchanged.
What Actually Changed
The AI coding tools that exist now, Claude Code, Cursor, and GitHub Copilot among them, don’t remove the work of building software. They redistribute it. The parts that required sustained, low-creativity effort (writing boilerplate, wiring up APIs, translating a known algorithm into a target language’s idioms) got substantially cheaper. The parts that require actual judgment (what should this do, how should it interact with existing systems, which edge cases matter) stayed roughly the same.
For a certain class of developer project, that redistribution changes everything. Consider the kind of small utility Willison has been building at tools.simonwillison.net: single-purpose web tools that do one thing, built in HTML and JavaScript, deployed statically. Each is conceptually simple. The implementation was tractable; the activation energy was the actual cost. Writing 300 lines of JavaScript for a tool you’ll use twice a month is a poor trade. Spending 30 minutes prompting and refining a working prototype changes the math entirely.
This is what makes the “eight years” framing accurate rather than hyperbolic. Those weren’t eight years of failing to prioritize correctly. They were eight years during which implementation cost was high enough to keep those projects off the schedule. When that cost dropped, the list moved.
Willison’s Workflow, in Practice
Willison is unusually transparent about how he actually works with AI. He maintains the LLM CLI tool, which lets him pipe content into a language model from the terminal and chain outputs into further processing steps. His public writing describes a tight loop: specify behavior, review generated code, run it, identify failures, iterate. He doesn’t describe accepting model output uncritically; he describes using it as a fast first draft he understands well enough to evaluate quickly.
That workflow functions because the knowledge gap between the generated code and his mental model is small. Willison has deep expertise in Python, SQLite, and web APIs. When Claude generates a Datasette plugin stub or a sqlite-utils transformation, he can evaluate it against a detailed model of what correct behavior looks like. A concrete example of what that compression looks like, using the LLM CLI tool:
# Generate a Datasette plugin from a description
llm "Write a Datasette plugin that adds a custom SQL function called
haversine(lat1, lon1, lat2, lon2). Follow the structure at
https://docs.datasette.io/en/stable/plugin_hooks.html" > haversine_plugin.py
# Chain analysis over piped data
sqlite3 data.db "SELECT * FROM locations LIMIT 20" | \
llm "Which of these records have coordinates outside the continental US?"This is grep and awk with a smarter pattern matcher at the end of the pipe. The reason it changes the backlog math is that a 20-minute script becomes a 5-minute script, and a 4-hour feature becomes a 45-minute feature. Multiply those compressions across 8 years of accumulated ideas and the arithmetic produces exactly the outcome Willison described.
The model compresses the time between “I know what this should be” and “this exists and works.” It doesn’t provide the knowledge of what it should be. That knowledge came from two decades of building tools in this space, and there’s no shortcut for it.
The Limit That Doesn’t Move
There’s a category of project where AI assistance changes almost nothing: the ones where you don’t yet have a clear enough model of what you’re building to specify it usefully. Novel system designs, data structures chosen for specific access patterns, architectural decisions in unfamiliar domains. These require exploratory thinking that language models can support but can’t replace. A model can explain approaches, generate example implementations to react to, and help articulate tradeoffs, but the direction-setting is still yours.
Most personal projects aren’t in this category. Most personal projects are “I know exactly what this should do and roughly how it should work; I just need to write the code.” That is the space AI coding tools currently dominate. The backlog of known, tractable ideas with bounded scope is the backlog that’s collapsing.
The backlog that consists of open questions, undefined interfaces, and problems you haven’t fully diagnosed doesn’t move at the same rate. The design work still takes the time it takes. Building something genuinely new, where you’re discovering the shape of the problem as you build, runs at roughly the same pace it always has. The implementation got faster; the discovery didn’t.
Willison’s eight-year list was almost certainly dominated by the first category: known ideas with clear specs, deferred because implementation felt expensive relative to the anticipated return. That is precisely the list that AI coding tools clear fastest.
The Signal Filtering That Already Happened
There’s an underappreciated aspect of the “ideas that survived eight years” framing. Most project ideas don’t survive eight years. They get invalidated by changing circumstances, superseded by tools that shipped instead, or simply forgotten as the itch fades. The ideas that remain after eight years passed the most demanding filter available: sustained relevance across a long span of time and changing context.
This has an implication that isn’t obvious at first. When developers say AI let them finally ship the backlog, they’re often shipping the highest-quality ideas they ever had, not a random sample. The ideas that felt worth building in 2018 and still feel worth building in 2026 survived because they were addressing something durable. The AI tools didn’t just change the implementation cost; they unlocked a prefiltered set of ideas.
What It Means for Your List
My own experience building a Discord bot over the past year maps onto this pattern. The features that sat on the backlog longest were the ones with clear specs: things I knew how to build but hadn’t built yet. Those shipped faster once I started working with AI assistance. The features still sitting on the list are the ones where I’m not sure yet what the right behavior is, and those haven’t moved much at all.
The practical implication for any developer thinking about their backlog: if you have ideas you’ve been deferring because implementation felt expensive, the cost structure changed. Not to zero, and not uniformly across all project types. But for projects where you have the domain knowledge and a clear enough spec, the binding constraint moved from time-to-implement to time-to-specify.
The ideas that survived eight years on your list are the ones worth building now. The filter already ran; what remains is worth the time.