I have been taking on "rescue" projects for a while through my business. Previously, the barely-functioning code was usually being generated via outsourcing agencies but it seems the new source is now going to be LLMs.
I imagine it will be the same set of issues really. Just a different way of cost cutting measures. There can be good reasons to take shortcuts but, in my experience, the problems start when you're not mindful that there's a price to pay for taking these shortcuts. Whether it comes from managers, employees or outsourced personnel, it's the same result.
I haven't thought about advertising it as a separate type of service(for vibe coded platforms) yet but maybe I should. The Australian software market is small so haven't been hearing much about the results of those experiments.
One of the issues with vibe coding vs. outsourcing agencies is the sheer volume of code it can produce in a short amount of time.
I vibe-coded a simple helper script. If I wrote it myself it would have been 1/3rd the lines, not covered most edge cases (some of which were completely irrelevant, some of which actually useful), and it would have taken me way longer than just checking if the vibe-coded code works (this was the "either it works or it doesn't" kind of task, not something where subtle errors could reasonably be introduced).
I skimmed the code and removed the line that deletes temp files to reduce the risk that it accidentally wipes my home dir and ran it. As I was trying to work with the data deeper, I noticed missing temp files, and realized that there were two other temp file deletion lines that I missed.
It's simply too much code for a human to reasonably read, but the speed benefits are real.
(My plan for the future is not reading the code more carefully, it's putting it in a sandbox and letting the AI play.)
There's a BIG difference, at least with tools like Claude Code: plan mode. I'm now using Claude Code a lot at at work, and the first thing I do is enter plan mode where I can have a "conversation" asking it explain how it would implement. Just a few back/forth later I end up refining its plan to conform to good (or what I think is "good") design, after which it will tell me exactly what it is going to do (with code diffs), which I sign off on (again, potentially after a few iterations). It's only then that it generates the code.
By contrast, on one project many years ago I was reviewing the code generated by an overseas team, and I couldn't make head or tail of it, it was an absolute tangled mess that was impossible to fix.
Might be a good idea, though word of mouth and networking is how I get work and SEO has stopped being a useful avenue for a project pipeline quite a while back.
I was thinking of doing something like that, but how does it work for the company in the end? If they vibe coded their project and now have shitty code full of bugs, you come in, fix the bugs and organize the code better and that's it? How do they continue to maintain it if they didn't have the knowledge to set it up in the first place?
They would try to hire and/or build the team they need to move forward, if they have the money.
Knowledge is usually not the problem, it is the shortcuts(or short-term decisions) that got them to a place where they can no longer operate the platform they need to survive. Often this is the cause of prioritizing velocity over anything and everything else. This is choosing the do it fast and do it cheap options with the assumption that it is always correct. That assumption of course is almost never true.
By the way, most cases where I've seen this there's usually an investor involved and they need to impress them.
The pattern I've seen repeatedly in real life is that a company does something they don't expect to be important and impactful, cutting every corner they possibly can to shovel out something that minimally meets the requirements. And then that software surprises everyone by actually being wildly successful, and now they have to support it and modify it to a state where they can build upon it. Which might be hard if the product is an unholy mess made by people who knew little of what they were doing and cared about it exactly as much as they got paid for it (that is, not much).
And cutting every corner to get the cheapest possible product out might not have even been the wrong call! Presumably most things made this way fare just as well as they were expected to and die quickly after being made, not spending scarce resources on making them better was probably the right thing to do.
It just sucks when you end up having to maintain strict backwards compatibility to something that was made in two weeks by one guy who took every shortcut on the way to duct-tape together something that technically does what was asked for. (Yes I'm thinking of you, javascript.)
This. Based on what I have seen so far in my company so very anecdotal.
Assuming they know and/or have the capability to do it, between the cost of correcting the issue and push to use AI into everything meaning raising any issue now, politically speaking, is a direct criticism of someone major VP pet projects. I personally simply started to log stuff.
The first thing they need to do first is acknowledge there is a problem to begin with. I am so glad I am not an actual programmer though. It would drive me nuts.
I think if they are interested on fixing it it's because the project provide business value, so then now it's worth it to build the software development team or make a contract with software development agency
I suppose a lot of the same kinds of skills will be required for both outsourcing, and LLM driven development.
That is, the "engineering" side of things (requirements gathering, communication, stakeholder management, defining specifications, testing, documentation, and generally managing chaos)
It's a bit strange that Karpathy's "vibe coding" ever gained traction as a concept, although perhaps only among those without enough experience to know better.
As I understand it, what Karpathy was referring to as "vibe coding" was some sort of flow state "just talk to the AI, never look back" thing. Don't look at the generated code, just feel the AGI vibes ...
It sounds absolutely horrific if you care even the tiniest bit about the quality of what you are building! Good for laughs and "AGI is here!" Twitter posts, maybe for home projects and throwaway scripts, but as a way of developing serious software ?!!!
I think part of the reason this has taken off (other than the cool sounding name) is because it came from Karpathy. The same idea from anyone less well known would have probably been shot down.
I've seen junior developers (and even not so junior), pre-AI, code in this kind of way - copy some code from someplace and just hack it until it works. Got a nasty core dump bug? - just reorder your source code until it goes away. At minimum in a corporate environment this way or working would get you talked to, if not put on a performance plan or worse!
For many non-technical people, their relationships with software engineers were producing horrific results. Vibe coding is an indictment of what we’ve been delivering. That a vibe-coded disaster is in any way desirable reflects poorly on us. The branding by Karpathy is cute but irrelevant to its success.
I know people running vibe coded startups. The software quality is garbage. But it does what they want. And that’s all they care about for now. Until a time when software quality impacts their business more than losing control does, they’ll keep vibe coding, rather than hiring a software engineer who bastardises their ideas.
A garbage version of the thing you want is better than a perfect version of something you don’t want.
Using AI doesn't necessitate "vibe coding" - there are smart ways to use AI, where you are managing and structuring the process, as well "vibe coding".
I guess the problem is that AI now allows non-programmers to program. It would be a bit like giving everyone a scalpel and they now either consider themselves to be surgeons, or give it a go regardless since now they can.
I'm not sure where you are getting software engineers that are "bastardising" your ideas?! You may want to look elsewhere, or pay for someone better !
Are they preferring AI over humans because the AI gives them what they want and humans don't? I thought they prefer AI over humans because AI is much cheaper and faster.
>I know people running vibe coded startups. The software quality is garbage. But it does what they want. And that’s all they care about for now. Until a time when software quality impacts their business more than losing control does, they’ll keep vibe coding, rather than hiring a software engineer who bastardises their ideas.
Well, IKEA's furniture quality is garbage yet they make billions. It's cheap and fast. That's capitalism for you. (not implying that communist countries produced amazing products...)
Like it or not vibe coding is here to stay, I too don't agree with the concept but have told people in my org that I've 'vibe coded' this or 'vibe coded' that. To us it just means we used AI to write most of the code.
I would never have it be put into production without any type of review though, it's more for "I vibe coded this cool app, take a look, maybe this can be something bigger..."
But ... why? Saying you "vibe coded" when you actually didn't makes you sound like you are doing something, well, dumber than you are actually doing, while also giving unrealistic expectations to people who don't realize you aren't actually vibe coding.
Yes definitely, but I'm pretty sure that he was just saying vibe coding is POSSIBLE and a fun thing to try, to see how far you can get (which is true, it can do some surprising things)
Not that companies should literally try to "vibe code" production software
The phrase got totally taken out of context, probably because it's what people WANTED to believe. They wanted to believe that the hard thing was now easy, and they could make/save a lot of money that way
I still maintain that the original tweet about it was a joke, or at least not a suggestion for doing real work but just a reflection on the freedom of yolo mode coding. It wasn't meant to be instructions.
I'm not sure.. I kind of remembered it that way too, although perhaps not so much as a joke but just a throwaway tweet of what he was up so - experimenting with AI and having fun.
However, I just searched up his tweet, and now I'm not so sure - he seemed to be advocating it as a new way of coding.
I feel at this point ‘vibe coding’ is just a disparaging phrase of any AI coding assistance.
As always people can create both good and bad code using the tools at their disposal but right now there’s a lot of upvotes to be had online by simply posting ‘lol vibe coding so dumb!’. It’s tiring at this point.
I suspect that he, as an insider is able to prompt and configure so that he gets good usable results every time, and when he describes that, it sounds so easy and obviously you should do it too.
> Startups save weeks getting to MVP with Vibe Coding, then spend comparable time and budget on cleanup. But that’s still faster than traditional development.
That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.
From what I've seen, I think developers can build just as fast, especially with AI assistance. They may not want to though, knowing full well the MVP/prototype will go directly into production.
Better to take some time to have a decent architecture early on. Product and management probably see that as a waste of time.
On the other hand, vibe coding allows the product team to make exactly what they want without having to explain it to developers. That's the real draw to this, basically a much better figma.
Perhaps there is a market for a product oriented vibe coding tool, that doesn't pretend to make code, but gives developers much better specifications while allowing the product and business side better input in the process.
>> Startups save weeks getting to MVP with Vibe Coding, then spend comparable time and budget on cleanup. But that’s still faster than traditional development.
> That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.
In a startup it's often very important to show traction, and thus decreasing time to market can be hugely beneficial, even if it costs you more time overall.
The same reason people can rationally take on technical debt in general.
There is a balance between getting to market as fast as possible and avoiding an architecture that will immediately make it hard to iterate after MVP.
The problem is that a lot of engineers don’t know how to not over engineer and waste time. And product/sales usually don’t know how to strike the balance.
For building a prototype, unless you have the discipline to not put the prototype into production and your organization has similar discipline, I wouldn't recommend vibe coding. We all know how hard it can be to convince management that he amazing thing they're using right this moment needs to be scrapped and rewritten because the insides are garbage.
No-code tools are better suited and safer to use in that respect.
This is true, except that in my experience, senior management seems to have a real hard time, differentiating between “ship-quality, but sparse, MVP,” and “lash-up, crap-quality prototype.”
> knowing full well the MVP/prototype will go directly into production.
If they didn’t think that was happening already, they were fooling themselves.
I remember a quote on here, where they said something along the lines of “If your MVP code doesn’t make you physically sick, you’re spending too much time on code quality.” MVPs seem to inevitably become the backbone of the company’s future.
I guess the service could be more accurately described as “C-Suite Cleanup As A Service,” but no one would hire them, then.
From the jump, even without the emdashes, it was crystal clear that this post was written by Claude. I'm sure the OP put their own ideas into the prompt, provided some sources, etc. But reading some of these phrases provoked a pretty visceral sense that I'm just reading an LLM's output:
"The harsh reality"
"he perfectly captured"
"architectural decisions that make senior engineers weep"
"fundamental issue"
It makes me wonder whether a whole class of writing is going to be deprecated because the cadence is just too similar to LLM outputs.
I wonder if vibe coding is a bit like DIY plumbing. You can do it yourself a bit and then later when water starts gushing all over your bathroom you hire an emergency plumber at a high fee.
You could say that. Professional plumbers often love to use tools built to make the lives of DIY plumbers easier too though. The difference is they know when and when not to do so.
It's an apt analogy. It's like the realtor is under pressure to sell the house so does a quick and dirty DIY plumbing. Then when the house is sold you hire a real plumber to fix it right, hopefully before the gushing disaster.
Here, founders demo something that attracts the investors' or customers' attention - then they can clean it up later.
Janitor Engineers [0] are already a thing? Damn. Also, all links in this article starting from the "Why AI code fails at scale" section are dead for some reason, even though it was written only 5 days ago. That raises some questions...
EDIT: Not trying to offend anyone with this [0], I've actually had the same half-joking retirement plan since the dawn of vibe coding, to become an "all-organic-code" consultant who untangles and cleans up AI-generated mess.
I’ve always found the pioneer, settler, town planner model to be a great way of thinking about this. Successful, long-term projects or organizations eventually can use all 3 types.
Maybe vibe coding replaces some pioneering work, but that still leaves a lot for settlers to do.
Vibe Coding is accelerating the death of documentation and architectural clarity.
Companies are measuring success by tokens generated and time-to-prototype, ignoring the massive, hidden cost of cleanup/maintenance.
The real skill is guiding generation carefully so the generated software isn’t crap. Some people here see Claude code and think it’s state of the art, whereas for best results you need a much more involved process.
It isn’t that different from any other form of engineering, really. Minimize cost, fulfill requirements; smarts-deficient folks won’t put maintainability in their spec and will get exactly what they asked for.
I bought into that idea a month or two ago, that more control and detailed instructions would deliver a clean result. That just led me down a rabbit hole of endless prompt re-runs and optimization loops. Many time I thought I had the final, perfect prompt, the next iteration slightly worsened the output. And sometimes the output was the same.
The last 20-30% of precision is brutal. The time and tokens we burn trying to perfect a prompt is simply not an optimal use of engineering hours. The problem is simple: Companies prioritize profit over the optimal solution, and the initial sales pitch was about replacement then it changed now its all about speed. I'm not making a case against AI or LLMs; I'm saying the current workflow, a path of least resistance means we are inevitably progressing toward more technical debt and cleanup at our hands.
Our company has been doing emergency fixes (system that are down, costing companies significant money and they cannot fix) for decades. We have been seeing a significant uptick in occurrences the past few years.
Readit News
I imagine it will be the same set of issues really. Just a different way of cost cutting measures. There can be good reasons to take shortcuts but, in my experience, the problems start when you're not mindful that there's a price to pay for taking these shortcuts. Whether it comes from managers, employees or outsourced personnel, it's the same result.
I haven't thought about advertising it as a separate type of service(for vibe coded platforms) yet but maybe I should. The Australian software market is small so haven't been hearing much about the results of those experiments.
I vibe-coded a simple helper script. If I wrote it myself it would have been 1/3rd the lines, not covered most edge cases (some of which were completely irrelevant, some of which actually useful), and it would have taken me way longer than just checking if the vibe-coded code works (this was the "either it works or it doesn't" kind of task, not something where subtle errors could reasonably be introduced).
I skimmed the code and removed the line that deletes temp files to reduce the risk that it accidentally wipes my home dir and ran it. As I was trying to work with the data deeper, I noticed missing temp files, and realized that there were two other temp file deletion lines that I missed.
It's simply too much code for a human to reasonably read, but the speed benefits are real.
(My plan for the future is not reading the code more carefully, it's putting it in a sandbox and letting the AI play.)
``` When making edits to the script, ensure the script remains
- Idempotent - Functional after a fresh install of a virtual machine
Additionally, keep things stupid simple and avoid:
- Unnecessary error checks - Defining colors and custom logging functions - Bells and wistles - Backups - Branching Paths - Script Arguments ```
I find it helps cull back the LLM 's overenthusiasm for abstractions.
By contrast, on one project many years ago I was reviewing the code generated by an overseas team, and I couldn't make head or tail of it, it was an absolute tangled mess that was impossible to fix.
Knowledge is usually not the problem, it is the shortcuts(or short-term decisions) that got them to a place where they can no longer operate the platform they need to survive. Often this is the cause of prioritizing velocity over anything and everything else. This is choosing the do it fast and do it cheap options with the assumption that it is always correct. That assumption of course is almost never true.
By the way, most cases where I've seen this there's usually an investor involved and they need to impress them.
And cutting every corner to get the cheapest possible product out might not have even been the wrong call! Presumably most things made this way fare just as well as they were expected to and die quickly after being made, not spending scarce resources on making them better was probably the right thing to do.
It just sucks when you end up having to maintain strict backwards compatibility to something that was made in two weeks by one guy who took every shortcut on the way to duct-tape together something that technically does what was asked for. (Yes I'm thinking of you, javascript.)
Assuming they know and/or have the capability to do it, between the cost of correcting the issue and push to use AI into everything meaning raising any issue now, politically speaking, is a direct criticism of someone major VP pet projects. I personally simply started to log stuff.
The first thing they need to do first is acknowledge there is a problem to begin with. I am so glad I am not an actual programmer though. It would drive me nuts.
That is, the "engineering" side of things (requirements gathering, communication, stakeholder management, defining specifications, testing, documentation, and generally managing chaos)
As I understand it, what Karpathy was referring to as "vibe coding" was some sort of flow state "just talk to the AI, never look back" thing. Don't look at the generated code, just feel the AGI vibes ...
It sounds absolutely horrific if you care even the tiniest bit about the quality of what you are building! Good for laughs and "AGI is here!" Twitter posts, maybe for home projects and throwaway scripts, but as a way of developing serious software ?!!!
I think part of the reason this has taken off (other than the cool sounding name) is because it came from Karpathy. The same idea from anyone less well known would have probably been shot down.
I've seen junior developers (and even not so junior), pre-AI, code in this kind of way - copy some code from someplace and just hack it until it works. Got a nasty core dump bug? - just reorder your source code until it goes away. At minimum in a corporate environment this way or working would get you talked to, if not put on a performance plan or worse!
I know people running vibe coded startups. The software quality is garbage. But it does what they want. And that’s all they care about for now. Until a time when software quality impacts their business more than losing control does, they’ll keep vibe coding, rather than hiring a software engineer who bastardises their ideas.
A garbage version of the thing you want is better than a perfect version of something you don’t want.
I guess the problem is that AI now allows non-programmers to program. It would be a bit like giving everyone a scalpel and they now either consider themselves to be surgeons, or give it a go regardless since now they can.
I'm not sure where you are getting software engineers that are "bastardising" your ideas?! You may want to look elsewhere, or pay for someone better !
Well, IKEA's furniture quality is garbage yet they make billions. It's cheap and fast. That's capitalism for you. (not implying that communist countries produced amazing products...)
Dead Comment
I would never have it be put into production without any type of review though, it's more for "I vibe coded this cool app, take a look, maybe this can be something bigger..."
Not that companies should literally try to "vibe code" production software
Two publishers and three authors fail to understand what “vibe coding” means - https://simonwillison.net/2025/May/1/not-vibe-coding/
( I think Karpathy addressed what he meant in this video, though I forget the details: Software Is Changing (Again) https://www.youtube.com/watch?v=LCEmiRjPEtQ )
The phrase got totally taken out of context, probably because it's what people WANTED to believe. They wanted to believe that the hard thing was now easy, and they could make/save a lot of money that way
However, I just searched up his tweet, and now I'm not so sure - he seemed to be advocating it as a new way of coding.
https://x.com/karpathy/status/1886192184808149383
As always people can create both good and bad code using the tools at their disposal but right now there’s a lot of upvotes to be had online by simply posting ‘lol vibe coding so dumb!’. It’s tiring at this point.
This point in history is not characterized by any real sort of seriousness about...anything, really.
Alternatively, it is the same sort of pleasant fiction that is being fed to CEOs about their workforce being able to be replaced Real Soon.
Deleted Comment
That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.
From what I've seen, I think developers can build just as fast, especially with AI assistance. They may not want to though, knowing full well the MVP/prototype will go directly into production.
Better to take some time to have a decent architecture early on. Product and management probably see that as a waste of time.
On the other hand, vibe coding allows the product team to make exactly what they want without having to explain it to developers. That's the real draw to this, basically a much better figma.
Perhaps there is a market for a product oriented vibe coding tool, that doesn't pretend to make code, but gives developers much better specifications while allowing the product and business side better input in the process.
> That's the core of situation as described in the article. I wonder how true that is, that it's faster overall than having developers build the MVP.
In a startup it's often very important to show traction, and thus decreasing time to market can be hugely beneficial, even if it costs you more time overall.
The same reason people can rationally take on technical debt in general.
People have to be careful not to miss their window trying to be perfect, but first and broken isn't a clear winner over second and working anymore.
The problem is that a lot of engineers don’t know how to not over engineer and waste time. And product/sales usually don’t know how to strike the balance.
But they grew, and one day could afford hiring professionals to rewrite it from scratch on a more scalable and robust stack.
For building a prototype, unless you have the discipline to not put the prototype into production and your organization has similar discipline, I wouldn't recommend vibe coding. We all know how hard it can be to convince management that he amazing thing they're using right this moment needs to be scrapped and rewritten because the insides are garbage.
No-code tools are better suited and safer to use in that respect.
If they didn’t think that was happening already, they were fooling themselves.
I remember a quote on here, where they said something along the lines of “If your MVP code doesn’t make you physically sick, you’re spending too much time on code quality.” MVPs seem to inevitably become the backbone of the company’s future.
I guess the service could be more accurately described as “C-Suite Cleanup As A Service,” but no one would hire them, then.
"The harsh reality" "he perfectly captured" "architectural decisions that make senior engineers weep" "fundamental issue"
It makes me wonder whether a whole class of writing is going to be deprecated because the cadence is just too similar to LLM outputs.
You learn a little more for next time.
If you do something for a living, you have to work faster than if you are doing it as a hobby for fun.
Here, founders demo something that attracts the investors' or customers' attention - then they can clean it up later.
EDIT: Not trying to offend anyone with this [0], I've actually had the same half-joking retirement plan since the dawn of vibe coding, to become an "all-organic-code" consultant who untangles and cleans up AI-generated mess.
Maybe vibe coding replaces some pioneering work, but that still leaves a lot for settlers to do.
(I admit I’m generally in the settler category)
https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
The real skill is now cleanup, not generation.
It isn’t that different from any other form of engineering, really. Minimize cost, fulfill requirements; smarts-deficient folks won’t put maintainability in their spec and will get exactly what they asked for.
The last 20-30% of precision is brutal. The time and tokens we burn trying to perfect a prompt is simply not an optimal use of engineering hours. The problem is simple: Companies prioritize profit over the optimal solution, and the initial sales pitch was about replacement then it changed now its all about speed. I'm not making a case against AI or LLMs; I'm saying the current workflow, a path of least resistance means we are inevitably progressing toward more technical debt and cleanup at our hands.
You can start off just with documentation and then in the process check if the code is still in line with the documentation.
You can also generate documentation from the code. Then check yourself, if it fits.