Vibe Code: From Zero to Production in 6 DAYS | The M.Akita Chronicles

SUBSCRIBE TO THE NEW NEWSLETTER: The M.Akita Chronicles READ THE BLOG VERSION: Blog LISTEN ON SPOTIFY!! Podcast

–

On February 10, 2026, I posted the tweet above, just throwing out there something that had been on my to-do list for years, ever since I was publishing videos on YouTube. I never did it because I hate HTML/CSS, and having to build an email template was enough to keep me from starting. On top of that, doing yet another newsletter, which is just a boring list of links, didn’t motivate me.

But that day I was already wrapping up my second vibe coding project, FrankMD, and I think I figured out the main tricks and the methodology to build a complete product the right way. So a bunch of ideas started popping up. I dumped them all into this little document.

I thought: what if I vibe coded not only the newsletter system’s code, but also had part of the actual content generated by AI in a quirky way, in the form of commentators: me and a robot? And, of course, with Hitchhiker’s Guide in mind, it had to be MARVIN, or rather, “M.Arvin” (so nobody hassles me about copyright).

Obviously, there would be a weekly email version and an archive blog. But since we were going all in, why not rewrite the whole newsletter as a podcast script? And since Qwen3 TTS recently came out, open source, why not train a LoRa with my voice (obviously, I have hundreds of hours of my voice on YouTube) and put together a fully automated podcast?

Finally, one of the things that would demotivate me is building a traditional Web Admin and having to log in manually to register news links and my comments. I knew I’d get lazy and, at some point, burn out. There was only one solution: build a smarter bot I could talk to via DISCORD. That way I can quickly jump in, whether from my PC or my smartphone, without having to log into a separate system or anything. I already chat with people on Discord, so the friction would be zero.

So:

• Marvin Bot to manage all the content (the stuff I send in and the automated stuff, with comments and everything else)
• An X.com monitor to check what I posted and grab it for the newsletter. Including the replies I give, which will become Q&A!
• Newsletter website to subscribe, unsubscribe, etc
• Blog for newsletter archives and podcast transcripts (also with terms of service and privacy — yes, I’m LGPD compliant!)
• Automatic voice generator and podcast assembler that uploads automatically to make it available on Spotify
• And also blog and email templates, with light and dark theme versions.

You, an experienced programmer, without AI, how long would it take you to build all of that?

Well, I started on February 10. I finished everything on Sunday, February 15. And today, the 16th, the production jobs ran for the first time, which generated the newsletter, blog posts, podcast, Spotify upload, email delivery.

And it wasn’t done the crappy way every amateur vibe coder does it:

Rails folks must be surprised: a project with a 1 to 1 test ratio! 1 line of tests for every 1 line of code: 100% coverage. And that’s without counting a separate full end-to-end integration project (which I used to make sure production would be flawless).

All the strategies I’ve learned over the years putting projects into production: security, scalability, durability, delivery guarantees without spamming duplicate emails, etc. I’ll see later if I write more specific posts about some of the technical tricks.

I’m not going to open source this project. I built it 100% custom for me, my workflow, and my style. It’s not hard for another competent programmer to do the same thing with vibe code: if I pulled it off, anyone can. So just don’t be lazy about thinking and doing. Honestly, I don’t get how tech YouTubers still aren’t launching 1 complete project in production, per video, for everyone to test and watch.

The screenshot also doesn’t show the Qwen3-TTS server, which produces audio. That one is much simpler, a PyTorch server. Here I actually used Python. The most important part is the fine tuning of the model to generate voices exactly the way I wanted:

The blog is all Hugo/Hextra, same as this one. And my bot publishes there automatically.

M.Arvin Bot

M.Arvin has a personality I spelled out exactly the way I wanted. And it’s a Discord bot, so my workflow looks like this:

I just need to send a link with my comment (the same way I’d do on X.com), or I can post directly on X and it’ll pick it up the same way. Then it fetches the content, writes a little summary, does a small fact-check, and M.Arvin generates its own comment on top of mine.

I programmed it to respond to a bunch of commands to make my day-to-day easier. This is just a small part of it:

Here’s an example: I have control over how much AI it’s using (it’s pretty cheap):

Deployment

In this post I’m not going to go into too much detail, but one thing I spent a lot of time on, going through several discussions and versions with Claude Code, was the infrastructure architecture. And in the end it managed to give me a Deployment Guide that I was able to follow all the way through, knowing at a minimum it’s set up the way I would have done it myself if I’d built everything alone:

No software is guaranteed to be 100% perfect; this one shouldn’t be either. Even with me reviewing for days, going through every step multiple times, there’s always some bug I didn’t anticipate. I “think” that, at least, everything I know usually causes problems in production, I “think” I managed to cover satisfactorily. If it were a human team, I would have pushed it to production in a worse state than what I reached with Claude.

Everything I could protect with Cloudflare, I configured. Every good practice for email/mailing, I followed. Every precaution against accidents I took (every deploy automated with Kamal) and every subscriber’s email was encrypted with AES-256 in the database (even if they leaked by accident, the user data doesn’t leak). I didn’t implement profiling, cookies, or tracking pixels, nothing. Privacy was the focus.

Everything I could reduce costs on, I reduced; after all, I’m paying out of pocket. So things like the RunPod GPU for generating the audio are serverless. I only spin it up at the moment of generation; it runs the whole process and then the machine shuts down. The server is all organized into a lightweight Docker image. All the AI models live on a separate network volume.

Process Spoiler

Later I plan to do a bigger post about my methodology, but it’s very simple: treat Claude Code/Codex like a hard-working human programmer — one who’s going to make lots of mistakes, but knows how to obey super explicit, direct, clear, unambiguous orders. My role is product manager, Tech Lead, or QA. It has to be all THREE roles.

In total, Claude Code made 201 commits. But these aren’t normal commits; I figure that in a normal project with humans, each one would have been roughly 150 Pull Requests.

Question for you folks doing sprints on real projects: how long does it take to get 150 user stories/bug fixes approved and in production on your actual project? How many user stories can you get done and approved (with QA and everything) in ONE week?

Here’s an example of a commit/“user story”:

When I was around commit 50, I was already thinking: “It works already!”* That’s the stage where every content creator (who has never actually put real projects into production) would already be posting, saying: “I vibe coded it in 2 days”. In fact, in 2 days I already had the bulk of the functionality ready.

The other 4 days were:

• 1 day for production deploy (when everything is planned ahead of time, all the contingencies already thought through, it’s easy).
• 3 days just testing, writing automated/integration tests, generating and regenerating, exercising every step of every part, multiple times, and making adjustments, refactors, or even throwing away entire pieces to change them, because the tests showed it was worth it.

That took from commit 50 to 200! And that’s the part every vibe coder skips. To be fair, it’s the part anyone, with or without AI, would skip. And that’s why projects always go wrong and end up in production full of errors and obvious security holes.

Even after asking Claude Code to review security best practices and test coverage, multiple times. Then I opened Codex and asked it to do the same thing, and it still found more security holes and more missing tests, multiple times. Even after both of them did these checks several times, I still found more holes on my own that I had them fix. At no point was either of them able to find “EVERYTHING”. Nobody can, not even AI.

Conclusion

Vibe Coding the right way has only one path: Extreme Programming!

Yes, all the “boring” and “bureaucratic” things every developer hates doing are what guarantees the AI will give you back a result acceptable for production:

• Pair Programming: you need to tell the AI to plan first and spell out exactly everything it’s going to do, BEFORE starting. I review, I tweak, and only when I’m satisfied do I let it go. I watch every single thing it does and, at the end, I tell it to fix whatever I think it missed.
• Test-Driven Development: every feature must come with unit tests. Every bug fix needs regression tests.
• Continuous Integration: every time it finishes implementing, you need to run the CI script to see if anything broke somewhere else. More than that: on the master branch, there are only commits with passing tests. I can revert at any point and the project runs.
• Small Releases: I really liked this about Claude, even if I end up forgetting to tell it to commit a task and send it off to do another one, in the end it doesn’t do that ugly git add . thing — no: it separates into 2 commits and describes each one the right way. On top of that, I pushed to production on Friday, and kept going Saturday and Sunday testing integration locally and in the production environment, to make sure there’s none of that “it only works on my machine” stuff.
• Coding Standard: I started with the bare minimum of technical requirements, but during development I had it refactor my way over and over again.

Those are the main tasks that need to be done. Let me get ahead of it: “Spec Driven Development” isn’t totally useless, but the structure doesn’t matter: it’s your text that counts.

It’s the same thing as User Stories. Big deal, you wrote “As the end user, I want that when I type X…, the system responds with Y”. The format is NEVER important. What’s important is HOW you wrote what goes in the middle. If you can’t write, the AI won’t know how to respond to you the way it should. I’ll do another article just to show how terrible all of you are at writing.

The message is simple: Vibe Code works, in part.

What actually works is “Senior Agile Vibe Coder”

I’ll ask again: how long, without AI, would it take you to produce 150 user stories/bug fixes, in the scope I outlined at the beginning? All the way to production with everything tested? I doubt it would be in 6 days like I did it.