Vibe coding cleanup as a service
donado.co
donado.co
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.
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.
The environment that creates "rescue" projects is usually not one where long term thinking is prevalent. It would be a pet project of someone who's still there or someone who left but where the ultimate decision maker is still there. Either case, you need to walk on egg-shells and be mindful that dealing with the technology problems is the easiest part of such an engagement. I'm not ashamed to admit that I've learned that lesson the hard way.
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.)
That is, the "engineering" side of things (requirements gathering, communication, stakeholder management, defining specifications, testing, documentation, and generally managing chaos)
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.
Thank you!
X. Don't write stupid code.
Replace X with your prompt.
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.
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...)
IKEA furniture is obviously a trade off between quality and cost, but it does what it is designed to do.
Capitalism isn't just a race to the bottom - there are markets for products at all sorts of price points.
Maybe typical Supermarket produce section = IKEA is a better comparison than vibe coding = IKEA, although whether a tomato that tastes of nothing is really doing it's job is debatable.
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
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.
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.
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.
I've lived through several semi-disastrous VC-pushed early product launches, and have seen some being sufficiently bad to entirely destroy a product, despite it being extremely useful.
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.
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.
But they grew, and one day could afford hiring professionals to rewrite it from scratch on a more scalable and robust stack.
"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.
It's taken 8 years to go from introduction of the Transformer (attention paper) to today's LLMs, so I wouldn't be holding your breath waiting for something significantly different or more capable to replace it. It may well take AGI to replace a human "vibe coded mess" fixer-upper.
The technical debt you're building up by vibe coding your product may well become a boat anchor well before some product you are fantasizing about materializes to bail you out.
If you've somehow vibe coded an MVP good enough to push out to customers, and achieved some degree of success with it, then what you need to keep going is momentum - to be responsive to customer feedback, add new features, etc. If you've built such a poorly designed and flaky MVP that you can't rapidly iterate on it, then that is probably not going to go well.
I feel this position severely discounts the acceleration that is going on right now and our inherently limited abilities. Humans are not going to ever be significantly better at coding than they are today, and we can literally watch LLMs improve on it, by the month.
I wouldn't expect to see a human level AI software developer (not just "coder" - the easiest part of the job) until we have human level AGI. Run-time compute and agents seem to be responsible for most of the recent advances in capability - good ways to squeeze the most out of the underlying LLM paradigm, but not the path to AGI.
We'll get there (AGI) one day, maybe in next 10-20 years, but in meantime if you want a vibe coded pile of sphaghetti to be cleaned up, it seems like it's going to be a job for a human.
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.
Perhaps the old adage "it's getting hard to find X employees [at the price we are willing to pay]" applies.
That surprised me because I've seen articles and heard podcasts for years where they've said COBOL programmers are well paid due to scarcity, though never quoting amounts.
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.
Low confidence to change it, low internal and external quality.
Also some differences: low age-to-quantity ratio, schedule pressure, inflated expectations.
It's most cost-effective to shift errors from runtime to compile time and from compile time to design time.
Unfortunately, AI rushes people to runtime as fast as possible.
I agree that vibed code can often be treated like other legacy code. However is it true that people are reluctant to change vibe code?
Depends on training data. It's not great at rust but it can chug along in small examples. I do suspect strongly typed languages are more suited to AI if it has the opportunity to learn them properly. The movement recently has been generalization, but i personally think if we want to reach further in AI coding, we need models with language and domain specialization.
I imagine a AI agent trained to parse LLVM and feed itself static analysis output, could reach new heights of code understanding for Rust for example.
> people are reluctant to change vibe code?
I think people are reluctant to change existing code in general. Its one thing for a personal project, but for a collaborative codebase, it's a large investment of energy to parse out a unfamiliar part of the system. "The original developer made sure this works, and it passes all tests, so i shouldn't poke it too much without knowing the system as well".
"Vibe code is legacy code (val.town)" https://news.ycombinator.com/item?id=44739556
https://www.slater.dev/about-that-gig-fixing-vibe-code-slop/
Your legacy code products may be happily running without problems, due to all those production issues (incl. new requirements) that were identified and fixed over the years, with the problem only coming when there is a need to change it, especially when there is no-one left familiar with the codebase, maybe not even with the language/tools used to build it.
But both is here to stay.
But the general idea of compressing every code example in existence into a predictive autocompleter and generative assistant will never go away.
It would be like coding without syntax highlighting, by choice. Sure, people did it when they had to, but not anymore. You could, but why?
Do I really feel better about myself for writing a slight variation on depth-first search by hand for the 80th time? Not really?
It could be interesting to take on a consulting project. I haven't done any contract work for many years but I'm curious to see if I could provide some value. Let me know if you need help with making a project more maintainable: refactoring, linters, writing tests, setting up CI/CD pipelines, etc.
* come up with requirements for a non-obvious system
* try to vibe-code it
* clean it up manually
* add detailed description and comparisons of before and after; especially, was it faster or slower than just writing everything manually in the first place?
My suspicion is that for any experienced dev this is slower every time
It is only faster when the person doing the work probably could not have built the thing themselves in the first place
i can only imagine that services like described in this article will become a very common part of getting proof of concepts built with AI into production.....
https://www.npr.org/2025/08/02/nx-s1-5483886/tea-app-breach-...
AI coding has the same bottleneck: specification quality. The difference is that with outsourcing, poor specs meant waiting weeks for the wrong thing. With AI, poor specs mean iterating indefinitely on the wrong thing.
The irony is that AI is excellent at helping refine specifications - identifying ambiguities, expanding requirements, removing assumptions. The specification effectively IS the code, just in human language instead of syntax.
Teams that struggled with distributed development are repeating the same mistakes with AI. Those who learned specification discipline are thriving because they understand that clear requirements determine quality output, regardless of the implementer.
I wasn't around then but colleagues told me it took years for leadership to understand what's happening and to turn the ship around.
And, on another, where the client seems to have tried to make it work through an LLM, but did not work.
LLMs are still too sycophantic. The ideal agent needs to say no increasingly as time moves on, explaining why new requirements would conflict with existing commitments, and grunt awkwardly and emit enough noxious fumes so that business people only come forward with their most pressing needs rather than wavering whims.
And so, I dug deeper, I tried Claude, GPT-5 and Gemini. While each have their own merit, they all seem to be flawed when it comes to keeping things simple. Having said that, there are a lot of times I'm stuck in these codebases and the AI knows exactly what's happening if you give it the right context (within VS Code). So, definitely you can just setup a small shop to "De-vibe" coding with AI. Ironically.
YMMV but I’d rather build the MVP without much AI but then clean it up using it.
So I suspect we will get AI-assisted vibe coding cleanup very quickly.
Our (new) AIs will help us solve problems that we wouldn't have without our (old) AIs.
They don't seem to have a 'cohesive worldview'; additional context can easily sway them from one conclusion to the opposite conclusion. A large part of coding is about decision-making and prioritization; it's difficult to perform well at either of these tasks unless your worldview is internally consistent.
And isn't the expected timeframe hours, days or weeks rather than milliseconds or seconds like people expect with MCP?
1) generate API tests using AI
2) refactor the app manually
3) make sure the tests passed
Took me a few hours or so. The app was pretty small, though.
Fixing vibe coding with yet another vibe coding should be the norm I guess.
Other people who have more or a lot of experience with coding, help them and everybody profits in the end.
I understand that it becomes a problem with some businesses but others may profit too.
It's not all bad.
To be fair to him, my partner who works in Healthcare has the same concern, and for quite precisely the same reason: if the kind of work normally done by juniors who are training/building their skills is done by machines instead, where do the next generation of seniors come from?
My response to both was that I was confident the market would fix this problem itself - people will not pay for garbage. There is a reason books are still printed by established publishers. Why buy a book when you can just print a book on printer paper yourself? Because reading a book on printer paper sucks.
I cannot imagine that machines will ever replace any work where there is any meaningful threshold for "correct". I am so intrigued to see how this plays out across the broader economy.
For most of human history calculations were performed by humans. Entire banking systems were 100% dependent on humans, with some helpful tools, performing accurate calculations. The idea of not performing that work with machines is laughable now. Machines have replaced humans, especially when correctness matters.
Humans are also remarkably bad at being correct and most jobs have a very low impact. I think your perspective is skewed towards the job you are doing, which is in no way representative of most office work, which is mostly tedious, low impact and low stakes.
Based on..?
>I cannot imagine that machines will ever replace any work where there is any meaningful threshold for "correct".
Autopilot?
(In my opinion: Somewhat, almost and complete.)
AWS CEO had roughly the same thought. Senior devs may skyrocket in price if juniors cannot progress to senior skillsets. Those that stop hiring juniors will have a rude awakening when they need more capable software devs in a few years, and all senior roles are now skyrocketing in price. Hire some capable juniors today to train up.
https://www.theregister.com/2025/08/21/aws_ceo_entry_level_j...
exactly, the usage of LLMs will only grow as they quickly get better than all the garbage code slop humans write
Company hires a bunch of young MBAs from prestigious universities who don't know how to code; pay them large salaries to produce a massive pile of junk which doesn't work. Pay some engineer with 10+ years of experience to be a 'code janitor' to clean up the mess to actually make it work.
Quite dystopian considering that the experienced engineer could probably build the whole thing in 1/10th of the time from scratch.
This would align with the trend of companies imposing an increasing number of arbitrary and counter-productive constraints on engineers whilst simultaneously expecting them to be more productive.
FSV = full slop version
> How Senior Engineers Clean Up Code and Scale Products with AI
> Partnering with us means investing in quality, not just speed. We leverage AI to accelerate development and testing,