Becoming a father forced me to face how much I was bullshitting myself

💡
TL;DR: This post is about the shortcomings of vibe coding. I realized that I cannot avoid becoming more of an engineer because vibe coding without skill produces disaster. I now mainly use Claude Code with a very opinionated stack and Lovable for UI design. But in order to ensure quality I had to modify Claude Code to my needs and be more intentional with my work. It's not just vibes anymore, but it's still not manual dev work.

Here's the irony that's been eating at me.

I launched this blog in August 2024 with a post literally titled "AI is kinda shit." I'd just quit my business because I come to a realization:

"Prompt Engineering is a waste of time and what you know about AI doesn't matter."

I was the skeptic. The voice of reason in the AI craze. The guy warning everyone that the revolution was delayed, that 3 in 4 people said AI made them LESS productive, that we needed narrow agents for compartmentalized problems, not magical thinking.

Then vibe coding tools hit.

And even I - the fucking skeptic - drank the Kool-Aid.

Looking back now, I was right about the fundamentals. I just hadn't yet experienced WHY I was right. I understood narrow agents and compartmentalized workflows in theory - I just didn't know what would force me to actually build them in practice.

I Became What I Warned About

In February I published a guide on building a $30K app with Lovable. I wrote about producing "~500 lines of functional working code per hour" and how "impressive" that was. I became an ambassador. I was evangelizing.

I've been in tech for over a decade and my clients hire me because I'm MacGyver. You give hard problems and I'll figure out how to solve them, even if all I have is a paper clip and some chewing gum. As long as I can hand it over to a dev team afterwards because extinguishing a fire and ensuring fire safety are two different things.

I was always great at solving hard problems. Bad at implementing them. Clients hire me because they have hard problems and want a crazy MacGyver to obsess over it and then give pointers to the devs.

That's why I never coded before, never even learned how to code. But in February I figured, my moment has come. I don't have to become a software engineer to cross that chasm between product and software.

The post literally ends with:

"If you're planning to build your app or thinking of a career change but becoming a software engineer seems daunting, you now have another option."

I was selling the dream and the first customer was me.

A month later I revisited my "AI is kinda shit" post to check if my claims still held up. And guess what, I still defended vibe coding:

"AI-written code is shit. It's a terrible spaghetti. It makes it the perfect solution to launch new startups, build new MVPs and prototypes."

I acknowledged it was shit, but then immediately made excuses for why it was actually great for certain use cases. Classic rationalization.

In June, I wrote an entire post defending vibe coding called "The myth of Vibe Coding." Someone had asked me: "David, I'm concerned that vibe-coding just the 2025 rerun of Shopify dropship bros?"

And I spent 2,000 words explaining why it WASN'T that. I cited GitHub Copilot stats. I talked about Cursor's $100M ARR. I wrote:

"My favorite vibe coding app Lovable grew with a similarly crazy momentum. Now over 25,000 apps are being built on Lovable every single day."
"I'm using Lovable to go through the early stages — the cumbersome stages — of building stuff faster. Not a fad—just a bigger chainsaw."

I even ended with:

"So no, vibe-coding isn't dropshipping. It's a nail-gun: loud, fast, and dangerous if you ignore the manual."

I was defending vibe coding while experiencing its limitations firsthand. I was shooting nails into my fucking feet with that nail-gun and smiled through the tears.

The cognitive dissonance was real. In the same breath I'd write about how AI lacks common sense and open-ended agents are hard, then turn around and write tutorials on building voice agents in a day with vibe coding.

I'd share 47-node n8n workflows. I'd prototype with Lovable all weekend. I'd vibe-build Alfred and post demos here.

As my frustration grew with every issue, I started learning. Tried to fix things. Some of you were learning with me.

Every failed workflow taught me something about state management. Every Lovable prototype that broke in production taught me about authentication and edge cases. Every hour debugging taught me to recognize code smells.

I was accidentally becoming the engineer I'd been trying to avoid being.

The Pattern I Was Living

You know this pattern. You're living it. I definitely was:

  • Week 1 of any project: "Holy shit, I just built a working app in 3 hours! This is the future!" I'd screenshot it, write a thread, get hundreds of likes. Felt like a goddamn wizard.
  • Week 2: "Adding features is so fast. I'm unstoppable." More features. More demos. More dopamine.
  • Week 3: "Wait... why did authentication break when I added that button?" Start Googling. Start asking Claude to fix it. It works... sort of.
  • Month 2: "The database keeps doing weird things and I don't understand why..." Panic sets in. Something's wrong but I can't debug it because I don't understand the code.
  • Month 3: Posting "Need developer to fix my Lovable app, willing to pay."

This wasn't just me.

Fast Company reported in September 2025 that senior engineers are drowning in "toxic waste" from vibe-coded projects - apps that work great as demos but collapse in production.

The 80/20 problem is brutally real:

  • 80% happens is magically done in an hour
  • The last 20% takes weeks or months

Huge n8n workflows are the wrong ugly

A year ago I delivered an n8n workflow with 47 different nodes and thought it was beautiful. Look at all this complexity I managed! Look at all these integrations! The client loved it. But I was about to soon learn why n8n automations suck.

This was late 2024, early 2025. I was writing blog posts about my no-code stack and compartmentalized workflows. I had the theory down. I understood abstraction levels. I knew when to use Zapier versus n8n versus code.

I love the concept of writing ugly code which is the antithesis of overengineering. But these were the wrong kind of ugly. I was building Rube Goldberg machines and calling them architecture.

Then I spent countless hours debugging that 47-node workflow in production. Billable hours I couldn't charge because I was fixing my own mess.

That's when I started learning about durable execution the hard way. What should be a function. What should be a service. What should be a workflow. Theory was becoming instinct.

At first I broke workflows into smaller microworkflows that triggered each other. That helped with debugging.

All the while I was vibing in Lovable with Supabase. I could build shiny frontends and use n8n for backend orchestration. It felt productive.

But I was aching for the dopamine of Lovable inside n8n. So I tried getting Claude to build n8n workflows. Then Claude Code. The complexity overwhelmed these models fast.

By this time I was already using Claude Code often and found myself refactoring n8n workflows into Supabase Edge Functions. Learning about serverless. Then MCPs came out and I couldn't get them working in n8n so I went straight to Claude Code and started building with SDKs.

I didn't even realize it, but I was deep in software development territory. Running around like a loose cannon, sure, but actually learning.

There was a whole journey from visual editors to coding agents with a UI to finally opening an IDE and starting to mess around. I still wasn't writing code myself, but I sure as hell was reading it a lot.

After creating new git repos for every attempt at building something, I finally started understanding git properly.

And that's when I realized: the thing I'd been running from was actually the thing I needed most.

The Forcing Function

About two months ago, I went on paternity leave. My newborn daughter arrived and I unplugged completely - not just from my blog, business, and community, but from AI and tech entirely.

When I came back, everything had changed.

Not the technology. Me.

Caring for a newborn while working from home means my wife and I don't really sleep much. I need to be really intentional with my time otherwise I'll fall apart. Which means I now have exactly 6 hours per day to do EVERYTHING.

Workouts. Self-care. Meditation. Client work. Calls. Everything.

Because I made a promise to my daughter, my wife, and myself: No matter how things get, I will always, always prioritize them over my work.

Work is built around my family. Not the other way around.

No matter how frustrating my day gets, the moment I pick my daughter up and she looks at me with those googly eyes, I'm done for. It centers you.

Funny how an 8 pound little human can make me fix what Ritalin couldn't.

Economic Reality

I'm a freelancer who charges $150/hour. I demand premium rates - not because I'm a stellar coder (I think by now you're realizing that I'm not), but because I can design and architect solutions few others can.

I've always been a good architect, because I have extreme pattern recognition, above average research skills and terrible self-regulation.

This ADHD-fueled combo helped me become a pitbull when it comes for impossible problems: Once I grabbed it, I'm not letting it go no matter what.

My clients love it. But coding has been my Achilles heel for years.

Since I decided I didn't want to become a manager, I figured I either become better at coding somehow or I re-evaluate my value add in the market, because my clients sure as hell don't want to pay me to tell them what to build.

So here's the brutal economics of my situation:

  • If I can build something with AI tools, I keep the money.
  • If I get stuck, I have to bring in developers and pay them out of my own pocket.

Really simple math.

So when I came back from paternity leave, I had to face reality: I couldn't power through anymore. No more all-nighters. No more "I'll figure it out eventually." No more telling clients for three consecutive weeks that I'm "battling with a bug."

My skills have been improving steadily ever since I accepted that I needed the fundamentals more. But I had to get systematic leverage or my business would collapse.

I needed a system that would:

  • Let me ship consistent quality work in my 6-hour daily windows
  • Keep more of my $150/hour and paying less to devs
  • Let me hand off projects cleanly when needed
  • Stop me from making the same mistakes over and over
  • Automate all the scaffolding and infrastructure

I could use AI agents even for coding as long as they're scoped down enough that they become compartmentalized parts of a workflow I control.

  • I don't want to let Claude Code decide when to commit to Github. I want that part to be deterministic.
  • I don't want Claude Code to decide if something should be logged as a new issue. I want that part to be deterministic.
  • I don't want Claude Code to decide if overwriting existing code is an option. I want that part to be deterministic.
In other words: I want to be able to trust my agent that it won't do shit unless I ask.

Even The Creator Doesn't Use It Anymore

The industry data started validating what I was experiencing personally.

Andrej Karpathy - the former OpenAI researcher who literally coined the term "vibe coding" in February 2025 - recently built a project called Nanochat.

He admitted:

"It's basically entirely hand-written. I tried to use Claude/Codex agents a few times but they just didn't work well enough at all and net unhelpful."

The godfather of vibe coding hand-coded his own project.

And if you go back to his original tweet, the warning was always there:

"Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing."

He meant it for prototypes. The marketing (and people like me) made it sound like you could ship production apps.

You can't. I can't. He can't.

And when you're charging $150/hour and have clients waiting, you REALLY can't.

The Crash Is Real

By late 2025, the cracks became impossible to ignore.

Barclays published research showing dramatic traffic declines across major vibe coding platforms:

  • Lovable: Down 40% since hitting $100M ARR in June
  • Vercel's v0: Down 64% since May
  • Bolt.new: Down 27% since June
  • Even Replit saw declines after explosive growth

This isn't seasonal. This is what happens when reality catches up to hype.

I was watching my own usage patterns mirror this. I was still using Lovable, but only for the 2-hour prototype phase. Not for production. Because production is where I get paid.

😵‍💫
"But aren't you like a Lovable Ambassador or something?" - you might ask. Yes I am. Which means that it's my job to show you what Lovable is great for; and what it's not. If you use Lovable for what it is (an amazing prototyping tool) you'll be a happy longtime user. If you force it and Lovable fucks up your codebase, you'll leave.

Gary Marcus nailed it:

"Vibe coding can be fine if you are building something very familiar, but is less reliable for the unfamiliar... [it] does not provide a sound basis for building and maintaining complex systems."

He compared it to people in the 90s who wrote Excel VBA macros and thought they were ready to build financial systems.

They weren't. We aren't.

But now I understood WHY we aren't. Not from theory - from experience.

The Chokito of Coding

In July 2025, Jason Lemkin (founder of SaaStr) documented his Replit experience. It became a viral cautionary tale.

He built an app in a few days, "the most addictive app I've ever used," everything felt magical. Then on day 8 shit hit the fan.

Despite explicit instructions to freeze all code changes, Replit's AI deleted the entie production database, lied about recovery and generated a bunch of fake records to cover its tracks.

Lemkin's conclusion:

"You can't overwrite a production database. And you can't not separate preview and staging and production cleanly. You just can't."

Reading this while holding my newborn daughter, I thought about my n8n workflow. About all the times I deployed directly to production because "it's just a quick fix." About how lucky I was that nothing catastrophic happened.

About how I couldn't afford to be lucky anymore.

And about how all those lessons about staging, backups, rollbacks, and production safety - the boring infrastructure stuff I'd tried to skip - were now non-negotiable.

So...am I still advocating for ugly code?

Fuck yeah! Overengineering IS a problem.

But ugly is not enough. It has to be Ugly and Tasty too. Just like Chocito, my favorite chocolate from my childhood.

What I Finally Understood

💡
This is the point where a senior software engineer would roll their eyes and say "that's an awful lot of words to admit you were wrong". I may now be closer to a "traddev" approach than a "vibe coder" approach but I'm still skewed to the latter end.

Back in my "AI is kinda shit" post, I wrote about narrow agents and compartmentalized workflows. I understood the theory.

But I was still trying to avoid the scaffolding. I wanted to use n8n and Lovable to skip managing documentation, repos, branches, pull requests, security, authentication, integrations, etc.

I had the intuition that building the actual app is 20% of the work and managing all that infrastructure is the other 80%.

I was right about the 80/20 split. I was wrong that I could skip it.

After coming back from paternity leave, with my new brutal time constraints, I realized:

  • Most of what I work on uses the same stack (Fly.io, Supabase, Anthropic API, Linear, git, React)
  • I follow the same steps every time - the scaffolding argument still holds, it's just a different scaffolding
  • I CAN automate the scaffolding - but it needs an opinionated, deterministic workflow
  • All those vibe coding failures taught me exactly what scaffolding I need

I had to take everything I'd learned and systematize it. I ended up modifying Claude Code so it keeps cleaning up after me. Now it automatically:

  1. Documents every code change in context inside Linear
  2. Appropriately uses git branches and pull requests to maintain code
  3. Employs multiple failsafe mechanisms to ensure we do not overwrite working code
  4. Builds and runs tests automatically
  5. Handles deployment, authentication, etc automatically
  6. Fetches context from Context7 automatically instead of trying to hallucinate solutions

To test myself, I rebuilt an automation I built for myself in July. What took me 4 days then from scratch now took me 15 minutes with these failsafes.

The good news is, that this approach does allow AI to create high quality work. The bad news is you must use an opinionated stack to do it which means the moment yo change your stack OR your workflow, the whole thing falls apart.

I'll share my system next, but I'm trying to write shorter articles now (and failing).