Every developer I know has a list somewhere. A notes file, a Notion page, a physical notebook with increasingly optimistic margins. Projects they wanted to build years ago, held back by one recurring constraint: not enough time, not enough energy, not enough confidence that the investment would pay off. The list grows because ideas are cheap. Execution is not.
Simon Willison has been writing about AI and software development longer and more rigorously than almost anyone. His April 2026 piece describes something that many developers have quietly experienced but rarely articulated: that AI-assisted development is not just making new projects faster, it is clearing out years of accumulated debt from the idea backlog. Projects he had wanted for eight years got built in three months.
That framing matters. It is not about AI writing code so you do not have to. It is about what happens to the calculation you make every time an idea appears. The old math looked like this: how many weekends will this take, is the payoff worth it, do I have the domain knowledge to do it well, and will it still be relevant by the time I finish? Most ideas fail that test. They get added to the list and stay there.
What Changes When the Execution Cost Drops
Willison is the creator of Datasette, sqlite-utils, and the llm CLI tool, among many others. He has been using LLMs as development tools for years, and he documents his process in detail. What makes his recent post notable is the time scale: eight years of wanting, three months of building. That is not a productivity improvement. It is a phase change.
When you can take an idea from concept to working prototype in an afternoon, the filter you apply to ideas changes. The questions shift from “can I build this” to “should I build this.” That sounds like progress, and mostly it is, but it introduces its own complications.
The old execution cost served as a forcing function. If you were going to spend four weekends on something, you had better think it through first. You would consider edge cases, user flows, whether the idea even made sense. That friction produced better-considered projects, or at least it killed the obviously bad ones early. When the cost drops by an order of magnitude, you lose some of that discipline for free. You have to apply it consciously instead.
The llm Ecosystem and What It Actually Enables
Willison’s llm CLI is worth understanding concretely because it illustrates how he works. It is a command-line tool that wraps API access to multiple language models, including Claude, GPT-4, Gemini, and local models via Ollama. A typical invocation looks like:
llm 'write a Python function that parses nginx access logs into sqlite'But more useful is the ability to pipe context directly:
cat schema.sql | llm 'write a datasette plugin that adds faceting for this schema'The plugin ecosystem around llm has grown substantially. There are backends for Claude, for Gemini, for Mistral, and for model-specific features. The tool also supports embeddings, which is what enables semantic search workflows without standing up a dedicated vector database.
This is not a vibe coding workflow where you describe a full application and hope for the best. It is iterative and granular. You write some code, ask the model to extend it, review the output, correct it, and repeat. The productivity gain is real, but it is the productivity of a skilled developer using a fast tool, not the productivity of a novice who has been handed a magic wand.
Specificity and the Problem of Accumulated Context
One aspect of this kind of development that does not get discussed enough is the role of accumulated context. When Willison builds a Datasette plugin, he brings years of knowledge about how Datasette’s plugin system works, what patterns are idiomatic, what the common failure modes are, and which abstractions are load-bearing. The AI can generate code quickly, but it is his understanding of the target system that makes the generated code useful rather than plausible-looking garbage.
This is why the experience of “AI let me build eight years of backlogged ideas” is not evenly distributed. It correlates strongly with domain expertise. A developer who deeply understands their problem space can evaluate and guide AI output efficiently. One who does not has a harder time telling good output from bad, which means more debugging, more iteration, and less of the speed benefit.
For me, working on Discord bots and bot infrastructure, this pattern is familiar. When I ask Claude to generate a slash command handler, I know immediately whether the permission model is correct, whether the interaction response timing is going to cause problems, and whether the error handling matches what the Discord API actually does. That knowledge is the multiplier. Without it, the code might look correct and fail in production in ways that are slow to diagnose.
The Shift in What Is Worth Building
Where Willison’s observation becomes most interesting is in the category of projects that cross the threshold. There is a class of tool that is genuinely useful but whose scope and complexity always made it not quite worth the investment. A custom log viewer tuned to your specific data format. A local search interface for your own notes. A small web app that combines two APIs you use daily in a way no existing tool does.
These projects used to fail the ROI test because the effort to build them exceeded the effort they would save over any reasonable time horizon. Now many of them pass. The calculation has shifted enough that projects which were previously irrational are now rational. That is a real change in what the software ecosystem can look like, particularly for infrastructure and tooling that serves small audiences.
Datasette itself is a good example of the kind of tool that benefits from this shift. It makes SQLite databases explorable via a web interface. The audience for any given Datasette instance is small, often one person. For years, building custom Datasette plugins for specific use cases required knowing Python and the plugin API and having hours to spare. Now the barrier is lower, which means more specialized tooling gets built, which means more people can do useful things with their data.
What Remains Hard
None of this means that software development has become easy in some general sense. The hard parts have moved, not disappeared. Debugging subtle state management issues in an AI-generated codebase is not faster than debugging the same issues in human-written code. Understanding why a generated approach is wrong in a particular context still requires understanding the context deeply. Maintaining AI-assisted code over time still requires someone who can read and reason about it.
Willison has been clear about this in his broader writing. He documents his TIL entries meticulously, not because AI generates them, but because the process of documenting forces clarity. The AI can help him build a tool faster; it cannot replace the understanding he develops by using and maintaining that tool over time.
The developer backlog is getting shorter for people who have developed the judgment to use these tools well. For everyone else, the backlog is filling with AI-generated code they do not fully understand, which is a different problem from the one they started with. Willison’s eight-years-to-three-months story is genuinely encouraging, but it is worth being precise about what made it possible: not just the AI, but the accumulated expertise that made the AI’s output usable.