CRACKED AI Debug Workflow Cursor & VSCode Users Are Missing

On average, developers spend up to half their time debugging. And with the amount of agentic workflows or full coding agents that are coming onto the scene, whether it's remote or local, it's becoming more important. I think we can all agree there. So, I want to talk about some workflows that I've been implementing and the different levels to it. There's three different levels. And let's jump right in. So, like I said, it's 25 to 50% of the time. I don't know if you guys have input on how much time you think that you're spending on debugging. Let me know. I know that my workflow has moved a lot from doing the manual writing of code to frontloading a lot of the work to the planning and the PRD and finding the functional and non-functional requirements and the UIUX and then the actual implementation of doing the tasks has become a lot easier whether it's taskmaster or you're using something that's open source like what we work on at Vi with the AI which is this software development life cycle. This is your typical software development life cycle. This is what I follow where you have problem identification, gathering the requirements, doing the UIUX, doing the architecture, the technical architecture, the system design, the data design, the back end, the front end, the author security QA. We're going to be talking about this one. So, what do we do? First off, you can just use prompts. So, I've bound these particular prompts to keys. So, if I do at B1, then this pops up. And I always try to model them around what the person in real life would be doing. That's all you're doing is you're trying to think through the lens of the LLM. Enthropic does a lot of talks on this. If you go and read the OpenAI documentation, you'll find the same thing. But in this case, it's the incident response engineer. And then I'm just passing in context of that problem. Those are logs, traces, any sort of monitoring or observability data that I've found. and I drop it into the current problem reported. We can demo this and we will demo this towards the end of the video, but I want to walk through each one of these levels. So in this case, you just pop open, let's say whether it's cursor or VS code with augment, you would just pop it open and then on the right hand side, you do at B1. Boom. Pops it open and you're off to the races where then I'd paste in whatever it is that is the error. And you'll notice that no matter how good the coding models are, you'll still run into bugs, right? So this is a quick way to do it where you'll just chain these three together. So you have the incident response engineer. It gives you an output of a root cause analysis, right? And so once we have that, then we can move into the next step. So I always recommend using a high fidelity thinking model or a hybrid model Gemini 25 or if it's really tricky you can throw opus at it but the more complex the problem the more thinking you want and then we jump into the incident solutions architect and you're probably thinking wow why would I have two roles for this you're separating the tasks similar to how you have separation of concerns think of it the same way but for prompts and so they analyze the RCA so it's dependent on the previous thing and then you get a sequence diagram as well and then you craft the solutions architecture document and markdown so I'll pass in that root cause analysis that I got from the previous prompt I'll pass in the sequence diagram and then I get a set of key responsibilities so analyze the incident report design the solution, develop the tech specs, plan the integration, and collaborate and communicate. I could probably plus this up, but this has worked really well for me because the output of that is the step-by-step guide on basically fixing it. And then lastly in this level one is the expert incident remediation engineer. Now, if you're like me, I've only worked in startups, so we didn't have these as names. it was just full stack developer or front end or back end or you go dev whatever it was but this again really nails it so I'll take the output from the previous you can go ahead and read these all of these prompts will be available on a repository and then I can see the solutions architect do document is down here so that's where I'll then pass in from the previous step so that is level one. And if you want to go access those, you can go to this link above, github.com/vibewai/ai-slc. And underneath prompts right now, these are all just for new feature generation, but I'm going to add a debugging workflow because I'm at the point now where I really want it. So, you'll have two different workflows, and you can obviously check out the other one if you want to develop on it. There's people that are going to be making PRs for this. It's been wrapped with electrons. So, if you don't like using a clei, you don't have to. Let's talk about level two. So, level two would be what I just was foreshadowing, which is having it be in some sort of cle where you're working through it and you're just saying SDLC next and it takes it from the previous step to the next step. And the way that it works is just exactly like you'd expect. So, I can iterate with the chat and then I jump into the agent mode. And the way that it works with the tags is it'll look a little bit different because it's got its own memory locally through a lock file where you can do the next step or pre step. So, let's just find it here. Sorry, this is the wrong one. But in here why receive when you receive the PRD and the format and then prestep. So that's the sauce. That's what allows you to move forward in the flow. I really like this because it is tool agnostic. I have my tools that I love. You have your tools that you love. We don't need to argue about tools. Although augment VS code I think are the best. And then for that's for heavy lifting stuff. And then for lightweight cleaning up multiple files at once and linting and stuff, then I'll maybe jump into cursor and have it go do things as well. So I'm leveraging both. And then level three is something I talked about on my daily upload channel. So I have another channel and I talked about this idea of the selfhealing code with AI debug agents codebase. So basically self-healing and if you recognize any of these logos why I was thinking about Dino is we have a member in VI which is a private network of builders. We have people from Microsoft and Google in here and we're launching a new product soon by the way. So it's not like a school community bro sesh. But anyways, one of the members in here was talking about his DevOps background and how open telemetry is great and how you could take the open telemetry data pass it down into your own debugging agents. And I thought that's really interesting. So I've been exploring this where you Dino was the idea that if you're not familiar Ryan is the founder of it but Dino basically it's the guy who made Node went and made Dino has not caught wild wildfire because the ecosystem of JavaScript just doesn't want to move on from node modules but it has hotel built in natively which is really nice because going and implementing that and I started to implement this inside of Nex.js KS and then fast API and all the different apps in your codebase can be a lot of grunt work but Dino makes it just native. So the idea would be that you have something that's piping data out, right? So you have logs. Whoops. Logs and then you have traces. Traces are better versions of logs. We have the humble log. That's not a log. But the humble log is not enough. You want monitoring and tracing some sort of observability stack that then is piped down into an agent or a flow. And so you can also use Prometheus or Loki or Graphfana or any of those things. That's kind of what you see here. But I think this is where it's going. And in an interview with Mark Zuckerberg, he speaks a lot about how majority of their code is being done by agents. And I know this for a fact that they're working on something and have completed something like this. So it's not just about new feature development. We need to be thinking about the other side of the coin which is debugging QA. How do you make it better? There are a lot of other things beyond just these reactive workflows. You can be proactive. And I think that some of the best ways to do that, just as a bonus for you guys before you leave, is just having strict formatting and linting because either while you're coding, you can run into, oh, I'm out of linting fixes or while you're deploying, you can catch things. So, I recommend using rough. I also think that biome is really great because you can have the right fixes set in place so that you can just you don't need to waste LLM tokens on that stuff. It's just going to be slower, more expensive, and most of the time less accurate. And then another safeguard would just be having endtoend type safety. So pedantic, TypeScript, TRPC. And then just the last thing is use established technologies. Don't be selfish with your stack just because you want to learn something because the agents won't be as good. So those are the levels of debugging. If you want to check this out, then you should go to that repository. Please open up a PR. We have a lot of exciting things coming down the pipeline for VI, including marketplace with discounts on different pieces of software with brands that we're starting to work with. Like I said, we've got some great people in there. We're going to be doing product roasts and workshops. So, if you like this video and you've learned something, just maybe one thing, make sure you like it. It's going to be good karma. If you want to see more videos like this, make sure you subscribe to the channel and I will see you in the next one. base.