Some thoughts after shipping a project 95% written by Claude

I ran this as an experiment. It was a side project I was probably never going to get around to building. I wanted to test the most extreme version of "Let Claude Do the Work" and see where it got to. I avoided plugins and just ran the out of the box Claude Code experience prompting it towards the end goal.

The project isn't 'done' per-say but it is live and online and usable in some sense. With that in mind I wanted to jot down some early experiences.

If you're curious, the 5% missing from the title was mostly me making small adjustments to text or config that would have been quicker to adjust than to ask for.

For some more context, this was a Django project with a focus on minimizing dependencies so no React or other frontend frameworks in the mix.

• Claude loves to write code. Even when it doesn't need to. It would often write migrations rather than use the makemigrations command. They were usually correct but it seems like a waste of tokens.
• Tech debt became spec debt. I wrote a fairly detailed PRD initially based on what I thought the product should do. It was great in getting V1 out but later it seemed to bias the model towards meeting that spec even when we'd deviated from the original ideas.
• UI design wasn't great. I avoided plugins or using any visual tools for this project. Layouts were passable but often crowded or lacking structure. A good chunk of my revisions revolved around this.
• I used the /clear command a lot. I was working things out as I went along with this project. I knew roughly what it should do but found that a clean slate helped back out of a lot of rabbit holes.
  • I've worked on other projects where I leave things in one long conversation. Plan mode and the occasional context compression seem to be mostly okay. Despite that I've found that regularly clearing the context has the added benefit that the prompts need to be clear and self contained which helps my thinking if nothing else.
• It definitely hallucinated but very rarely. I was adding Posthog to the project for event tracking and it called functions with arguments the function didn't have. This seems odd to me given the docs were likely available but once corrected it didn't make the same mistake later.
• The initial back and forth was interesting. I asked Claude to read my spec and work through a plan together. I was strict on not adding external libraries without permission and the process of talking through the plan and refining it was fun. It helped my thinking on the project and, despite the comment on spec-debt above, led to a better implementation.
• It helped a lot that I knew the stack pretty well already. A lot of the choices were between two plausible solutions but there was often a better choice for each. If I hadn't built a lot of similar projects before it may have been a bit of a guessing game.
  • I could have tried asking Claude to weight up the differences, something I might do next time it happens to see what the outcome it.
• I really like making things. This project was on the back burner because the actual code writing part of this project wasn't fun. It's a lot of boiler plate and repetition. Seeing the outcome here gave me joy.
  • Other projects are the opposite. The process of working on the code and getting deep into the problem is the enjoyable part there. This is often more 'technical' projects where part of the outcome is me understanding things more.
• There's still a lot of things you need to consider. A couple of weeks after putting the project live I noticed a slowly increasing number of non-activated accounts. Some bot had caught wind of the sing up form and would sign up 20-50 new accounts every day. Without monitoring and knowing why this was bad this could easily have gone on for months, ruining my sender reputation in the process. There is still a lot of 'engineering' work left to do in the a world where a lot of the 'software' is now written by the computer.
• If its a side project, you aren't going to need multiple instances of an agent running in parallel. I am sure that is useful at scale when you have a backlog full of issues but in reality the first phases of any new project are pretty linear. I certainly wouldn't have seen major gains from running multiple agents at once.

As mentioned, the project is still a bit of a work in progress. I'll post a follow up in a few months to see how my experience changes and hopefully share a link for anyone curious.