top of page

I spent the weekend vibe coding with Claude 4.5, here's what I learned

  • Writer: Chris
    Chris
  • 15 hours ago
  • 4 min read

This weekend I took a departure from the work I typically do for DuckAbroad to see for myself the progress that is being made in the "Vibe Coding" space. Here's what I found.



AI is supposed to handle the boring stuff so humans can do the creative work.


This weekend, I experienced the opposite. Claude 4.5 did the parts I enjoy, writing code, designing features, solving architecture problems, and left me with a tedious cycle of test, copy, wait, repeat.


And yet? I have a working iOS app that would have taken me weeks to build alone.


Let me explain.


The problem I wanted to solve


ree

Every parent knows this nightmare. You're out with the family, maybe on vacation, and it's time to eat.


Everyone has an opinion. No one wants to decide. The kids are arguing over who picked last time and how they never get to choose.


I've had an app idea for this for years: a family restaurant decision-maker that pulls in nearby options and breaks ties with a spinner wheel. After hearing Dan Shipper and Paul Ford discuss vibe coding with Opus 4.5 on the AI & I podcast, I decided to finally build it.


The first pass was almost magical


I signed up for Claud AI and gave it a detailed prompt...the core concept, the user flow, the APIs I wanted to use. It asked smart clarifying questions and suggested we start with an MVP.


The result? Nearly a working app from the first attempt.


I still had to copy files into Xcode and ask Claude to fix some errors, but it delivered features I hadn't even considered. The profile page didn't just capture food preferences, it included allergy settings. That's the kind of thoughtful addition a junior developer might miss.


Better still, Claude iterates without amnesia. I've lost count of how many times ChatGPT has changed variable names mid-conversation or quietly dropped features I'd already approved. Claude 4.5 remembers context and builds forward.


Where things got ugly


The basics came easy. The details nearly broke me.


Design problems are invisible to AI. I spent multiple rounds trying to get the map width to match the restaurant list below it. The map would grow, the list would shrink. Then vice versa. Claude finally fixed it...accidentally...while solving an unrelated button issue.


Unknown APIs are a dead end. We hit Google Places API feature limits early on. Claude suggested Foursquare based on its pricing, but had no idea how to implement it. I had to feed it documentation, working code examples, and expected responses before it could connect. Even then, the results were poor. Only after I pushed it to try Yelp did things work properly.


When AI can't see the problem, it confidently guesses wildly. This was my biggest frustration—and it ate most of my Saturday.


Let me explain...


The spinner wheel nightmare

ree

Claude had suggested a tie-breaker feature: a spinning wheel showing the finalist restaurants, each in a colored segment. Simple enough, right?


The wheel would spin, slow down, and stop. But it kept selecting the wrong winner. The display showed one restaurant. The code picked another.


Each time I described the bug, Claude enthusiastically announced it had found the problem. It hadn't. Then it added logging...reasonable, but the output didn't reveal the problem. I explained precisely what was happening. It changed unrelated things with the same broken result.


I thought about giving up and trying another solution but I really liked this option so I pushed forward.


It wasn't until I was lying in bed early Sunday morning that a solution occurred to me.


I had to instruct it on how to build the wheel, the logic, and it's structure. I needed to think about how it was seeing the problem and then adjust my prompts from there.


Claude needed to understand how a spinning wheel and a static arrow pointer interact: the wheel segments are painted blue, green, red, repeating. But when the wheel spins clockwise, the arrow reads them in reverse—red, green, blue. Claude was calculating the winner based on how the wheel was built, not how it actually moved.


To fix this, I had to ask Claude to explain its own logic, then manually walk it through what was really happening. Only then did it fix the actual problem.


The uncomfortable truth


Despite all this, the app would have taken me much longer to build alone.


Vibe coding works.


But here's what I can't shake: I like writing code. I like designing applications. That's the creative work that energizes me.


Instead, my weekend looked like this: test the app, find an issue, explain it to Claude, wait for changes, download files, copy to Xcode, test again, hope it works. Repeat.


That's not a creative partnership. That's quality assurance with extra steps.


What I learned


Vibe coding requires developer experience. Non-developers aren't shipping anything but basic apps with this approach. You need to understand how code works to keep AI on track when it drifts and to solve complex problems.


AI excels at known patterns, struggles with novel problems. Yelp API? Easy. A spinner wheel reading colors in reverse? Hours of pain.


Speed isn't the same as satisfaction. Yes, I got a result faster. But as someone who tries to enjoy the journey, this particular journey I could do without.


Hopefully, as AI evolves, we'll find a better working relationship...one where human creativity blends with AI efficiency instead of being replaced by it.


For now, I have a working app. And a nervous twitch when I see spinner wheels.


There's still polishing to do but I hope to have the app ready and in the app store by the beginning of next year.


Reach out if you’re interested in joining the beta.


Comments


bottom of page