What 149 prompts actually look like

I didn't hand-write most of this site. I described what I wanted, read what came back, and corrected it — over and over, for a week. That came to 149 prompts. I went back through the logs to count, because I was curious whether the story I'd tell about the process matched what actually happened.

It mostly didn't.

The tally

Spread across 34 separate sessions. Those 149 prompts turned into 38 commits — roughly four prompts per meaningful unit of work — and somewhere north of two thousand individual actions taken on my behalf: files read, files edited, commands run, pages loaded in a browser to check the result.

More prompts did not mean more progress

Look at July 14: 47 prompts, my busiest day by a wide margin, and it produced 10 commits. July 13 produced 12 commits from 14 prompts.

So my heaviest day was my least efficient one. I remember that day — it wasn't building, it was circling. Small corrections, re-explanations, "no, not like that." The prompt count wasn't measuring output, it was measuring friction. That's a genuinely useful signal in hindsight: when the prompts start piling up fast, that's the cue to stop and rethink the approach, not to keep nudging.

The scaffolding I was proudest of barely got used

Early on I set up a whole supporting cast — specialised assistants for reviewing code, checking accessibility, writing copy — plus a set of shortcut commands for common workflows. I spent real time on it. It felt like the clever part.

Final usage: the assistants were called on 16 times, the shortcuts 6.

What actually carried the work was much duller: a single project file describing the conventions, the structure, and the mistakes I'd already hit. Every session read it first and behaved accordingly. The leverage was in the written-down context, not in the machinery I built around it.

Being asked was better than being obeyed

Thirty-six times the agent stopped and asked me something instead of guessing — usually a fork where two reasonable interpretations existed and picking wrong would have meant redoing the work.

Those were the best moments of the whole build. An assistant that confidently does the wrong thing is worse than useless, because you have to find the damage before you can undo it. I'd rather answer a question than review a mess.

I also cleared the conversation and started fresh 11 times. Knowing when the context has gone stale turned out to be its own small skill.

What I'd tell someone starting

• Write down your conventions before you write any code. It pays for itself in a day.
• One thing per prompt. Bundled requests come back half-done in ways that are tedious to untangle.
• Watch your own prompt rate. A sudden spike means you're fighting, not building.
• Start fresh more often than feels necessary.
• Read everything before it lands. You still own the result.

The tooling I built to make this faster mattered less than the paragraph I wrote explaining what I wanted. That's the whole lesson.