We "vibe coded" for 30 days. Here's what we learned...

Everyone, including Y Combinator, says vibe coding, it's the future. Meaning, instead of coding, you just talk to an AI model via cursor. Uh you tell it what you want and it will do it for you. And that's the only thing you need these days to build cool games like this one, which can make you thousands of dollars a month. As senior developers having built dozens of applications in production, we very much doubt that.

So, Bogdan here in the call with me has been vibe coding for the last 30 days to see if as a senior developer, he can get his job done without basically writing a single line of code. So, in this video, we're going to share why we believe vibe coding, it's not the future. Actually, far from that, how it will actually make developers more valuable, not less, and why developers thinking that they soon won't have a job because of LLMs, AI, vibe coding or whatever comes next, are making a huge mistake.

Now, Bogdan, what have we been building with vibe coding these days? Well, the first project we've been trying vibe coding with was a Next.js application where it's very similar to the technical assessment we have on our website. You can basically answer questions and get an analysis of your skills. The next project was a Chrome extension where it will basically save the jobs you applied to. So you don't have to do it manually.

You basically just click save and they will go into a tracking system so you know how many developer jobs you applied to. And it also does some some basic pricing where it figures out if the job was at the senior level or mid level, the salary and so on, basically from the job description. And uh finally this is a small game I built for my girlfriend, she loves Pandas and it's about a panda that has to eat bamboo and when you eat the golden bamboo, you actually get to the next level.

And I think I built that in about roughly 4 hours of coding and a bit of debugging. Now, looking at the repos, we've seen it's about 80,000 uh lines of code that we're talking about, which uh it's a considerable output. Some of the projects were small, the production ready. And what we found out, it's number one, that you can't actually build what you don't understand. The easier generating code becomes, the more you need best practices and proper tooling to manage it.

The skills that you need to work well with AI are actually exactly the same you need for you to be a great software engineer and developer. Even if you vibe code 100% of the time, you still have to test Q&A and sometimes tell AI exactly what you want to achieve. Uh in my little panda game, this was very much the case. The AI would get stuck with basic stuff, basic config stuff, and I would have to basically either start everything from scratch or, you know, go fix it myself and come back and and start again working with the AI.

And finally, many of us were actually already vibe coding for a long time before AI. The whole goal of high-level programming languages, frameworks, compilers, interpreters, all kind of developer tools was to abstract a lot of the low-level work for the developer to be able with a bunch of commands to get a lot of stuff done, right? Uh there is a big difference with vibe coding, uh which is those systems were deterministic, so in many cases the outcome was even better, but let's say it they weren't able to to generate and to customize the code to the level that vibe coding it's able to do it.

Exactly, so of course you can go a bit faster if you already have a structure and you have a project and you're just using AI suggestions. You can sometimes go faster because it's pretty on point when it comes, for example, to let's imagine you have a form, it has five fields and you need another six. It's extremely good at doing this kind of thing, but whenever you go deeper, you will find yourself in a mountain of spaghetti code.

that you have no idea who wrote, what why did the AI decided to do it that way, and the effort for you to clean that up and to actually streamline that and to debug that, takes as much as if you were just building stuff yourself. And you need to know the same mental models. thing you need to know how to implement uh modules and separate code to make it more maintainable. All these things I needed more than ever because you'll find yourself surrounded by a lot of code you haven't wrote.

So it's literally like if you're working for a new company every week, you wake up to all these kind of new code base and you need to find your way through it. And AI is very good at generating those first initial versions, but it degrades slowly and it will get to a point where you will have to be the one debugging everything. Yeah, and talking about the fact that you cannot build things you cannot understand.

I mean, this is the way builders in the past way building cathedrals, like Gothic cathedrals were built based on trial and error without any understanding of the principles underneath, the physics behind it, right? And what happened is they would collapse a lot. Not only that, but humanity as a whole didn't advance much while it was doing things by trial and error. At some point in time, you know, calculus was invented, then we got like structural physics, and this is when actually humanity as a whole took took off, right? That's what triggered the industrial revolution.

Up until that point, we were just observing things in nature and kind of trying to mimic that. Uh we we had an outcome in mind, but we did not know exactly what's happening underneath and how to get there. And I think if you if you look like at AI systems, the way they are built is they sell lamps, um and the models out there are kind of bring the same, you know, they try to replicate a certain outcome using a very well trained, let's say a very optimized uh statistical model in the end.

But they cannot really reason underneath it. And I think that's the mistake that a lot of developers do when looking at that code, they think this is the result of some kind of reasoning that the LLM has done. Uh when, in fact, it's it's not. The second thing we learn is that English is not a programming language. It wasn't built this way. English is a human language, it's ambiguous, it leaves a lot of space for interpretation.

And this is why we have lawyers and they have a job, right? Because human laws, even if they are very clear, they can be interpreted in many different ways, which is exactly what you don't want to when you program a computer. Humans can deal with this ambiguity because because we have and they have a non-verbal understanding of the words. Actually, the way we understand the word, it's not via language, we communicate via language. But when you when you talk about a a computer, your brain knows what the computer is, like at least visually, it has a concept of the computer, right? The language is just a reflection of that. Programming languages in exchange from human languages were built because we needed a deterministic way to program machines, right? And programming languages were built to eliminate ambiguity and to eliminate options and to make everything again very deterministic. One example, it's AI actually not being very deterministic when changing randomly changing labels, manipulating environment files and fixing things that you don't even explicitly told it to fix. Exactly, so especially when you do vibe coding, which is pretty much giving it some variable instructions and then have the agent go ahead and create a code base with your prompt and then continue execute on that flow or whatever cascade, whatever they they call it now. You will see that all of a sudden there will be a lot of files that you never intended to touch that were changed by the AI. And it will go ahead and start handling error edge cases that you never talked of, which on the surface looks like, wow, it's so smart, but in reality, it was doing it against previous implementations. So which was literally going off the hook and just coming up with whatever would fit the context and the prompt. I still had to review manually every single piece of code. If not, the the code that I committed without correcting, I had to go back when an error appeared. So eventually I'll have to do the work anyways. And the reason behind that is because AI models, as large language models that we're using, are based on probabilistic methods. So they will kind of infer the solution, but you never get the exact thing you were looking for. The problem is, if you apply that to a huge code base, your code starts being less and less accurate. To the point where you get to this metastastic code base that we talked in a previous video, where the whole code base feels sick.

gotten, because everywhere you have all these huge uh pieces of code that no one really uh take the time to to actually structure, to make sure they integrate well, to unit test, and you find yourself in a uh big ball of mud as we used to call it. The third point we learn, and actually we intuitively knew as software engineers, is that there's a big gap between an MVP, in production ready software, right?

Building the MVP, it's actually the easy part, right? Building software, it's estimated to be around 10% coding max. A lot of the work goes into actually, you know, figuring out what to build, designing the solution, right, getting feedback, iterating, fixing bugs. And we all know that most of the time, whenever we had to push things to production, was dedicated to that last mile that you'd say, hey, I, you know, just just really getting things uh to be production ready.

The bottleneck was never more code or more features. Again, if you think about value and what is value in a software product, it's always condensed information that turns into a feature that adds business value. Right, not in adding more features and more noise, right? The best feature is the one you don't need, and if you don't need a feature, then you don't build it. Like and it's all about figuring out what shouldn't we build and what can we with the you know, with the little resources we have, what can we actually deliver?

You cannot brute force your way into building software, in the same way you cannot brute force your way into building an airplane. Without in the past, maybe you could build a a church, a small Gothic cathedral, but that's the maximum you would get to. Past that point, you need design and you need to really understand what you're doing. Yes, so for example, when using Winser, which is the IDE and cloud, and I think I was using the reasoning model, the 3.7, the latest one.

Whenever I would ask for a feature, it will add an extra file of for type definitions for some native libraries. Now, I did had a package of types I already installed for that. But it would keep doing that on and on again until I specified, hey, date's already one. And so it will go ahead and just do all these random changes to your code base, which creates a lot of work because you would need to ideally review your that code before you even deploy it. If you deploy it non-reviewed and you get a bug, you'll have to do it whenever you get the bug. So, especially after you got from the first draft where you generated a full application, when you start extending it, when you start fixing bugs, when you start being doing things more reusable, that's when you're done into a lot of problem. Porton and as an experienced software engineer, I know in this um YC combinator video, one thing they mentioned is that we don't need debugging because you can just whenever you get an output that you don't like or if the application breaks, you can ask the the model to regenerate the whole thing from scratch. What do you think about? What's what's your take on this statement? The reality I've seen using the tool is that it in several cases I had to delete full features because it run itself into a loop where it couldn't get away from. So I would ask it fix the bug and then it would try to fix it, but break it again and then it would break something else, break something else and then the model will just time out. At least the cool thing about windsurf is that whenever it makes its own mistakes, they don't try you for that, but I had several occasions where I had to destroy the whole feature branch and start from scratch. Because if you don't know what the model did and it runs in itself into a loop, which is extremely easy, especially when you go beyond a certain complexity of the feature or just a smaller, medium sized code base, then it will just die. So it's extremely hard for me to believe that someone that doesn't understand anything about the technical stuff would be able to deliver working, quality software or reliable software beyond the the hobby projects that we've seen people posting. So there's a big difference between the vibe coded MVPs that we see all over the place where people say, well, I coded this page in two hours and it's already live. And an actual production system. And when we talk about software in the software industry, at least the decent software jobs are building software for the retail industry. For the financial industry, for payment processors, for insurance companies. And so you cannot go around and just throw some bunch of coder and you know, kind of the the spaghetti against the wall. Just throw some things.

against the wall, see if the AI can figure it out. Test it a bit manually. Write some unit tests, which again don't make any sense because they are generated by AI. Why why would you need unit tests? It doesn't make sense, the AI understand the code anyway. And then expect that to work. We haven't seen anything beyond hobby projects or a small scale SAS that maybe blows up because the person building it has some social media presence.

But other than that, you won't see any consistency in the quality. And so, yes, it's extremely easy nowadays to build an SVG generator or whatever you want to play around. Maybe learn a concept or two. But when it goes back to the commercial use, you really need to sit down and study and understand clean code. Understand dependencies management, understand how package managers work. Understand testing, accessibility, web performance.

How programming languages actually work, and then also a bit about your users. If not, you're just like, if you are in a forest and rather than having a map, you just have a flashlight and you just see in front of you and then you move and then you go in circles. And it feels like you're making a lot of progress, but without the map, you are literally going nowhere. Which gets us to the next point.

A lot of people say, hey, no, but, you know, it will get better. And what we believe, based on what we've seen so far, is that no, it won't get fundamentally better, despite what people with a lot of credentials are claiming in this sector. And that's because software, it's an ever-changing solution to ever-changing problems and user needs built on ever-changing technology. Meaning that context, it's perpetually incomplete when building software.

Things change all the time. You can basically increase the context that the model can digest up to infinity, and you probably won't be able to capture. the complexity of building software in the real world. Something that humans do very, very well, because we use heuristics. Right, we we learn how to we grow up in the world. We know how to deal with ambiguity and complexity. And doing our vibe coding experience, we've served a set of anti-patterns.

One of them, for example, being agent starvation. Exactly. feature where you need to do something project-wide, or you need an integration with the back end, you need to simplify a data structure that's maybe maybe being used in different components or different user views, then the agent will either run into a lot of errors, and then it will run you know, the type checker or the prettier to really figure out if it made a mistake and then feed the error to itself.

But the problem is, if it keeps doing that and adding more code and keeps doing that and adding more code, it will just basically kill itself, let's say. Um, it will get to a point where number one, you're paying a lot of money per query because you have this huge code base. And number two, you don't really know, it cannot really gets itself out of the rot. And then the other anti-pattern we've seen when vibe coding is the prompt error amplification or propagation.

So, pretty much whenever you start, you will get very good results, because you probably wrote some code, it's reasonably clean, and then AI would be really good at completing or inferring from that. But as you make more and more prompts and you leave it to its own devices, the probability that you get a bug will duplicate. And so, let's say you are two hour, you've been vibe coding for two hours.

It's very unlikely that, you know, pretty much every front will generate an error. So, all this dirty code that AI is writing or apparently clean code in isolation, right? It looks really good, but then when you put the system together, there's no coherence. and that will amplify, and you'll get to a point of no return. At that moment, you'll have to stop, clean everything up, read the code, understand it, you clean it up, you leave it all nice and tidy, and then you start generating code again and maybe you can go on for another half an hour, but then you need to stop again, review everything, commit, clean it up.

And so, at the end of the day, it's more of an assistant rather than just give control and and have no idea what you're doing and hope that it will vibe code its way into a solution. And regarding people claiming that it will get better. If you remember in the 1950s, 1960s, some people were very convinced that by the 2000s, we will have, you know, flying cars. It's 2025 and the most sold car in the US, it's uh for Willstruck.

We are very bad at predicting the future. And don't don't let yourself don't we we like to look into the past and think that the future will be like the past, but the future by definition, it's almost nothing like like the past. If you want to get a more realistic understanding of what these models can actually do in reality, check out these other videos where Bugden I went deeper and put a lot of the of the claims that you see online to test.

One last word, if you're a software engineer, you probably see a lot of this reels going around where CEOs of rain own companies say things like this one, right, that in the next three to six months AI is going to be writing 90% of the code and maybe in 12 months all code maybe generated by AI. And what I would say is do not get terrified by these people, they have a huge incentive, they will say whatever they shareholders want to hear in order for their companies to keep the value they have and increase their value.

But do not take that as a face value and I don't want to call call them con artist or anything, but these days, you know, everything that has AI on top of it and everything that claims that we are close to AGI will be um, you know, will give you get your investor money. So be aware, be aware of the biases people have when making statements. With that being said, Bugden, thank you so much and we will see you folks in the next one.