And isn't the expected timeframe hours, days or weeks rather than milliseconds or seconds like people expect with MCP?
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.
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?
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.
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/
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-...
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.
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.
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.
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.
* 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?
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.
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?
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 humans write
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.
d_tr•4h ago
sjdonado•3h ago
d_tr•2h ago