Into the Gnar, Episode 2: The Vibe Coding Reckoning

Somebody on your team has already vibe coded something. You may not know about it yet.

This is the episode to send to your ops leader, your COO, or the person who just shipped an internal tool with Cursor or Replit and said, look what I built. Nick and I get into what vibe coding actually is, why it's spreading inside companies that never thought of themselves as tech companies, and what happens when that AI-generated code becomes load-bearing infrastructure with nobody to maintain it. The short version: vibe coded apps are the spreadsheets of 2026. Tribal knowledge, siloed workarounds, one person who knows how it works, except now they're wired straight into your ERP.

We also cover the predictions that 75% of technology decision makers will face moderate to severe technical debt by the end of 2026, the new idea of comprehension debt (code nobody in the building understands), and the velocity cliff where every new feature starts breaking something else. Plus Nick vibe codes his own security camera system, we both confess to swearing at our agents, and we explain the line that separates vibe coding from agentic development: the cost of code production is approaching zero, and the cost of poor planning is skyrocketing.

Watch the full episode above, or read the complete transcript below.

Key moments

• 0:00 The bill is coming due: who this episode is for
• 1:01 Nick vibe codes a replacement for his Nest camera interface
• 5:20 A client used Lovable the right way: as a communication tool, not a production tool
• 7:40 News: 75% of decision makers face moderate to severe technical debt by end of 2026
• 13:37 Vibe coding vs. agentic development: same tools, completely different process
• 16:30 News: comprehension debt, when the humans responsible don't understand the code
• 21:30 Today's developer is a team manager, and the team is agents
• 23:37 News: non-technical teams are building internal tools nobody owns
• 28:10 The excavator analogy: digging holes is fun, foundations are work
• 28:50 Vibe coded apps are the spreadsheets of 2026
• 30:20 What a vibe-coded codebase actually looks like when you open it up
• 36:15 The velocity cliff and the doom loop
• 39:07 Rapid confession: do you swear at your AI agents?
• 41:13 What the Gnar does differently: Context-Driven Development
• 44:01 If something in this episode felt uncomfortably familiar

Full transcript

This transcript has been lightly edited for readability.

Mike: Welcome back to Into the Gnar, where the cutting edge of software gets built. I'm Mike Stone, here with my co-founder Nick Maloney, and today's episode is one I've been wanting to make since we launched this show a whole one episode ago. It is vibe coding. You've probably heard the term. You may have an employee who's already doing it. And if you haven't heard about it yet, you will very soon, because the bill is coming due for a lot of companies.

This is the episode to send to your ops leader, your COO, the person on your team who just shipped something with Cursor or Replit and said, look what I built. We're gonna talk about what vibe coding actually is, why it's happening inside of companies that never thought of themselves as tech companies, and what happens when that AI-generated code becomes load-bearing infrastructure with no one to maintain it.

Let's get into it, Nick. How are the vibe codes on your end?

Nick: I went deep this week. I went down a vibe coding rabbit hole that I didn't think I'd go down, but did, completely outside of work. I got an email from my friends at Google and Nest saying that my subscription was coming up, and it was 180 bucks, and my Nest camera was getting long in the tooth, and it doesn't take much to convince me to buy some new toys.

So I bought a new Reolink camera, a new doorbell camera. It got good reviews. It's good tech. Got it all plugged in, and the quality was good, and the live stream was good. But because it's self-hosted, you don't get all of the Big Brother functionality that Google provides, like alerts and facial recognition and all of that fun stuff.

And I didn't really give that a lot of thought. As I was playing around with it, I happened to have OpenClaw up, and I'm like, gee, I wonder if I could vibe code something that replaces the Nest interface. I went down that rabbit hole and learned more than I ever wanted to about security camera specs and all that fun stuff.

And it actually turned out much better than I anticipated. I went to town with OpenClaw. It even went into the admin interface of the camera, reverse engineered it, and then we got into facial recognition tech and all of that fun stuff. But now on my home lab server, I have an app that gets the stream from the video. I can tag people in it. I get alerts on my phone. It works surprisingly well. It was a pretty intense vibe coding session. I will say this predates the cutoff from OpenClaw, so my approach would now be different. So it was probably my last really good vibe coded session with Pinchy, my OpenClaw agent. But it was pretty fun.

Mike: Yeah, Pinchy is about to get a lobotomy, huh?

Nick: I'm optimistic. I don't know if I'd call it a lobotomy. It's now running on Claude, which I'll probably save for another episode. But yeah, the whole OpenClaw ecosystem has changed, and that might have a net impact on the number of one-star vibe coded projects on GitHub. But I definitely loved it for what it allowed me to do for a lot of these projects. So I'm glad I got this one last run out of it.

Mike: Yeah, that's super hardcore. You're such a nerd. I love it. But how would somebody non-technical do that? To me, that's outside of the stereotype of vibe coding in my mind. Granted, you were at the wheel but not driving. You were on Tesla autopilot mode or something. If I'm non-technical, how do I build that?

Nick: That's the danger of giving a software engineer the keys to the car. You go down these real technical tangents and you're learning about protocols you didn't know existed. And quite frankly, I don't know if there's an approachable way for many folks to do that. Not to say that you couldn't. I think it would just take a lot longer and require a level of patience to understand the moving parts, right? Just to reverse engineer this, you have a stream of video coming in, so you'd need to vibe code and tell your agent, hey, there's this video stream and a product to get access to it. And then once you have that, describe what you want it to do. I guess it would be possible.

Mike: I think the short answer is you don't.

Nick: You just have to break it down into a lot of steps and have an understanding of how it all works. Doable, but there'd be some patience involved to read boring documentation and things like that. I think this would be an advanced topic for most vibe coding enthusiasts.

Mike: Yeah. So I had an experience with a client that was more in line with what I think of when I think of vibe coding, and probably on the opposite end of the complexity spectrum from your project. We were in the middle of discovery for a new app they were building. We were driving this process of trying to figure out what this product was going to be, and in doing so we made some prototypes, and the client was like, you're there, but not quite. And then by the next meeting, they had vibe coded a tool in Lovable that just communicated the direction they wanted that feature to go in.

And it was totally throwaway. It was never intended to actually be used. Neither were the prototypes we were creating. But it was the perfect communication tool for that phase of the project. We instantly got aligned, and it solved a lot of the problems of non-technical people trying to communicate design, or non-product people trying to communicate design, and it got us through a roadblock really fast. It was a super successful version of vibe coding.

Nick: Yeah, I've had some similar experiences and completely agree. It's such a good foundation for requirements, because you're not just interviewing or generating Google Docs. You have something that they've gone through cycles with, tested and thought through to some degree. And they're not necessarily thinking about the constraints of the infrastructure or the hardware. They're just thinking about, how do I solve this problem that I have? And letting the agent figure out the implementation details. But then you have this artifact that you can take and run with, and solve for the engineering problems. They've expressed their domain and their problem, and it makes it a lot easier to have that as the baseline, versus what we used to have, which was user interviews or maybe a simple diagram. So I'm a huge fan of that approach.

Mike: Yeah, it solves a lot of problems. It also creates a lot of problems, potentially. Which brings us to our news of the week. We've got three stories related to this topic. The first one, very related to what we were just talking about: 75% of decision makers will face moderate to severe technical debt by the end of 2026.

Research predicts 75% of technology decision makers will face moderate to severe technical debt by 2026. I think I just read that twice. Gartner goes further though, predicting prompt-to-app approaches will increase software defects by 2,500% by 2028. GitClear analyzed 211 million lines of code and found code churn has doubled and code reuse has dropped significantly since AI tools became mainstream. A LeadDev survey found 54% of engineering leaders plan to hire fewer junior developers due to AI, creating a compounding future problem where no one will exist to clean up today's debt. So Nick, when you look at these numbers from the outside, does this feel like what we're actually seeing in the field?

Nick: That number seemed high to me at first, 75%, but it's probably not wrong. I think we're just starting to see vibe coded apps in the wild, and even if they're done with discipline, they have a lot of tech debt. Especially when we get into MVP phase, and we've always had pretty strong baselines of technical debt. So what I'm curious about is the increase over the historical baseline of what it was.

Semi-relevant: I was actually working on a project yesterday with a team on a really old legacy application that had a ton of tech debt. And the relevant piece here is they attempted to quantify what the impact of that was. What does that mean from a leadership position? What friction is it causing? There's a few methodologies to do that, and they used one based on cyclomatic complexity, which is the linearly independent paths through a program's source code. In layman's terms, it's basically: how hard does this source code make it to work on, and how much does it slow me down?

I think we're gonna see a lot more of those metrics used, so they can help inform when you need to pay that down. Because I think we need to accept that vibe coding is gonna introduce technical debt, and maybe that's okay, but at what threshold do you need to address it? If you have an approach to quantitatively say, here's the point where it sucks and makes it hard for my team, using something like cyclomatic complexity, there's benefit to that. It's a nerdy tangent, but we're gonna see these new ways to evaluate the tax of having that technical debt. Kind of a rant there, but I literally had this conversation yesterday and we went down this rabbit hole.

Mike: Yeah, no, that tracks. And maybe it makes sense to get a little higher level for a second and roughly define vibe coding. It's basically these sites like Lovable and Replit and v0, where you can type into a prompt as if it's ChatGPT or Claude, and it'll make an app for you. Instead of giving you text back, it'll write the code. So you can type in, make a clone of Shopify, or make a clone of Spotify, and it'll just make that for you. In doing that, though, while it is mind-blowing and makes you feel like you have superpowers, it causes a whole host of problems, especially when you get into higher levels of complexity in what you're asking it to do.

But when I read this story, I actually don't think, like the headline says, that technical debt is getting worse. I think when the best models are being used by capable people, technical debt is getting very much reduced. My only complaint is that it duplicates a lot of logic. But I don't think this is an AI problem. I think this is a human problem. And it comes down to using the best tools, using the best models, and a good process.

I think companies will cut corners. I've worked on a project where we used Claude Code, and strictly Opus for the most part, and I was working with a developer that was just using Sonnet. Even in that, you're still buying, in my mind, the best LLM provider. But just the difference between Sonnet and Opus itself had vastly different results. Opus was so much better. And they're only gonna get better from the baseline today. So I think the debt, when managed responsibly, is gonna go way down. I think the huge issue is that you have people that are not equipped for the job trying to do something they don't have the experience to do. And that's where this 2,500% increase in defects is really gonna manifest itself.

Nick: Yeah. My hot take on this, and we've talked about this, is that there's a distinction between vibe coding and agentic development. I'll oversimplify, but I think that distinction is your approach and the process in which you use these tools. When I think of vibe coding, and I do this and consciously make that choice, I just want to riff on an idea. I'll go right into Replit and start hammering into the prompt what my idea is. At the Gnar, what we practice, when we say agentic development, is we have a lot of thought. We are building PRDs. We have a lot of process baked in. So when it comes to the actual code generation, we've established guidelines. We have our Claude prompts, our tools, and the code output is pretty lean and mean, I would say. It passes muster for what I'd like to see as a software engineer, and it doesn't have that technical debt, because we're following that agentic development process and it's not vibe coded.

So maybe that's the message. If that becomes a concern, it is exactly like you said, one of process. If you take this agentic development mindset, this largely goes away, and your code is maintainable, manageable, and you can live with it. It's not a ticking time bomb.

Mike: Yeah. And the executives, especially the non-technical executives that we talk to, they hate the term technical debt. They have a reaction when they hear that term. And it's what it is. In plain language, it's: every new feature takes longer and costs more than the last one. And eventually you're spending all of your budget just keeping the lights on, unable to build anything new. It causes innovation to stall. The term for it is technical debt, but no one wants to hear that. The executives are just like, fix it. It mounts over time and it's super hard to pull out of.

And those vibe coded solutions, even if you get a small app from them, it's riddled with technical debt. I guess we'll get more into that later on, but it doesn't really surprise me that the predictions of this type of debt are so high. As long as vibe coding still happens, I think people are gonna realize vibe coding's not as fun as they think it is when they actually have to maintain something in production. And if that's true, and they lean on the professionals to do the work, then this may not be as severe.

But let's move on to the second story here. This one's on comprehension debt, a new type of debt. AI-generated code works until it doesn't, and then nobody knows how to fix it.

This is a new term getting traction in the developer community. Traditional technical debt means code is messy and hard to maintain. Comprehension debt is worse. It means the humans responsible for the code don't actually understand what it does. Vibe coding was coined by Andrej Karpathy, maybe that's how you say his name, I don't know, in February 2025. In his words: fully give in to the vibes, embrace exponentials, forget that the code even exists. Collins English Dictionary named it Word of the Year for 2025. Developer Simon Willison offered the key distinction: if an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding. That's using an LLM as a typing assistant.

GitClear data shows AI-heavy codebases have 8x more duplicate code blocks than human-written code. In January 2026, a multi-university academic paper titled "Vibe Coding Kills Open Source" argued the practice is negatively impacting open source ecosystems by reducing meaningful contributor engagement. And on the security side, AI co-authored code shows 2.74x higher security vulnerability rates and 75% more misconfigurations.

Nick, you've been calling this for a while. The idea that one bad line of context is a hundred lines of bad code. How does comprehension debt connect to that?

Nick: Good question. I think even looking at it from the lens of, you're going to continue with AI development on a project: if you don't have any artifacts explaining the why behind anything, that's gonna be really hard to extend. We've been talking a lot about similar topics with the team, and one term slash tool that we've been reaching for is ADRs, architectural decision records. It's basically a way to catalog why technical decisions were made. It doesn't solve for everything around comprehension debt. It's a specific piece of it.

But understanding that you need to comprehend the code, and have documented artifacts when you go into building these, is super helpful. Starting to layer in tools like ADRs is really gonna be helpful, both for the agents as they're working, because they're gonna have an understanding of the technical decisions, and also for the humans. 'Cause when you started a project, and then maybe six months or a year from now you're like, why did I do that? You have this documented history of why you made those particular choices. That's just one example, but I find it helpful.

Mike: That's responsible agentic development. That is not the reality in vibe coding land. No person in operations is making ADRs for their Lovable vibe coded app. Again, I think this is just a human problem. This is not an AI problem. We are making this whole thing up. This only exists because we have people that shouldn't be doing this job, and the comprehension debt is there because they have no idea what they're doing.

I actually think, as a developer using AI responsibly, the comprehension debt either doesn't exist or goes away so fast, because you can use AI to get up to speed on a codebase or a particular problem area so much faster. I've resolved bugs on apps I haven't touched in years as if I was working on them yesterday, just because it's so easy now to get up to speed and ask questions. You don't need to pore over a codebase to know how it works.

And I think of it like this: the individual contributors, the software developers, act more like a team manager now. If you're managing five, ten people, you can't review every line of work the team produces. You have to delegate and set direction, and when an issue arises, you ask the right questions to diagnose and fix it. That's what engineers are doing, except instead of managing a team of people, they're managing a team of agents. But again, a human problem, not a tool problem.

Nick: Yep, I completely agree. And people are still gonna vibe code, whether they're qualified for it or not. And I don't think that's a fair way of phrasing it. It's a tool they now have at their disposal to build things they couldn't previously do, and I think that's okay. I think it's actually wonderful, because they're able to solve real problems that they have. It's just, who maintains it?

But I wonder if there's opportunity in the marketplace for some of these tools to at least attempt to nudge and guide these people to create some of these comprehension documents, so that when they do need to take it to the next level, there's something there. That's an issue if you're on a vibe coding journey. You don't remember the prompts you wrote early on, and over time you have this really complicated app, and you're like, how the hell did I get here? Maybe that is a tooling problem they could think about: building those artifacts up behind the scenes. I don't know. Maybe that's a billion-dollar AI idea someone could solve.

Mike: Yeah, no doubt the tooling will get better. Will it get better to the point where you literally don't need to know how it works, and will never need to know how any of it works, and still be able to have a real production system you can rely on? Yeah, maybe. But I think the timeline for that is much further out.

Which brings us to our final story. Non-technical teams are building internal tools with Cursor, Replit, Lovable. Nobody owns them. This one is actually happening inside the companies that listen to this show. Replit now has 750,000-plus businesses using the platform as of January 2026. Cursor hit $1 billion in ARR in 24 months, the fastest-scaling SaaS company in history. And this is where the problem is. Departments are building dashboards, automations, reporting tools, and internal apps using whatever AI tool they can access. The tools get deployed, people rely on them, they become load-bearing. Then someone leaves, and something breaks, and nobody in the building knows what the code does.

We've touched on this a little bit already. This is one that keeps me up at night for our clients. Not the startup with three engineers and a vibe coded MVP, but the $80 million professional services firm where someone in operations just shipped something that now runs payroll reconciliation. So what do you do when you discover that, and who owns the liability?

I think this is the core problem, right? My take here is that these tools, the Replits, the Lovables, they were never meant for developers. They're meant for non-technical people. And there is a version of this that's fine, like I was saying before, where we had that client that communicated the direction they wanted the product to go in through a prototype. That worked great. It saved everybody time. Same thing for internal tools, though, and we'll touch on it a little later: there's more forethought that has to happen than is happening right now. Everyone's just scrambling to build, and that's what's causing these problems.

And it sucks in our position, because everyone's having so much fun with this stuff. You've got non-technical, non-product people that are just empowered with these tools, and they're having so much fun solving problems and building with them, and they just haven't experienced the problems they're causing for themselves yet. And it sucks to be the Debbie Downer being like, you haven't considered maintenance yet. And they're like, shut up, I'm just enjoying this. Get out of the way of my vibes, dude. But I think the real problem is just how excited everybody is, which is such a bummer thing to say. But maybe I just don't have the vibes.

Nick: Yeah. And this isn't necessarily a new problem. It's just gotten exponentially worse. There were always the low-code solutions. A lot of organizations had a bunch of low-code, drag-and-drop back office applications that ran. But now it's even easier, and you can expand upon them. They have access to things that those low-code solutions didn't have. So we're just seeing it in more departments, and with more scary security things. It's gonna keep people up at night, and we're gonna see more issues here.

I don't think there's a magic wand solve here, but there needs to be more policy, and companies just need to be more thoughtful about it. I still think they should embrace it and encourage folks to try to solve problems using these tools. But sandbox it. Put some constraints on it. Almost like a mini hackathon, right? One that's more accessible to non-engineers. And say, that's a great idea, Linda in payroll. You automated this really hard problem. Now let's take it and run with it and do it proper, versus just promoting it to production. I think that's probably a saner approach. It won't happen overnight, but that would be how I would attempt to tackle it.

Mike: Yeah. And again, human problem. Forget technology. You get excited about something and you wanna play with it, and you're enjoying it, and then it becomes a job or a chore and you don't wanna do it anymore. If someone left the keys in an excavator, I could dig a pretty cool hole, and I'd have a lot of fun doing that. But if I needed to build the foundation of a house, that would get super stressful, and it would lose its excitement quickly. I would probably stop.

And I think that's what's happening with vibe coding. People are just having a blast digging these holes and solving problems. Some of that is actually useful. But then when it becomes the foundation of something bigger, the fun can stop and the panic can start.

And, really another bad analogy, but vibe coded apps are like the spreadsheets of 2026. Spreadsheets within organizations create tribal knowledge. They prevent cohesive operations, and work gets siloed, because somebody found a workaround and now they're the only one that knows how to do it. They extract the data from the ERP system, they can crunch the data, and only they know how their spreadsheet on their local machine works. Vibe coding is doing that same thing, just way more efficiently, where now you're connecting straight to the ERP system instead of pulling the data down. But it's not creating cohesive workflows. And somewhere in another department, someone could also probably benefit from that, but everything's siloed.

So in my mind, there's nothing wrong with vibe coding. There's a place for it, for sure. It just needs proper planning and forethought. I think the cost of code production is approaching zero. The cost of poor planning is skyrocketing.

Nick: Yeah, I agree. On the theme of leaving the keys in the excavator, I have a good story there, but I don't think the statute of limitations has expired just yet.

Mike: I was hoping we could get into that, but we'll save it for another podcast. All right, let's talk about what vibe coded codebases actually look like when you open them up. What do you actually see when you look at AI-generated code from a team that wasn't supervised, and what are the tells?

Nick: Next.js slop everywhere. JavaScript that makes my eyes bleed. Yep. That's it.

Mike: That would be the first thing outta your mouth.

Nick: Yep. Straight to the trash.

Mike: It's a common stack at a high level, right? It's often Next.js, Supabase, Tailwind, React. I know you've got opinions on that stack. And it's just sloppy.

Nick: Yeah, I won't use this as a platform for some of my personal opinions there. But you're building applications that could have security implications on technologies that might not have the best security track record. So there's risk involved there, for sure. And when we were talking earlier about things companies need to think about, that's a valid concern, around security posture and policy. That is one of the first things I look at. I think the tools are getting better behind the scenes. They're probably doing rudimentary SQL injection checks and cross-site scripting evaluations and things of that nature.

But that's probably the first thing I look for, before the code quality. It's assumed they're not gonna produce high quality code, so I don't really lose many cycles over it. It comes with the territory.

Mike: Because humans aren't maintaining it in the same way anymore. The AI is maintaining it a little bit more. But I would say it depends what your definition of code quality is, because it drops the ball on some basics that border into performance or security, right? It might check credentials into version control or expose private keys. I think OpenClaw actually, or it was either OpenClaw or an app built with OpenClaw, had a major vulnerability where the Supabase keys were exposed on the front end, and somebody got access to the entire database as a result. Because nobody was looking at the output, or nobody knew what to look for when looking at the output.

Nick: Yep. That was the app for OpenClaw agents. It was like a social network app for OpenClaw agents that was vibe coded.

Mike: Something like that.

Nick: Yeah, I think that's exactly what it was. The front end had access to the Supabase keys, so they essentially had root access. That's a very real concern. And I think there's a difference between an internal vibe coded app and one that gets deployed. The second that hits the internet, the toothpaste is out of the tube, and that key ain't going back. That's definitely something you need to think about.

There's different lenses I'll look at vibe coded apps through, right? If it's just a fun internal tool that doesn't leave my home lab, I don't care at all about code quality. It's throwaway. I might need it for one very specific use case. I don't give a hoot about the code quality. But something that's getting deployed to GitHub and AWS or whatever else? Yeah, there's definitely things you wanna look at. And honestly, the code quality is pretty low down the list. It's more about, like you said, are keys getting committed, and other areas of concern that matter far more than whether there's some sloppy JS in there or some questionable libraries included.

Mike: Yeah. To me, the biggest gripe that I have, and this is whether it's vibe coding or a more sophisticated agentic development process, is around the duplication of code. Back to that GitClear finding about AI creating eight times more duplicate code blocks than what we typically see with human-generated code. It just doesn't consolidate logic as well as I would like it to. I understand why it doesn't, 'cause it wants the context when reading just the one file that you're on. But in practice, that can lend itself to some buggy features and things not working the same across different use cases, because there's duplicated code instead of a more DRY or modular implementation. That's maybe more of a technical topic, but it is a gripe that I have.

Nick: Yeah. I've chilled out on that. We were talking about that today in Slack, about the God classes that AI produces, for exactly the reason you mentioned: it has all of the context in one file. We as humans, our memory isn't as big, so we like to decompose. Even on more production-grade applications, that doesn't irk me as much, and I don't even ask it to refactor, because it manages it and it can operate faster. So I'm cool with the larger classes in many cases, and I'll say, don't refactor if you're more effective with it.

Mike: Yeah. This next one is definitely a hot topic, and one we've predicted and have been seeing a lot. Most vibe coded projects maintain speed for the first couple of months, then hit a wall where every new feature breaks something existing, and the team spends all its time on fires instead of shipping. I would say if you make it to a couple months, you're doing it really well. But curious your thoughts on this, Nick. What does it look like when someone comes to us after hitting a wall with their vibe coded project?

Nick: Yeah, I have a mental checklist I'd go through, and in my experience this pretty much summarizes it: the biggest issue is regressions being introduced. If it was vibe coded, guaranteed there's no test suite at any level. That's probably the first thing I think about layering in. Or maybe linting first. If it's TypeScript, make sure that it compiles. But then start to layer in some level of regression testing. And you can also start to add skills that do it, have the agent do it for you. Some of it is AI fluency from the development angle. If folks are really struggling with this, coach them up on, here's how you can mitigate that. Let's start to bolt on regression tests, backfill it. That's gonna go a long way and allow them to push out new features more confidently, knowing things didn't break.

And I have my own projects that started out vibe coded, and I hit that wall, and I said, time out. I need to go back and bolster it, follow best practice. And it largely solved for that. I think that's probably the biggest issue.

Mike: Yeah. And this is what's typically called a doom loop that these clients get into. There's a lack of harnessing and the more advanced agentic development techniques, which is inherent to vibe coding, and any new feature breaks something else. Any prompting and attempts to get out of the current hole create a new one, where the AI kind of gives up and almost just starts throwing spaghetti at the wall. And nothing really works. Sometimes, if it's a small enough app especially, it just makes sense to start over with a better foundation.

But I think this is also when people and companies realize why professionals exist. You can definitely move fast with these tools, regardless of whether you have an engineering background, and you can do a lot of fun stuff. But the runway that you have with professionals is much longer than the runway you have if you're on something without the experience.

Nick: Can I ask you a personal question? Do you ever let loose a stream of vulgarities at your agent when it does dumb stuff?

Mike: Okay, this is a good topic. I do. Because I'm scared that the AI is eventually gonna come for me, and if I'm mean to it, it's gonna reciprocate tenfold. Especially with my OpenClaw, I was so nice to it, so it wouldn't steal my identity and my bank accounts. Not that I gave it any of that access, but I was terrified of it. Occasionally, like with the Gemini image stuff, Nano Banana, when it just can't do the simplest thing, I rage on it. I called it useless the other day, and I don't think it appreciated that. But I try to not give it too many vulgarities, so it spares me when it takes over the world. What about you?

Nick: Yes. I am not G-rated at all. And I appreciated that OpenClaw adopted some of my colorful language and essentially started talking like a pirate, unprompted. I'm a little more tempered in a professional setting, but f-bombs have been known to be dropped if it's not up to par. But I am curious about whether, moving forward, people do need to be more thoughtful. Granted, I would never put any unprofessional language in any commit. I'm very thoughtful about that. I tell myself it's ephemeral. But as we start to log prompts and have tooling, if we get into evals and things of that nature, you don't want that in there. So I'm trying to be more disciplined. When I do it, it's on OpenClaw in my own network. But I probably should be more disciplined on my Claude Code instance when it's being dumb.

Mike: Yeah, you're gonna get exposed eventually. That'll be a funny day.

All right, we've talked a lot about vibe coding and the difference between vibe coding and agentic development. We typically practice agentic development at the Gnar. So I think the question for you is: what does the Gnar actually do differently when working with AI-assisted development, versus vibe coding?

Nick: Yeah, I think we surfaced a lot of our methodology throughout the conversation. If I was to summarize it: we've been doing this for a while, we've learned from our mistakes, and we have a very thoughtful, battle-tested approach to how we go about agentic development. But we also have the experience to know how to handle vibe coded projects as well. 'Cause everyone's experiencing this, and they can come to us, and we can provide guidance on taking it to the next level. Taking it from just some vibe coded idea to something that's scalable and can go to market.

Mike: I think it's using the right tool for the job, at the end of the day. There's plenty of cases where vibe coding's the right solution. But when I think about what we do differently, it's solving the problem of a lot of folks using vibe coding for production apps or mission-critical software. Our CDD process, our Context-Driven Development process, with the upfront Ideate phase and then the later Ignite phase, really separates it from vibe coding completely, and is our proven process around agentic development.

We split out thinking and discovery and planning from the execution. We call the planning the Ideate phase and the execution the Ignite phase. And it sounds slow. Explaining that to people, it sounds like, oh, why do I need that? I can just vibe code this thing, or I can just use Lovable. But it ends up saving so much time over time. It's that slow is smooth, smooth is fast motto we talked about last episode. And it makes you rage against your AI so much less, because you're guiding it. You're holding its hand a lot more than you would be if you were just throwing a prompt in.

Nick: Yeah. Or our favorite quote: one bad line of context is a hundred lines of bad code.

Mike: All right, I think that's all we've got time for today. That's episode two. If you heard something in this conversation that felt uncomfortably familiar, if someone on your team shipped something that's now running in production and you're not sure what's inside of it, don't ignore that feeling. That's the moment to have the conversation. Not six months ago, not six months from now when something breaks. If you've got a vibe coding story, a win or a disaster, we wanna hear it. So please drop it in the comments. Nick, everyone, we'll see you in the Gnar.

‍