The messy truth about learning to code with AI: A beginner's war stories
I'm consolidating all of my posts about learning how to build under the Forward Deployed Editor banner. So my apologies if you've seen this already! From this point forward, all of the mistakes you read about will be newly discovered mistakes...
Today I'm celebrating something that would have felt impossible just 6-months ago: I built and launched my first iOS app. Audio2 is a free app that lets you take whoa! moments from favorite podcasts and turn those insights into shareable video clips for LinkedIn, messages, Teams, Instagram … you name it. Check it out on the App Store: https://lnkd.in/dD5CSMFr
But this isn't really about the app. It’s about my discovery of the joy of building and being able to build.
I started on Audio2 while on vacation and continued over nights and weekends. I began as a total newbie: I hadn’t written code outside of basic HTML or, literally, BASIC. But day by day I began to understand the architecture of what I was building. I was like a tourist who could now understand — though frequently misunderstood — the local language; a closed world was opening to me.
Two metaphors keep ringing in my head as I've gone down this path:
1️⃣ The rise of blogging. Blogs debuted while I was a writer and came to challenge the domain of the journalist. The ability to influence and express opinions at scale had belonged to those with access to a printing plant — like me! Soon it diffused to anyone with a Tumblr. It unleashed ideas into the world that never would have had a shot of being heard.For decades, the same was true in tech. Creation required computer science degrees, deep technical knowledge, large teams. The barriers were fortress walls. But AI has let the barbarians in — like me! — and suddenly people with limited tech chops can test out ideas at scale.
2️⃣ The weekend car tinkerer. What motivates someone to spend Saturdays under the hood doing something a professional mechanic can always do better and get paid to do so?
While working on Audio2, I discovered the pure joy of doing work just for fun. I'm sure my code would make a real software engineer weep, but for me, every small breakthrough was intoxicating. I broke the app constantly and then had to research fixes. I learned how to coax the AI tools into giving me what I wanted and discovered where they'd confidently lead me astray. Each session felt like a victory, even when I had to scrap the whole night's work because it didn’t actually, you know, work.
Building Audio2 taught me something I had heard people say (and even said myself): The future belongs to people with good ideas who aren’t stopped by technical barriers. These tools are learnable. The tech keeps getting better. You just have to have the idea, the excitement, and the patience.
Every app you love started as someone's crazy idea. If I can go from a word guy to an app builder in 4 weeks, what's stopping you from trying?
Recommended by LinkedIn
This weekend, I sent an update of my podcast-clipping app to the App Store for review. While I wait on approval, I thought I'd also give an update on my vibe coding journey, in case anyone else wants to learn from my mistakes.
I discovered that some rabbit holes not only don't have a bottom, they're the wrong holes
I spent weeks trying to solve a problem with out-of-sync captions. Claude kept telling me, "I see the problem!" and we'd spend hours implementing a solution that ultimately failed. I finally had it research the technical aspects of podcast distribution, which led to the lightbulb: Some podcasts use analytics services like Podtrac that redirect through multiple CDNs. Audio2 goes through a couple of hops to make captions and each hop pulls — as it turns out — from different CDN nodes, causing slightly different audio content at the same timestamps. I now think I’ve got a fix. But I've also learned that nothing goes smoothly. So it could be weeks at my pace. My temp solution: a warning label and an opt out for the worst-offending podcasts.
I discovered a dark side to Git branches
In my initial post, I talked about how much I relied on branches, which enabled me to cleanly nuke my code if it didn't work.I learned the downside of branches this weekend when I tried to merge a complicated branch with the main branch. The branch had diverged so far that Git couldn't automatically resolve conflicts. Features had been added, code had sprawling dependencies, and manual merge resolution became a multi-hour nightmare of untangling overlapping changes and repeated testing.
I became dangerous in a whole new area
I'm a total novice and every time I work on this I learn something new. This time: learning to deploy and maintain a server. I stood up an instance on Railway that acts as a middleman between my app and AssemblyAI's transcription service. The server takes Audio2's URLs and timestamps, validates the timing parameters, and forwards requests to AssemblyAI with the right settings to transcribe just the clip segment I need (big cost saving). Then it sends the captions back to the app. I got my hands dirty with server deployment, environment variables, API routing, and how to debug services running in the cloud — all concepts that were foreign to me last month.
I took the Cursor training wheels off
I ditched Cursor and went straight to Claude Code. I realized I could do the same thing Cursor did in Terminal, just keeping the windows open that I needed. I was basically spending all of my Cursor time in its chat and terminal panes. Claude Code served as the chat interface and Terminal handled the command line work, so I saved $20/month. But… I was burning through Claude time and had to up my plan to the $100/month version temporarily. I'll adjust my plan monthly based on whether I'm actively building.
Got your own stories? I'd love to hear them!
I’m a current cursor user but I keep hearing everybody talking about Claude. My current plan right now is $60. I don’t know if I wanna pay 20 per month to figure out cursor. Probably major struggles are creating a set up documentation so it could the reference everything I need for example define acronyms as I’m learning them, one step at a time to not go into long explanations, as I learned, and then my list of project details. I want one document to have the blueprint for every single project.
Very thoughtfully put, Daniel! I see this as the core of creativity itself, the ability to recognize obstacles while focusing on the possibilities that tools provide. I absolutely love the phrase “The future belongs to people with good ideas who aren’t stopped by technical barriers.” It captures something essential about our time, but also something slightly tragic. Because while it’s true that technology today enables more than ever before, the future has perhaps never been so dependent on its conditions. In the past, innovation wasn’t just about tools; it was about courage, creative risk-taking, and the ability to unite people around an inspiring idea. I keep thinking about how technological development has democratized access to creation and visibility, yet, paradoxically, also made it harder to be seen through the noise. It still takes something deeply human to break through: ideas with direction, meaning, and the power to truly move people. Maybe that’s why this digital letter resonated with me, thank you!
Loved reading it.
This is awesome. Congrats Daniel Roth.
Exceptionnel