Don't vibe code your config: How I shot myself in the foot
How my mistake vibe coding cost me tons of (important) data (and why I should've known better)
So not long ago I vibe coded an app. It’s not my first, I’ve got a few apps running in production that were 100% written by AI. But this time, I really shot myself in the foot.
I have a friend job searching and I remember tracking all the applications and interviews being extremely tedious during my last search. So I decided to quickly throw together a job application tracker.
The app is a simple CRUD app, something I could’ve thrown together with Rails in a day or so - which made it an excellent candidate for me to test out Claude Code. I actually wrote about using Claude Code to build this app in the story below:
Maybe give the above a read and see if you can guess the problem.
So what’s broken with my app?
My single beta user started immediately using the ap, logging lots of jobs they were applying to.
A few days in I get a question:
Hey, I can’t log in, is something up with the app
I assumed it was a forgotten password problem, and since I didn’t actually set up ActionMailer the forgot password button would be broken.
But I was so very wrong.
In case Ruby/Rails isn’t your thing - this is a screenshot of a live shell on the server. I first looked for the last user in the database. Nothing.
Then I looked for the first user in the database. Nothing.
Then I looked for all the users in the database. Nothing.
I immediately realized the problem and the cause. There’s no data in this database. Which means the database got wiped. How could that happen?
Well the default database in Rails 8 is SQLite (yes, even in prod!)
I thought this was great because I didn’t want to pay for a fully managed database provider for an app with one user. I was even surprsied that my initial deploy to Render resulted in the app working without any configuration at all. A far cry from my experience deploying Rails apps with Kamal.
Well I should’ve been more suspicious. I was so excited from just smashing approve on Claude Code that I didn’t think critically about my database, which really is kind of embarrasing.
If you’re not familiar, SQLite stores the database as a regular file. Without configuration, Rails just dumped the file in the Docker container which was fine until the container restarted. Every time the container restarted, that file got nuked (along with my data).
How am I fixing the app?
Well one option is to just move to Postgres. This is actually my preferred option since I’m familiar with it an Render offers affordable Postgres options. Another (usually) fine option is to use a Docker volume for the file so it persists past the containter, but this won’t work for a reason Render describes very well:
Most importantly, because Render services have an ephemeral filesystem. This means that changes to local files (including SQLite databases) are lost after each deploy. You can attach a persistent disk to preserve local files, but this disables zero-downtime deploys.
I followed the steps in the Render docs to set up a Postgres service and get my app connected. It honestly didn’t take too much time. A simple fix to a catostrophic problem.
Was vibe coding really the problem here?
My take? No. I was the problem here.
Vibe coding is fun and useful, but software engineers using AI tools should really split their usage into two categories:
I’m having fun and shipping slop, it’s okay if it makes mistakes
I’m building something valuable that deserves my human thought
The second category is obviously how I view my usage of AI tools at work. The first category is how I often view small projects I’m hacking around with after work.
Obviously this project ought to have belonged in the second category considering it has a real user depending on it, which is what makes this mistake extra painful. Learn from this mistake, I know I did!
If you’re new to the newsletter, I hope you’ll consider subscribing. If you’re a regular reader, thank you so much for your support. There’s over a thousand of you now, and I’m very grateful that you’re finding value in what I write about AI in software engineering. Do consider joining the several dozen paid members of the newsletter if you’re interested in the full archive of deep dives to stay on top of how fast things are moving.