I built this site over four days, in conversation with Claude. I described what I wanted, Claude wrote the code, I reacted to it, and we went round again. It worked. The site got good.
Then something felt off. I couldn't say what. Nothing was broken, nothing looked wrong. So I asked a question I hadn't thought to ask before: had it actually read my project brief?
It hadn't. Not that day, and not for a while. It had been working from its own notes about my brief (a summary, mostly accurate) and building against the summary.
What I couldn't put my finger on
The advice I was getting was good advice. That's what made this hard to see. It just wasn't always advice about my project. It was advice about a project like mine, and that's a difference you can only catch if you're holding the original document.
I wasn't holding it. It was in a chat window from day one.
What had already gone wrong
An hour before I asked the question, I'd had three sample journal posts deleted. I wanted to start my journal from scratch with my own writing, which felt reasonable.
My brief required exactly those three posts as a deliverable. Neither of us knew. I asked for the deletion, Claude carried it out efficiently, and the requirement it broke was sitting in a document nobody in the room had open.
Being right about my hunch felt good for about four seconds. Then it stopped, because if this had slipped past me in an hour, I had no idea what else had slipped past me over four days.
Why I didn't notice
Everything I was handed explained itself. It cited the files it had changed, gave reasons for its decisions, admitted trade-offs, and flagged its own uncertainty. It read like competence.
And I treated reading like competence as being correct.
That's the actual mistake, and it isn't really about AI. Good work and work that matches your requirements are two different things, and only one of them can be judged by reading it. The other one means going and opening the document.
Four days isn't long enough to get complacent. I managed it anyway.
What I changed
- The brief is a file in the repository now.
docs/brief.md, committed. Any session, any tool, any future me can open the real requirements instead of a memory of them. - I ran a clause-by-clause audit. Every requirement marked done, partial, or missing. It found three things I'd have shipped without noticing, including a page-transition feature whose CSS was written but never actually switched on.
- I re-anchor at the start of each session. Every new conversation begins with a summary of the last one, and summaries drop things quietly.
# the brief now lives where the work can be checked against it
git add docs/brief.md
git commit -m "Add the project brief to the repository"What I'd tell someone starting out
I'm early in this. I don't have a general theory about working with AI, and I'd be suspicious of anyone claiming one this year.
But I have one specific thing. The risk isn't bad code. Most of what I got was better than what I'd have written alone. The risk is quieter: work that's good in general and wrong for you in particular, delivered in a tone that gives you no reason to look closer.
So keep the thing you're being measured against somewhere it can be checked, and check against it on a schedule rather than when you happen to feel uneasy.
I got lucky. My unease arrived before my deadline did.