Our First Vibe-Coding Rescue Project

A friend and former colleague reached out to me recently to ask if I could help him fix a couple of bugs in a small project he’d been working on. He was not a developer, but had worked in and around developers for his whole 20+ year career as a business analyst, product owner and program manager. With the advent of tools like Cursor and Lovable his lack of coding ability was (maybe) no longer a barrier to getting some ideas he’d been incubating in his mind for a while, out into the world. With credit card in hand, he dived headfirst into the world of “vibe” coding. 

We met for coffee, and he showed me the prototype he’d built. I was quite impressed with what he showed me (running on his laptop…deploying it anywhere was a bridge he had not crossed yet) – a capable working prototype that demonstrated the ideas he was trying to prove out. I asked him about the “development experience” and he said it had been great at first, and he’d been able to make a lot of progress quickly, but at some point he hit a bit of a wall where each change he tried to make introduced more issues, and he felt like it was pointless to continue. He’d switched between a few different AI coding tools in an effort to see if the problems he encountered were specific to the tool he’d started with, but without success. The vibes had run out. 

When The Vibes Ran Out

I said I’d happily take a look at what he had and give him an estimate of how long it would take to fix the remaining issues. The architecture of the solution was simple enough and well suited to what he was trying to achieve – a Supabase back-end with some edge functions. The front-end was React, Typescript and Tailwind. So far so good. I got the solution working readily enough, but started to see a lot of small and not-so-small issues when I played around with it. I think in order to give me an overview of everything, he’d carefully worked around a few issues that now came to the fore. I figured out how to work around those too and dived in to trying to fix the first issue on his list. 

 

Fixing The 'Last Few Bugs'

In the words of Yogi Berra “you can observe a lot by just watching” and the more I looked, the more I saw. The first thing that dawned on me was the staggering lack of consistency as I tried to apply patterns that were working in one area to fix a bug in another area. Cursorrules files can be used to improve consistency, and my friend had not created one of those. Does using cursorrules go against the spirit of vibe coding? Does aiming for code consistency? 

The second thing I started to notice was regarding state management – it was a mess. It made me realise all the different ways you can access state in a react application – via an API, via props, via hooks, fetched from an API, as part of the route, and so on. Once again there was no consistent approach – values were read from props that were never set that could have been gotten from the route. The nature of the app was very simple – state was a simple hierarchy being edited by a single user, and yet it still seemed like a big stumbling block. 

The third thing I started to notice was bits of back-end functionality that didn’t work, but weren’t on my friend’s list of bugs. After discussing a few of these with him it became apparent that these were never features he’d asked for, but hallucinated features that had gone un-noticed because they were failing silently. Like a vestigial appendix in the code-base these could (and certainly should) have been removed, but teasing out what was “real” and not working, and what was just noise would take time. 

As these issues began to mount the final epiphany I had was that (for me) it was hard to fix a system like this because my mindset was now different to fixing issues in a “normal” project. In a normal project I often push through issues by trying to think about the state of mind of the previous person working on the code – you see something in there and even though it might not be right you can see what they were trying to do. Things, even buggy or misguided things, exist for a reason. Here, there was no “they” – more and more it felt like just a lot of random code that had been welded together. I was amazed that it worked at all, and suspected and subsequently confirmed with my friend that there had been a lot of back-and-forth prompting that would have gone something like this: 

 
user: I’m getting the following error when I do X  
agent: I see there’s an issue with the DoX method, let me fix that. 

user: I’m still seeing an error when I do X, it says..
agent: I apologize for the error. I see now there is another issue with the DoX method. Let me fix that.

History, Repeating

“Vibe” coding is the latest in a long list of tools from Microsoft Access, Hypercard, Visual Basic, Excel, and many “low code” tools that have allowed citizen-developers to create complex systems with no programming knowledge. Many of the aspects of this “rescue” would be familiar to industry veterans who’ve participated in similar projects for other citizen-developer programming efforts. My friend said he did find the vibe coding process to be very useful in fleshing out his ideas, but it remains to be seen whether the issues he hit can be overcome to develop production-quality applications. 

Reviewing the results of my friend’s vibe coding experience I have mixed feelings. On the one hand greenfield development is notoriously one of the most productive stages in a project, so vibe-coding a POC quickly is less impressive to me. Also, it seems like vibe coding eschews many of the time-consuming parts of development (like testing) by just not doing them. On the other hand, the fact that it even works at all does still amaze me. Vibe-coding allows non-programmers to create things that they previously couldn’t, which is a step-change in capability. 

The Road Ahead

Vibe-coding is an extreme form of agentic development. Practices, tools and foundational models are improving quickly in this area. I can envisage a more productive future that blends some of the speed of vibe coding with more of the rigour of current software engineering practices using rules files for agents, onboarding files written specifically for agents to give them more context, linting rules, test suites, judicious use of version control, and deployment pipelines as well as hosting infrastructure to take the vibes directly to production.