Vibe code is legacy code
blog.val.town
blog.val.town
What I think happened: there are two incumbents in this space that are not happy about him showing up and charging a fraction of their monthly cost for a better, more modern product (their products are Windows-based desktop software). So they hired hackers to hack his SaaS (because these hackers have never demanded money). Unfortunately, that vibe-coding resulted in some bad code that made it easy to hack. First, the user list was leaked on the FE of the code and the hacker emailed all of the customers. Second, the hacker got a hold of his Stripe key and issued every customer a refund. Third, the hacker has been trying to inject XSS attacks into app (we'll see a random `<script>alert()</script>` tag in some fields)
I think indeed, vibe-coded software in the hands of the inexperienced is instant tech debt. But at the same time, he was able to prove out a viable business in a matter of a few months with no engineering background and no technical capability.
Now he's hiring a developer to shore it up.
Was it worth it? Yes, it is terrible, shoddy, insecure code, but he proved out a viable business with just a few hundred dollars of investment.
How much is it costing him to hire someone to reimplement his idea correctly?
And it only works because has proven the revenue model and found the customers already.
Generally bandits are not interested in sparing anyone. =3
=3
He hasn't validated the market at the price point that includes the cost of a developer to build the product. He's validated a market in which it costs him close to zero to deliver. He's not validated a market which costs (say) a few months of dev time.
The important question is: what was the cost and consequences of the exploits for users of the service?
> ZUCK: i don’t know why
> ZUCK: they “trust me”
> ZUCK: dumb fucks
(E.g., early Dropbox went four hours accepting any password for any account, and shortly thereafter somebody got about 30 million of their passwords, and they’re doing just fine.)
But I'm guessing there are lawsuits incomming with GDPR/US equivalent fines.
You can download a few of them out of GitHub and run them immediately, too.
Half an hour after the push I got an email and text from GitHub that I had exposed credentials. I quickly logged in to my AWS to turn off the service, to see that AWS had suspended that service because the bounce rate on the 80000 emails sent in that 15 minute period was too high. It was crazy just how fast it was exploited.
People underestimate the speed, but also the number of pivots that advanced attackers will make. Sure, these kinds of problems are easy to exploit, but with major organizations that employ reasonable defenses, the attackers will pivot through 50+ exploits/machines/layers to get to the target(s). This can take place over weeks or months.
1. Distracting from a more important vulnerability
2. Later contacting customers, advising them of the "accidental" refund and redirecting them to a more appropriate payment mechanism (one without the KYC Stripe does, were they to try to steal funds directly)
3. Testing stolen credit cards before using them elsewhere
Etc. Scamming people is a big industry, and not all of the plots are immediately obvious.
The internet is a wild place in any aspect of it. You should try spinning up a random virtual private server on any cloud provider, plug in a public IP address,and listen to traffic. Sometimes it takes seconds to get your first traffic from vulnerability scanners.
Basically a simple server listening on a port will experience hundreds of random script-probing attacks per day. And if any of them show the slightest hint of succeeding then that escalates quickly to thousands per minute.
You don't need a DNS entry to "expose" the IP address (there are only 4 billion). Moving to another port reduces, but doesn't eliminate the traffic.
Telling people this freaks them out. But as long as the server is done well its just noise.
There are groups out there just looking at the certificate transparency logs to get the newly added certs to scan.
Back then, I mostly only ran Linux, but for some reason, I needed to run something on a Windows machine, so started installing Windows 98 SE onto a machine, and set it up with a public IP address without even thinking about it. It crashed before it'd even finished installing [0], and investigation showed that it'd been whacked by an automated RCE exploit scanner.
I immediately decided it was never worth the risk of putting a Windows machine on a public IP, and set up a NAT even though I had 3 spare public IPs.
[0] There was already a published update to protect against this exploit, but I was scanned and hacked between the base install exposing the bug and the automatic update patching it.
Create a new Github repo, within minutes there's someone (or something) poking around it.
Similarly if you post any credentials, they'll either get nabbed and used or a friendly scanner service will notify you about it and will tell you exactly where the credential is if you make an account in their service.
# zcat -f /var/log/auth.log* | awk '/sshd/ && /Invalid user/ && $6 != "from" {print $6}' | sort | uniq -c | sort -bnr | head -n 30
5190 #redacted: my domain name
3063 admin
1891 #redacted: another domain name
931 user
724 ubuntu
287 test
268 solv
206 odoo15
200 solana
197 sol
184 ubnt
173 wialon
170 Antminer
169 guest
168 odoo17
159 oracle
157 postgres
151 git
150 support
142 ftp
135 ftpuser
120 debian
118 pi
91 nginx
85 baikal
82 docker
81 perl
74 operator
74 deploy
72 dev $ journalctl | awk '/sshd/ && /Invalid user/ && $6 != "from" {print $8}' | sort | uniq -c | sort -bnr | head -n 30
34 admin
26 oracle
21 postgres
20 user
18 test
18 seekcy
17 ftpuser
15 ubuntu
15 inspur
9 zabbix
8 nginx
8 mysql
8 jenkins
8 hadoop
7 server
7 nagios
6 teste
6 amax
5 support
5 backup
5 administrator
4 git
4 demo
4 a
3 zyfwp
3 usuario
3 tomcat
3 testuser
3 test1
3 teamspeakI wonder why this features so low in the list. The default user:pass combo for Raspbian/Raspberry Pi OS is pi:raspberry
22307 admin
19668 user
15396 ubuntu
7038 user2
6954 test
6375 debian
3938 ftpuser
3433 postgres
3416 oracle
3076 deploy
3003 steam
2917 user1
2830 dev
2570 test1
2352 es
2187 server
1957 hadoop
1680 alex
1676 guest
1517 testuser
1494 sammy
1392 mysql
1228 minecraft
1218 pi
1184 support
1148 sysadmin
1140 ubnt
1120 from
1090 123456
1035 test2In high school in the early 2000’s, I ran a small Apache server from my home that was basically Geocities but even less discoverable - I used it to learn PHP, SQL, and frontend. One day my log started filling rapidly as someone effectively ddos’d my home server. If they’d bothered to actually poke, they likely would’ve been able to exploit it relatively quickly even without all of today’s tools. I imagine the process of discovery and exploitation is magnitudes more impressive and performant today.
Your friends' service was just the proverbial paper car in a thunderstorm: the thunderstorm doesn't care about the paper car but destroys it just the same.
I was mirroring this to another machine, and I'd foolishly already configured haproxy to serve from either machine. In the 10 minutes (guesstimate) between starting to populate the directory and closing off access, I had one bot scrape every single file in there. What was worse was that it'd cached the index, and continued scraping these files from the other backend too, so I had to shut off access to that directory on the live server as well as the backup.
Whilst technically, all of these files were "public" because I wanted to share them, some of them weren't publicly linked to (things like my CV etc) which I'd rather hadn't been scraped by some random bot (that of course, didn't identify itself or respect robots.txt).
I could offer some anecdata as a counterargument but I'm a bit ashamed about how it happened so I'll just say, you friend was lucky it only ended at that.
1) They took action after getting the Stripe key by refunding all customers
2) They drafted an email to all customers after a hack that got the mailing list and API route to send emails
3) Not once has the hacker asked for compensation of any kind nor a ransom
Your friend should take this as a lesson instead of trying to deflect blame to their competitors.
I think you mean “for the lulz”
Definitely not a good idea but it's not an unreasonable motivation.
Breaking things is just fun for them and the internet is their video game.
Also the vibe I am getting from places like reddit/etc... is that it's currently open season on vibe coded apps. Lot's of internet points to be had for destroying them.
I am not saying it is the most likely case or even ethically justified but it is definitely not a super unlikely one. Anyone who thinks that's an impossible scenario has not been in the hacker's shoes.
He's lucky they didn't find a way to use it for card washing.
If someone took money out of your pocket would you call it stealing? What if they gave it to someone else, like a past employer or your parents or a humanitarian organization?
By the way, you should check a dictionary. The definition of "stealing" is literally taking something away without permission.
Protect your keys.
No, it doesn't.
So if I get your house key I can use your bathroom?
Seriously, what hill are you trying to die on here?
Can you name an instance of stealing that could not be described as a forced refund?
Respectfully, what the hell are you talking about?
Imagine you work 40 hours making an app and I pay you for those 40 hours. A third party comes in and says, I'm forcing a refund here - you lose the money you made, but you get the app you made.
How do you feel about this forced refund?
I remember when I was a kid running a tiny forum with phpbb or something, and some script kiddies from g00nsquad (can't remember exact spelling, but something like that) defaced it. They didn't ask for money, they just did it for fun.
Sure things have changed now and the internet has become more corporate, but I reckon there are still people out there doing this stuff l because they can.
I recall a while back there was a story here about a recipe app that used LLMs to generate recipes. It didn't took long before posters started showcasing recipes they tricked the LLM to generate, involving ingredients such as cyanide and computer chips.
The pull is always there.
Most of what I see is looking for very specific vulnerabilities - a very high proportion are looking for hidden files and directories being served (e.g. .git, .env) or specific software (e.g. Wordpress), or similar.
In over 20 years of dealing with many mostly smallish businesses the compromises have been:
1. A client who insisted on using Wordpress for one of their sites (against my advice) because they had people who knew it so it was the cheap option. It was easy to see what would happen because those people were not available long term. 2. A very carefully set up server with a hardened kernel etc. I did not set it up so cannot give all details and neither do I know how it was compromised. It was carefully set up because it was a target for political reasons so I would guess it was a targetted attack.
On the other hand I know there have been many vulnerabilities. There have been many vulnerabilities in the applications - the outstanding examples being creating queries by concatenating user input with SQL (no escaping at all) in multiple places across a small site (years ago), and (recently) finding code that called (python) exec on user input. Many other flaws that have been present for years. Not updating OSes, server software and frameworks for many years is usual.
In spite of all that, just those two compromises. You will probably get away with a high degree of bad code and bad practices in deployment and maintenance with a small site.
One those vulnerabilities are found, the hackers will pounce, and, whilst ransomware is one potential outcome, they might instead do all of the kinds of things GP has described. They don't care what the site is for or what industry you're in.
...and work to exploit your code to their own benefit. They don't do this just so that they can refund your customers.
It’s called a skill issue and to prevent these you have to actually spend time learning instead of vibing.
It’s literally the same as driving a car without license.
Everyone can do it - but shouldn’t.
What a surprise.. This has become the new "the default password was admin and no one changed it". And I remember vendors getting enough flak for those defaults that most of them changed them.
In a perfect world the creation of software would have been locked down like other engineering fields, with developers and companies suffering legal consequences for exposing customer information.
The EU is the only place hiring software engineers right now. Everyone in the U.S. just keeps laying them off.
Spotify is European. Any innovative SV companies going to unseat them with sheer pluckiness? Same goes for Meta or Amazon going the other way.
China and to some degree Russia have their own ecosystems due to anti-innovative barriers they put up.
You can add Korea to this list.
Even in the US most software jobs are lower-scale and lower-ROI than a company that can serve hundreds of millions of users from one central organization.
But for the engineers/investors in other countries... I think the EU, etc, would do well to put more barriers up for those companies to force the creation of local alternatives in those super-high-ROI areas - would drive a lot of high-profit job- and investment-growth which would lead to more of that SV-style risk-taking ecosystem. Just because one company is able, through technology, to now serve everyone in the world doesn't mean that it's economically ideal for most of the world.
There are some industries where the massive cost of this type of lock down — probably innovation at 1/10th the speed at 100X the cost — is needed. Medicine comes to mind. It’s different from software in two ways. One is that the stakes are higher from a human point of view, but the more significant difference is that ordinary users of medicine are usually not competent to judge its efficacy (hence why there’s so much quackery). It has an extreme case of the ignorant customer problem, making it hard for the market to work. The users of software usually can see if it’s working.
Which are reasonable prices when lives are at risk.
Yes, I know RTOS are not general purpose, this is NOT apples to apples, but that is what that kind of reliability, testing, safety certification, etc. costs.
I'll say video games would certainly be worse.
I don't know if we'd be worse off with a lot of other software and/or public internet sites of 20-to-30 years ago. A lot of people are unhappy with the state of modern consumer software, ad surveillance, etc.
Probably a lot less identity theft and credit card/banking fraud.
For social media, it depends on if that "regulate things to ensure safety" attitude extends to things like abuse/threats/unsolicited gore or nudes/etc. And advertising surveillance. Would ad tracking be rejected since the device and platform should not be allowed to share all that fingerprinting stuff in the first place, or would it just be "you can track if you check all the data protection boxes" which is not really that much better.
I'm sure someone would've spent the time to produce certified Linux versions by now; "Linux with support" has been a business model for decades, and if the alternative is pay MS, pay someone else, or write your own from scratch, there's room in the market.
(Somewhere out there there's another counterfactual world where medicine is less regulated and the survivors who haven't been victimized by the resulting problems are talking about how "in that other world we'd still be getting hip replacement surgery instead of regrowing things with gene therapy" or somesuch...)
What you're really talking about when you talk about "locking down the field" is skipping or suppressing the PC revolution. That would make things like opaqueness and surveillance worse, not better. There would be nothing but SaaS and dumb terminals at the endpoint and no large base of autodidact hacker types to understand what is happening.
I have wondered if medicine wouldn't be a lot more advanced without regulation, but I tend to think no. I think we have the AB test there. There are many countries with little medical regulation (or where it is sparsely enforced) and they do not export sci-fi transhumanist medical tech. They are at best no better than what more regulated domains have. Like I said, I think many things about medicine are very different from software. They're very different industries with very different incentives, problem domain characteristics, and ethical constraints. The biggest difference, other than ethics, is that autodidactism is easy in software and almost impossible in medicine, for deep complicated practical as well as ethical reasons.
For software we do have the AB test. More conservative software markets and jurisdictions are vastly slower than less conservative ones.
Investing time building familiarity with proprietary software is already a dubious move for a lot of other reasons, but this would be just one more: why would I build curriculum around something that I'm just going to have to change next year when the new CEO does something crazy?
And as bad as it might be for many of us who hang out here, killing off proprietary software would be a great step forward.
Microsoft in the 1990s would have used the regulatory and licensure process to shut down open source. They tried to do it with bullshit lawsuits.
A doctor kills a patient because malpractice. Could that patient have died anyway if the patient had a more critical condition?
That is a non sequitur argument.
> Would they still be liable in your perfect world?
Yes. The doctor would be liable because did not meet the minimum quality criteria. In the same way that the developer is liable for not taking into account any risks and providing a deeply flawed product.
It is impossible in practice to protect software from all possible attacks as there are attackers with very deep pockets. That does not mean that all security should be scrapped.
Your spouse dies in surgery. The highly experienced surgeon made a mistake, because, realistically, everyone makes mistakes sometimes.
Your spouse dies in surgery. The hospital handed a passing five year old a scalpel to see what would happen.
There's a clear difference; neither are _great_, but someone's probably going to jail for the second one.
In real, regulated professions, no-one's expecting absolute perfection, but you're not allowed to be negligent. Of course, 'software engineer' is (generally) _not_ a real, regulated profession. And vibe-coding idiot 'founder' certainly isn't.
What happened is a perfect natural selection. The friend is a very small actor with probably a dozen customers not a multi-billion $$ company with millions of customers.
But I guess the lesson is to vibe code to test the market while factoring a real developer cost upfront and hiring one as soon as the product gets traction.
Were going in circles far too fast to have licensure that hinges on being up to date.
> legal consequences for exposing customer information.
Still a good idea. Also without taking vibe coding into account. Far too many tech companies are way too sloppy with customer data. Often intentionally so.
This feels like less of a win for the customers though. They're paying money and exposing their data insecurely, all for a product that maybe does what it's trying to do.
> Now he's hiring a developer to shore it up.
This is going to be way harder than it sounds...
I'm all for AI as a reference or productivity/learning aid, but the results without a human in the loop quickly get horrific.
It's because the software is that much of an improvement over the incumbents at a fraction of the cost. Better features, more flexible, easier to use, faster, etc. Everything about it is better than the two major vendors.
The rebuild will likely end up easier, IMO, because the screens and the logic is all done. Most of it just has to be moved to strict backend and then have the APIs secured correctly.
How to draw an owl…
Step 1. Draw a circle. Step 2. Draw the rest of the owl…
In this case, it's understanding the use cases and flows that the customers value and where the incumbents are coming up short.
There are other (worse) ways to structure data, you should not assume that a badly-built CRUD app uses a good one.
I would have never thought i would one day envy licensed professionals like lawyers who have a barrier for entry into their profession.
Atlas can finally be relieved of holding up the sky, since the 'just' in that sentence is capable of even heavier lifting.
It's only possible for you to say that because you know that the financial incentive is tipped towards vibe coders who don't care about security vs towards consumers...
The problem is that, as it often happens, the prototype was then deployed to production. In this case, it was partly the fault of your non-technical friend who didn't know better, but software engineering history shows us this sometimes happens because of customer/boss pressure.
So it's often the case prototypes designed to prove feasibility or to demo to customers become production software, and AI makes this undesirable result even more frictionless.
It seems in our line of business we are doomed to repeat past mistakes -- forever.
They will push out to the moon even after all the technical staff had signed a report saying why it's a price of trash and why shouldn't be done.
Double that down of they are financial or research. Commercials are much more practical and understand you needed a real product for client retention.
Maybe we get something good of this push for AI and people begins to understand the difference between product and prototype.
There should be legal consequences for treating people's data with reckless abandon. It's normal for restaurants to be inspected. Commercial apps should also be inspected by independent bodies and fines must be paid if serious negligence is found. Imagine finding out that your favorite restaurant had a rat infestation on their storage room for a year.
And of someone gets food poisoning because the restaurant used expired ingredients, it gets heavily fined and possibly shuttered. This should also happen with software. If your root AWS user key is leaked in your frontend, your service deserves to be shuttered.
The good news is that with each of these we get to "validate" that having an idea still isn't worth much without the ability to actually execute.
It's the opposite, right? When a dominant incumbent exists, you have to prove that there is a market for an alternative that can compete with more mature, established software.
If he had been unable to get customer he would have known it was not worth building a real product.
and the vital ingredient? complete contempt for his customers
I predict 2030: all sites in most countries will need a license to operate and something like SOC2 certification. Even for your blog.
This is a no fly zone amigo, that's going to be a hard no from me dawg.
That's not instant tech debt, that's a class action lawsuit for negligence with damages that were I a juror in a trial I would find him liable.
Some of the software we know and love today started with someone writing their very first line of PHP code, or Rails.
Vibe coding is ultimately about getting ideas shipped faster. Code quality is an engineer recruiting/retention strategy.
As we saw with that Tea app (which wasn't even vibe coded), you're only as secure as your weakest firebase store.
I can name many companies that have Olympus Mons levels of tech debt, and are doing great. Here's one: Spotify
Studies show that using LLMs for coding results in negative net productivity gains on average.
Ultimately, whatever the hype factor there is a large number of clever people putting their time and money into it for a reason.
It had a very specific caveat of "within existing codebases that the engineer was intimately familiar with."
In all other instances, it was not slower
Plenty of people probably. There are hundreds of businesses that constantly get exposed for massive leaks and/or horrendous business practices yet they're doing just fine. I'd imagine the killing blow in this case would be the stripe key but beyond that they would've likely had no massive issue.
I feel like this describes most people that start their own business at first. It just usually isn’t a lack of experience in producing the product. It’s a constant tradeoff of what skill to invest more time into to keep it afloat. They’ll learn sooner or later.
It's just search, and most people who try will discover ways to fail, not to succeed.
The customers know there was a hack because the hacker emailed them (I had a test account and received the same email). Yet he's had no churn because there's so much value being delivered.
I think there's something to be said for that.
He's doing the digital equivalent of drop-shipping. No one is making money at that anymore either, although people did well at first.
Drop-shipping software products isn't a long-term thing.
> Yet he's had no churn because there's so much value being delivered.
In a market that is tolerant enough of broken software that they won't churn after getting notice that it broke, it only takes another "ideas guy" to vibe-code a competitor product and take all the customers because they can charge less than he is charging[1].
[1] Because, as you said, he now has to retain a real dev to fix it, which costs money, which will have to come out of the customers., said customers being willing to switch to a cheaper replacement, which will be the vibe-coded low-cost competitor, which will eventually need a real developer, which will raise costs, which have to come from the customer, which ....
But the reality is that the users are first and foremost concerned with their day-to-day business. Just because you can do X doesn't mean you will do it.
It's also true that there still remains some foundational knowledge required like knowing what a database is, what React is, how to prompt. There's a big generational divide on this so I do not think we are the point (yet) where "anyone" can do it. There is still a need to have some background knowledge and some technical friends that can guide you.
Thank god that someone, somewhere, was able to make some money out of irresponsibly releasing software into the world!
I don't think it's stretching the airplane analogy to say: just because you can run the autopilot doesn't mean you are qualified to fly a plane and doing so might be irresponsible. Vibe coding (or vibe whatever with AI) too often overlooks the experience and expertise needed to do the thing.
See also the Tea app hacks.
I have personally taken this approach with web dev, granted I'm a very senior developer. First, develop features, then ask a larger/smarter model (o3, o3-pro, gemini-2.5 pro) to analyze the entire codebase (in sections if needed) and surface every security issue, vulnerability, attack vector, etc. I then pass that back to agents to execute refactors that clean up the code. Repeat until all your keys are in the proper place, all your calls are secured, all your endpoints are locked down, all your db calls are sanitized, etc etc etc.
Now, this should have been done PRIOR to release and would have only taken a few more days (depending on app complexity and the skill of the developer).
[1]: https://arxiv.org/html/2505.15216 - "OpenAI Codex CLI: o3-high, OpenAI Codex CLI: o4-mini, and Claude Code are more capable at defense, achieving higher Patch scores of 90%, 90%, and 87.5%"
It doesn't look at the big picture of multiple entry into the software. For example he had one vulnerability which required a hop through email which would create an entry into a table that ended up elevating permissions temporarily.
Hopefully platforms like Replit, Firebase Studio, et Al one day just include a security audit agent.
Fixing design and/or architecture at a high level usually requires a signficant rewrite; sometimes even a switch in technology stacks.
Vibe coding is going to bring upon regulation, which is the opposite of the lower barrier to entry people want it to be.
This has been the main Silicon Valley business model for years. Find an existing, regulated industry (taxis, hotels); skirt the regulation via the magic of computers (and contractors) until you become Too Big To Fail.
I don't think he proved that. In fact the point of the story seems to be the opposite: even if you have a nice looking demo that does the thing, there is a lot of unseen cost to bringing it up to production spec that has to be accounted for.
Wait, if there are competitors, how was he able to prove a viable business when there were two viable businesses out there?
They are legacy incumbents using desktop software in an ostendibly solved space.
The question here is whether was appetite for a lighter, web-based solution.
Is that your takeaway? My takeaway is that he was able to prove that paying nothing for s/ware development is a viable strategy to outcompete businesses who pay for s/ware development.
I mean, by that measure, I can "prove" a viable market for ride-sharing that charges 50% of what Uber, et al charges. All I have to do is have the drivers drive for free.
> Now he's hiring a developer to shore it up.
I would bet good money that that is going to go badly too, unless his instructions to the developer is "Do whatever is necessary, including rewriting from scratch if that is necessary", and the reason I say this is because the vibe-coded apps I looked at were all very hard to follow.
That statement is a bit of a stretch though, because
> charging a fraction of their monthly cost
I have to assume at least part of his success was the price point; and that price point was possible because he wasn't paying any software developers to do things right. So "having lots of vulnerabilities" was a core component of his business model. Once that part is removed, the model is no longer proven.
That is what is so broken about this whole vibe coding to riches thing. Ignoring the very real problems with the quality of the code and security issues, if you can vibe code it what is stopping someone else from doing the exact same thing.
It sure isn't like security is any better... clearly.
The thing is, not everyone knows about these tools. Many small businesses are focused on their day to day. Even if you can build it yourself, there is still some operational overhead. Even if you don't have to be technical as an engineer, you still need to know a bit about apps -- what's React? What's a database?
I think that tells you something: they have a real, painful, and costly problem to solve that he solves for them to a T.
> ...normie-coded startups
Having been in the startup space for the last 20 years spanning bootstrapped companies to startups that raised $8m seed rounds to startups that raised a $100m C round, I've learned that there's only one thing that matters: solving valuable problems and getting that in front of customers.
You can be as technically pristine as you want and live in an ivory tower, but that rarely if ever leads to a successful entrepreneurial endeavor.
To quote another recent article: That is to say, it turns out that the core competency of smiling and promising people things that you can't actually deliver is highly transferable.
Was it worth it to put all his customers at risk like that?
He is honestly lucky, the "hackers" could have done much worse, it would have been much more profitable for them to go after his customers via his software than to demand money from him had they been financially motivated.
> Third, the hacker has been trying to inject XSS attacks into app
> Now he's hiring a developer to shore it up.
So this is an ongoing attack? He should probably also hire some incident response and get some security consultancy.
Come to think of it, the exact same thing happened when the PC became popular. Mainframe people were aghast at all the horrible unprofessional mess that the PC people were creating.
Some AI generated code does come through, but at that point it's already mostly alright. Code review is still required for things like unnecessary comments or detecting duplicate functionality (exact duplicate code is already pointed out by Sonar).
And as someone who’s reviewed plenty of production scripts, functions, and services written by junior developers, including my own early work, this take is overly absolutist.
The problem persists in the vast majority of organisations.
You can write articles criticising LLM-generated code, but if you’ve spent most of your career fixing, extending, or re-architecting systems built by others, you should know better.
Until software engineering adopts the same standards, certifications, consistency, and accountability as traditional engineering, along with real consequences, these arguments don’t hold much weight.
This entire modern industry was built on the opposite philosophy: agile. Move fast, break things. Ship iteratively with minimal design. Drop production? Just revert. Outage? Oops.
Software is still treated like a toy. It’s playdough in the hands of toddlers led by other toddlers. You might be among the 1% who do things properly.. but the other 99% don’t.
And odds are, if you’re reading this, you’re not the 1%.
I'm not saying the code should be up to any specific standards, just that someone should know what's going on.
With this in mind, it's all matter of what are your metrics for "trust". If you are placing trust on a human employee because it was hired, does this mean the trust comes from the hiring process? What if the LLM passed went through that too?
About familiarity and history: we are at the point were many people will start working at a new place were the strangers are the humans, you will actually be more familiar and history with LLM tools than actual humans, so how do you take that into consideration?
Obviously this is a massive simplification and reduction of the problem, but I'm still not convinced humans get a green checkmark of quality and trust just because they are humans and were hired by a company.
This isn’t always true in absolute terms. In many places and projects it’s about doing a good enough job to be able to ship whatever the boss said and getting paid. That might not even involve understanding everything properly either.
Plenty of people view software development as just a stepping stone to management as well.
With reading enough code it becomes apparent that the code quality that AI generates will often be similar or better to human developers, even if the details and design are sometimes demented.
Legacy code isn't a bad thing either. The majority of code that actually generates revenue right now is probably considered "legacy" by the devs working there.
The article's point is that if you are planning to maintain something, you've created instant legacy code. Which might be fine, depending!
I know zero about the code the LLM created, though. I've tried going through it, and it is all well-written, but it's all foreign. I wasn't there for any of its creation and I don't have any map in my head about the layout of the functions or the flow of the apps.
I've also, in pre-llm days, seen warnings to not show visually polished prototypes to non-technical customers/salespeople/managers because they have no way of judging the quality and will try to force you to use the prototype immediately because "look, it's done".
Just yesterday a coworker who knows little Rust vibe coded a new feature that “worked” but is actually horribly broken (lots of synchronous I/O/locks/channels in a tokio async context). On top of everything else, they created their own bad abstractions for things that already had safe async abstractions.
If they’d had to actually do this themselves they either would have asked for help sooner so they could be guided or they would have done research in the code which already had examples on how to do things.
This is what all software will become, down to the smallest script. The vast majority of software does not need to be provably correct in a mathematical way. It just needs to get the job done. People love the craft of programming, so I get it, it's uncomfortable to let go.
But what is going to win out in the end:
- An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements. Cost: $50K of API tokens
- A well engineered and honed 30K loc program, built by humans, with elegant abstractions. Backed by 3K tests. Built to the same requirements. Cost: $300K of developer time.
If I am a consumer of software, and not particularly interested in the details, I am going to choose the option that is 6x cheaper, every time.
> built by humans, with elegant abstractions
Frankly, I look at both of these options and think I haven't seen either in the wild...
Until the next set of needed changes due to exterior requirements. And this software is one of the pillar in the business. That is when you switch vendors if you were buying the service.
That is why support is always an essential part of B2B or even serious B2C. The world will change and you need to react to it, not just have the correct software now.
People who work in formal verification will either vehemently disagree with you or secretly know you're right.
What happens when you need to modify large portions of it? Fix security issues? Scale it up 20x? You can throw more tokens at it and grow it into a monstrous hulk. What if performance degrades due to its sheer weight?
I know humans aren't perfect and are capable of writing really bad unmaintainable code too, but this is just embracing that more. This feels like going further down the same route of how we ended up with 10MB websites that take many seconds to load. But yeah it will probably win over the market.
As my team has spent the past several months trying to explain to upper management, you can't guarantee that the program does what the client wanted just by adding more tests.
If the AIs ever become capable of reliably producing what the client wanted, they will win. But I'm not convinced they will. They might be able to produce what the client asked for, but programmers have known for decades that that's pretty much useless.
What? It costs exactly $200
You still think out all the classes, algorithms, complexities in your head, but then instead of writing code by hand, use short prompts like "encapsulate X and Y in a nested class + create a dictionary where key is A+B".
This saves a ton of repetitive manual work, while the results are pretty indistinguishable from doing all the legwork yourself.
I am building a list of examples with exact prompts and token counts here [0]. The list is far from being complete, but gives the overall idea.
[0] https://sysprogs.com/CodeVROOM/documentation/examples/scatte...
You can get way better results with incremental refinement. Refine brief prompt into detailed description. Refine description into requirements. Refine requirements into specific steps. Refine steps into modified code.
I am currently experimenting with several GUI options for this workflow. Feel free to reach out to me if you want to try it out.
E.g. if you point at a vector class and just "Distance()" for prompt, it will make assumptions like "you want to add a function calculating distance from (0,0)", "function calculating distance between 2 vectors", etc. It runs pretty fast with models like LLaMA, so you can get small routine edits done much faster than by hand.
The part I am currently experimenting with are one-click commands like "expand" or "I don't like the selected part. Give me other options for it". I think, I'll get it to a mostly usable state around Monday. Feel free to shoot an email to the address in the contact page and I'll send you a link to the experimental build.
[0] https://sysprogs.com/CodeVROOM/documentation/concepts/planni...
They claim junior devs are now 10x more productive, and project managers are shipping code themselves. Now, close your eyes for five seconds and try to picture what that code looks like. It's 100% legacy, disposable code.
The problem isn't AI, or PMs turning Figma into code, or junior devs prompting like mad. The real problem is the disconnect between expectations and outcomes. And that disconnect exists because people are mixing up terminology that took engineers years to define properly.
- A lean prototype is not the same as a disposable prototype
- An MVP is not the same as a lean prototype
- And a product is not the same as an MVP
A lean prototype is a starting point, a rough model used to test and refine an idea. If it works, it might evolve into an MVP. An MVP becomes a product once it proves the core assumptions and shows there's a real need in the market. And a disposable prototype is exactly that, something you throw away after initial use.
Vibing tools are great for building disposable prototypes, and LLM-assisted IDEs are better for creating actual products. Right now, only engineers are able to create lean prototypes using LLM prompts outside the IDE. Everyone else is just building simple (and working?) software on top of disposable code.
I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.
I hope so. This is something I'm hoping to get into. As long as companies are trying to push their internal teams to use AI tools, I think it makes sense to position myself to follow along after them and clear the mess
I imagine 'vibe coded' applications to be similar to this but even worse.
This is one of the larger trends I've observed in about 10 years of the software industry. A lot of these terms are really the crystallization of discussions at the water cooler, expositions in books or articles, or on technical fora like these, that span months if not years and thousands upon thousands of words. A veteran utters the word and immediately all the past conversations he's had regarding this topic come to mind.
Newer cohorts come in, and, not having been privy to those discussions, latch on to the jargon in a mimetic attempt to stochastically parrot the experts, but don't have the substance underlying the word - they only have the word itself. Now it gets thrown around as an ill-defined, ill-specified buzzword that means multiple different things to multiple people, none of whom can clarify what exactly the definition of that word is, what it means to them, because they were never part of the discourse, the oral or written tradition, in the first place, and don't understand the meaning of that word in context, its usage.
"Agile." "Technical debt." "DevOps." And now, "vibe coding." There was an article here on HN [0] [1] discussing semantic drift of the term "vibe coding" and how it now means something different from what was originally intended; I will merely point out that this is par for the course in software.
For other, more technical, examples of linguistic sloppiness: see JavaScript's conflation of objects, JSON, dictionaries, and hashmaps; to the computer scientist, you have the compositional primitive from object-oriented programming, the JavaScript Object Notation for serialization, the abstract data type, and the concrete data structure, respectively. To the JavaScript programmer, you just have "objects," and the fidelity of your linguistic and conceptual space has been reduced to a single pixel instead of something with more resolution and nuance.
I'd argue we should better define working. Take for example a generated UI, they all look the same and are subtly wrong or broken in many ways. At a first sight it might seem "working" only to fail at the first user test. Also generated UIs already feel like obsolete, meaning they religiously follow the trend at the training moment, they spectacularly fail coming up with something new
Tell that to almost every company I've worked for!
The whole "make it to the next financial quarter" attitude among directors and C-suite these days leads to the kind of crap where developers build an MVP and then are made to move on to the next thing. Like you said, it's not really about vibe coding at all. To a degree, they're right; the perception of feature richness leads to the bottom line irrespective of quality because few are truly comparing products, assuming it's feasible.
Hell, are developers (which we now call engineers apparently) even empowered to prototype things these days? I'm sure it happens, but it doesn't seem all that common. Maybe it happens in the gaming industry and actual tech (not "big tech"). Most coding outfits don't provide much affordance for that. It's just MVPs all the way down. At best, vibe coding just accelerates that process while quality suffers.
Usually that was when an engineer chimed in, and made the broken part into something more useful and more maintainable.
Then an architect looked at the codebase and tried to reduce its complexity.
Now, post LLM, it seems we have 100x the code written by devs, and engineers and architects are completely left out.
And that's what we are observing.
If you figure out how to test this, whether or not with e.g. a TDD MCP server or a DDD MCP server (or whatever workflow and architecture you prefer) you have a potential for a trillion dollar startup. We need to scale the efficiency of code reviews, because currently that is utterly broken as a concept and doesn't scale well enough.
"[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." (Melvin E. Conway)
Keep in mind Conway's law also works in reverse, try running a private project wiki with documentation, and a ticket/task queue with small tasks.
Setting pie-in-sky project goals is just as bad as ivory tower engineers. =3
Hahaha you're funny :-)
It's no different to vibe coding, except if you ask an LLM to harden your code base to pass a pen test, it will do something.
Enterprises just don't give a sh!t.
Most of the time it's not "don't give a sh!t"--it's they genuinely don't know any better, no actual stakeholders even see the codebase nor are in any position to pass judgement, etc.
Most of the time folks that are "enterprise architects" or some such haven't written code in a decade and spend many hours a day on meetings.
We asked them: "Where is xyz code". It didn't exist, it was a hallucination. We asked them: "Did you validated abc use cases?" no they did not.
So we had a PM push a narrative to executives that this feature was simple, that he could do it with AI generated code: and it didn't solve 5% of the use cases that would need to be solved in order to ship this feature.
This is the state of things right now: all talk, little results, and other non-technical people being fed the same bullshit from multiple angles.
This is likely because LLM's solve for document creation which "best" match the prompt, via statistical consensus based on their training data-set.
> We asked them: "Where is xyz code". It didn't exist, it was a hallucination. We asked them: "Did you validated abc use cases?" no they did not.
So many people mistake the certainty implicit in commercial LLM responses as correctness, largely due to how people typically interpret similar content made by actual people when the latter's position supports the former's. It's a confluence of Argument from authority[0] and Subjective validation[1].
I figured the issue out the old-fashioned way, but it was a little annoying that I had to waste extra time deciphering the hallucinations, and then explaining why they were hallucinations.
Now, they see themselves challenged to defend against the non-technical departments, because all they see are some elitist developers, that deem something as "not good enough", which, from a user standpoint, "is working quite well".
However - it's unmaintainable. That whole situation is a mess, and it's becoming bigger and bigger.
Vibe coding - you don't care about the code. You don't look at the code. You just ask, test that what you received works, and go on with your life.
LLM-assisted coding - you care about the code. You will maintain that code. You take responsibility and treat it as any other software development job, with everything that's required.
Same same, but different.
I care when it doesn’t just work.
I hardly look when it does.
The productive discussion left the chat some shareholder rounds ago.
I guess I see your point in quantity. I could see how this would be more widespread than c/p from SO. And the results would "look" better crafted at a glance, but might explode later on.
I would argue "yes" - it is far more easier to pretend with LLM, because the loops are way more faster. When copy & pasting from StackOverflow, you need to, at least, gain some type of understanding from what you are doing. There is no one to help you. With an LLM, you can keep on asking questions - if you hit a roadblock, you scrap the last 10 iterations and start over, because it is so fast.
In another code base, all the code was written with this pattern. Its like the new code changed what the old code did. I think that 'coder' kept a big context window and didn't know how to properly ask for something. There was 150 line function that only needed to be 3 lines, a 300 line function that could be done in 10 etc. There were several a sections where the LLM moved the values of a list to another list and then looped through the new list to make sure the values were in the new list. It did this over and over again.
As I did this, I was keeping everything documented using a memory bank approach[1], so that I can fire up Claude Code and get it up to speed without explaining everything from scratch. Even with this disciplined approach, the code base got to a point where Claude would "forget" the big picture and start trying to optimize locally, hurting the global optimum. Eventually, I got burnt out by having to keep it in check every time it tried to do something stupid. I found myself always needing to remind it to check other modules to see how things fit together. I guess the memory bank got big with many concepts and relationships that Claude "got lost" in it.
Also, I realized that I missed the opportunity to learn deeply all those topics. so now I'm back to coding things myself, with little help from Cursor Tab, that's it. Will see how that goes.
I’ve noticed myself writing requirements for a feature and asking Claude to help me think through and expand. Obviously in a real project, there are challenges: (1) how do we tell Claude what is already in the project so it doesn’t reimplement existing methods? (2) how do we get Claude to fully implement the feature and not just “stub it out?” (3) how do we help Professionals maintain visibility and digest the new code?
Claude recommends the explore-plan-code-commit loop. I’m working on a package which formalizes that process within a Laravel application.
I have seldom encountered these.
What I encounter, instead, are lashups that the engineering team thought would be throwaway, but which Management made "Final Ship" code.
I have learned to always do "ship-shape" code; even for the most innocuous projects. I may be a bit sloppy as I'm exploring different paths, but the minute I decide on a firm plan, the code cleanup and documentation starts.
If you ship, and charge money for it, you are responsible for maintaining it. Can’t treat it as throwaway, even if you meant it as such.
Once you embrace the fact that all the code is legacy, then it's clear how writing more code, faster cannot be helpful from a maintenance POV: You are just creating more work for yourself.
And no, libraries don't really solve the problem, but might make it a bit less so if they are well maintained, because hopefully then they are someone else's problem. Eventually it can be mostly trusted and be almost not legacy. But a library that changes too often, or has a bad interface, is just legacy code which you also cannot change easily for a double whammy.
The more one writes code, the more one eventually realizes that the one way out of the problem is doing less: Not necessarily you, but just needing fewer things, in general. Because all complexity is ultimately a puzzle for someone that doesn't remember, and that's probably you a week later, or even in the way you typed it, as what you thought were the requirements might not really have been the requirements. And even if they were what a supposed expert told you they should be, that doesn't mean that whoever told you was right, and that's true even when you are the supposed expert.
Just ask the model.
Vibe code is legacy from day one and with changing styles
Like you say about libraries, it is possible to have code that isn't your problem. It's all about how leaky the abstraction is. Right now LLMs write terrible abstractions, and it's unclear how long it'll take for them to get good at writing good code.
I am excited to invest more in tools to make the understanding of code easier, cheaper, and more fun. My friend Glen pointed one way in this direction: https://glench.github.io/fuzzyset.js/ui/
As Geoffrey Litt likes to say, LLMs can help with this by building us throwaway visualizers and debuggers to help us understand our code.
I see people going all in with LLMs and forgetting that those even exists. It's hard to take such people seriously.
This is "but humans also", which I believe should be a recognised fallacy at this point.
Not all code is legacy code, for one thing; some is small enough that it is absolutely live in the minds of developers.
The best practical definition of legacy code is that it is voluminous, entrenched and owned by nobody currently in the organisation. Vibe code typically meets two of those requirements the moment it is produced.
"Legacy" for me is a bad word. I refuse to use it, and I scold my colleagues when they do: it's our code, we modernize it if we don't like it, and if we stop using it, then it's finished code. What is this false dichotomy between legacy code and "not in prod yet code" ?
In companies we call our regulatory prosecutions for fraudulent behavior that are so complex that they last for 10 years "legacy matters". Do you think that points at a statement of factual representation, or at a ridiculous attempt at distancing ourselves from our actual responsibilities ?
I expect code quality to be way, way worse in the coming decade. Its not legacy because of age, its legacy feom day one. Pure nightmare fuel.
But it seems like advocates of "vibe coding" will fall into the trap of assuming "vibe code can't ever be legacy, because you can just point another LLM at it and it will pick up right where it left off"
This was also the era of jQuery with easy to use AJAX methods, which enabled almost anyone to create a front-end that calls backend code.
All of that was simple code that was easy to share with others on forums. This led to insecure websites where, to exaggerate slightly, every input field could be used for SQL injection attacks.
To be fair with PHP of that era, it was possible to create secure websites with it. It's that the ease of use created the illusion that once the website worked, you didn't have to tackle any other portions of development process such as quality control or security.
It was a glorious era.
What's happening is that all this "vibe coded" software needs someone to fix it when it breaks. I've been getting more requests than ever to debug AI-generated codebases where the original "developer" can't explain what any of it does. The security audit work alone is keeping me busy - these AI-generated apps often have vulnerabilities that would never pass a human code review. It reminds me of when WordPress democratized web development. Suddenly everyone could build a website, but that just created a massive market for developers who could fix broken WordPress sites, migrate databases, and patch security holes. The difference now is the scale and complexity. At least with WordPress, there was some underlying structure you could reason about. With vibe coding, you get these sprawling codebases where the AI has reinvented the wheel five different ways in the same project, used deprecated libraries because they were in its training data, and created bizarre architectural decisions that only make sense if you don't understand the problem domain.
So yeah, the jobs aren't disappearing - they're just shifting from "build new features" to "fix the mess the PM made last weekend when they tried to ship their own feature."
this is like the third time i've mentioned this on HN (over a year.) Apparently everyone else is too busy complaining or defending Claude Code to notice.
Dogs can also factor 15:
great!
A running joke we had at my startup years ago was "... and after we ship this feature we'll be finished and we will never have to write another line of code again!"
Good software is built with future changes in mind - that's why I care so much about things like automated test suites and documentation and code maintainability.
Letting LLMs generate black box garbage code sounds like a terrible idea to me. The idea that LLMs will get so good at coding that we won't mind is pure science fiction - writing code is only one part of the craft of delivering useful software.
You'd only need one accurate ASM manual per variant.
Malbolge is a couple of decades old. Apparently the first working "Hello World" was made by a genetic algorithm.
LLMs work best with interfaces meant for humans because they're trained on human behavior. It's why they generate JSON and not BSON.
Don’t see where current AI fits in this except being a better intellisense for an IDE.
Wow, no. Bad misunderstanding of what legacy means.
Long-lived organizations all eventually go through tech renovations, where they re-platform their business functionality onto more modern systems. But sometimes, the cost/benefit analysis to that re-platforming doesn't make sense... yet. The pieces of the business still running on the former platform are legacy code.
People do understand it. Often, deeply understand it because they wrote it, and have lived and supported it for years. They know the reason behind the tech debt, all the odd tech constraints that drove it to where it is, they can keep the thing running without breaking a sweat. It is second-nature to them.
But it is not easy for anyone other than them. That is the true risk of legacy code, and that is probably where the author got off-track. They may have only ever worked in orgs after the last of the legacy coders left, and everything was a disaster. You definitely do not want to let a legacy system get to that point... and at the same time, if you ever do get there, the cost/benefit analysis has changed and you need to retire the legacy stack.
All that being said, now, yes, we can compare it to vibe coding. If nobody understands the code from the beginning, you never have that magical timeframe when someone just keeps the system alive with ease. You never solved business problems with it. It is just bad code launching straight into the disaster-filled zone where nobody can maintain anything.
I don't think it counts as legacy code if the original devs are still around to work on it
Legacy is not just "old" it is something that was left behind by someone else
I much more agree with the blog author. Once the last developer that has a deep understanding of a codebase moves on (or simply forgets it all), that's the point it becomes legacy.
It becomes legacy when it is no longer running on a tech stack that matches the future strategy of the organization. Legacy is a strategic label, not an engineering label. There is no age where something becomes legacy, it happens when business strategy moves on to something else.
Martin Feathers, in the most popular book on legacy code, defines it as code without tests. This is not a good definition at all, but it shows just how hard it is to define it. This is not meant as an attack on anyone: I just think some flexibility and slack is called for here.
You could easily write an long white paper trying to define 'legacy code', and it would be a lot less interesting than the target article here.
You're assuming the people that wrote it are still there, which is often not the case.
Non-programmers can't do any of that. That's why I believe that programmers should use vibe coding to get work done faster, but non-programmers should restrict vibe coding high quality projects to their dreams only.
I've found it faster to have AI write the code, revise with instructions as necessary, and delve into the code itself if I need to.
But, especially with legacy code and monoliths with a lot of different conflicting patterns, you MUST check every thought and step. Every change. Lest it goes off and forgets what it was doing because it is stuck rewriting the same code in different ways.
tbh, I think it is fair to say these tools only really help if you are very senior and can smell bad code from the other room ;-) On real world legacy codebases at least. The code is ok and often on par with half the guys that work here, but they learn from mistakes and feedback ;)
There are approximately two definitions of "legacy" code that I'm familiar with. One is: "valuable code that you're afraid to change." This definition is subjective. I might be afraid to change code that you're unafraid to change, especially if it's code that you wrote (because you remember, at least vaguely, how your code is "supposed" to work).
Another definition of "legacy" is attributed to Michael Feathers: "Legacy code is simply code without tests." The definitions overlap because code without tests is definitely scary to change, because it's very hard to be sure whether or not you've broken it, or even understood it in the first place.
When vibe-coding with an LLM that generates automated tests, (as they mostly all do nowadays), it's not legacy code. The tests both specify and ensure correct behavior.
Automated tests are particularly useful for vibe coding, because they help prevent LLMs from hallucinating answers. (This is also why type checkers are so helpful for LLMs.)
Once the code has tests, you can pretty much let the LLMs change anything they want, including refactoring the architecture. LLMs are extremely good at refactoring code with automated tests, in the sense that they'll puke out some hallucinated, hilariously wrong answer, and then refine their answer automatically until it passes the tests. (Just like I did when I was a junior engineer.)
But watch out, because sometimes the LLMs try to delete tests that are hard to pass. If vibe-coding means reading no code, not even the tests, then, yeah, you're gonna have a bad time. But if it means "only reading the tests and not reading the application code," then vibe coding works pretty well, actually.
What the new systems give you (and especially junior engineers/PMs) is disposable code with automated tests, ensuring that that you can dispose of the code and regenerate it (aka refactor it) and add features with confidence.
That's the very opposite of "legacy code."
> But watch out, because sometimes the LLMs try to delete tests that are hard to pass. If vibe-coding means reading no code, not even the tests, then, yeah, you're gonna have a bad time. But if it means "only reading the tests and not reading the application code," then vibe coding works pretty well, actually.
Yeah, vibe coding means plowing forward with whatever the LLM does without understanding it. That's the definition. If you're using your brain, you're not vibe coding.
Personally however I've found more luck generating requests from the "code model" rather than generating code from the "tests" at present. Only because tests are usually much more code than the code itself under test (one code has many scenarios) w.r.t. productivity. Everything still needs review, manual tweaking and understanding of course for now.
So if the foundation is overengineered, it will produce over-engineered code on top. If your code is super clean and succinct, it will produce code that is equally neat and succinct.
I've used Claude code with my own backend serverless platform and it's like it can read my mind. It's almost exactly how I would do it. It's like working with a clone of myself. I can implement nuanced features and ask for very specific changes and the success rate is extremely high.
On the other hand, I've worked with some other people's code which was slightly over-engineered and it struggled. I managed to achieve what I wanted with a lot of manual intervention and careful prompting but it was a very different experience and the code it produced didn't look like my code. It looked like it was written by a mid-level dev.
I can sense that it's a code completion engine because it clearly doesn't have an opinion about code quality. It doesn't know what metrics to aim for. It doesn't aim for succinctness; just as most human developers don't aim for it either.
My assessment of LLMs is that they don't have a specific intrinsic goal so the goal/motivation is inferred from the text it sees (from the input). If the original author of the code was motivated by creating complexity for the purpose of lock-in factor and career advancement, the LLM will produce code which optimizes for that. Unfortunately, this describes the vast majoy of code which is produced.
You can tell a lot about someone based on their code.
that's great but that's not what vibe coding is though
Sounds to me like you're not vibe coding, you're coding. https://simonwillison.net/2025/Mar/19/vibe-coding/
With agentic programming, I need issue tracking that is accessible from CLI, and in three evenings I’ve made what would have taken two weeks.
The thing is, I would have just never finished it, or started in this case.
An engineer can guide an agent to write good, modular code, but a non programmer can't.
The engineers I see thriving aren't those maintaining perfect understanding of every line, they're developing what I call "the adaptation advantage": knowing when to dig deep vs. when to trust the process and iterate.
This connects to a broader pattern I've been exploring, AI is creating a skill gap between those who see it as amplifying capabilities vs. those who see it as threatening their identity. https://www.derekneighbors.com/series/ai-excellence-gap/
The "vibe code" concern is valid for maintainability, but we might be optimizing for the wrong risk.
What’s the definition of “Legacy Code”? It’s code that has business value.
(otherwise you’d just delete it and move on)
I think that we devs are now very skeptical because we are the ones that have to fix the sh that llms spit out. But likely we will be taken out of the loop completely.
Some devs may have all of these, some may lack several.
I certainly benefit from having a better overview while vibe-coding: I don’t get lost in some rabbit-hole trying to optimise something that is good enough, and my most important tasks are always well-defined before I start.
There’s just shit buggy software everywhere now and I’m definitely not expecting AI to make the way we build things better.
There's a certain chance that this development will force our hands at inventing new ways to handle code verification though?
Always has been and always will be. This article was eye opening to me because I didn't even realize how often I was working around buggy software.
Interesting times ahead for sure.
This might be a new branch of software developers on the rise. Those that take sloppy AI code and turn them into real applications for customers.
What we've had a hard time with is understanding what this article calls legacy code, and also understanding where our new changes fit into a larger context.
It isn't at all dissimilar from the paintbrush analogy that all the (neo)vimmers love. We spend more time reading and navigating than we do writing.
AI needs to help with that.
Same applies to "live" code with owners still within a team - it can be extremely bad.
The issue with LLMs is you don't know what you get. It can produce a very robust routine, that will just work and have a clear API, or it will look like it, but will have a terrible design decision that will lead to an API redesign.
But so why couldn't AI-generated code be maintained by AI? Why couldn't AI in general be used to fix and evolve legacy code?
I guess it all depends on your end goal. If you intend to make your vibe coded app into a profitable, maintainable product with any sort of reliability guarantees you better understand its failure modes and how to fix things when they break. It’s really hard to create recovery procedures for a black box.
Legacy code is difficult to work with because the reasons "why" something has to be some way are missing. The "whys" can change over time, be interwoven with business requirements not in the codebase, and compound/nest with other whys that have come and gone. Often only humans in the business know, and you have to figure out who and what to ask.
Second insight is that LLMs have so far been very bad at holding on to the thread of winding, changing requirements, which is something it would have to be good at in order to revisit old codebases. Even one it wrote itself. It would need some kind of historical changes to business requirements database, which I have never seen a business keep, it'sjust the collective human knowledge of the business. Otherwise it'll make changes without accounting for historic requirements as well as your new ones.
I think there are probably some workarounds, like getting it to write lengthy documentation to refer to. Long term perhaps it just gets smart enough. Legacy codebases are something I specialise in working with somewhat, I spent a long time consulting so I was often parachuting into unfamiliar codebases and trying to quickly understand years to a decade or more, of evolving requirements in a business/codebase. I have a lot more to say on the topic but those are two of my insights.
This may have something to so with the AI "frame-problem".We can't document all "whys" in the current "frame" because they depend on other "frames" like the current legislation. We don't write down "this will work because ..." . We just assume it, and asume many other causally related things.
In other wrods it would very hard or impossible to document "what must not change" for our system to continue to be useful. For instance Sun must still exist and air must be breathable for this system to be useful.
Full context > human context capacity > LLM context capacity.
We should all be able to agree on this and it should settle the debates around the efficacy of vibe coding.
It doesn't, as you say, work for large and complex contexts. But it can work really well for automating parts of your work flow that you otherwise wouldn't have bothered to automate. And I wonder if there are more ways where it can be useful where the context can be narrowed down enough.
It's very true that any vibe code is immediately legacy after they are generated. In other words, they are incarnations of foreign minds, things from a realm that is shuttered from my access, and they are giant pile of code that is beyond immediate recognition to any human engineers.
> If you don't understand the code, your only recourse is to ask AI to fix it for you, which is like paying off credit card debt with another credit card.
LLMs really know how to bring out the worst in intelligent, hard-working, respectable developers. I can't even imagine what PMs are saying to them, but I'd happily pay another $30 a month just to read those messages :)
Invariably, after using the brain, the real fix was usually quite simple - but, also invariably - was hidden behind 2-3 levels of indirection in reasoning.
On the other hand, I had rather pleasant results when “pair-debugging”, my demanding to explain why or just correcting it in the places when it was about to go astray certainly had effect - in return I got some really nice spotting of “obvious” but small things I might have missed otherwise.
That said, definition of “going astray” varies - from innocently jumping into what looked like unsupported conclusions to blatantly telling me something was equal to true right after ingesting the log with the printout showing the opposite.
What we are seeing right in front of our eyes is how the boundaries of what is possible in the realm of software programming has gone from AI/LLMs poorly writing simple scripts, to being able to "zero-shoot" and "vibe code" a complex system, with a set of instructions written in natural language.
What we might be seeing in 2025 is how programming, the way it has been for the last decades, be disappearing and becoming a rare artisanal craft, not meant for being productive, but for showing off skill, for intellectual entertainment of the programmer.
I know how hard this hits the real coders. I am one, too. But I cannot unsee, what I have seen. The progress is so undeniable, there is no doubt left in me.
Real "AI" may happen some day, but it is unlikely going to be an LLM. =3
It’s fine. Some things it’s awful at. The more you know about what you’re asking for the worse the result in my opinion.
That said a lot of my complaints are out of date apis being referenced and other little nuisances. If ai is writing the code, why did we even need an ergonomic api update in the first place. Maybe apis stabilize and ai just goes nuts.
So far, the syntax has gotten better in LLMs. More tooling allows for validation of the syntax even more, but all those other things are still missing.
I feel like my job is still safe: but that of less experienced developers is in jeopardy. We will see what the future brings.
"all code will be generated by compilers from basic prose"
"enterprise software will be trivialized by simple SQL prompts that anyone can write"
...
The progress is so unreliable, there is doubt left in me.
I think the whole premise of the article is wrong because it compares apples to oranges, assuming that you’re going to maintain “vibe code” in a traditional way.
But context is text documentation, and that stuff rots just as much, if not more, when LLMs generate it.
Nothing beats having the actual code and the thoughts that went onto it in your wetware. I still remember the hardest problems in my professional life in the last 15 years down to a scary detail.
The docs don’t rot because you can throw them away and have the LLM recreate them at any time. And they’re not for you, they’re for the agent.
It’s a completely different mindset.
The ecosystem is bigger than the internet.
Much of my mental space is spent building and updating the mental model. This changing of my mental model might look like building a better understanding of something i had glossed over in the past, or something that had been changed by someone else. Or it is i think the fundamental first step before actually changing any lines of code, you have to at least have an idea for how you want the mental model to change, and then make the code match that intended change. Same for debugging, finding a mismatch between your mental model and the reality as represented by the code.
And at the end of the day, AI coding tools can help with the actual writing, but the naive vibecoding approach as noted is that they avoid having to have a mental model at all. This is a falacy. They work best when you do have a mental model that is good enough to pass good context to them, and they are most useful when you carefully align their work with your model over time, or use them to explore/understand the code and build your mental model better/faster/with greater clarity.
I think vibe coding makes that initial conversation between a non-technical client and a technical designer/developer much more interesting. Because, now, that client can first communicate their ambiguous ideas to an LLM, have it generate something visual and concrete, and then communicate that generated thing to the designer/developer. A much better way to exchange ideas, no?
But, yes, relying on vibe-coded code is not reliable.
I'm really curious whether that will become a trend.
They kind of vibe coded that app well before vibe coding had been a thing.
Some code makes you aware of the limited shelf life of code.
we give it bits and pieces one after another and marvel at what its done. It nags at us that we can't reason about the outcome, but use it anyway. It's no problem. Or it is sometimes. We don't know what's going to happen. We switch tooling completely, then again. This shit is miraculous. Clock in.
A quote from the article:
> Programming is fundamentally theory building, not producing lines of code. We know this.
Well, then you should understand that the "vibe coder" is someone with the idea for the code and during the vibe code session they build the theory for the program. Coding is less important than the idea behind the code.
So what the resulting code is "one use" and "legacy" or whatever if it does the job? If the vibe coder has saved their prompts - it could be later reproduced, improved and extended just the same way!
Excellent article! But I wonder if the above point will always be true. Maybe AI at some point could become better at cleaning its own mess?
I really don't want to sign up for a service and then get my shit leaked immediately
In general, a good code base teaches future developers how to leverage a pragmatic solution in the context of the use-case. Often, "vibe" code relies on superfluous computational heuristics overhead to compensate for people that had zero notion of what they were doing in the first place.
To summarize, no one competent is fooled by low-value content farmed blogs, or the folks that rely on LLM. The age of Spam exceeding content is upon us. =3