After the vibe-coding rush comes the debugging hangover

0
1
After the vibe-coding rush comes the debugging hangover



ZDNET’s key takeaways

  • Vibe coding makes features fast, but reliable apps take work.
  • Stubborn bugs still demand patient, hands-on investigation.
  • AI needs human guidance for architecture, testing, and design.

There’s no denying it. Vibe code is a rush. I find that dictating a product description to the computer and seeing an app take form in front of my eyes is nothing short of magical, and maybe even somewhat addicting.

Also: ‘I can’t stop’: 80% of developers find AI coding more addictive than helpful

For me, the early days of new app vibe coding are the best. As ideas and plans come to me, I share them with the AI, and after a few moments of deliberation, it creates them in code. Feature after feature, the full app takes form.

It’s a friction-free process of ideation to manifestation. It’s breathtaking.

But unfortunately, except for the simplest of apps, the approach is also unsustainable.

Days of wonder

About two weeks ago, I started work on a new Mac app, a fully customizable list manager. Yes, I know the Mac has about a thousand other list manager apps. But I’m a bit of a list manager fanatic and pretty fussy about how I want mine to work.

So I decided to use Claude Code to create a list manager that looked and worked how I wanted.

I spent a glorious ten days or so sneaking in vibe-coding instructions for Claude Code between my actual work sessions, and watching an app that looked like what I pictured in my head take shape.

Also: I used Claude Code to vibe code a Mac app in 8 hours, but it was more work than magic

But then, Saturday, as I scrolled down my first fairly large list, the unthinkable happened: The Spinning Beachball of Death.

For those of you who are not Mac users, here’s what that issue means. When a Mac app gets busy, it often spins a beachball cursor to indicate it’s working its way through something.

Back in the pre-Apple Silicon days, seeing the beachball was fairly common. The processors weren’t as powerful, and apps really had to spend time getting their work done.

Now, however, seeing a spinning beachball generally means your app is actually struggling with something. The Spinning Beachball of Death arrives when the ball doesn’t stop spinning, and the app becomes totally unresponsive.

Also: This AI expert says the job apocalypse isn’t coming, even if you’re a coder – here’s why

On Saturday, after running beautifully as I added feature after feature, my app became afflicted by the issue.

And then vibe coding stopped seeming so magical.

Bad vibes

A bug, put simply, is a situation when software doesn’t perform the way it’s supposed to. Some bugs are simple to fix. A minor omission or an algorithmic misunderstanding causes them.

Simple bugs are ideal for AI coding remediation. When you’re vibe coding an app, these simple bugs turn up constantly. Text might have the wrong font. A background color might not properly show up on a header. A change might not save at the right time.

Also: My 3 favorite AI tools for voice dictation while vibe coding – and one is free

Sometimes, with a simple bug, observing it, reproducing it, and accurately describing it is all you need to find out what needs fixing. From those descriptions (and an occasional supporting screenshot), the AI can quickly find a solution and update the code.

Then there’s that Spinning Beachball of Death. I started with a simple report: “The app has hung.” Claude went digging, but didn’t find anything.

I restarted the app. The problem went away. Later, it came back. This kind of inconsistent, intermittent bug is the bane of all programmers. Having a semi-sentient AI coding superhero doesn’t mitigate this sort of problem. The AI can’t fix what it can’t find.

Claude and I spent about two-thirds of Saturday narrowing down the conditions. We eventually figured out that the issue occurred on one list, but only after switching from another specific list.

Also: 75% of developers I surveyed prefer Claude Code – here’s why they choose it over Codex

I won’t bore you with all the details, but eventually we figured out how to reliably reproduce the bug. That process took hours and hours. It wasn’t the approach of ‘I just gave Claude Code one prompt, and I had a million-dollar app’ that vibe coding promises. It was work.

Actually reproducing the bug is half the battle. The other half is then figuring out what it is. Doing so took the rest of Saturday and all of Sunday.

Context is king

Claude Code (and most other agentic AI tools) have two main restrictions that constrain their work. The first is their context, which is roughly analogous to their internal memory, except it’s filled with AI tokens, not bytes of data.

As each session continues, the context fills up. The more the context fills up, the more overwhelmed the AI becomes. It’s like starting your day with a clean workbench that fills up as you work. Later, you find yourself attempting to fix something while your workbench is piled nine inches high with the remains of five previous projects.

Also: Worried about AI coding? Why the invention of power tools is the blueprint for your career future

If you’re working on an ongoing issue, you don’t want to lose the context even when it gets filled up. The right process is to save a set of memory files, so the AI can pick up where it left off after restarting the session.

As you spend more and more time on the same problem, those memory files get bigger and more numerous. Each session starts by reading memory files, so you eventually start a session with half your context already consumed.

The second restriction is usage allocation. Your plan determines this capacity, but it’s generally metered by the AI juice you use in five hours and the total amount you use in a week.

If you exceed either, you get cut off until you wait the mandated time, or you upgrade your plan to a higher-cost tier.

My $100/month Claude Code Max plan seems to hold pretty well in terms of usage, although I did get cut off once over that recent debugging weekend. My $20/month ChatGPT Plus plan offers far less usage, so I often get cut off rather quickly.

Team effort

Debugging turns out to be a team effort. Claude coded in a potential fix, compiled the application, and launched it. Then it was time to test it.

Sometimes, Claude could work on and test the app’s internal operations without needing my hands. Other times I would tell it, “You have the machine,” and it would launch the app and do its best to try out its own fixes.

Also: A low-tech solution from the past may be your best defense against AI deepfakes

But not everything in Apple’s SwiftUI can be done with Claude’s virtual interface. So it also relied on me for testing.

Back and forth this process went, all weekend long until we eventually fixed the bug.

Be the jockey

One thing that always amazes me about show jumping at an equestrian event is that the horses demonstrate such a perfect, innate grasp of the physics of jumping. The jockey has to train and guide the horse, but there’s a point when the horse has to launch a thousand pounds in the air and absorb the brunt of roughly 4,500 pounds of force on landing.

Also: I used Claude Code to vibe code an Apple Watch app in just 12 hours – instead of 2 months

In this kind of event, the jockey has to manage the course strategy and help regulate the horse’s pace, balance, and rhythm so that it arrives at the barricade with just the right speed and energy. The horse itself has to do complex vision and proprioception calculations, adjust its form in flight, and balance and shift its center of gravity for a perfect landing and recovery at speed.

Yet while the horse is an amazing athlete, with an inner knowing about jumping, it needs the jockey’s guidance to apply that incredible capability for performance and safety.

I think of vibe coding the same way. The AI can produce amazing code, but it needs deft guidance. This is where newbie ‘just give me that million-dollar app’ wannabe coders fall. The AI will give them what they ask for. But they really, really need to know what to ask for.

As an example, my app manages very large blocks of text. When I asked it to implement a search algorithm, it made several bonehead choices, ranging from re-reading and re-indexing every document every time the app loads to scrolling a hundred pages on screen before showing the requested line.

Also: You can earn your Google Al Professional Certificate for free – and I highly recommend it

It didn’t take much work to guide the system to build index tables and to reconstruct an on-screen frame around the found item. But I needed developer-like experience to realize those approaches would be problematic. Then I needed the understanding to guide the AI to a much sounder architectural approach.

Claude also likes to guess the problem when a bug is reported. I have to instruct the AI regularly to re-read the actual code. I also have to tell it to set up a mechanism for logging actions in the software, so it can then do log analysis to see what is happening.

Feature after feature, bug after bug, I have to guide the AI. It can create amazingly capable code in minutes that would literally take me months, but it doesn’t always know what the code should do, or how it should do it. I have to be the jockey, guiding the coding athlete that is the AI to where I want it to go.

Post-flow drop

With vibe coding, new features are quick. But the bug fixes can take entire days per bug. I don’t think there’s been enough discussion about the post-rush drop of vibe coding. Vibe coding can be the ultimate flow state. When you’re in flow, your synapses flood with potent brain juices of dopamine, norepinephrine, endorphins, anandamide, and serotonin.

The post-flow drop state entails a level of synaptic depletion. Neurotransmitter stores are empty. The result can be reduced receptor signaling. These issues leave your brain feeling fatigued and overstimulated. And that, unfortunately, is when the real work starts.

The gotcha of vibe coding can hit in two ways. Even for experienced developers like me, there’s the post-rush drop where you still have to make code workable and reliable. Then, you have to test everything (because the AI sure as heck won’t be able to, despite vendor claims), then negotiate with the AI to clean up its messes, and fix bug after bug. You’re still getting some good brain chemicals here if you are a coder.

Also: ‘Sophisticated’ AI swarm attacks are months away, OpenAI warns: What experts say businesses must do

For non-developers, it’s worse. Coders can at least guide the AI into making better decisions and help prevent it from leaving time bombs to discover further down the line. Folks with no development experience have to strap themselves to the horse, yell “giddy-up,” and hope the horse knows where it’s going.

I am finding vibe coding to be an amazing, astounding, deeply enjoyable experience. But it’s not all the rush. That’s the myth. Yes, I’m shortcutting months or even years of coding time. But the force-multiplying nature of vibe coding means I’m building much bigger projects, with much more complexity. All of that complexity must be tested, debugged, architected, tuned, and made solid.

Rather than coding, I spend most of my time testing and debugging. Vibe coding doesn’t reduce that time or effort. While Claude Code and Codex can be a 10x or even 100x force multiplier for writing code, I’m still chugging along at normal speed (or even slower, because I have to discover what the AI did to debug it).

To give you an idea of how much work goes into what most folks think of as “instant” vibe coding, I’m probably about a third of the way done with my Mac app. So far, I’ve given Claude 1,392 individual instructions (prompts, if you will). Of those, I prompted Claude 312 times as “we” diagnosed the bug that froze my app.

So yes, vibe coding is magical. But you need a solid grounding in real-world software engineering to capture that magic and turn it into a productive app that actual humans can rely on to get the job done.

Have you tried vibe coding on a project that later demanded serious engineering support? Let us know in the comments below.


You can follow my day-to-day project updates on social media. Be sure to subscribe to my weekly update newsletter, and follow me on Twitter/X at @DavidGewirtz, on Facebook at Facebook.com/DavidGewirtz, on Instagram at Instagram.com/DavidGewirtz, on Bluesky at @DavidGewirtz.com, and on YouTube at YouTube.com/DavidGewirtzTV.