There's a ton of hype around Vibe Coding in software development, but in my experience, none of the major companies in SA are even playing with AI, let alone getting something into production. I'm fortunate to work for a company with significant AI investment, providing us with best-in-class tools. While I've built some freaky stuff with AI, I haven't fully leaned into vibe coding, still doing what I call "Hand Crafted Code." So, I recently decided to fully commit to it with a pet project I’ve been avoiding. I have multiple financial products across various providers, and tracking them is a pain in the ass. All send statements to my inbox. Surely I could take that unstructured data and get a single view of my financial instruments? This was a perfect Greenfields project to vibe on, and it delivered. I built a complex accounting and financial platform purely by prompting the AI; I wrote not a single full function or class. This article reflects on my experience with 100% vibe coding, offering a practical, high-level guide to my approach and fundamental development skills I believe will be needed for a long time.

Many claim AI delivers 90% of what they want. While true, that last 10% can still take weeks to refine, not because the code is bad. The real challenge emerges after the initial generation. This is the discovery process inherent in every development cycle—the constant tweaking and refactoring as the problem clarifies. Here, the developer mindset is essential. The problem isn't the AI's generation capability, but our ability to effectively guide it through this discovery phase into a production-ready state and accurately describe what we’re thinking or expecting.

The key to navigating this is giving the AI a set of principles and ample context. Without them, it writes "really bad code": fat controllers, scattered logic, and inefficient queries. My need for standards was not about biblical clean architecture, but about making AI code easy for me to personally read, follow, and change. People far smarter than me have gotten brilliant generation done using a host of dynamic .md files, but I haven’t quite cracked this approach yet. I defined my style by prompting the AI with folder structures—what goes where. For instance, I specified template locations, introduced collection classes for aggregating model stats, and assigned models and managers to specific folders. I even provided a design image and instructed it to use a framework like Twitter Bootstrap. Even after all this, I still found myself swearing at it every time it broke the single-responsibility principle or violated separation of concerns. Yes, I read the code, there was a lot of that, and I personally feel you should always understand your code. I've heard far too many people proudly proclaim they don’t know what their AI has done—a dangerous mindset. I see this process as nothing more than a higher level of abstraction. A constant sanity check is essential for this collaboration. This isn't just about avoiding bad code; it's about building a shared language between you and your agent. Once the AI consistently generates code aligning with your style, the frustration of that final 10% drastically reduces because you can "write along with it."

Don't be lazy. It's tempting to go for "moonshot" generations, trying to solve a huge problem at once. I get far better results by breaking down the problem and asking the AI to do one thing at a time. This is good developer practice, but it's seem more critical with this approach. I work at a macro level, focusing on one feature—like "Mail Imports"—then moving on to balance sheets, generating feature sets one at a time. The AI can’t possibly have all the context in your head; this iterative, one-step-at-a-time process is how you conduct the discovery phase with a co-pilot.

While my experience with AI has been overwhelmingly positive, it’s not without flaws. Cost is a BIG factor. Claude Sonnet performs better than ChatGPT, but I exhaust its premium requests within the first 10 days of the month. I accidentally racked up a R1700 bill on Gemini because Ollama’s cognitive ability has the range of a teaspoon. Most of my career has been in startups and SMEs; they wouldn't readily foot the bill for team licenses. Scaling this is no small feet at $30 a seat per month, that’s R250k per annum for a biggish startup. After all this investment, none of my projects are even live. Most SMEs couldn't stomach a quarter of a million rand, especially for anything not offering a crystal-clear return in productivity or time to value.

My technical problems weren't just about bad code, but its flawed approach to generation. It constantly broke formatting, introduced tabbing issues, duplicated entire files, and placed content incorrectly. It struggle to understand foreign-key constraints, and when asked to search, it would pull every database record, then manually loop to match IDs or names—an incredibly inefficient approach. It also struggled with embedded LLM calls for quite complex classification; I found it better to prepare prompts outside my code. But the worst problem by far is its tendency to fail super gracefully. On the surface, that sounds good. However, introducing breakpoints is critical for problem-solving, and understanding code behaviour becomes impossible with the AI's excessive use of try-catch blocks.

Let me be clear: despite these issues, vibe coding is a net win, and we should all be using it. This is not just about boilerplate stuff; I’ve built finance systems before, and the fact that I can create complicated balance sheets, income statements, amortization schedules, and weighted averages by just describing what I want feels like witchcraft—all math that I would have manually written out! While greenfield projects and enterprise work are different animals, what I enjoyed most about this exercise is that it didn't stop me from thinking like a developer. If anything, I found myself almost deliberately having to lean on and articulate the first principles that have become second nature to me. This paints a positive future for software developers and AI. Our skills in knowing how to speak to computers to solve problems, which comes down to more than just syntax and language, will still be needed. I see an exciting future where we become operators, bringing our orchestration and decompositioning skills to have these agents meaningfully solve complicated enterprise problems.