Claude & I – A Vibe Coding Story

If you’re a developer reading this, you’re likely to face palm… a lot. Either that or laugh a lot at my stupidity.

Let’s set the record straight. In no way am I a software developer. As far as I've ever gone is dabbling with a basic website, like a decade ago, learning HTML and CSS… It had about as much JS as a pop-up needed. She was basic. I managed to get a Hello World up, which triggered playing some music on load—top-notch quality coding.

That short-lived experience made me realise what it would take to learn the craft of software development, so I decided to stick to the areas I knew… everything else, other than the coding part.

Having worked alongside development for all these many years, it’s given me quite the leg up as I enter my foray into the vibe coding arena. Understanding how to design software and the principles of software development have equipped me with a few weapons to fire.

But mainly it equips me with being dangerous enough to create a right bloody mess. And a right bloody mess is what I found myself making when I decided to vibe code my first product.

The Origin of the Idea

A couple of weeks ago, I decided it was time to start planning my upcoming holiday. I did what most people do: I set out to create a to-do list. One that I knew I would forget about, change, and barely manage, but this is the starting point of my people.

As I lifted pen to paper, I thought, hang on a dang tooting second. A basic to-do app seems like a nice and simple project to vibe code; it’s usually a place where developers start. “I got this”, I told myself. This is it. This is the moment I can add Vibe Coder to my resume.

With hope kindling in my heart that this would be a quick and short adventure, I set out on my quest.

The Picking of the Tooling

Rumour had it that Claude was becoming a frontrunner in the code generation space. Rather than validate said rumour, I thought I would just dive in and find out for myself.

Off I went to Claude, asking the fundamental question on what my architecture should be for a basic Windows desktop app. I really didn’t want to deal with environments, hosting, and that next level complication. Just something I can run on my machine.

Claude recommended the following tech stack:

• Electron: For building a cross-platform desktop application.

• Node.js: Providing the runtime environment for Electron and backend logic.

• React: With TypeScript for building the user interface.

• Material UI (MUI): For UI components and styling.

• Babel: For transpiling modern JavaScript and JSX.

• Electron Forge: For packaging and distributing the app.

Great, now all I needed to do was install an IDE, with a bunch of extensions, Git, and Node.js. Just to be clear, I had none of this tooling installed on my device. I was starting from ground 0.

Why am I not installing the rest of the stack upfront as well? This is managed within the project itself. Look at me learning.

Claude had given me some basic boilerplate code for a to-do list app, so once I had everything installed, I’d be able to run and view a basic app.

Gotta say though… that wasn’t as smooth sailing as I thought it was going to be. Apart from those initial installs, that seemed easy.

Getting to a Successful ‘npm start’

Running PowerShell in the terminal instead of Command Prompt

Click that plus thingy, obvs

I know, right? This probably sounds basic to you as a developer. But none of the prompts that Claude gave me were working. Why? Oh right. Change that little plus thingy over to Command Prompt you say.

First basic lesson learned.

Npm audit fix --force

As I watched the dependencies install, I encountered numerous errors and warnings about deprecated items. The command prompt said to run npm audit fix --force to fix it. I kicked that off without asking my pal Claude, as it seemed legit. As it was running, I thought I'd better let Claude know what I'm up to.

Claude No Happy

Claude wasn’t happy.

Claude yelled at me.

Yeah… I’d made a bit of a boo boo there. But it seemed logical to me. Why would you want all these errors and warnings to exist? What does it mean to have them? Why do we have them? I had more questions than answers, but I knew I needed to keep going.

Don’t get lost down a rabbit hole Demelza.

I at least needed to understand why I shouldn’t upgrade.

Everything could break. Right. This damn force fix meant it would ignore version compatibility checks, potentially making breaking changes to dependencies. A whole whopping set of incompatibilities apparently. Why would this even exist in this state people?  Whhhhhy?

Guh. No more questions Demelza.

With my tail between my legs, I deleted the project and started again. This time I did not get sucked into force, the force was not with me.

TypeScript No Likey

The last hurdle on my journey to getting that sweet, sweet, successful npm start was a bunch of errors with TypeScript. After a few failed attempts to fix it, Claude and I decided to reduce complexity and proceed without it in the stack. Well, Claude did. I think Claude felt my confusion and frustration rising.

And finally……… npm start SUCCESSFUL.

I had myself a little working app. CRUD wasn’t quite working as expected, and now that I could visibly see it, I had some more ideas on what I wanted it to do.

My first working app, just look at her

Co-Design With Claude

With my ideas in hand, I went back to Claude for some more code generation. I didn’t realise the ability to do this existed within VS Code, so I was running this all in the browser. I’m new to this, remember? Give me a break.

I started with the basics of getting CRUD working correctly in the prototype, and with a few prompting attempts, Claude got some workable code that set that straight.

I felt like I was cooking with gas at this stage. This felt like a workable process.

Within the Claude browser editor, it splits screens so you can visually see the design concept, which allowed me to refine my design further. Claude is simultaneously creating the code for the idea, so at any time I am ready, I can copy that over.

I started to overcook my simple little app. Nothing like a Product Owner to want every feature they think is awesome and totally needed.

Here's my list of features:

• A live countdown timer to the exact time I get on my flight: In QLD time zone

• A daily holi-yay reminder for me to send to Paul

• CRUD to-do list. 1 list spawned into 2. Got to have a top priority list, and another ordinary list to manage

• Live weather display long-range forecast for the dates of my arrival in Bali and Vietnam

• Up-to-date news related to travel and weather in those destinations

Yeah. I was probably taking it a bit further than its original intent, but these felt like the kind of things I'd usually have to check on different apps and websites as my holiday approaches. And this was a Holi-yay Planning app I was designing after all. My brain told me this was sound logic.

While the basics of the app were coming along, so was a beautiful, almost 90s era styled design. The kind of modern-day 21st-century version.

Just look at her.

I'm sure I could win a design award for this

At this stage, I prioritised function over form as much as it ailed me. I had to focus on nailing the basics in code first. So once the features were skeletoned out, I grabbed the code, copied it into VS Code, and npm start’ed that baby.

She was working; however, there were bugs in quite a few areas.

The Painful Adventure of Fixing Bugs

Weather API Integration

The weather was showing all sunny. I knew, however, this was not to be the case as I had been tracking the long-range forecast. My best friend's wedding was during the day, outside, so boy were we watching that weather like a hawk. Claude, there is just no way this is right.

Getting Claude to fix it to the correct weather - 8 attempts. Every time I told Claude the fix didn’t work, I got in response, “You’re right”! And then it would proceed with another fix, which didn’t fix the issue at all.

Claude. Come on. You got this.

It didn’t got this. I had to get this.

Why?

Claude couldn’t query the API itself to check the response. This was an open API, so there was no need for authentication. Through a bit of conversation, we figured out that I had to call the API itself to then supply the response to Claude. That helped us to narrow down where Claude was going wrong in the weather codes and corresponding icons. We got there, and it was eventually solved.

The news feed wasn’t live either

Loading news… permanently.

“Why Claude?” I asked.

“Oh well, it's likely that the RSS feed that it selected would likely not return any data. Likely, the feeds are blocked,” Claude responded.

“Sooo… should we find another source then?” I exclaimed.

“You’re right”, Claude then repeated for the thousandth time that morning.

And while those words are usually so, so sweet to the ear, from Claude… it was beginning to feel very disingenuous.

At this point, I probably should have added this to the original prompt, that I would like a working API with live data displaying. This seemed like a ridiculous thing to have to ask; surely it would have been assumed that I would need an API with that live data. You know what they say when you assume though…

Claude did as it was told and went and found another source. And then lo and behold, we have a source that works!

The Paul Reminder

The daily Paul reminder would not default to today. It had been working in an earlier version, but all this fixing of other bugs had done something to break it. And this bug nearly broke me. In the attempts to fix it, the navigation between days would break, revert, and sometimes the whole page wouldn’t return data.

Claude and I were back at it. Going backwards and forwards again. It felt to me like this was a pretty basic fix for someone in the know. At this point, on top of not resolving the bug, Claude started to slow down. Grinding. Crashing. Painfully slow.

I’m sure it’s now duplicating code, and every line reference it gives me for the code I need to fix is incorrect. So I copy the code back in, so that the starting point is cleaner. But it just can’t read its code well enough. Claude really started to grind now, in speed, and my gears.

Patience is a virtue Demelza.

Don’t give up Demelza.

Just do it Demelza.

All these popularised, saturated words of wisdom were washing around in my head.

It was becoming survival of the fittest. Me vs Claude. I was starting to get hungry, and that was a dangerous proposition for Claude. Lucky Claude is not something physical for me to be able to get at.

To make matters worse, the naming convention for this component was Paul. Somehow, he was laughing at me. Somehow, he was getting his revenge on my holi-yay reminders that I had not even had the chance yet to deliver to him.

Before I could get food, I felt I had to solve this issue.

Must. Solve. Bugs.

Must. Get. Working. App.

Claude and I were at the stage of adding extra debugging to the logging to help narrow down where the issue was. But even this was now crashing dev tools in Chrome.

Guh.

What the hell Claude. …

It was a merry-go-round of issues: navigation going the opposite way than expected, default date being incorrect, resetting back to future dates, navigation would break entirely, then just no data being returned… until finally it worked.

IT WAS WORKING.

I focused on the content of the reminders Claude had crafted, realising how crap they were. I’ll come back to that later. Just celebrate this win for now, Demelza.

DON’T TOUCH IT. IT WORKS. SLOWLY BACK AWAY.

In Summary

After half a day of battling, my Saturday didn't quite go as planned. I somehow diverted from actually taking action on my holi-yay to-do’s, to instead creating a system to note those things down.

I can see how vibe coding would be dangerous in the wrong hands, especially in a live environment, and even more so if there was any sensitive data involved. Once you're in a loop of breaking bugs, you need to know how to prompt it into a fix, knowing how to investigate an issue, and where it could be within the code, within the architecture, or even within the data being returned in that API.

On the flip side, it’s a great way to learn the basics of software development, as you can get from zero to MVP in a short time. There is nothing more motivating than creating something that works. And let's be honest, a couple of hours isn’t too bad to get to an MVP. From here, you can step backward to understand all the bits and pieces you put in place to get it there.

And look! I created a thing!

As for my app? I want to come back and take it to the next level. I didn’t get to deploy and install it properly; I’ve just been running it locally.

But first?

HOLI-YAY TIME.

P.S. I went back to Claude when I was writing this article out to look at my prompt history on this project… and Claude is now broken from the journey we went on together. It’s done. No coming back. Fine. I’m feeling the same way, Claude. The feeling is mutual.