Six durable AI coding workflow patterns that hold up across changing tools and hype cycles
Nate B Jones presents a framework of six stable AI development workflows, illustrated with examples from industry leaders.
Summary
Nate B Jones argues that most AI coding advice is too tool-specific and brittle — tied to a particular prompt, hack, or application that quickly becomes obsolete. Instead, he identifies six workflow patterns that remain stable regardless of which AI tools are in use, drawing on the practices of named industry leaders including Claire Vo, CJ Zafir, Eric Provenar, Gurgaly Oros, Melvin Vivas, Simon Willis, Riley Brown, Dan Shipper, and Peter Yang. The six patterns are: codebase mapping and onboarding, planning-first development, natural language or vibe coding, AI-augmented debugging, AI-assisted code review and refactoring, and context engineering and consistency enforcement. Jones closes with a direct appeal to non-technical people, arguing that the barrier to building software has dropped to the point where anyone with a clear idea can now act as their own technical founder.
Key Takeaways
FULL TRANSCRIPT
The problem with tool-specific AI coding advice
Nate B Jones: One of the challenges with artificial intelligence and development — or building in code — is that everyone is going for "this is my particular hack," or "this is my gimmick that I use," or "this is the tool set." And it all feels really brittle. It feels like if you don't use that tool, if you don't use that prompt, and if you don't build exactly that thing, it's not going to work.
I wanted to do something a little bit different. I wanted to go through and look at work patterns that I see being practiced across multiple industry leaders. Now, these people are not all founders. Some of them are indie hackers. Some of them are product leaders. They exemplify how rich and how varied the opportunity is right now for people who want to start building in software. They also exemplify how many different tools you can use.
I include lots of tool reviews in this article. You will not be short of those if that's your thing. It's probably the most comprehensive look at industry coding tools with AI anywhere on the web. That being said, I think the heart of this approach is really the six proven work patterns that I've been able to uncover, and the examples I can give you of how different tools can be stitched together to create those work patterns.
I view those work patterns as the hidden stable elements in an otherwise endlessly changing sea of new tools, new patterns of prompting, new leaders that come along and give you new hacks, new applications. Every time I turn around, there's a new thing in AI. And so what I wanted to get to were these patterns that were battle-tested — that you could go back to and bet on.
So with that in mind, let's look at all six and look at examples from leaders along the way.
Pattern 1: Codebase mapping and onboarding
You might not think of that as a development pattern, but it really is. You can use AI to quickly understand existing codebases. You can generate maps, summaries, or graphs for onboarding or legacy dives. This is especially useful if you have an existing codebase, obviously. And if you want to bring someone in on your team quickly, you can treat AI output as a starting point for further refinement.
In this context, this can accelerate onboarding very rapidly for new builders. It can extract high-level context really quickly, and it's very useful for people who are non-engineers to get to know a codebase. I've actually written some prompts that are designed to help you get to know a particular coding pattern that you're using — a very similar process.
Here are some examples from actual leaders that use codebase mapping and onboarding. Claire Vo uses Devin for initial repo analysis and then refactors her assessments in production codebases based on Devin's assessment. She'll use Devin to generate PRs or tests with roughly an 80% success rate on the first try, she says, and then she can train into Cursor for edits down the road.
CJ Zafir loads PRDs and plans into Cursor — specifically Cursor's `.cursor/rules` file — to establish persistent context, and then uses Gemini 2.5 to scan a large codebase. Eric Provenar primes Claude Code with a repo prompt and an `onboard` file for context, and then enables structured XML edits from there.
These get very tactical and specific, and by themselves you might be overwhelmed. "Repo prompt/onboard file — what is that? `.cursor/rules` file — what is that?" You can look those up, and I give you more information in the report to dig into it. It's not that you are going to be lost looking things up. It's that you will be lost if you don't see the common pattern. And that's what I want to give you.
Claire is doing initial assessment with Devin. CJ is loading PRD plans into cursor rules. Eric is loading Claude Code with a repo prompt and onboard file. They're giving it the context it needs to map.
Gurgaly Oros uses Claude Code's `codex` command line for session context on larger projects. Melvin Vivas uses Windsurf's Cascade for auto-context on large databases. You can see all the different tools you can use for this. Simon Willis uses Claude Code and an onboard file as well, but he uses it for GitHub Actions context. You can mix and match these tools in a lot of different ways.
The goal isn't for me to give you the single golden best way, because someone's going to come along — ChatGPT 5 will come along — and it will change the way we think about what is best on a particular tool basis. It will not change the fact that we will use AI for codebase mapping and onboarding. That's going to stay, and that's why I call it out.
So what are some tools that get mentioned a lot here? Claude Code, Devin, Cursor, Windsurf — I also want to call out Aider. Aider is helpful here as well.
The principles to pull out of this first mapping and onboarding piece: point the AI at a repo, prompt it for summaries or graphs, and then refine from there. I would start with a small codebase. I would update context files regularly. And for teams, you can share those AI-generated docs almost like documentation for collaborative onboarding.
Pattern 2: Planning-first development
I actually teach this one a lot when I am teaching my Maven course. You want to use AI as an architect to outline plans, functions, logic, and edge cases before you generate code. Then you approve and refine and proceed. You can actually simulate pseudo-code as a way of getting there — you can have Claude code up a React artifact as pseudo-code that helps you understand what you want.
This prevents tangential outputs. It ensures coherence. It ensures maintainability. And conveniently, all the work you did doubles as documentation.
We'll go back to these leaders to see how they're doing it. CJ Zafir asks Cursor for approaches and plans, generates an actions list, builds in chunks, and uses o3 mini to develop — I kid you not — 40-step plans. Dan Shipper sets up opponent processors in Claude Code for parallel sub-agents with opposing goals and then synthesizes outputs on long runs. Again, it's a planning action. Eric Provenar delegates planning to o3 via chat and then Claude applies edits. Gurgaly uses plan mode in Claude Code and the Codex command line for roadmap sub-agents for parallel tasks.
I want you to think about this as: these leaders have tools they feel good about working with, and then they're going through these workflow motions in a way that makes sense to them. You too will probably have tools you prefer. And even if your tools are not the same ones — maybe you're not using Claude Code, you're using something else — you can still go through the same process. You can plan for Lovable just like you plan for Claude Code.
Peter Yang demos three agents in Claude Code with custom commands like "think ultra hard" for quality plans. Riley Brown uses Cursor Composer for planning in diagram phases, and he finds that if you're not planning, outputs can be verbose and wrong. That's actually something we see across the board.
Dan Shipper notes that you can have high-load Claude throttling issues, which you can get if you're not planning well. And you can get model refusals if things get pushed too far — Claude can just absolutely refuse if it runs out of context. CJ Zafir notes that Windsurf sometimes will break after initial steps.
So essentially, the pitfalls are reminding us of the importance of planning, because if you have something that's somewhat brittle like that, you'd better have a solid plan so that you can roll back to it and continue to follow it. The people I know who are able to build successful applications put their 80/20 effort into planning first and then execution, because they can always go back to the plan.
The principles are: prompt for a breakdown. Look for a sketch or solution design — something that actually gives you a full picture of what you're trying to solve. Approve that plan before you code, and then use whatever tools you need to plan out the layout of complex features. You can do it in Claude Code, as you can see. Some people are doing it in Cursor. Some people are doing it in Windsurf. You can probably do a version of it in Lovable as well. And then, wherever you can, go back to the plan over time. You need to have habits of work that push you back to the plan.
Pattern 3: Vibe coding and natural language-driven development
This one is related to tools and it is not going anywhere. You know what the fastest tool to $100 million is? It's not Cursor anymore. It's Lovable — the vibe coding tool. It is such a big deal that Microsoft launched their own copycat version for GitHub called Spark.
Natural language-driven coding, or vibe coding, is in a sense its own pattern, and I wanted to give it its own airtime. You prompt in natural language for code generation, you iterate for refinements, and it's ideal for prototypes, scripting, and exploration. And you can honestly build real applications. I know people who have built a CRM for small services businesses off of Lovable. I know people who have built small applications focused on crypto monitoring off of Lovable.
The strength is speed. You can get through things very, very rapidly. There's absolutely zero setup in many tools, and non-coders are not blocked. The only thing blocking you, if you are a non-coder, is increasingly the clarity of your intent. If you are clear about what you want, you can make it.
Riley Brown uses Cursor for a 100% AI workflow and then uses Replit to go quickly from idea to deploy — he's demonstrated a CRM in one prompt and can quickly game out the UI. Melvin Vivas prompts Windsurf for deploys and switches to Gemini for the UI. Peter Yang types app descriptions in Claude Code and asks agents to build them.
You'll notice that even though it's called vibe coding and I talk about Lovable, these leaders are not confining themselves to prompt-driven tools like Lovable, Bolt, GitHub Spark, or similar. They're using Cursor for this. They're using Claude for this. You can vibe code in these tools.
CJ Zafir prompts Cursor for tweaks and v0 for UI. CJ wrestles with the idea that if you have ambiguous prompts, you are aiming the code off base. And CJ is not the only one — Peter, Melvin, Riley, and others have mentioned cases where if you don't prompt with intention when using natural language, you end up steering your codebase in the wrong direction.
One of the biggest challenges with natural language-driven development is that you have to interpret an ambiguous human phrase into very unambiguous code. The fact that it kind of works is a miracle — and it's getting much better. Lovable actually launched an agent feature recently, and the focus of that agent is to help you burn fewer tokens on Lovable by making surgical fixes and improving the accuracy of code editing and updates, because Lovable is aware that you need the option to refine and iterate as you see what the system initially infers about your human language intent.
Application principles for vibe coding: you have to describe very clearly. You have to review for security and style. You should start small and iterate. And you need to pair it with planning — I emphasize that so much. If you want to read more, I have a whole article on vibe coding that's separate, called the Vibe Coding Bible, and it will help you get deep into it. I think it's a discipline that everybody would benefit from playing around with, given the strength of these tools.
Pattern 4: AI-augmented debugging and testing
Bug, bug, bug, bug, bug — I hear about bugs so many times. You want to pull AI into debugging. You want AI to help you analyze errors, suggest fixes, loop until resolved, and automate fix-run cycles and tests as much as you can.
Examples from leaders who have tackled this: Claire Vo uses Devin for debugging with Datadog and generates tests with human review. Riley Brown uses Cursor's terminal access for API setups and then fixes them via diffs. Simon Willis reviews commits file by file in Claude Code.
You have to recognize that it's not always going to work well. I have seen cases where you just pound on that bug over and over again and you don't get anywhere. You need to recognize that any fix may introduce regressions — reducing that was actually the goal of the new Lovable agent build. Logical bugs may need humans. If Windsurf is just stopping mid-session, which happened to Zafir, humans may need to step in to figure out what's going on. And Devin may, in particular, underperform in messy repos. So keeping your code organized and neat is one of those hidden success factors for building.
From a principles perspective: you want to make sure that your error traces are very clearly presented to the AI. One of the hidden things with these tools is they can't see the localhost previews or the previews on your screen that you sometimes see if you're prompting in Lovable. They don't know. You have to paste the error traces that you're getting clearly into the model. You should be able to prompt for a clear root cause assessment — I have a prompt for that, designed to dig in, find the root cause, and come back with a proposed fix. And then you need to make sure that you are fixing cautiously. Make sure you know what files are being touched. I would recommend sandboxing if it's a real production build, so that you can see it working in the sandbox before you deploy to production.
Pattern 5: AI-assisted code reviews and refactoring
Imagine AI as a pre-pull reviewer. Prompt it for feedback, automatically refactor, and so on. Claire Vo chains Devin to chat, PRD for PRs, and Cursor for surgical changes — enabling Devin to act as an initial reviewer. Gurgaly uses Cursor and Windsurf for inline edits during rollouts. Simon Willis commits file by file after reviewing Claude Code output.
Some of the pitfalls here: if you trust blindly — if you do not actually check what the system is doing — you can get nasty regressions. Cursor can edit outside scope, but it's not just Cursor. I have seen report after report — Lovable does this sometimes, Claude Code will sometimes do this. Complexity can lead to confusion, and you can get these larger, beyond-scope edits.
The principle to call out here is that you want to prompt for a review, and you want to prompt very specifically for the constraints and guardrails around that review. If you want to review a particular part of the code, say it. Say what it is. Constrain it as much as you can to avoid that over-editing problem. Make sure you have humans for final sign-off. And make sure that you have clear rules on how you want the resulting code to look and work, and any dependencies that it's related to.
Pattern 6: Context engineering and consistency enforcement
Yes, a lot of words there, but we'll get there. You want to maintain AI-readable files — like a `claude.md` file or a `.cursor/rules` file — with clear guidelines that prepend to prompts for on-target outputs. This is what I mean when I talk about maintaining your house style. It's going to reduce drift. It will reduce hallucinations. It reinforces best practices across your codebase, and it compounds benefits over time.
CJ Zafir uses `.cursor/rules` and Cursor for this. Eric Provenar uses `claude.md` in the repo. Gurgaly uses Model Context Protocol to handle context limits. Melvin Vivas uses Cascade for auto-context.
I am combining both context engineering and consistency here because I think they're related. If you have consistent rules in a markdown file, you can more reliably use Model Context Protocol to go and get context — surgically get context and not over-get context. It's really important that you have root files with clear principles and examples.
I also want to call out that Claude Code sub-agents have recently launched. Sub-agents enable multi-agent workflows like opponent processors or parallel task agents, and this allows you to build prompt-based setups that are quite complex. If you can get into responsible manual orchestration of these sub-agents — give them separate rules and separate tasks — you can do incredible things. You can have one agent expanding your PRD. You can have another agent architecting. You can have a third agent building. And so on.
It is really important, though, to follow these principles as you apply it, because sub-agents essentially just accelerate you. They don't actually give you different capabilities. They just enable you to go faster if you're already applying these principles successfully.
Reviewing all six patterns and their durable principles
I want to go through these six again and make sure you really understand them. I don't want you to be confused by the tool mentions. I want you to think about the principles.
Codebase mapping and onboarding. The durable principle here is that you are pointing the AI at the repo, you are prompting for summaries of the repo, and you're refining manually.
Planning-first development. You are prompting to understand what you want to build first. You're developing a plan first. You're approving the plan before coding. It's really, really critical.
Vibe coding or natural language-driven development. It doesn't have to be in a vibe coding tool like Lovable, although for many people that's a great starting point. You must describe clearly what you want — it goes back to that planning piece. You have to review it for security and style. You should probably start small if you haven't done it before, and be willing to iterate thoughtfully. Sometimes in parallel — I will sometimes build with Bolt and with Lovable and with Replit in parallel to see what gets me the farthest.
AI-augmented debugging and testing. You want to make sure that you are pasting your actual error traces and communicating clearly what's wrong. That you are being very specific and prescriptive about how the system will get to root cause, about the kind of suggested fix you will accept in line with your house rules. And you should apply fixes cautiously, especially in production codebases.
AI-assisted code reviews. You want to be in a place where you can prompt for review of the code and then constrain the review to just the space you want looked at. Keep in mind, humans will have to do a second pass, but you can use a tool like Devin to go and get a lot done quickly. Claire Vo is a great example there.
Context engineering. It is really important to look at context engineering as an opportunity to reduce drift and reduce hallucinations through two basic principles: one is maintaining AI-readable files, and the other is being clear about your prompts for on-target outputs. When Gurgaly uses Model Context Protocol, it's a combination of having clear rules and then having clear prompts that tell Model Context Protocol where to go.
Why these patterns matter — and a call to non-technical builders
These are the six patterns, and I'm going to dive deeper into them in the article. I'll talk about each of the leaders. I'll talk about all of the different pitfalls that we've seen come across from those tools. No tool is perfect. But the thing I want to emphasize is that this overall review of workflow patterns is durable. When ChatGPT 5 comes out — maybe later this week — you are not going to lose your way, because you can slot it into these durable patterns. It's something you can hang on to in a world that's changing very, very fast.
I want to close with a question that I get a lot: why should I care? And I want to tell you that prompting for development — or using code to develop with AI — is one of the easiest and most efficient ways I have ever seen at helping people understand what AI can actually do, because it's so clear. The prompt runs or it doesn't run.
So even if you don't plan to ever be a builder, I encourage you to think about exploring Lovable, exploring a simple tool that lets you play around with developing code to express your idea. The most powerful thing I have shared with many people in the last year is that the old fears — that they were not technical enough, that they could not be their own technical founder, that they could not be their own builder — are not true anymore. You can be your own technical founder. You can be your own builder for any idea you want to create.
I have yet to see people really not be able to do something because they didn't have the knowledge. When you know how to ask AI to teach you — which is something I've written about — and when you know how to apply these six work patterns in ways that enable you to build with AI, you are in a position to make the dreams of what you want to make come true.
Now, I'm not saying — and I don't believe in — a future where all of us will only build our own apps and we won't ever buy apps from each other. I don't think that's true. Cooking has been around for a long time. We have kitchens, we cook, but we still go out to restaurants. We still DoorDash. In the same way, we're still going to buy software. But I think knowing how to cook and knowing how to build are equivalently useful skills. And actually, knowing how to code is not more difficult than knowing how to cook now. It's become much simpler thanks to artificial intelligence.
And so if you are listening to this and you have never tried building, this is my plea to you. I want you to not be left behind. I want you to be able to try. And that is why I have taken the time to break out these tools and these leaders' examples into discrete, specific, durable patterns.
And if you are building, the durable patterns are pretty helpful too, because one of the things I hear from people who build is that it's hard to keep up — everything changes. These durable patterns aren't going to change. They may have new tools that slot in, but the patterns are still going to be there. Vibe coding will still be there tomorrow. It's not going to go anywhere.
So look at these as the six underlying work patterns of the AI development revolution, and figure out where you want to level up your own work so that it is more effective. Maybe you're really good at vibe coding and what you need to learn about more is planning. Maybe what you need to learn about more is review. There are things we can all grow in. I personally think I can get better at test-driven development — at telling the AI to run unit tests as I build. That's an area of growth for me. Everyone has their area of growth.
My goal with this is just to lay out the patterns so that you can jump on them and find them useful. I hope this was helpful. I hope this demystified some of the chaos and some of everything that's changing with AI right now in development.