Simon Willison is linking to a confession that’ll sound familiar to a lot of developers right now. David Wilson tallied up what he’s been building with Claude and other AI coding tools: 16+ projects. A Chrome extension here, a dashboard there, some automation scripts, a few web apps.

Here’s the problem: he didn’t actually mean to build most of them.

“Usually the Claude session started with something like ‘write a quick script for X’, and one hour later the result is not a quick script for X,” Wilson writes. Worse, his original problem often isn’t solved either.

Willison, who builds Datasette and writes extensively about AI tooling, finds this “very relatable.” So do I. So might you.

The friction went away, and so did the filter

AI coding assistants are legitimately good at spinning up projects. They’ll scaffold a Next.js app, write your API routes, add TypeScript configs, throw in some tests. In the time it used to take to remember the Vite command, you’ve got a working prototype.

That’s powerful. It’s also kind of a trap.

When starting a project meant wrestling with boilerplate and documentation, the friction served as a filter. You had to really want the thing you were building, because getting started cost time and attention. Now that cost is nearly zero. Got an idea? Claude will have you 60% of the way there before you’ve thought through whether you actually need it.

This connects to something Daryl Cecile wrote about recently in a post making the rounds on Hacker News. Cecile talks about how AI tools have changed the speed of prototyping, making it trivially easy to build things that look polished but might not solve the actual problem you have. The velocity is seductive.

It’s not just about building too much

The deeper issue isn’t project proliferation, though that’s annoying enough. It’s that AI coding tools change your relationship with the code.

When you write something yourself, you understand it. You know which parts are fragile, where the edge cases hide, why you made that weird choice in the third function. When Claude writes it, you don’t. You can read through it, sure. You can probably modify it. But do you really know it?

This matters less for throwaway scripts. It matters a lot for anything you’ll maintain.

The tools are also really good at making things look done when they’re actually 70% done. The UI works. The happy path runs. Then you hit it with real data or a real use case and discover all the places where the AI’s pattern matching produced code that’s plausible but wrong.

We’re all building the same muscle

There’s a skill here that nobody’s really talking about: knowing when to let the AI run and when to write it yourself. Knowing when that “quick script” should stay a quick script, and when you’re about to spend an hour generating code for a problem you don’t have yet.

Some of this is just discipline. Close the AI coding tool and use grep. Write the bash one-liner. Don’t scaffold the full project when a Python script would do.

But some of it is genuinely new territory. We’re all learning to calibrate our sense of “is this worth building” in an environment where building costs so much less. That’s harder than it sounds, because the old heuristics don’t quite work anymore.

Wilson’s post ends with his title: maybe the solution is cancelling his AI subscription. He’s probably not going to. Neither are most of us. But the question behind it is real: are these tools making us more productive, or just more prolific?

Those aren’t the same thing.