There’s a category of project most developers accumulate over time: genuinely wanted, technically feasible, and perpetually deferred because the expected effort never quite lines up with available time. Carrying something in that category for eight years means the math never worked, not that the project wasn’t worth building.
Simon Willison wrote recently about finally building something he’d wanted for eight years, completing it in three months with AI assistance. The framing matters. This is someone who can build things. He co-created Django, maintains Datasette and the LLM command-line tool, and has written more carefully and frequently about working with language models than almost anyone else publishing in public. The barrier was never technical incapacity.
What AI tools changed was not his ability to write code. It was the economics of deciding to start.
The activation energy problem
Software projects have a startup cost that has nothing to do with the end product’s complexity: the cost of beginning. Setting up scaffolding, making early architectural decisions, writing the boilerplate that has to exist before you can write the interesting parts. For a solo developer with existing projects to maintain and limited time, this startup cost is often enough to keep something in the drawer indefinitely.
AI coding tools have changed this cost structure in a specific way. They haven’t eliminated startup costs, but they’ve shifted who bears them. You can describe the shape of what you want and get a working scaffold in minutes. The choice of whether to use SQLite or PostgreSQL becomes an experiment rather than a commitment, because you can prototype both paths quickly enough to compare them with real data. The boilerplate you dreaded writing generates itself in seconds.
This is distinct from raw coding speed. Research on AI developer productivity tends to focus on tasks-per-hour metrics. GitHub published findings in 2023 showing Copilot users completed tasks 55% faster on average. The efficiency gain is real, but that framing misses the more important change. A 55% speedup on code you were already going to write does not cause the project that was never started to get started.
The threshold effect matters more than the rate effect. A weekend project that realistically requires six weekends stays in the drawer. The same project at two weekends has a different calculation entirely. That shift in activation energy is what turns eight years of wanting into three months of building.
What this development mode looks like in practice
Having built increasingly complex Discord bot infrastructure and tooling with AI assistance over the past couple of years, the pattern Willison describes maps closely to what I’ve found. The workflow involves directed generation rather than delegation. Not “write me a bot,” but more granular: describe the interface contract for a specific service, generate an initial implementation, then shift into review-and-edit mode. The AI handles the tedium; the developer handles the decisions that require understanding the system’s actual constraints.
Willison has written about a related distinction, separating proper AI-assisted development from what Andrej Karpathy called “vibe coding” when he introduced the term in early 2025: the practice of accepting AI output uncritically and shipping without deeply understanding what it does. The two approaches produce very different results.
In the deliberate mode, where the developer uses AI as a capable draft author but remains the architect and reviewer of everything that ships, the AI-generated first draft is a starting point for engagement, not a finished product. The developer who reviews carefully gets code comparable in quality to code they would have written themselves, arrived at substantially faster. This is not a passive relationship with the tooling. It requires genuine interrogation of the output, which in turn requires enough domain knowledge to know what questions to ask.
This matters for deferred projects specifically, because they often get deferred for reasons beyond raw time. Holding the full shape of an ambitious system in your head while writing every line of it is exhausting in a way that reviewing and directing is not. AI assistance changes the character of the work, not just the speed. The cognitive load distribution shifts in a way that makes sustained effort on ambitious projects more tractable.
What eight years actually means
A project conceived eight years ago would have been sized against the technical context of 2017 or 2018, before the transformer-based model revolution reached developer tooling in any practical sense. Before GitHub Copilot, before Claude, before any of the current generation of AI coding assistance. Whatever Willison wanted to build, he was calculating its cost against the capabilities and time budgets of that era.
Projects deferred in that period often stayed deferred even as tools improved incrementally. Build tooling got faster, type systems improved, frameworks matured. But the fundamental cost structure of building something ambitious as a solo developer or small team didn’t change discontinuously. One person could still only move so fast, and ambitious projects require sustained momentum that’s difficult to maintain across months of evenings and weekends.
What changed from 2023 onward was not gradual in the way that build tool improvements are gradual. The capability of AI coding assistance crossed thresholds. Projects that used to require dedicated multi-year effort became tractable in months. The gap between a project worth starting and one that gets started narrowed substantially for developers who learned to work with these tools well.
Willison is a useful bellwether here specifically because of his willingness to document his own process in detail. His writing on AI tools over the past three years traces someone genuinely working out how to incorporate these capabilities into serious software development, not just experimenting with demos. When he reports completing an eight-year project in three months, there’s a body of documented methodology behind that number.
The quality question
There’s a real concern about what this development mode costs in code quality: whether understanding gained through review runs deep enough to support long-term maintenance. The concern is worth taking seriously.
The answer depends heavily on review practice. Code that passes through an AI-to-developer pipeline without serious engagement is often brittle where it looks solid. The surface is coherent but the seams are weak, because the developer doesn’t know where the seams are. Code where the developer has genuinely interrogated every generated section, pushed back where something doesn’t fit the actual system constraints, and rewritten the parts that are wrong tends to be about as good as code written from scratch.
The review process is faster than authoring from zero; that’s where the efficiency gain accumulates. But review is not free, and treating it as free produces the quality problems that make people skeptical of AI-assisted codebases. The discipline required is different from traditional solo development, not lower.
Willison’s consistent position across his writing is that the quality ceiling is set by the developer’s judgment, not the AI’s generation quality. A careful, experienced developer working with AI gets careful, well-considered code. A developer who delegates without engaging gets the problems that implies. This doesn’t resolve every concern about AI-assisted development, but it does locate responsibility clearly.
What shifts when the drawer empties
If projects deferred for years are getting built now, the question worth asking is what they are and what they add to the ecosystem. The projects that sat in the someday drawer weren’t all small. Some were deferred precisely because they were ambitious, requiring more sustained effort than any realistic side-project window could support.
Solo developers and very small teams are shipping tools and libraries with the feature depth and structural quality that used to require sustained team effort. This is becoming visible in the open source ecosystem over the past year in a way that’s difficult to attribute to coincidence. Something has changed about the distribution of what gets built.
The implications run beyond individual productivity. A generation of projects that would have remained in the idea phase are shipping instead. Some of them will be valuable. Some will fill gaps that larger organizations had little incentive to address. Some will be the foundation for things we haven’t anticipated yet.
Willison’s three months is one data point in a pattern that will keep producing data points. The projects deferred for eight years weren’t all deferred for the same reasons, but a significant number were deferred because the math on solo development didn’t work. The math has changed.