Nobody uses one AI model for coding anymore. Nobody serious, anyway. My multi-model coding workflow has me running four-plus models in sequence on most days, and I ship more in a week than I used to in a month. That's not hype - that's what happens when you stop treating AI coding tools like a single hammer and start treating them like a crew. Here's the actual stack, why it's built this way, and what most people get wrong about "vibe coding." What "vibe coding" actually means It's not "ask ChatGPT to build me an app." That's how you get a 400-line index.js with no error handling that half-works for 20 minutes before collapsing. index.js Real vibe coding is coding with leverage. You still need to understand what the code does. You still need to catch hallucinations. You still need to make architectural decisions - maybe more consciously than before, because the AI will happily scaffold the wrong architecture at 10x speed if you let it. What changed: the AI handles the typing and the boilerplate. The parts that used to eat 60% of my time - setting up file structure, writing CRUD routes, building form components I've built a hundred times - that's mostly automated now. What I bring is the product sense. Knowing what to build is harder than knowing how to build it. The "how" is commoditized. The "what" and "why" still aren't. My background is product design. Ten-plus years of it, including a long stint as sole designer at a fintech platform doing $4B+ in digital assets. That taught me to think about systems - how pieces connect, what breaks under edge cases, where the user actually gets stuck. That context is the thing AI can't replace. It's why a designer who codes can actually get further with these tools than a CS grad who just knows syntax. The four-model lineup These are the main players. Each one has a job. Grok (grok-code-fast) - The fast pass. I use this first. It's cheap, it's quick, and it's genuinely good at scanning code for obvious issues - logic errors, missing edge cases, things that'll blow up. I don't use it for fixes. I use it for triage. Grok (grok-code-fast) Claude Code - The surgeon. Best AI I've used for understanding context and making targeted edits. If I have a function that's almost right but subtly broken, Claude finds the problem without bulldozing the surrounding code. It reads the file, understands the intent, and makes the minimal correct change. This is rare. Most models over-edit. Claude Code Codex - The builder. Heavy refactors, multi-file changes, greenfield scaffolding. When I need to restructure a whole module or build something from scratch, Codex is the move. It's not as precise as Claude on targeted edits but it handles scale better. It'll touch 8 files in sequence and keep things coherent. Codex Gemini (Flash or Pro depending on context) - The reader. When I need to analyze a large codebase or understand a sprawling chunk of code I didn't write, Gemini's context window is unmatched. I'll drop 50K tokens of code in and ask it to explain the data flow. It handles that better than anything else I've used. Gemini (Flash or Pro depending on context) That's the core four. v0 gets a slot for frontend component generation. It's the fastest way to get a working UI component I can then iterate on with Claude Code. How the actual pipeline runs Real example of how a feature goes from idea to done: I write a rough spec in plain text. What the feature does, what the inputs and outputs are, what edge cases matter. This step is underrated. The cleaner my spec, the better the AI output at every stage.If I'm building frontend: I hit v0 first. Describe the component, get something that renders. It won't be perfect but it's 80% of the way there in two minutes.Grok does a fast pass on whatever exists so far. I'm asking it: "what's obviously wrong here? what breaks?" Quick, cheap, catches the low-hanging problems.Claude Code handles the refinement. Takes the rough output, applies targeted fixes, handles the business logic, integrates with the rest of the codebase. This is where most of my back-and-forth happens.If Claude hits a wall - something too structurally complex, or needs changes across multiple files - I hand it to Codex. Codex finishes the heavy lifting.Grok reviews the final output. Another fast pass. At this point I'm looking for regressions and anything the other models introduced.I read the code. Final check. I don't skip this. I write a rough spec in plain text. What the feature does, what the inputs and outputs are, what edge cases matter. This step is underrated. The cleaner my spec, the better the AI output at every stage. If I'm building frontend: I hit v0 first. Describe the component, get something that renders. It won't be perfect but it's 80% of the way there in two minutes. Grok does a fast pass on whatever exists so far. I'm asking it: "what's obviously wrong here? what breaks?" Quick, cheap, catches the low-hanging problems. Claude Code handles the refinement. Takes the rough output, applies targeted fixes, handles the business logic, integrates with the rest of the codebase. This is where most of my back-and-forth happens. If Claude hits a wall - something too structurally complex, or needs changes across multiple files - I hand it to Codex. Codex finishes the heavy lifting. Grok reviews the final output. Another fast pass. At this point I'm looking for regressions and anything the other models introduced. I read the code. Final check. I don't skip this. That last step isn't optional. You cannot ship AI-generated code you haven't read. The hallucinations are sneaky. They produce code that looks right and runs right in tests but breaks in production on a Tuesday when someone does something slightly unexpected. Your name is on the commit. Read the code. My multi-model coding workflow for backend vs frontend Different problem types call for different entry points. Frontend Start with v0. Describe the component - what it does, any constraints, the general look. Get the initial render. Then switch to Claude Code for every iteration after that. Claude is better at "change this specific behavior" than v0 is once you're past the initial generation. For anything that needs complex state management or integration with existing backend types, I'll write that part myself or with Claude Code from scratch rather than trying to wrangle v0's output. v0 is a starting point, not a production artifact. Backend Codex for scaffolding. Give it the data model, tell it what the API needs to do, let it build the structure. Claude for the business logic layer - anything that involves conditionals, data transformation, edge cases. Debugging: paste the error into whatever's fastest. Usually Grok for the first look, Claude if it needs deeper investigation. For architecture decisions - where to put things, how services should talk to each other, what the data model should look like - I make those myself. I'll ask Claude or Grok to rubber-duck a decision with me, but I'm not delegating architecture to a model. That's the one place where the AI's lack of business context will hurt you. The MCP layer This is the part most people aren't talking about yet. MCP (Model Context Protocol) tools change how much context your AI coding setup can actually see. Without good context, you're pasting code snippets manually and hoping the model understands the surrounding system. MCP (Model Context Protocol) The one I use daily: sammcj's devtools MCP. At ~9K tokens it gives me basically everything meaningful about a codebase - file structure, dependencies, key functions. I drop this context at the start of any substantial session and the model quality jumps immediately. Less hallucination, more accurate edits, better architectural suggestions. sammcj's devtools MCP If you're using AI coding tools without MCP integration, you're leaving a lot on the table. The model can only help you as much as it understands the system. Give it the context. What this costs People act like the price of these tools is a dealbreaker. It's not. But you should know what you're actually paying. I'm on OpenAI Pro ($200/month). That's basically required if you're using Codex for real work - you need the usage headroom. Claude Pro or Max depending on the month. Grok is included in X Premium, which I'd pay for anyway. All in, I'm spending around $350-400/month on AI tooling. I get somewhere between $800-1,200 of nominal usage value out of it based on what the APIs would cost at direct rates. And I ship maybe 3-4x faster than I did 18 months ago. The mental model I use: I'm hiring a part-time engineer who's excellent at specific tasks, needs supervision, and occasionally hallucinates. At $400/month, that's a steal. The thing that makes it work is knowing which part-time engineer to call for which job. That's the whole game. What breaks this workflow Being honest about failure modes: Bad specs kill everything. If I'm vague about what I want, every model in the chain produces something subtly wrong in a different way, and now I have five things to reconcile instead of one thing to fix. Time spent on the spec is time saved everywhere downstream. Bad specs kill everything. Chaining without reading. Running model output straight into the next model without reviewing it first compounds errors. Grok flags an issue, Claude "fixes" it, Codex rebuilds around Claude's fix, and now the original problem is buried under three layers of AI decisions you didn't validate. Read between steps. Chaining without reading. Using the wrong model for the task. Claude on a large multi-file refactor gets expensive and sometimes loses coherence. Codex on a targeted three-line fix is overkill and occasionally makes it worse. Matching the model to the job isn't optional. Using the wrong model for the task. Architecture by committee (with AIs). I did this once - asked three different models how to structure a feature, got three different answers, tried to synthesize them. Waste of time. Architectural decisions are mine. I use models to validate and poke holes, not to make the call. Architecture by committee (with AIs). The honest take on vibe coding Most of the backlash against it is people who watched someone generate slop and extrapolated. Most of the hype is people who generated something that worked for 10 minutes and declared victory. The actual version is somewhere more boring and more useful: AI handles commodity work at speed, you handle judgment. The skill ceiling on building shifted. You don't need to memorize syntax. You do need to know what good architecture looks like, how to write a tight spec, when the AI is confidently wrong, and what the user actually needs. I couldn't do this workflow without 10 years of product and design experience. Not because the tools are hard - they're not. But because the inputs I give them are shaped by that experience. The prompts are good because I know what I want. The reviews catch problems because I know what breaks. The architecture holds because I've seen what doesn't. If you want to build a similar stack: start with one model and learn it well. Understand its failure modes. Then add another model where you keep hitting walls. Don't adopt the whole thing at once - you'll just have four sources of confusion instead of one. Read everything you ship. That's the one rule that doesn't have exceptions. You can see more about what I'm building and how I think about this stuff why prompt engineering is dead. And if you want to dig into related topics - multi-agent systems, prompt engineering, tool comparisons - check out the MCP server I built to find threads that go deeper. why prompt engineering is dead the MCP server I built

OpenAI

The Design Work Nobody Posts on Dribbble

Portfolio

Nobody Serious Uses One AI Coding Model Anymore

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

The Noonification: Use This 7-Step McKinsey Framework to Solve Any Problem (1/10/2023)

The Noonification: A Taxonomy of Inclusiveness (1/11/2024)

The Noonification: What is the InfiniteNature-Zero AI Model? (11/19/2022)

10 Ways AI Has Changed Our Lives

100 Days of AI, Day 8: Experimenting With Microsoft's Semantic Kernel Using GPT-4

Accessible Data Visualization in Fintech: Why It Matters

The Noonification: Use This 7-Step McKinsey Framework to Solve Any Problem (1/10/2023)

The Noonification: A Taxonomy of Inclusiveness (1/11/2024)

The Noonification: What is the InfiniteNature-Zero AI Model? (11/19/2022)

10 Ways AI Has Changed Our Lives

100 Days of AI, Day 8: Experimenting With Microsoft's Semantic Kernel Using GPT-4

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps