How AI-assisted development is transforming the way we build software
The name “vibe coding” might sound like another tech buzzword destined for the graveyard of forgotten jargon, but the process itself? That’s not going anywhere. In fact, it’s about to become as essential to development as version control.
Since starting what people call “vibe coding” in 2024, after using AI to assist with coding since 2023, what I’ve discovered has been nothing short of transformational. At times, it’s been along the lines of rainbows, unicorns, and butterflies – absolutely amazing what this technology can accomplish.
Here’s what I’ve learned about agentic coding (my preferred term): you want to start from the premise of what you wish was possible and work from there. The best vibe coders aren’t the seasoned veterans – they’re the people just starting out who don’t know the syntax, don’t know the “rules,” and don’t know when something should technically be impossible.
Conversely, I find that senior developers are the worst at using vibe coding because their experience handicaps the capability of what the AI can do. Their own belief of how something should work creates limitations. It’s this idea that because they know, they don’t believe there is another way. This reminds me of a fascinating study involving clinical diagnosis. Doctors were correct 76% of the time on their own. When AI could ask questions and make diagnoses independently, it achieved 91% accuracy. But when doctors and AI worked together, the doctors barely improved – just a 2% bump to 78%.
The reason? I believe the clinicians’ experience actually hindered the AI’s capabilities. Their knowledge of what “shouldn’t” be possible created artificial limitations.
The number of times I’ve been working on something, thinking “this is impossible, it can’t be done,” only to type it in and watch it work flawlessly is mind-boggling. I’ll look through the generated code afterwards, absolutely amazed at what the AI accomplished. This is the essence of what I call PIM coding: Prompt, Iterate, and Modularise. While I’m not a fan of the “vibe coding” name, the concept is revolutionary.
Let me clarify what I mean by “vibe coding.” It’s a term I use for people who are new to AI coding and are not ready to use it in full production environments. They’re getting the hang of how to work with AI – starting in Ask/Chat mode, then progressing to agent mode, and finally understanding how to guide and work with AI to go into YOLO modes. From there, they transition to using this in production environments outside of learning. That’s when a person moves from vibe coding to agentic coding.
I believe the majority of people who put down vibe coding or have had bad experiences is because they use lower-level, non-enterprise coding agents like basic OpenAI models or Codex. These agents aren’t ready for development-level work and cause people to have bad experiences, making them resistant to vibe coding or agentic coding in general.
As I’ve developed more codebases and rolled out more features, I know for certain this isn’t a passing trend. This is going to become a necessity in every company. Codebases will need to be structured so AI can quickly gain context and make adjustments without breaking existing functionality. Standing here with my experience, I can say with confidence: if something isn’t working, it’s because of something I’m doing, not a limitation in the AI’s response.
Let me give you an example. Early in my AI coding journey, I was working on a login problem. I’d tell the AI “the login isn’t working” – something any human developer would understand. But through trial and error, I learned I needed to be specific: “When I put my email address in, enter my password, and click login, my information is cleared and the page reloads, but I’m not logged in.” That specificity resulted in the AI’s famous response: “Oh, I see the problem now. I see the issue.” And it resolved the problem immediately.
I’ve discovered that spaghetti code – overly complex, tangled code – occurs when I try to “prompt through” problems instead of rolling back to where the issue originated. I’ve learned never to prompt through something. Instead, I figure out where the bug started, roll back to that point, and with 20/20 hindsight, tell the AI to avoid that approach.
It’s like a friend of mine who does crafting. She’ll be knitting something together, hit the wrong stitch, become aware of it, and have to unravel hours, days, or even weeks of work to start from that point again. In AI coding, I’ve learned that my greatest enemy is the belief that I can prompt through anything.
The first time this happened, I lost a week’s worth of work and had to roll back. What should have taken hours to resolve properly stretched into days of futile prompting. It’s painful to roll back – the sunk cost fallacy plays a major part in becoming good at agentic coding. You need to learn when to cut your losses, fold that prompting hand, and start again.
Now when I’m debugging, I’ll work through the issue, prompting three, four, five, six times – adding debugging, console logging, figuring out what’s wrong. Once I get the solution working, I’ll ask the AI: “What was the problem? How did you fix it? If I run into this again, what do I need to say to resolve or prevent this issue?” Then, and this is crucial, I roll back to when the bug started and paste in that response. If I kept all those iterative prompts trying to fix it, with the AI saying “aha, I found the issue” or “I’ve got this fixed,” I’d leave a lot of additional uncertainty and spaghetti code in my project.
When I first started AI coding, I felt it was necessary to be strict about what to do and how to do it, otherwise it would crawl through and change other code, breaking peripheral features. Over time, I’ve learned to be structured with my code and strict with guardrails about what it should not do, but allow it to reach its own conclusions. When I tell AI exactly how to do something, I impose my own limitations on what’s possible, handicapping the process and creating situations where the code doesn’t work as well as it could. Instead, letting the AI work through the process and reach its own solutions yields far better results.
The ability to code with an agentic process is changing everything. I believe that unless there’s a specific reason otherwise, all codebases should be structured to be managed with agentic coding in the future, and that future isn’t years away, it’s months.
There are exceptions. Some codebases can’t be managed this way because agentic coding prefers the latest standards and doesn’t like working with legacy systems. Code written in COBOL for banking systems, for example, still requires senior programmers who understand those legacy foundations.
But if you’re willing to eliminate legacy wastage, and I’m referencing an AWS article where Amazon upgraded tens of thousands of production applications from Java 8 and 11 to Java 17, taking 30 minutes to an hour per application and saving them $260 million dollars in annual cost savings, the benefits are extraordinary. Legacy wastage is real and expensive. You might not realise you’re paying accelerated hardware costs because of memory leaks, outdated looping systems, or inability to use the latest security, processing, or caching structures.
Companies need to start systematically AI-rating their code and transitioning to agentic coding management. This requires a methodical approach – starting with the most challenging files, refactoring them systematically, and building proper testing processes. The benefits are remarkable: rapid feature deployment, well-thought-out cutting-edge solutions, reduced hosting costs through patching holes and system updates, and proper documentation creation.
Documentation separates a dime-store application from a million-dollar SaaS product. I’ve noticed that many vibe coders lack proper documentation, but documentation, along with context, is everything. With properly prepared codebases, you can automate, streamline, build faster, and deploy quicker. You can set up comprehensive testing situations and accomplish whatever you can envision. But you can’t do this from day one – you have to make your codebase capable first.
In my current projects, I’ve built tools specifically designed to find issues, correct problems, locate potential security vulnerabilities, and ensure SOC2 compliance. I have ethical hacking tools to verify required security measures, code mapping tools to locate wastages and leakages – all possible because of agentic coding.
With the recent $9 billion valuation of Cursor, the leading IDE with agentic AI coding built in, and OpenAI’s $3 billion acquisition of Windsurf, this has moved from niche to enterprise. Every business with software engineers should be preparing for this shift. It’s fast, it’s amazing, you can streamline processes, lower the barrier from ideation to deployment, test comprehensively, implement rapidly, and create numerous integrated systems within your codebase.
When I’m working on a properly prepared legacy codebase and an error occurs, it’s invariably because it happened in a file I haven’t sufficiently prepared with context or updated to take advantage of agentic coding. The future of development is here. The question isn’t whether you’ll adopt it – it’s how quickly you can prepare your systems and your team for this fundamental shift in how we build software.
The revolution isn’t coming. It’s already begun.