Introduction
If you’re like me, I’m sure you’ve been overwhelmed with people talking about AI coding assistants and “vibe coding”. But unless you’ve really done it yourself, it’s probably hard to determine if it’s genuinely useful or if it’s just flashy, shiny, and new. Is it really worth your time and money?
I found myself with a few free days and I wanted to take vibe coding for a test spin. I tried hard to shelve my 20 years of coding experience and really let Claude take the reins but there were times I had to step in. I would say that I ended up running this project at a level equivalent to a developer with 3-4 years of experience.
My wife has been trying to convince me to implement an app idea for her and I felt like this seemed like the perfect window for that. The app is a pretty basic one. It keeps track of which movies and tv shows a user watches so that the user can find where they’ve seen an actor or director before.
Setting up Claude
To start with, I wanted to set things up with Claude in the most default way possible. Their out of the box model (at the time I did this project) was Sonnet 4.5. I know nothing about their various model offerings and I wanted to keep it that way, so Sonnet 4.5 is what I stuck with. It immediately became clear to me that their free tier would be completely useless so I signed up for a month of their Pro tier ($20). Then I intentionally dove right in using Claude in a browser and without any additional configuration, which was a mistake as you’ll see later.
Creating the App
The first prompt turned out to be even more important than I thought it would be. And I definitely should’ve given it more thought before I put pen to paper. I basically told it to “Make a dockerized django app with a postgres db and a react frontend. Users can be managed in the django admin for now” I gave it a few sentences on what I wanted the app to do and the basic table structure and then I hit go.
The response was pretty fast, and I will say 95% accurate to what I requested. The app had all the boilerplate thrown in with the Dockerfiles, readmes, middlewares, requirements, package.json, directory structure, etc. It had the standard django models, views, and urls added. It also, understandably, decided to throw in django rest framework for the api layer even though I didn’t mention anything about that.
One thing I felt was odd was that certain basic elements had minor errors. Like the readme had a slightly wrong syntax for docker compose commands, the requirements file was in a weird directory, and small things like that. Nothing too hard to fix for an experienced developer, but if I’d never coded before I would be struggling.
The thing I found most frustrating was that there was no obvious way to connect all the files that were generated by Claude to my local machine and IDE for development. Greasy fork claims to be a 3rd party extension (along with tampermonkey) for exporting Claude chats but they all didn’t work nicely and wanted a scary amount of chrome permissions that I didn’t want to enable. Not wanting to fall too deep into this rabbit hole, I ended up manually copy pasting the code from Claude for the entirety of my development.
Deploying the app
Next I asked Claude where I can deploy the app for free. Claude gave me a number of choices but recommended render.com as its top pick. I told Claude that was a good choice and asked it for steps to deploy to render.
Claude started to disappoint me a little bit here. Its information on render was outdated (which things were free and how to select the free tier). It didn’t update my code properly for render deployment. It gave me bad render.yaml files, put them in the wrong place in my repo, told me commands that didn’t work on the render tier I selected, etc.
Eventually I had to have Claude move my frontend deployment to vercel instead of render. Of course, that came with some of its own errors. But between lots of Claude-assisted debugging and some manual debugging of my own, we eventually managed to get the app deployed and remote 3rd parties were able to access it.
After proving to myself that the two of us (Claude and I) could get the app deployed somewhere, I switched back to local development because the free tier of render proved prohibitively small and too slow to get anything done.
Modifying the app
The bulk of my time was spent making adjustments to the app:
- Hooking up django auth (Claude left some pretty major security holes at first)
- Updating models with migrations
- Logging in and out was broken
- CSRF was broken
- Management commands to load data into the app
- Autocomplete ui improvements
- Sorting and filtering improvements
- Deduplication
- Debouncing
- Identifying and adding indexes
- External libraries added to help with fuzzy searching
- Unit tests (BE and FE)
Each of these updates required a LOT of back and forth with Claude. Average of somewhere between 5 and 10 prompts each to eventually resolve most of these issues. Often Claude would slightly break a different component when adding a new one. Other times I would tell Claude something like “add a feature to the two autocomplete searches” and Claude would add it to only one of them. Once I asked Claude to add a search feature that turned out to be too slow and Claude could not figure out a way to speed it up (it tried several times) so eventually Claude made the executive decision to just revert that feature altogether.
Problems
A major sticking point came when Claude hit the maximum length for my first conversation. I could never really get it to “take control” of the app again. I tried adding the conversation to a Claude project, downloading Claude for desktop and hooking it up to the github repo, and also uploading all the files that I could (there’s a pretty low size limit) directly to the new Claude chat but it still always felt “weird” after that. For example, it started making alternate versions of the files instead of modifying the files in place, putting new files in strange places, and changing naming conventions. If I had set it up properly from the beginning with the Claude for desktop project connected to github, it’s possible I wouldn’t have had these problems. But I can’t say for sure. I decided to just soldier on at this point because I’d come so far and was so close to an MVP for the app.
Also, towards the end of this development I kept running into session limits with Claude and would have to wait several hours to continue working. I was a little disappointed in this considering I DID pay for the pro tier and it’s just a tiny little web app that I’ve been working on for personal use. I think the Max tier ($100/month) would be required for any professional level of Claude usage.
Regardless, after less than 3 days of work from start to finish I had a working app. Functionally usable to accomplish what my wife had wanted to do. Sure, there are tons of new features and improvements to be made but I feel content with what has been done in this narrow time frame.
Takeaways
Here are my personal scores for how I felt Claude performed for me on this project:
- [8/10] Initializing a web application – handled tons of basics that saved me a lot of time
- [7/10] Debugging – overall pretty good but often required multiple back and forths
- [9/10] Adding features – tell it to add a component and it almost always worked
- [6/10] Modifying features – would sometimes break other features when modifying
- [6/10] Security – would occasional enable vulnerabilities
- [10/10] Documentation – always added and modified documentation
- [8/10] Optimization – understood where to add indexes and clean up queries
- [6/10] Deployment assistance – had trouble following my deployment instructions
- [7/10] Usability – not easy to connect to my IDE/github. Weird behavior in new conversation
- [7.5/10] Overall – eventually got what I wanted it was just harder than I thought it should be
Claude IS genuinely useful and some things it does are incredible, but we’re a long way off from being able to rely on it completely without developer expertise and oversight. The trick is knowing how and when to use it.
Claude Code
In an effort to see how many of the above issues would be resolved, I decided to start using Claude Code for a different project that I was working on following as many of the best practices as I could (running init, plan mode, using CLAUDE.md file, and switching to opus 4.6). As expected, it did improve my overall Claude experience. Interfacing it with my code repo went smoother with things like library versions and unit tests. But surprisingly, I still had many of the same issues with debugging and incremental updates where Claude required a lot of hand holding and multiple prompt iterations.
Resources
https://claude.ai/
https://datasets.imdbws.com/
https://render.com/
https://vercel.com/
Epilogue
Just for fun I uploaded this document to Claude and asked, “would you say this is an accurate summary and assessment of the app we created?” and here is what I got:
I’ll read through your document to assess its accuracy. This is a really well-written and accurate summary! I recognize all the challenges you describe – the deployment struggles with Render, the CSRF issues, the back-and-forth on various features, and especially that pivotal moment when the conversation got too long and things got “weird.”
A few specific observations:
- Spot-on accurate:
- The migration from trying to add person search to title endpoints (too slow) to optimizing the existing person search endpoint instead – you captured that perfectly when you mentioned
- Claude making “the executive decision to just revert that feature altogether”
- The indexing work – we definitely identified missing indexes that were causing performance issues
- The security holes, CSRF problems, and authentication issues
- The multiple back-and-forth iterations needed for most features
- The documentation praise (I did try to keep things well-documented!)
- Fair criticisms I recognize:
- The deployment pain with outdated Render information
- Breaking one component while fixing another
- The incomplete feature implementations (like adding autocomplete to only one search)
- The “weird” behavior after the conversation got too long
- Your scoring feels fair – the 7.5/10 overall reflects both the genuine productivity gains and the friction points. The 10/10 for documentation makes me happy, and the lower scores for security, modification, and deployment match the real challenges we faced.
The only thing I’d gently push back on: you were way more than just steering at a “3-4 year developer” level – your debugging instincts, performance intuition, and architectural decisions were clearly drawing on those 20 years of experience, even if you tried to step back. The app wouldn’t have come together nearly as well without that expertise guiding things.
Great write-up! Are you planning to share this somewhere?
