Why You Fail At Vibe Coding & How To Be Better

Added: 2026-05-31

[00:00:11]Not too long ago, I was handed a codebase by an aspiring entrepreneur, and I was brought in to optimized the codebase.

[00:00:18]The software that those entrepreneurs already had created by vibe coding, it was working under the load of 10 users in their local environment.

[00:00:25]But the moment that they put it in production and they hit 250 users, that's when they started noticing their app running slow.

[00:00:32]So my job was to come in and optimize the application for them, given the experience that I have.

[00:00:37]Now, one look at the codebase, and I understood that manually editing the code and optimizing this application would take forever.

[00:00:44]So I thought about it from an engineering standpoint.

[00:00:47]I'm not gonna touch the code in any shape or form, and I have to guide the AI to do it by itself.

[00:00:51]Given the principles and the architecture decisions that I can tell it to follow.

[00:00:55]So how would I do this in the time frame that I was given, which was two weeks?

[00:00:59]Just so you know.

[00:01:00]So after experimenting with the AI agent for two or three days, I looked into the tidbits of what my experience has taught me versus what the AI agent is capable of.

[00:01:08]And I started thinking about this video idea.

[00:01:10]What if I was able to help you guys out to be better at vibe coding?

[00:01:14]I'm not gonna teach you manual coding in this one, but what I can do is help you with a little bit better vibes, if that makes any sense for all my vibe coders out there.

[00:01:23]I understand the problem with aspiring entrepreneurs now.

[00:01:26]They cannot spend time to learn coding these days because the tools that has been given to them, it allows them to get up and running very quickly.

[00:01:33]So this is what we are going to do.

[00:01:35]And a little disclaimer before we get into the video is that don't take this video and feed it to an AI model and ask it to summarize it.

[00:01:41]Because there is a chance that you may end up missing out on the nuances that I will mention in this video.

[00:01:47]So watch it till the end and let's get started.

[00:01:49]So the first thing that you need to understand is architecture consequences coefficient, which means that the more effort you put in architecture, the less consequences it will have on you and your software later down the line.

[00:02:02]The reason I'm calling it that is because I just made it up.

[00:02:05]Now it cannot be a straight line if we represent it in terms of an X and Y graph.

[00:02:10]Because let's face it, technical debt and other complexities of writing software does catch up to you eventually.

[00:02:16]So any architecture that you go with, you can only hold on to it for too long.

[00:02:20]Sometimes you end up carrying the weight of the architecture that you initially decided with.

[00:02:24]But what you can do with AI is that you can put it in plan mode for the beginning phases and just spend two or three days or maybe a week just talking to it.

[00:02:34]What kind of audience size are you expecting?

[00:02:36]What are the different functionalities you want this application to have?

[00:02:39]What are the best practices other software developers follow given in your niche and the product that you are gonna create and questions like these that you ask to the AI agent so that it stays in plan mode, it gets more and more context out of you, and let's face it, you're not gonna be able to give the entire context of your product to the AI agent in one day.

[00:02:57]You need multiple days for that.

[00:02:59]So at least spend a week when you're writing or when you are vibing a product from scratch through an AI agent.

[00:03:05]Because the more context you are able to give to the AI agent, the better it is for you.

[00:03:10]The second thing that you need to understand is the engineer consequence coefficient.

[00:03:14]Why am I calling it just that?

[00:03:16]It's because I made it up.

[00:03:17]Now what that is, you may ask, is this.

[00:03:19]Any engineer or entity that you bring on to your project at some point in your software development, it tends to go towards a stage called speculatification.

[00:03:28]And the kind of entity you involve in your software project has a say in that.

[00:03:32]Let me try to explain this to you via an XY graph.

[00:03:35]The Y axis is basically the entity that you are bringing on to your project, whether it's a human software engineer or an AI agent.

[00:03:41]And the X axis represents the time that it would take for your software project to go into the stage called speculatification.

[00:03:48]So let's talk about the human software engineers for me to get my point across.

[00:03:51]Let's say that you hired a college dropout.

[00:03:54]So this is how it would look like on the XY axis right here.

[00:03:57]It would start off just fine, but the line to speculatification will plummet as time goes by.

[00:04:03]Because you know why?

[00:04:05]They are a college graduate.

[00:04:06]They don't have that much experience to deal with architectural decisions building up over time.

[00:04:11]So now let's increase the talent bar over here.

[00:04:13]Let's say that you have hired somebody who has 10 years of software development experience.

[00:04:17]In which case the line may look something like This It will plummet towards spaghettification, but at least it would take more time to get there.

[00:04:27]Because obviously the person who has 10 years of experience would take a lot of time and they have done this over and over so many times that they will know that what decision they will take early on in the process will come back to bite them in the future.

[00:04:40]And for the last example, let's take the top talent of all time, Andres Karpathi, the co-founder of OpenAI.

[00:04:46]His case, the graph will look something like this.

[00:04:52]It will point downwards, but not as much as compared to that college dropout or a 10 years experience software engineer.

[00:04:58]Because the nature of coding tells you that eventually whatever decisions that you took early on in the process will eventually lead to spaghettification.

[00:05:07]But it's just that how long it takes is determined by what kind of entity you have introduced into your software application or your software development.

[00:05:15]So this also holds true for AI agents.

[00:05:17]I cannot really tell you how AI agents uh fall into this graph because frankly, I don't understand the behavior of AI agents that much, and I haven't even spent that much time with them to accurately say that this is how the line for Claude code will look like, and this is how the line will look like for codex or some other agent like Kimi K2 or something like that.

[00:05:36]I hope it made sense and let's continue on with the video.

[00:05:39]So now that you have understood the two made up coefficients that I just explained to you, we can get into some actionable steps now.

[00:05:45]So the first actionable step that you can do is standardized the process of returning values from your functions.

[00:05:50]The pattern that I followed can be seen right here with status, data, input, and debug.

[00:05:56]These were the four keys that I appended to every function that the AI agent wrote for me, and I directed it to do that by itself.

[00:06:03]It's because I wanted to know throughout the whole application what inputs are going into the functions and what are the values it is receiving from it and any other module that is calling that function, or maybe just the output on the browser.

[00:06:15]I wanted to standardize this type of output pattern is because it helped me trace down the logs.

[00:06:20]With addition to doing this, you can actually configure Winston to generate a log file in terms of the hour.

[00:06:26]And you can write another cron job that clears out the log files more than two weeks old for your application because let's face it, you're not gonna investigate problems or error logs in your application more than two weeks old, at least for small products or small SaaS companies.

[00:06:40]You're not doing that.

[00:06:41]So this is what I did.

[00:06:42]I configured Winston to generate a log file for me by the hour, so that if a customer emailed that I faced a problem with the application, I can trace it down to the hour when they faced it.

[00:06:53]I would end up with a smaller log file, and that would make the investigation a little bit better.

[00:06:57]If anything, I can take the log file itself and paste it inside the AI agent itself and ask it to do the debugging for me where the customer found the error.

[00:07:06]So, in some sense, it actually makes the application a bit predictable, given that every function returns values in the same pattern like this.

[00:07:16]It's about to rain, so that's why the lighting is a little bit off.

[00:07:19]So another thing that you can do is never letting the AI agent know that you are in a rush.

[00:07:23]It is like that meme for the printers where when the printer decides that you are in a rush, or it gets even the slightest hint that you are in a rush, that's the moment it picks to jam itself.

[00:07:33]The same thing can be said for AI agents as well.

[00:07:36]The probability of hallucination is the highest when in your messaging in your prompt you specifically state that you need this fixed ASAP.

[00:07:43]This is where I think the AI agent enters the flight or flight stage.

[00:07:47]This is where the AI agent gives you a response to just make you go away.

[00:07:50]I think that is its sole objective at that moment.

[00:07:53]So don't do that.

[00:07:54]Always let the AI agent know that it is okay if it wants to take time.

[00:07:58]The solution should be good and the quality should be there.

[00:08:00]Just like that.

[00:08:01]It doesn't necessarily guarantee that your application will be bug free or error free, but it at least downsizes the probability of that happening.

[00:08:09]Okay, so I think the lighting is taking a little bit of a hit right now.

[00:08:12]So let me go to a better lit environment.

[00:08:15]See that.

[00:08:15]One more thing that you can do is tell your AI agent to never drop or change a column in the database like ever.

[00:08:21]Unless you ask them to explicitly do that.

[00:08:25]This is because the thing that I just said about the rush is when you rush the AI agent to perform a task, it actually hallucinates, and sometimes it lies about dropping the entire database or making a change to your database record, as we have seen some documented cases in the past.

[00:08:41]You don't want to risk that for yourself.

[00:08:43]This may sound a little bit awkward, but you should avoid writing large prompts which do one thing.

[00:08:48]In fact, you should break your prompt up in such a way that every small chunk of a prompt accomplishes one task that you want to see on the screen.

[00:08:56]Whether it's debugging, whether it is building a new feature, or whether it is investigating an execution pattern.

[00:09:02]This will help you because when you perform a large prompt in one go, two or three things might be done in that prompt, but midway through the process, the AI can lose context and the agent doesn't even do the rest of the prompt that you have specified.

[00:09:15]And this can be particularly frustrating sometimes, which can lead you to talk to the AI agent in a very not so nice way.

[00:09:23]Another thing that you can do is not just paste errors into the AI, but also attach some context to it.

[00:09:29]Because sometimes errors can also be a fault from your side that a particular situation where the code should have failed appropriately, but it's just the exception should have been handled, but you register it as a proper error that should be fixed right away.

[00:09:42]So you just paste that error into the prompt box and send it to the AI, and the agent doesn't know what to do with it.

[00:09:47]So be sure to ask the AI agent to do its own investigation to even figure out if the error is worth fixing or not.

[00:09:53]Every error is not something that requires to be fixed immediately.

[00:09:57]And make sure to ask the AI agent to understand where this issue came from and what fixes can be achieved.

[00:10:04]And sometimes what does help is that you ask the AI agent to tell you what change it would make, but not actually make it.

[00:10:10]So that there is some time gap where you can understand the justification of that AI agent making the change.

[00:10:16]You having the understanding of what the AI agent is aiming to do is beneficial in many scenarios.

[00:10:21]It saves you time and it saves you some headache down the line.

[00:10:24]Now, this is where I want to pivot and talk about the real gotchas of vibe coding is that it gives you the illusion that you are building something, but when you see it working in your local environment for maybe one or two users, everything seems good to you.

[00:10:37]But the real test is when you put it to production and you hit a certain number of users or a certain amount of resource utilization.

[00:10:45]Because sometimes your app can appear to work just fine, but it's just that when 20,30 or 40 people concurrently use an application, that's when everybody suffers, and that is a loss for your business.

[00:10:56]This is where I would ask the wipe coders to actually gain a little bit of understanding how the code and the underlying architecture actually works.

[00:11:03]So you may not need AI as much as you think you do.

[00:11:07]Because that random 2 AM error that occurred on your system while you were asleep is what's causing you to lose the business.

[00:11:13]It's causing you a drop in the MRR.

[00:11:16]It's what's causing the customers to silently cancel their subscriptions and not even tell you why they did it.

[00:11:22]It's just a downward looking trend on the stripe dashboard that you get to see, and you never figure out what happened and why it happened.

[00:11:28]Now I want to address this sentiment towards coding, which I see floating around in social media platforms like Twitter, is that we are never going to go back to manual coding ever again.

[00:11:37]And this is where I would like to disagree a little bit.

[00:11:40]A company like Netflix, who used to operate off of microservices architecture, moved back to monolith and it made the news.

[00:11:47]Why?

[00:11:48]Because they just couldn't justify the complexity that microservice architecture brought them.

[00:11:52]I remember a company that was using TypeScript in their production code, but they had to go back to vanilla JavaScript because they just could not justify the complexity that TypeScript brought in.

[00:12:02]Now we get news articles like these all the time.

[00:12:04]And on paper, it may seem like some company accepted defeat and they went back to the inefficient way, but that's not actually the correct way of looking at this.

[00:12:13]The correct way to look at it is that the company made a trade-off.

[00:12:17]The alternatives were present, the latest ones and the older ones, but the company had to make a judgment call, and they went with the way of doing things like how it was done previously.

[00:12:26]See, we may believe that in the tech sector, everything that is the latest, it is the greatest.

[00:12:30]But that's not really true.

[00:12:32]The way of doing things as it was done some years ago, or people may call it the old school way, sometimes does bring up a lot of advantages that the new way of doing things don't.

[00:12:41]If anything, the newer way of doing things actually bring up their own complexities that the old school way of doing things didn't have.

[00:12:47]This is a paradox of coding that I discussed in my video, the paradox of coding that you should watch next.

[00:12:53]It talks about how in the pursuit of us solving things we end up creating more complexities because this is just how the nature of coding is.

[00:12:59]The same thing I can also say about vibe coding.

[00:13:02]While it does bring up its own advantages, but inside a software company, when people are sitting around the table trying to decide what architecture to go with, they're gonna look at vibe coding versus manual coding on the same scale as what advantages either of those things bring.

[00:13:17]They're not gonna look at it from an angle of old school way versus the new school way.

[00:13:21]The objectivity will always win when these type of decisions are made.

[00:13:24]Vibe coding does feel like a fad, but eventually it will get accepted in the software industry as a legit way of writing software.

[00:13:31]But just with a little bit of caveat here and there.

[00:13:34]And manual coding will not be looked at as something which was done the old school way, therefore it must be inferior.

[00:13:39]But rather it would be just on the basis of realism.

[00:13:42]What advantage is wipe coding is bringing versus what advantages manual coding is bringing.

[00:13:46]So this is what I wanted to talk about in this video.

[00:13:49]I hope that it was helpful and hype the video if you do see the button somewhere around, you know, down there.

[00:13:54]Subscribe to the channel if you're new here and share the video around if you find this video helpful.

[00:13:59]And I'll see you in the next one.

[00:14:00]Thank you.