This is Part 2 of my AI coding journey. In Part 1, I got into a fight with my AI coding assistant—stuck at 90% complete for weeks, frustrated and defeated.

Here’s what I learned from losing: I was fighting the wrong opponent.

The enemy wasn’t my AI assistant. It was my approach.

The Moment of Clarity

Somewhere between calling my AI assistant a “complete idiot” and wanting to “smash it to bits,” I realized I was asking the wrong question.
Instead of “How do I make AI code better?” I should have been asking “How do I code better with AI?”
That shift—from AI coding FOR me to AI coding WITH me—wasn’t just semantic. It was a complete reframing of the relationship.

The Real Problem with “Vibe Coding”

Here’s what nobody tells you about the AI coding productivity dream: it works brilliantly until it doesn’t.
AI can build you a marketing website in hours. It can scaffold a basic CRUD app while you grab coffee. It can generate boilerplate faster than you can type.
This creates a seductive illusion: if AI can do all that, surely it can build my complex, novel, production system too.
But there’s a fundamental difference between code that’s been created thousands of times and code that’s never existed before.
AI is a prediction machine trained on billions of code examples. When you ask it to build something common, it’s interpolating from patterns it’s seen countless times. The predictions are solid.
When you ask it to build something novel—combining frameworks in new ways, implementing cutting-edge features, solving problems with limited training data—it’s extrapolating. And that’s where the predictions become convincing lies.
The specific combination of Agno Framework, Groq, Langfuse, and my business logic? Never seen before. So it did what it does best: confidently predicted code that looked right but subtly wasn’t.

The Tom Cargill Trap

There’s a famous software development truth that hit me hard during this experience:
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
— Tom Cargill
With traditional coding, that last 10% is painful but predictable. You understand the architecture. You can debug systematically. You know where the edge cases hide.
With vibe coding, that last 10% can become an order of magnitude harder—or simply impossible.
Why? Because you don’t understand the foundation. You can’t debug what you don’t comprehend. And your AI assistant, which got you to 90% so quickly, hits the limits of its pattern-matching abilities.
You’re stuck at 90% with a confident yet incompetent coding partner and a codebase you don’t fully understand.
That’s the trap.

The Way Out: A Philosophy, Not a Hack

After I admitted defeat and started over, I didn’t look for a better prompt or a new AI tool. I went back to what has worked for me over the last decade as a software engineer.
The question became: how do I translate my expertise into a better working relationship with AI?
The answer wasn’t changing my process to fit AI. It was adapting AI to fit my process.

Research → Learn → Plan → Code

This became my new framework. Not because it’s revolutionary—it’s how experienced developers have always worked. But because it fundamentally redefines the AI’s role.
Old Mental Model:

• AI = Fast coder who does the work
• Me = Manager who reviews and directs

⠀New Mental Model:

• AI = Research assistant, teacher, and collaborative partner
• Me = Architect and decision-maker who codes alongside AI

⠀Phase 1: Research
Every new feature or significant refactor starts with AI researching the latest best practices and framework documentation.
Not just reading it—but synthesizing it into documentation tailored to me and my project.
The shift: Instead of asking AI “Can you code this?” I ask “What do we need to know to code this really well?”

Phase 2: Learn

This is where the magic happens. I don’t jump straight to coding. I read what AI researched. I ask questions. I request examples tailored to my use case.
I’m creating a personalized course where the example project is my actual project.
What surprised me: This doesn’t just help me—it dramatically improves AI’s coding ability. By investing in the learning phase, we both grow. I gain deeper understanding, and AI gains the context to make better predictions.

Phase 3: Plan

Not “AI, make a plan” and then run with it blindly, but “Let’s brainstorm on different architectures, then draft a plan for us to discuss.”
I’m making the architectural decisions. AI is helping me think through implications, suggesting alternatives, catching edge cases I might miss.
We break things into small, reviewable chunks. I use thinking models for architecture, faster models for execution.
The shift: I’m not managing AI’s plan—I’m architecting with AI as a thought partner.

Phase 4: Code

Now we code—but I understand every decision. I review every line of business logic. When AI suggests an abstraction, I evaluate if it’s worth the complexity. When it wants to optimize prematurely, I push back.
We’re writing code together, not AI writing code for me.
The difference: Progress feels slower at first, but it’s real progress, not the illusion of progress.

The Diagnostic: Fighting vs. Accelerating

How do you know if you’re doing this right? Here’s the test:
You’re Fighting If:

• You’re frustrated more than you’re learning
• You have little working code compared to hours invested
• You’re copy-pasting error messages constantly
• You can’t troubleshoot without AI
• AI keeps reverting to the same mistakes

⠀You’re Accelerating If:

• You understand more today than yesterday
• You could build this without AI (just slower)
• You’re making architectural decisions, not just prompting
• Working code accumulates steadily
• AI feels like a collaborative partner, not a problematic employee

⠀If you’re fighting, stop. Revert to a known good state. Slow down. Learn how to do it without AI, then do it with AI.

When to Let AI Code vs. Code With AI

This framework isn’t for everything. Here’s when to use what:
Let AI Code (Minimal Oversight):

• Marketing websites
• Internal tools or prototypes
• POCs that won’t go to production
• Solutions built hundreds of times before
• Non-critical features

⠀Code WITH AI (Full Collaboration):

• Anything requiring security
• Mission-critical features
• Complex business logic
• Novel or cutting-edge implementations
• Production software

⠀The Litmus Test: If you can’t explain how the code works without AI, you’re doing it wrong.

The Productivity Paradox

Here’s what still blows my mind: I set out to use AI to code less, but what I found was that I could have it code plenty—it just needed a strong foundation and context to work from.
The Real Productivity Formula:
80% of time in research, learning, and planning + 20% in collaborative coding = Sustainable, scalable, maintainable solutions
The False Productivity Formula:
5% planning + 95% “vibe coding” = The 10% trap
That 80/20 split feels backwards at first. Shouldn’t AI make me code faster, not spend more time planning?
But here’s the thing: the 80% isn’t wasted time—it’s multiplied time.
When I understand the frameworks deeply, I code faster. When AI has proper context, it suggests better solutions. When we’ve planned well, debugging is straightforward.
The time I “lose” in research and learning, I gain back tenfold in execution and maintenance.

The Stakes at Scale

This isn’t just about individual productivity. What happens when entire teams fall into the vibe coding trap?
Technical Debt: Code that works until it doesn’t, then nobody knows how to fix it
Talent Debt: Developers who can prompt but can’t architect, debug, or make informed decisions
Knowledge Gaps: Solutions nobody fully understands, creating single points of failure
The combination of these three is a recipe for a valley of death where the nuclear option becomes your only choice.
I’ve seen this playing out. Junior developers who can generate impressive demos but can’t troubleshoot when things break. Senior developers who’ve become so reliant on AI that their architectural skills are atrophying.
The irony: The developers who will thrive with AI aren’t the ones who let it code for them—they’re the ones who use it to amplify their expertise and accelerate their learning.

The Real Outcome

Many late nights and early mornings later, we delivered a multi-agent solution that actually works consistently.
We’re not production-ready yet, but I have zero doubt we’ll get there because:
1 I understand the foundation we’ve built
2 We have solid architecture and organization
3 We follow current best practices
4 I can troubleshoot and extend it confidently
5 We have real, documented knowledge share

⠀This foundation can only be skipped for simple, non-critical solutions that have been created dozens of times before.
If that’s what you’re building, let AI code it and don’t waste your valuable human effort.
If you’re building something novel, complex, or mission-critical, use AI as a partner, not a replacement for your expertise.

The New Reality

When you get this right, coding with AI helps you grow and accomplish more than you ever thought possible.
It’s not about AI writing code for you—it’s about AI accelerating your learning and amplifying your expertise.
The story being told is that you need to completely change to leverage AI. But the truth is simpler: develop the skill of adapting AI to you and what you know it takes to achieve results.
When you’re in the groove—learning together, planning together, coding together—it’s a lot of fun.

Coming Next: The AI Coding Playbook
Want the specific prompts, tools, and workflows that make this approach work? I’m creating a comprehensive playbook with:

• Exact prompts for each phase
• Cursor-specific workflows and features
• Debugging tactics that actually work
• Security review practices

• In the meantime, what’s your experience? Are you fighting with AI or accelerating with it? What’s working for you?