Cowabunga: How I Built My First AI Dev Team Using Ninja Turtles
Learning complex systems through familiar relationships
I've been staring at Claude Code for weeks now, trying to figure out how to actually use this thing to build something real. Not just ask it questions. Not just generate snippets. Actually build.
The problem wasn't the AI. The problem was me.
I kept treating Claude like one person who could do everything. Plan my architecture, write my components, catch my bugs, deploy my code. And every time, I'd end up in this weird soup where nothing quite connected. The AI would suggest one approach for the database, then contradict itself when building the frontend. No consistency. No memory of decisions. Just vibes.
Then I saw Prajwal's post about structured AI development, and something clicked.
The Mental Model Problem
Here's what I realized: I didn't have a mental model for how a development team actually works.
I'm not a trained developer. I'm learning this as I go. So when people talk about "architecture" and "QA" and "DevOps," I understand the words, but I don't feel the relationships. I don't know who hands off to whom. I don't know when the database person needs to talk to the frontend person. I don't know the dance.
But you know what I do understand? The Teenage Mutant Ninja Turtles.
I know Leo is the leader who makes the plan. I know Donnie is the tech guy who figures out how things work. I know Mikey is the creative one who makes things fun. I know Raph is the enforcer who catches problems and isn't afraid to break things to fix them.
I know Splinter only steps in for the big decisions. I know April handles communication with the outside world. I know Casey shows up to test things in the field.
I've known these relationships since I was a kid. They're in my bones.
So I thought: what if I mapped my AI development team onto characters I already understand?
The Crew
Here's what I built:
The Core Four:
- -Leo — Strategic planner. He maps out PRDs and roadmaps. He decides what we're building and in what order. Before anyone writes code, Leo has a plan.
- -Donnie — Tech architect. He breaks down systems, designs APIs, figures out how the pieces connect. He speaks in diagrams and data flows.
- -Mikey — Creative developer. He builds the UI, makes things beautiful, adds the personality. He's the one who makes users actually want to use the thing.
- -Raph — Quality enforcer. He catches bugs, flags security issues, stress-tests everything. He's not here to be nice. He's here to make sure it doesn't break.
The Extended Crew:
- -Master Splinter — Senior advisor for complex architectural decisions
- -Bebop — DevOps, handling deployments and infrastructure
- -Rocksteady — Database specialist
- -Casey — QA tester finding edge cases in the field
- -April — Documentation and external communication
Each agent has their turtle personality. But more importantly, they have relationships. Donnie doesn't start until Leo's plan is clear. Mikey builds what Donnie architected. Raph reviews what Mikey built. They reference each other's work. They hand off cleanly.
Why This Works
The magic isn't the TMNT theme. The magic is that I finally had a model for how teams coordinate.
When I'm confused about when to think about the database, I ask myself: "When would Rocksteady show up in a TMNT episode?" Early, when they're planning the mission. Not at the end when everything's on fire.
When I'm tempted to skip testing, I imagine Raph standing there with his arms crossed, refusing to let me deploy. It sounds silly, but it works. The characters create accountability.
This is how I learn: I take something complex and map it onto something I already know. Familiar relationships become scaffolding for new understanding. The TMNT aren't just a gimmick—they're a translation layer between "how does software development work" and "how do teams I understand work."
Building id8composer
I'm using this system right now to build id8composer. It's the first real project where I'm not just vibe coding—where there's actually a plan, an architecture, a review process.
Is it perfect? No. I'm still learning. The handoffs aren't always clean. Sometimes Donnie and Leo argue about scope. Sometimes Mikey runs ahead before Donnie's done thinking.
But that's the point. Now I can see those problems because I have a model that makes them visible. "Oh, Mikey started building before Donnie finished the architecture" is a sentence I can understand. "Premature implementation before architectural decisions were finalized" is the same problem, but it doesn't land the same way in my brain.
The Bigger Idea
The future of AI-assisted development isn't just about speed. It's about building systems you can actually understand and maintain.
For me, that meant finding analogies that fit my brain. TMNT might not be your thing. Maybe you think in sports teams, or kitchen brigades, or heist movie crews. The specific metaphor doesn't matter.
What matters is this: when you're learning something complex, don't just learn the technical terms. Find the relationships you already know and map them on.
Models for new models. Analogies as architecture.
That's how I'm building this.
Cowabunga.
Update: One month later, I refined the system with hooks, sharper roles, and context persistence. The result? Deepstack built in 1/4 the time. The turtles grew up.