Most developers have a list. Projects they have wanted to build for years, tools that would scratch a real itch, automations that would save time every week. The list grows; the projects sit. The obstacle is rarely capability. Building them requires a sustained block of focused time that is hard to carve out alongside full-time work, open source maintenance, and the general entropy of a life.
Simon Willison’s recent post puts numbers on this. Eight years of accumulated projects. Three months to build them, with AI as the primary coding collaborator. Willison is a credible narrator here. He co-created Django in 2003, has maintained Datasette for years as a tool for exploring and publishing SQLite databases, and has been one of the more careful public voices on what LLMs are genuinely useful for in day-to-day development. He does not hype AI carelessly. When he says something changed, it is worth examining what.
The Bottleneck Was Never Capability
Those eight-year-old projects were probably buildable by any competent developer with a focused week. The problem was the activation energy required to begin.
When you are already a working developer and you want to build something in a domain adjacent to your main expertise, friction accumulates quickly. A Python developer building something with a polished frontend has to navigate JavaScript tooling, CSS layout, build systems, and framework choices before writing a line of product logic. Each of those is learnable; the sum cost makes a personal project feel far larger than it is.
AI tools compress that friction. The models are not always correct, but the iteration loop is tight enough that being wrong costs little. You describe what you want, get working code that does roughly the thing, read it, fix what is wrong, and move forward. That loop, repeated across an afternoon, covers ground that used to take days.
Willison has been systematic about documenting his own approach. His llm CLI tool, developed over the past few years, lets you run language model queries directly from the terminal, pipe output into other tools, and store conversation history in SQLite. A quick invocation looks like:
# Ask a model and get output directly in the shell
llm "write a Python function that parses this log format: ..."
# Pipe output from other commands in
cat error.log | llm "what might cause this?"
# Use a specific model
llm -m claude-3.5-sonnet "refactor this for readability" < module.pyIt is a developer tool built for his own workflow, and the design reflects that. He has written about using it for everything from quick code generation to data exploration tasks that would otherwise require constant context-switching between tools.
The Shape of the Loop
The practice Willison and others have converged on is not “tell the AI to write the whole thing.” It is closer to a tight feedback loop: describe a component, review the output, ask for revisions, run it, observe what breaks, describe the breakage. The human role shifts toward specifying intent and exercising judgment about what comes back.
This resembles how senior developers work when collaborating with junior engineers. Less time writing, more time directing, reviewing, and making architectural decisions. The code requires understanding; you cannot ship what the model produces without reading it. Reading is faster than writing, and for projects that have been sitting in a backlog for years, that difference matters.
Where this works well is precisely the situation Willison describes: personal projects with no legacy codebase, no team, and flexibility on implementation choices. The constraints that complicate AI-assisted development in large production systems, consistency requirements, testing discipline, code review standards, do not apply the same way when you are the only person on the project and shipping at all is the goal.
Ownership and Understanding
The question that tends to come up in discussions like this is whether it is really your project if an LLM wrote most of the code. The framing is mostly unproductive, though it points at something real.
Ownership in software has never been purely about who typed the characters. Developers copy Stack Overflow answers, paste library examples, and adapt documentation code constantly. The criteria that matter are whether you understand what you shipped, whether you can maintain it, and whether you can explain the decisions in it. AI assistance changes the input mechanism; it does not change those criteria.
What it does change is the relationship between domain expertise and shipping velocity. A developer who deeply understands what they want to build gets further faster with AI assistance than someone who is still working out the problem. The AI is better at filling in implementation details than at knowing what to build. That distinction matters more now than it did when all implementation had to originate from the developer.
An eight-year backlog represents a collection of well-understood problems. The developer knew what they wanted. The obstacles were time and incidental complexity. That is the category where AI assistance works best.
Where It Falls Short
The same properties that make AI assistance effective for personal projects make it risky in specific contexts.
Security-sensitive code is one area where the fast iteration loop can be dangerous. Models generate plausible-looking code that contains real vulnerabilities, and those vulnerabilities often look correct on inspection because they are subtle. Authentication flows, input validation, cryptographic operations, and anything touching session management deserve skepticism proportional to the risk. The model has no context about your threat model or your deployment environment.
Performance-critical code is another. AI-generated code tends toward correctness over efficiency. For most personal projects that trade-off is acceptable, but if performance is the point, the generated code often needs significant rework that the model cannot do reliably without concrete benchmarking feedback to work from.
Long-term maintainability is the concern that matters most for projects that gain traction. A codebase generated quickly with AI assistance is often harder to navigate than one built incrementally by hand, because the abstractions were chosen because they seemed to work rather than because they would be clear to read six months later. That is addressable with active code review, but it requires the developer to do that review rather than treating generated output as finished work.
What Changed
Building Discord bots, I have had a version of this experience. Features that had been sketched out for months, per-channel configuration, conversation memory, background monitoring loops, got built over a few weeks of working evenings with Claude. The bottleneck shifted from writing code to understanding and integrating what came back.
Willison has written extensively on his blog about using LLMs in his development practice, and the pattern across those posts is consistent: focused use for specific tasks, genuine skepticism about limitations, and an emphasis on the developer still being responsible for what ships. That is a different posture than the “vibe coding” framing that has circulated recently, where the suggestion is that understanding the code no longer matters.
What Willison is describing is probably the most honest accounting of what AI-assisted development provides. The models require engineering judgment to use well. What they reduce is the time between imagining something and shipping it.
For anyone sitting on years of accumulated project ideas, that is a meaningful change in what development looks like day to day.