The Deferred Project Problem, and What Three Months With AI Actually Looks Like

Every developer carries a list. Not the kind in Notion or a task manager, but the mental inventory of things you genuinely want to build and have never started: the tool that would scratch a real itch, the project that sits at the intersection of three things you care about, the thing you keep sketching in the margins and never quite open an editor for.

Simon Willison, co-creator of Django and the person behind Datasette and the llm CLI, recently wrote about finally shipping something he had been wanting to build for eight years, accomplished over three months of AI-assisted development. The specifics of what he built matter less than what the timeline implies about why it wasn’t built before, and what changed.

The Bootstrapping Tax

The reason most long-deferred personal projects stay deferred is not that the developer lacks the skill. It is that building software has a fixed overhead that compounds with ambition. You need to choose a stack, scaffold the project, implement authentication if it needs users, wire up a database, build a deployment path, and write enough boilerplate that the actual interesting problem becomes visible. For a weekend project, this overhead can consume the entire weekend before you reach the interesting part. For an ambitious tool, it can consume several weekends before you have enough working to know if the idea is even sound.

Simon has written about this before in various forms. His entire Datasette project is built on the premise that there is an enormous amount of interesting analysis locked inside data files that people own but cannot query, and that the bootstrapping tax of standing up a database with a web interface is the main barrier. Datasette eliminates that tax for one specific problem class.

AI tools eliminate a version of that tax across a much wider problem class, but not in the way most commentary suggests.

Not Autocomplete, Something Different

The popular framing of AI coding tools is that they make you write code faster. This is true but it misidentifies the valuable thing. Writing code was rarely the bottleneck in deferred personal projects. The bottlenecks were: not knowing the right API surface for an unfamiliar library, not wanting to read four pages of documentation to do one small thing, having to stop the creative momentum of figuring out the interesting problem to solve an incidental plumbing problem.

AI tools collapse that distinction. When you are building something with Claude or Copilot or Cursor, you can stay at the level of the interesting problem longer. You describe what the plumbing should do; the plumbing appears. You get to keep moving.

Simon’s approach to this, as documented across his blog over the past two years, has been deliberate rather than speculative. He writes tests. He reads the generated code. He treats the AI as a knowledgeable collaborator who needs to be directed rather than a vending machine that dispenses finished software. This distinction matters enormously for whether the output is maintainable.

What Three Months Actually Represents

Three months of steady AI-assisted development on a personal project, by someone with Simon’s level of skill and domain knowledge, is a substantial output. Consider what the arithmetic looks like without AI assistance. Ambitious personal projects tend to move at weekend pace: two or three focused hours, once or twice a week, interrupted by the bootstrapping tax and the context-reloading overhead of picking up a project after a gap.

At that rate, three months of productive time might represent eight to twelve real working days spread across forty weekends. With AI tools compressing the bootstrapping tax and reducing the penalty for context gaps (the AI can be given a summary of where things stand and resume from there), the same calendar period can yield substantially more working software.

The eight years of wanting is equally telling. That is not eight years of active development that stalled. It is eight years of a project sitting on the mental list, occasionally reconsidered and deferred again because the ratio of interesting work to setup work looked unfavorable. AI tools changed that ratio.

The Datasette Parallel

This is the same insight that motivated Datasette. Simon recognized that the friction between “I have a CSV file” and “I can explore this data in a browser” was almost entirely bootstrapping tax: database schema, import tooling, query interface, web server. Datasette eliminated it by handling all of it with sensible defaults, leaving the user to do only the interesting work of the query.

The llm CLI, his tool for interacting with language models from the command line, follows the same pattern. Rather than writing a Python script that imports the Anthropic or OpenAI SDK, handles streaming responses, manages API keys, and serializes conversation history, you run:

llm "explain this error" < traceback.txt

Or pipe it into a chain. Or store the conversation and continue it later. The bootstrapping is gone; the interesting work remains.

The pattern across all of Simon’s work is that the best tools are the ones that make the ratio of interesting work to setup work as favorable as possible. His three-month AI project is that observation applied to his own development practice.

The Sustainability Question

The reasonable concern about AI-assisted development at this pace is code quality. If you are generating more code faster, are you generating more technical debt faster? In Simon’s documented practice, the answer appears to be no, because he applies the same discipline he would apply to any code: reading it, testing it, understanding it before committing it.

This is where the “vibe coding” framing that has become popular does a disservice. Vibe coding, as Andrej Karpathy originally described it, is accepting AI output largely without review, leaning on iteration rather than understanding. It works for throwaway prototypes and small scripts. It compounds dangerously in anything you expect to maintain.

Simon’s approach is closer to what you might call directed generation: using AI to produce a first draft of each component, then reading and revising that draft with full understanding of what it does and why. The AI speeds up the first draft. The developer still owns the architecture.

Context windows have made this more tractable. Claude’s 200k token context and Gemini’s 1M token window mean that more of the project can be in scope simultaneously, reducing the risk of the AI generating something that contradicts a decision made in a different file three days ago. For a three-month project of moderate scope, it is now plausible to keep the entire relevant codebase in context during a working session.

What Gets Built Next

The broader implication of the “eight years, three months” arc is that a category of software that was previously economically unviable for individuals to build is becoming viable. Not startup-scale software, but ambitious personal tools: the niche data explorer, the workflow automation that is too specific for any general product to solve, the integration between two things that nobody has bothered to connect because the market is too small.

Simon has spent years writing about the potential of small, sharp tools that do one thing well and compose with other tools. The shift is that those tools are now within reach for a single developer with a long weekend and a clear idea, rather than requiring a dedicated side-project month or a team.

The deferred project list is not going to empty. New ideas will accumulate faster than they ship. But the calculus has genuinely changed, and what Simon built in three months is a data point worth sitting with: eight years of wanting, three months of building, something finally shipped. The interesting question is what you have been putting off that belongs in the same category.