Vibe coding is easy – Production ready is hard | karotammela.fi

AI has made the entry point to coding ridiculously easy. Tools like Lovable and various "vibe coding" platforms are fantastic because they bridge the gap between technical skill and visible results. You can describe an idea on a whim and, moments later, you have a prototype or at least a semi-functional product in your hands.

But there’s a catch. If you settle for mere vibe coding, you quickly realize you’re building disposable software. It’s fun for tinkering, but when an application needs to handle actual payments, manage complex data relationships, or scale properly, a good "vibe" and a pretty interface aren't enough. Beyond the risk of endless bugs and vulnerabilities, AI cannot yet replace the necessity of human architectural thought and planning.

My own path has involved plenty of this "YOLO mode" experimentation. I’ve learned the hard way that letting an AI simply fill in lines without a clear plan—the autocomplete trap—lands you in a swamp very quickly. You end up spending hours debugging a house of cards: an application that looks functional on the surface but begins to collapse the moment you try to expand it.

A mockup is not production code

I still use vibe coding, but I treat it as a deliberate part of a larger process. "Vibing" is an excellent way to build quick UI mockups. I might discuss the visual direction with an agent and polish the interface until it’s aesthetically pleasing. Even here, the agent acts as a capable CSS writer, but it doesn't truly "feel" how the design translates to a human user experience.

Once the mockup is ready, I move it to a dedicated "plans" folder. This is the crucial step: I clearly mark it as a code example only. I strictly forbid my coding agent from pushing it to production as-is. Why? Because it lacks the necessary data relationships and underlying logic. It is significantly more efficient to build authentic functionality in one go on top of a solid plan than it is to try and shoehorn complex backend logic into a hollow, pretty shell.

Directing the Agent: Implementation Plan and Progress

Perhaps my most important lesson has been learning how to stay in the driver's seat. I constantly maintain "implementation plan" and "progress" files while working on a project. These serve as the map and compass for the coding agent. When I switch tasks, the agent reads these files and knows exactly where we are in a matter of seconds. Typically, at the end of a task, I ask the agent to update these files, after which I review them personally before moving to the next phase of the project. This is essential for me also because I might work on three different projects simultaneously, and I need to keep track of the state of each.

When working on a domain that is new to me, I utilize a "double-check" system. I use Gemini Pro for validation: I feed it the code produced by the agent and ask for feedback on implementation alternatives and code quality. I might spend an hour or two in these conversations, diving deep into a new technology or library that Gemini suggested. I then port those insights back to my coding agent (Kilo Code) as refinements. This doesn't just ensure quality; it serves as my personal coding school. I am constantly learning the logic behind technologies I didn't fully understand—or even know existed—fifteen minutes prior.

Three hours from idea to production

I wanted to test this controlled workflow when I set up the first production version of my own site. I set a three-hour time limit for myself. I was able to estimate the time fairly accurately because I had already built the necessary components in previous experiments. That window included everything:

• Buying the domain, configuring DNS in Cloudflare, and setting up the GitHub repo
• Database configuration
• Actual coding and "training" the AI gatekeeper
• Created first production versions of the pages and contents
• Integrating email services for forms
• Deploying to Vercel, importing .env files, and assigning the domain

Out of scope was this blog section contents, setting up web analytics and cookie consent banner.

My time limit was pretty accurate. It was +/- some minutes to the three hours I set. The only thing I did not do was write the content. I used a separate agent to generate the content, and I edited it manually. I am of course still working on the content, but I am happy with the progress and outcome for the first version.

The CI/CD pipeline is now a routine part of my process. My tech stack is largely established, but because my hunger for knowledge feels bottomless right now, I am constantly testing new things, evaluating different LLMs, RAG and optimizing token costs.

My next big step is to push automation even further. My goal is to build a system where production error logs are read automatically, and an AI agent suggests or even implements fixes immediately. Technically, this isn't a massive hurdle anymore, but automating hotfixes requires significant guardrails and testing experience before I’d trust it in a live project. I need to build a sandbox environment first to train this process safely.

The journey from vibe coding to this point has been fast, but in the age of agents, it feels like I am constantly running ten steps behind the curve. A couple of months is a long time now; in that window, dozens of useful open-source projects emerge, and better models arrive almost daily. On top of that, I am still catching up on the technical debt I accumulated over the first forty years of my life.

I will likely never become a "coder" in the traditional sense of the word. Instead, my main goal is to create the methodologies that allow me to harness agentic coding safely and efficiently for real-world solutions.