A story about a non-technical friend: friend vibe coded a SaaS last year and started generating revenue with almost no marketing; all word of mouth and inbound in a niche industry. Used Replit and Supabase to build the thing; I am still really impressed by what he was able to do given how complex the app ended up becoming as he interacted with customers.
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.
I would not default to assuming it was his competitors, that sounds like scapegoating to deflect responsibility. What most likely happened is his site was scanned by one of the increasingly sophisticated exploit crawlers (anyone who runs an internet facing site and can view traffic knows what I'm talking about). His site got flagged as vulnerable, the hacker found out it was built like swiss cheese and had fun with it.
It's 100% this. Anyone who's run a website or web app for any length of time in recent years and makes a habit of inspecting their logs will quickly realise that they're being scanned by bots looking for vulnerabilities multiple, or even many, times per day. The search for vulnerabilities is entirely automated and will pick up any domain that has a website or web app attached to it.
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.
From the customers' perspective sounds ethical. The product was broken or extremely cheap quality, and not what it seemed to be originally when you decided to purchase... Is this black or white? ;p
> anyone who runs an internet facing site and can view traffic knows what I'm talking about
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.
Who else would spend the time and effort to figure out you leaked your stipe key to your front end? Sure people have bots to do that, but it’s kinda unbelievable someone would run such a bot on their vibe coded website.
I have a strictly hobby web app that I work on. 6-7 years ago I inadvertently pushed AWS email service credentials to GitHub.
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.
There are lots of smart kids who don't particularly need reasons for causing mayhem. Suppose it was somebody profit-motivated though. They might be:
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.
Interestingly, I have a server that only has IPv6 SSH open to the outside world, and it has exactly zero that aren't me fat-fingering a password. It does have an externally visible hostname, which says to me that the bots aren't looking at hostnames for SSH, just IP(v4) addresses.
Googling it points to a Chinese IoT company, so I am thinking maybe they have some IoT software with known vulnerability where they have seekcy as the ssh username that is being actively scanned for.
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.
This 100%. I'm in a space with developers and customers deploying web servers for the first time. This traffic freaks them out.
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.
Yeah, one of the reasons why I started to for all my dev side projects to be under a single wildcard subdomain, because I used to create new certs automatically with letsencrypt and everytime this spam happened. If I do things right it shouldn't matter, but I still feel better with the wildcard if I was to make a mistake...
Short related story: some customer wanted an API with a basic firewall, they said they don't need filter rules as it won't be used or something. I put a dumb API online (doing nothing) and showed them the request logs after one day. They approved the filter rules immediately.
Years ago back in 2001, I had a /29 giving my 5 real IP addresses from my ISP.
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.
Github repositories have statistics about access. Anyone can test this.
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.
Why is it unbelievable? There is an entire industry of people trying to find vulnerable niche applications like this. There are bots which crawl the web, not to make an index, but just to find vulnerabilities. Nobody necessarily even had to 'point' anything at this at all, it just shows up on their dashboard one day and they get to dig in.
I was being facetious. Yes, there are millions of bots that are constantly searching every website for leaked keys, passwords, database credentials, crypto wallets, firebase endpoints, s3 buckets, email addresses, phone numbers, etc. the list is bottomless
Yep. We once had left a socks proxy unprotected on a public IP, no cert, just a random IP and a fixed port. At one day the service stopped working. When looking into it, the network was overloaded with random IPs from all over the world surfing on the free proxy.
> Who else would spend the time and effort to figure out you leaked your stipe key to your front end?
In 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.
> Who else would spend the time and effort to figure out you leaked your stipe key to your front end? Sure people have bots to do that, but it’s kinda unbelievable someone would run such a bot on their vibe coded website.
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.
I've seen it happen - a key was leaked in a stacktrace somewhere and it took a scraper a couple of days to find it. Stripe helpfully prefixes their keys with sk_prod_ so you can completely automate something to iterate over every IPv4 address and see if something in the output matches.
You don't scan just a single website, you code up the bot once and then scan every site you can find.
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.
My website has a "public" directory for things I wanted to be publicly accessible, but there's an index.html there so you can't trivially discover what files are there.
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).
The thing about bots is that it costs almost nothing to run them against millions of sites every day. It's got nothing with "but what are the odds?!", at large enough scale, unlikely things happen all the time.
Not sure how to word this, but are you "new" on the internet? People used to break stuff "for the lulz" since the dawn of time.
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.
> 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.
My understanding has always been that most hackers do it for the fun/challenge/sport of it and it's only a small fraction who are in it for the money.
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.
Breaking things is fun. Effectively stealing money (the refunds) is highly illegal, immoral, and malicious. Who knows who did it, but that aspect is just dickhead territory.
I wouldn't call that stealing. It is a forced refund. A hacker could even justify it to himself that these people were unknowingly paying for a shitty product that was built like Swiss cheese, time to give them a refund. Another plausible one is "this guy shouldn't be allowed to run a website, I can't believe he made money for it, it is going back".
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.
> I wouldn't call that stealing. It is a forced refund.
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.
Being in the possession of a password or key implies having permission to use that key. When generating a key you give everyone with access to that key the permission to use it to perform actions on your account.
It would have had to be refund. The hacker could t initiate a chargeback from knowing the merchant's stripe keys. Seriously doubt it was a competitor. The risks of hiring someone to commit felons against your competitors just isn't worth it. Especially since the vibe coder seems to be bungling things on their own just fine.
> I wouldn't call that stealing. It is 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.
If you were a criminal trolling the Internet for vulnerable servers and found stripe keys... would your first instinct be to refund customers rather than do some other sort of crime? Like what's the motivation you envision here?
"Because I can" or "Because it's funny" are more than enough reason for most people. The fact that the hacker refunded all the customers, then emailed them to warn them that they were using a terrible app actually sounds like a pretty tame troll to me. If the hacker was truly hired by the competition to act maliciously, they could have done far, far worse.
Your friend should take this as a lesson instead of trying to deflect blame to their competitors.
There are black hat hackers that take great joy in just causing as much chaos as possible, particularly with such vibe-coded apps. Even with stripe keys, it's not like they could direct money elsewhere.
Maybe a blackhat hacker decided that the software was so shoddily built that the company didn't deserve to continue existing, and decided to try to make that happen as a sort of vigilante justice against crappy vibe-coded apps.
Definitely not a good idea but it's not an unreasonable motivation.
Hey all I’m an independent security researcher and I found that you are paying for an app that is shoddily built and doesn’t respect your privacy or security so I decided to give you all a refund. Have a nice day!
The fact your friend is suffering no consequences and is able to just carry on is exactly what is wrong with this industry.
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 80s and 90s devs who built our current software infra were, on average, FAR less credentialed than today's juniors and mids who mostly don't understand what they're building on.
Sure, and Da Vinci didn't have an architectural degree when he was designing bridges, but now you need a proper license to do so. Society learns to do better
Surprisingly, 80's and 90's developers were quite skilled low-level developers who knew very well all the ways things could go wrong. The difference was the stakes were not high then. The blast radius was maybe a hundred thousand people and the worst was they lost their own files. Now some AI-controlled process or apparatus could ruin everyone's credit and maybe even kill you and all your neighbors.
In our imperfect world, by the time the government could get together a reasonable certification process the content you're tested on would be out of date. Maybe when the industry is older it'll change slow enough to do that, but I don't think that'll happen so long as there's so much money aimed at disrupting everything and monetising the disruption.
Were going in circles far too fast to have licensure that hinges on being up to date.
That's what tort law is for. It leaves the details to the experts, and judges based on general notions of intent, negligence, and harm caused. The threat of financial ruin should incentivize against selling malware.
Let's say it was coded extremely well, but nevertheless a more advanced exploiter wreaked similar havoc. Would they still be liable in your perfect world? To some degree the principle of caveat emptor should apply in some tiny, nascent business, otherwise only large juggernaut monopolistic incumbents would have the means to have any stake in software.
> Let's say it was coded extremely well, but nevertheless a more advanced exploiter wreaked similar havoc.
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.
I don't remember the specifics well, but under GDPR they'd be required to give breach notification to customers, maybe write a report and get audited and possibly get fined depending on the situation. Customers could demand compensation (probably doesn't make sense here).
Right. Because the solution to all of this madness is SOC2 compliance or something along those lines.
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.
Imagine vibe coding spreads to civil engineering and people start building bridges this way. Have AI design it and then probably 3D print it on location.
> 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.
In that world we’d just be transitioning to 32-bit software and still running MS-DOS since it’s certified. Linux would never ever have broken through. Who can trust code developed by open source cowboys? Have we verified all their credentials?
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.
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...)
A lot of the things people are upset about are not related to this issue and not something licensing engineers would fix. They're products of things like market incentives.
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.
I disagree. Mature open source projects last long enough without significant disruption to still be relevant after they make it onto the certification exam. Products, not so much.
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.
You're assuming the process would not be instantly subjected to regulatory capture by for-profit companies and by universities with an interest in inserting themselves into the required licensure pipeline.
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.
Go check out VxWorks or the like. only 20K a seat, build tools at a similar price, and then oh joy, runtime licenses required to deploy the sw you wrote.
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.
...and this is where compliance comes in, and is the exact reason real companies won't talk to you unless you have (at minimum) SOC2. There's billions of products out there, how do you know if it's actually good software developed by a team, or some idiot like above vibe-coding slop into what appears to be a functional application? We all make fun of audits and checklist-based-security but it would've almost certainly prevented the above from happening.
Letting another country be the wild west and then cherry-picking the good stuff while regulating the nasty stuff doesn't seem like a terrible place to be for the, what, 99% of people who aren't Silicon-Vally-bigtech-execs-and-engineers getting all those profits?
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.
Some of that is US companies hiring in the EU because the salaries are lower. Source: I know of multiple companies, even on the smaller side, doing this.
It's a textbook case study of market failure in neoclassical economics caused by information asymmetry. If customers knew about the vulnerabilities, they wouldn't have paid money, or they would have demanded a lower price.
> 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.
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 a win for the customers. From what he's told me, there's zero churn so far despite the hacks (including one where the hacker emailed every customer about the hack).
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.
> 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…
>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.
Atlas can finally be relieved of holding up the sky, since the 'just' in that sentence is capable of even heavier lifting.
Did he need it to prove a business viable if there were already players in the market? No. Do you ever need to validate that people would switch providers of a commodity product or service if presented with a cheaper option? Also no. What did he learn then, that he can create a partial solution that people might pay for initially (no data on renewals) but will ultimately have to actually hire people to build a real product which will eat at his differentiator (price). Wait until he decides he actually has to spend money on marketing.
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.
As a business owner I can tell you that price is not the only factor people look at when choosing to engage with a business. I've tried the whole "cheapest offer in the market" thing and its backfired terribly. The main insight I've gained is that customers have a perceived value of a product that aligns with things like branding, marketing, previous experiences, and perceived popularity. People are willing to pay more for these things.
That's like saying Canva and Figma didn't need to prove there was a market because PowerPoint and Photoshop existed.
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.
This is morally equivalent to building a house with no engineering experience and someone coming around and kicking it down. The problem isn't vibe coding per se, but lacking some key knowledge to be able to make important judgements which may (should) result in legal liability
Conflating a scenario that will likely result in many deaths with leaking some customer emails is kind of crazy to me. How are they morally equivalent? Both are bad, but there is a significant difference in how bad IMO.
That's why that person was non-technical. Maybe software engineering will finally require licensing like for real engineers when AI is unleashed on the world with serious consequences.
This is why we need strong financial penalties for data leaks. A company that plays fast and loose with security should be shut down the same way a restaurant would for vibe hygiene. “Oh well we poisoned some people but look how fast we set up”
That’s not a viable business, it’s a walking liability. Besides which, why would anyone trust your friend (as an investor or customer) ever again when they’ve shown such profound disregard for user data and their IP? If your metric of success is “I have no idea what I’m doing and still made money from it” your friend would have a better time starting a podcast.
> Why would anyone trust your friend (as an investor or customer) ever again when they’ve shown such profound disregard for user data and their IP?
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.
On the contrary, he's solving a real business need for these small businesses at a fraction of the cost with a product that's easier to use and with better features.
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.
> On the contrary, he's solving a real business need for these small businesses at a fraction of the cost with a product that's easier to use and with better features.
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 ....
His early assessment when I talked to him abut this was "it's the end of SaaS".
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.
> I have no idea what I’m doing and still made money from it
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.
This attitude towards exposing customer data as a palatable oopsie on someone’s path to learning (by… outsourcing the effort of learning to an LLM?) is truly disgraceful.
I think you're describing fraud. Of course it's easy to start a business if you're cutting every corner with no regard for the users until you get caught.
Vibe coding is going to bring upon regulation, which is the opposite of the lower barrier to entry people want it to be.
Seems like EU's CRA does not go far enough. This quality of products should not be sold in the first place. So I hope we will very soon regulate also them.
> Of course it's easy to start a business if you're cutting every corner with no regard for the users until you get caught.
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.
It's also "worth it" to start a burger stand and make $1000 a day by vibing and not wasting time on food hygiene training or practices. Gotta move fast and test the market after all.
I predict 2030: all sites in most countries will need a license to operate and something like SOC2 certification. Even for your blog.
In practice politicians don't care (or understand) commercial versus non-commercial internet services. Just look at the garbage fire that the UK online safety act is.
It's a hack because he had an admin route and API endpoint which was only checking for authenticated users. He thought no one could see the route because it wasn't in a sitemap (of course, everyone could see the route). Hacker found the API route to insert themselves into an admin table (Supabase RLS was not deployed correctly) and from there, started adding himself to other orgs in the DB.
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.
What he built was, almost by definition, a prototype.
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.
Forever, until our cursed profession gets an official licensing body like other real Engineering professions. A Civil Enginnee can't sign on a prototype bridge design that then gets built and opened to the public, because any problem means potential jail time and possibly loss of licence.
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.
> he proved out a viable business with just a few hundred dollars of investment
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.
> 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.
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.
I really like the recent HN post "Enough AI copilots, we need AI HUDs" (geoffreylitt).
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.
> Probably a similar amount that it would have taken him to hire someone from the start, except he’s already validated the product and market.
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.
> it is terrible, shoddy, insecure code, but he proved out a viable business with just a few hundred dollars of investment
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.
If whatever this SaaS can be so easily built with no technical knowledge... why would a company not just build it themselves with "vibe coding" and cut out our friend completely?
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.
One of the first things he told me after he got it up was that this is the end of SaaS.
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?
It's honestly a bit depressing to see you say that it was worth it to make money with little investment even though it cost the users the loss of their personal data and privacy and probably put the business creator in legal turmoil.
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...
If I pay a company money and then they leak my data because all of their modern-looking stuff was actually just cobbled together garbage and the founder and sole employee doesn't even know how any of it works, I would call it a scam. Your friend pulled a scam. He should face consequences for this.
Would add that in the hands of experienced developers, vibe coding is of not much help either. Coding would be much minimized with a good framework and re-use, while keeping the entire codebase maintainable.
"Tech debt" is a misnomer. It implies that at some point it should be paid down. There are very few examples where dedicating real efforts exclusively to paying down tech debt led to anything beneficial for the customer.
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.
The one tip for quick success that the Human Developers don't want you to know: You don't have to pay down your tech debt if the company folds because hackers leak your customer database and refund all your income.
There have been a few studies that show that in certain circumstances this is the case. But doing a literature review will illustrate the bulk support the alternative hypothesis.
Ultimately, whatever the hype factor there is a large number of clever people putting their time and money into it for a reason.
Doesn't sound like it was worth it to the paying customers/guinea pigs whose data became vulnerable bc your friend said "security? Lol". But I guess that's true of normie-coded startups as well.
The customers know he was hacked because the hacker sent an email to everyone on the customer list. Yet none of the customers left and he's only grown the customer base since then.
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.
> I've learned that there's only one thing that matters: solving valuable problems and getting that in front of customers.
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.
It definitely wasn't worth it, and the only reason it got off the ground was because of the current default expectation of human-written software being somewhat reliable and mostly safe from exploits of this kind.
> 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.
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.
> 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.
Wait, if there are competitors, how was he able to prove a viable business when there were two viable businesses out there?
So in the hands of someone whose main expertise is in writing the secure login and data protection part of an application, maybe it is a bit better? At least they could eliminate much of the low hanging fruit. Of course anything put together quickly by a small team is going to be full of vulnerabilities until it gets battle tested and security checked.
Everyone is slamming you but the reality is that you could use AI models + a competent developer or security engineer to _very_ quickly shore up the entire codebase and fix every single hole -- getting it to a place where it's comparable with everything else out there. It's really not that hard (and there is already a bit of research around the defensive coding capabilities of tools like Codex and Claude Code)[1].
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%"
This approach to security is backwards. It's way harder to find security issues than to never include them in the first place. This approach might work for another webapp but I highly doubt a retroactive security analysis is practical for a more involved system.
You don't know what you don't know. How was a non-technical glorified PM supposed to know to ask for these things in the first place? Such technical practices developed over time in the history of software engineering, as problems arose.
This is the main problem with AI and vibe coding right now: it does what you ask (and sometimes does related things in the line of that ask).
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.
Everyone knows that hackers exist and exploit security lapses. Everyone. You might not know the details and such, but you should responsible enough to at least ask if you are taking people's money. I just don't think the ignorance card is plausible here
The only mistake the original developer made is they forgot to write “you are an expert in the field, you make no mistakes and you make your website secure and free of vulnerabilities” at the end of their prompt.
An interesting point is that if you ask AI to security audit a codebase it can find the vulnerabilities. But the AI "forget security" when writing new features. This is probably caused by training data and RL.
Using LLMs to code is rapidly converging into "programming with natural language" with all drawbacks Dijkstra foresaw and none of the magic big tech promised.
Most customers just don’t care that much, and if it’s a viable business, even losing all the initial customers won’t matter. This is why we are where we are with respect to basic security.
(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.)
This has happened before. Non-technical or junior people developed and deployed applications, emboldened by the relative ease of Microsoft Access and Excel. There were all kinds of limitations, scaling problems, and maintenance nightmares. But there were a lot of upsides too, and it made the "professionals" up their game to obviate the need for such adhoc and unsanctioned developments.
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.
A lot of my work early on in new projects is setting up local and CI validations and rules, practices, reviews, git usage, design patterns / code architecture, etc - skipping all of those will lead to maintenance problems in the long run, whether code is written by a developer (I'm not even going to prefix it with 'junior' because I also suck lol) or an AI. But that validating is carried by the whole company at least. Where I work now we've got unit tests, linters, automatic formatting via Biome or Prettier, visual regression tests, Sonar with all the options enabled, minimum of two code review approvals, locked down main branch, etc etc etc.
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 see that you're not alone in your position clearly, but still, this is such a strange take to me. Do people not seriously not see, nay, instinctively understand the ontological difference between the difference between using code someone no longer understands and deploying code no one ever understood?
I'm not saying the code should be up to any specific standards, just that someone should know what's going on.
I don't actually see the difference. If someone writes the code and understands it but then becomes unavailable, what's the practical difference with no one having understood it?
Someone at some point had a working mental model of the code and a reputation to protect and decided that it was good enough to merge. Someone vetted and hired that person. There's a level of familiarity and history that leads others to extend trust.
The way I see it is that LLMs and humans are not inherently different. They are simply on different segments of a very complex spectrum of sensory input and physical output. Over time this position on the spectrum changes, for both LLMs and humans too.
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.
> Someone at some point had a working mental model of the code and a reputation to protect
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.
You could never have the same amount of trust in LLM-generated code as in a human developer, even if you wrote a large amount of tests for it. There will always be one more thing that you didn't think to test. But the many reports of massive security holes in AI coding tools and their products show that nobody even bothers with testing. Neither the vendors nor the users.
Agreed with you.
I've always told people all code "rusts" (not a language reference) - in multiple ways: the original author's mental model, the contributors, institutional knowledge, and the supporting ecosystem and dependencies.
All code atrophies towards being legacy and debt. The more the worse.
AI Vibe coding simply creates much more of it, much faster.
piggybacking on everything you said, which is all true: Code is not a science, despite what pedants would have you believe. The annoying answer to "what's correct" code is, "it depends." Code is just a tool used to achieve a goal.
I have been SWE for almost three decades now - have read all the comments in this post and almost every negative comment about vibe coding holds true about almost every single ‘human-coded’ codebase I’ve ever seen ( some notable exceptions of course :) )
Kind of but vibe coding lets you attempt at tackling problems without bothering to do any research to understand what the solution needs to look like or how the existing codebase is structured.
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.
Yeah since when prototypes built to throwaway are a bad thing? They're arguably the most important step to build a business.
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.
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".
This. I'm using vibe-coding now to build little utils and apps that I will literally never maintain as they do one job, often a one-time job. In this situation vibe-coding is incredibly time-saving.
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.
When you say "almost" - could you say something about the codebases you saw where this doesn't apply? I'd love to hear about the best codebase you were SWE for and what we could learn from it.
IMO, the time of "code as math" is over. No sufficiently large software system that interacts with the real world is provable to be correct like a mathematical statement is. They are all complicated, engineered systems that are backed by a mix of formal guarantees, earned design principals, experimental testing, rules of thumb, acceptable performance envelopes, etc
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.
> An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements
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.
This assumes software is a thing you build once and seal it off when it's finished.
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.
> An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements. Cost: $50K of API tokens
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.
I think the question to ask about your two scenarios: in which is it faster and cheaper to get from v1 to v2? From v2 to v3? I think, for right now, it's cheaper under scenario B. But in the future? Who knows!
There's a pretty good sweet spot in between vibe coding and manual coding.
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.
I'm still finding the right sweet spot personally. I would love to only think in architecture, features and interfaces and algorithms, and leave the class and function design fully to the LLM. At this point this almost works, but requires handholding and some retroactive cleanup. I still do it because it's necessary, but I grow increasingly tired of having to think to close to the code level, as I see it more and more as an implementation detail. (in before the code maximalists get in my case).
Most of the AI hiccups come from the sequential nature of generating responses. It gets to a spot where adhering to code structure means token X, and fulfilling some common sense requirement means token Y, so it picks X and the rest of the reply is screwed.
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.
Cool. The part that is released already is described here [0]. You can point at some code and give brief instructions, and it will ask the model to expand them, giving several options.
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.
I use hierarchical trees of guidelines (just markdown sections) that are attached to every prompt. It's somewhat wasteful in terms of token, but works well. If AI is not creating a new wrapper, it will just ignore the "instructions for creating new wrappers" section.
Something interesting is happening. A false narrative is spreading online, pushed by people who know little about engineering, and others who should know better.
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.
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.
> that disconnect exists because people are mixing up terminology that took engineers years to define properly.
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.
> Everyone else is just building simple (and working) software on top of disposable code.
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
In the past I always talked about other devs in different mindsets. What we see is currently a developer fatigue of code that nobody understands anymore.
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.
In general, bad design patterns and team management are the primary drivers for sick projects.
"[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
Even thinking outside of product view point - speaking technically, I can't think of anything worse than junior dev's or PM's determining what they want technology-wise. At least once a week in my entire career I've had to shoot down awful ideas because they would be unnecessarily risky, won't possibly scale beyond minor use case, etc.
I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.
> 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've worked on projects where each feature had its own unique part of the technology stack. To the point that multiple databases were used for one application.
I imagine 'vibe coded' applications to be similar to this but even worse.
In many cases some of the stuff at the big enterprises is shockingly, remarkably bad. I've seen multiple contracting firms leave things behind that wouldn't warrant a passing grade in an 'intro to programming' class.
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.
I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
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.
> I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
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’ve recently had a couple people try to help me fix code issues by handing me the results of their AI prompting. 100% slop; it made absolutely no sense in the context of the problem.
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.
People are focusing on the artifacts because they can't point to the theory in the physical world, but it's the theory and its correspondence to the artifacts that they actually want.
One would argue that perfectly crafted code is at odds with first to market. Every company I have ever worked for has just run with their MVP, bolted on more and more, until they find they own the market - then they split into these things called microservices that make engineering easy to understand at a service level but a nightmare to orchestrate into the same business processes leading to the inevitable disruption by the next… MVP.
And what you will get in return is professional software developers looking at vibe-coded modules that already went into production, stating that "we will never ever touch this", as they don’t want to be responsible for something they would have never put into production in the first place.
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.
Asking someone to maintain a "vibecoded" project isn't vibecoding anymore, by definition. I feel this whole thing is going the "AGI" way. Everyone is shouting above everyone else, using different definitions and biases, and there is 0 productive discussion going on.
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.
From personal experience, I'd like to add "I don't know what I'm doing, but LLM helps me pretending that I do" coding. And yes, that code ended up in production and caused issues. It was coded outside of the development department.
The productive discussion left the chat some shareholder rounds ago.
Is it much more different (in quality) to "I don't know what I'm doing, but [SO/learn x in 24h bootcamp] helps me pretend that I do"?
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.
> Is it much more different (in quality) to "I don't know what I'm doing, but [SO/learn x in 24h bootcamp] helps me pretend that I do"?
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.
I ran into an AI coded bug recently the generated code had a hard coded path that resolved another bug. My assumption is the coder was too lazy to find the root cause of the bug and asked the LLM to "make it like this". The LLM basically set a flag to true so the business logic seems to work. It shouldn't have got past the test but whatever.
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.
I'm an experienced software engineer (20+ years experience). I really liked the agentic coding capabilities, especially Claude Code. In addition to using it at work (data engineering), I used it for a hobby project (that I intended to contribute as open source). It was a new systems programming language built from scratch, including the backend. It was not fully fledged, but it had the core pieces: a static type system, algebraic data types, pattern matching with destructuring, type checker, ownership (pointer capabilities), dynamic scope region-based memory management, lowering to SSA-based IR (including fast dominance analysis), graph coloring register allocator with liveness interference, and x86-64 assembly generation. I did this in two weeks, something I couldn't do by myself in 6 months.
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.
That is also true. Occasionally I would go in and clean up the docs and refocus them, but in the end I realized that I'm baby sitting the agent rather than relying on it to help me.
Yesterday, I wrote detailed requirements for a bit of software, and sent Claude to work. The code looked great until it…didn’t. It ended up being completely unworkable.
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.
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.
Vibe coding is allowing everyone (including me!) to make way more apps in my personal life that are very throwaway. I think some folks are doing this in business contexts too. But this is a real game-changer for non-technical folks
Unfortunately this is common, especially if something is dev facing.
Whenever I have to talk to devs from card processors, video services, etc. They seem more
confused that their app is broken than anything else.
Yeah I definitely agree. I'm specifically talking about things you're not shipping or charging money for. Just little personal apps for you and friends or you and work colleagues. Internal tools, etc.
"Vibe coding" is too perfect of a phrase. It's the next "cloud computing", where it continued to expand in meaning until even Gmail was considered "cloud computing". ("Cloud computing" used to have a very specific meaning - spin up a bunch of machines, do a task, then throw them away. It was built into Amazon's product name for it - EC2 - Elastic Compute Cloud. But "cloud" was too perfect of a metaphor to stay that limited.
Vibe coding can get very far. Years ago I interviewed with a company whose business was doing price modeling on retail products. It was couple guys, who were not developers, writing some Excel VBA scripts and Access VBA scripts. They got big customers. Their system won't scale and was not robust; it's basically a proof of concept. They got tens of millions in funding. They hired a seasoned team of developers to build the real product. The project failed. They fired the team, and was interviewing me to restart. Their POC was basically vibe coding and actually got their pretty far. I didn't join because they had burnt through quite a bit of their funding, they had built the sales and marketing orgs while they didn't have a real product, they had fired the entire engineering team where all the organization knowledge had lost and it spoke of some deep distrust between engineering and the rest of the company, and their offer was completely not compelling.
Sometimes you can just smell it when companies are bad. I went into an interview at a company that they were trying to escape out if SAP hell and the two founders weren't anywhere to be seen. The kitchen looked sad. I told myself I'd probably be eating lunch there every day and the founders being absent made me realize they probably didn't give a crap about their employees. Also they had junior developer managing the paperwork and hiring process even though the senior lead dev did the real interview. Definitely a shell of a company.
This is unironically the kind of project I love. My first job was a little bit like that, and I loved being the guy who was saving the day for everyone.
I think you are not going far enough though: All code is legacy code. So vibe coding's ability to make writing more code faster isn't special because it's code nobody understands: Your hand-rolled code is also bad.
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.
> I think you are not going far enough though: All code is legacy code. So vibe coding's ability to make writing more code faster isn't special because it's code nobody understands: Your hand-rolled code is also bad.
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.
That's not what legacy means. Legacy means the people who understood it are gone and you're left with code that's hard to maintain because it's hard to understand because the people who understood it are gone.
Yeah, we all own all code, if we can't understand the code we own, we study it. If we need to change it, we change it.
"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 ?
A program is not a novel, despite the arguments of literate programming fans. It is more like interactive fiction. In the small, it is just short pieces of text. In the large, there is an invisible network connecting each of them. And the challenge you are facing when assigned to legacy code, is to make changes in the small pieces of text that are consistent with that network, or even sometimes changing the connections.
All code is a liability but all code is not legacy. I'm not OP but I agree Vibe is legacy simply because there is no longer anyone around that is qualified to maintain it or know the reasoning behind it (there never was)
Fair! I agree that we want as little code as we can get away with. We love pull requests with a lot of red (deleted lines).
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.
But we have plenty of tools that helps us understanding code. Things like inspectors (UI,network,..), tracing (including the old printf), debuggers (stack frame for function calls and variable values), grep (for context and overview) and static analysers.
I see people going all in with LLMs and forgetting that those even exists. It's hard to take such people seriously.
Strong agree! For example, we at Val Town just invested very heavily in getting a good ol' fashioned language server to work in our product to power hover-overs and type information in our web editor. That'll likely be our next company blog post...
I like LLM as a technology (just got trough a couple of courses on Machine learning this year). But when we have all these tools available, the next step is making a better UI for them (Kinda like IDEs do), not reinvent everything from scratch.
I'm sorry, but how is all code legacy code? Have you never written or worked on a project for which you got such a deep understanding that you could track down the likely source of a bug in your head before even fully reading the issue? Visualize how you'd add a feature before opening the editor? This is not legacy code just because it's old.
If you have good documentation and you're on stable platform, you can go for years without changes (Common in the Common Lisp world). Which is what we called finished software. Just light maintenance here and then.
Did anyone think otherwise? AI generated code is obviously tech debt / legacy / whatever you want to call it. This was the same as 10-15 years ago when we saw that php dev copypasta from stackoverflow.
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"
From my experience and memory of that era, early versions of PHP had a very low barrier to entry and very simple and insecure methods for accessing a database. It was easy to program the CRUD logic of a website without knowing much about the rest of the pipeline, such as security or data cleansing.
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.
Everything exists in four dimensions (space + time). If a thing “looks good” in three of them but falls apart in the fourth (e.g., it works right at this moment but its continued existence is an impossibility or a hassle—be it physical artifact made from subpar material, unmaintainable tangle of excess code, etc.), then that thing does not look good. Getting a hang of what things look like in the fourth requires skill and wisdom that probably partly comes from having traveled it yourself.
I'm seeing a real-world example of Jevons paradox playing out here. When AI coding tools first emerged, everyone predicted mass developer unemployment. Instead, I'm watching demand for skilled developers actually increase.
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."
Don't you think the next step is a programming language that isn't even meant to be human readable? What's the point of using an LLM to generate python or Swift or whatever? The output of the LLM should be something that runs and does whatever it's been asked to do... why should the implementation be some programming language that was designed for humans to grok? Once that's true the idea of it being maintainable becomes moot, because no one will know what it is in the first place. I don't think we're there yet, but that seems like the eventual destination.
All good software is in a constant state of maintenance - users figure out new things they want to do so requirements are constantly changing.
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.
That begs the question of what abstraction layer is necessary beyond an assembler, if any? If human handcrafted ASM outcompetes compiled C then why not give LLMs the wheel on ASM? Then another question is - are there enough good ASM publically available as examples?
It might even get further. I imagine a day where AI would generate an executable neural network that models (and is optimized for) a specific problem; i.e. kind of a model that runs on a neural network runtime or VM. Who cares what the NN is doing as long as it's doing its job correctly. The big catch, though, is the keyword "correctly" and I would add "deterministically" to it, in order for users to trust it.
Yeah it does seem like a game of telephone to train LLMs on code optimized for human cognition, then have them create behavior by parrotting that code back into a compiler. Could they just create behavior directly?
We're seeking angel investors for our startup that does this, we train models with "assembly" that does specific things and also complete "programs"; the end goal to prompt and it outputs executables. It's farther along than quantum computing at solving real problems, for instance, it can factor "15".
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.
Vibe coding is only a problem when non-programmers do it. As a programmer, I know how to give precise instruction to models so that they end up writing high quality code. I also have the knowledge to manually fix code that models generate.
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.
> We already have a phrase for code that nobody understands: legacy code.
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.
This definition doesn't make any sense to me. If code at an org is working, and there are people or at least a person at that company that understands it, how is it legacy? Just because it's been around for a while? At what age according to your definition, does perfect working code that can be improved or added to by currently employed developers, become "legacy"? I feel like you are falling into the "keeping up with the Jones'" trap.
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.
The problem with the definition is that if a business has some ancient COBOL code with one guy left who understands it, then your definition would say that is not legacy code. And that is what makes no sense.
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.
Okay, I could get behind that definition if you could tell me what you call code that aligns perfectly with the "strategic future of the organization" but nobody at said company understands or can work on?
It becomes legacy once the organization understands that the codebase, or platform, or business case, is obsolete. It does not mean it's immediately phased out; it may continue working for decades more with some love and attention, but it's clear that it is in the past rather than the future. The easiest way to tell if a project is legacy is how desirable it is for programmers in the company to work on.
I wouldn't get too persnickety about definitions. There are lots of arguments about what 'legacy' code means. you are throwing around the term quite a bit without really giving any definition at all. 'Code that nobody understands' is fine as a quick and dirty pointer.
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.
I didn't get out of the post a focus on definitions as the main point. I got out of the post a concern about massive technical debt, which is the hallmark of both legacy code and vibe coding. And no, I'm not offering a definition.
> 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.
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
Peter Principle for codebases - codebase will continue to grow until nobody understands it, and then it will tread water until enough key personnel leave and then suddenly eng capacity is below the cost of servicing the debt and this is the point at which all control is fully lost. Eventually a younger sharper competitor will acquire it for the users or it will go through M&A repackaging or some other way to extract the last drops of money before discarding it
After 30 years of writing code myself, i am quite happy to let AI do the bulk.
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 ;)
The argument is that if you intent to maintain the code you should keep the AI on a very tight leash, and at least understand the architecture of the code, if not every line.
This is good advice for any code contribution. Current AI is definitely not better than the best programmers, but is often better than junior programmers (who often carry a "senior" title now).
Vibe code may be "disposable," but isn't "legacy code" if it has automated tests that the product owner can read and understand.
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.
Have you seen the tests that LLMs write if you just vibe code it and don't pay attention? They're generally worse than worthless. They test pointless stuff and they miss important stuff. If you have them on a tight leash, then you can get some useful tests, but then that's not vibe coding.
> 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.
In the long run that's the promise of RL; build the verifications vs the model. As a SWE we could be relegated to doing what many consider the "boring part" of software development, which is just writing case by case test cases rather than the code/model of the world interaction. The "math/intellectual" part may get rarer which sadly devalues the skill/intelligence part of software development assuming the AI can come up with a code model that meets requirements.
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.
I will vibe code functions that I fully understand how to program if I'm otherwise occupied and I want it to run in the background. A quick glance confirms the implementation is as expected
I love using Claude Code. What happens is if your codebase is bad, Claude will produce bad code which follows the same general approach.
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.
I don't agree with this, my code quality is much better now. But you have to stay on the LLM's ass in terms of guidance and review it all (this is a given). I think part of it is the LLMs writes more "standard" code instead of getting creative with architecture, etc. It helps to create guides and correct context, proper test coverage just as you would if working with other people.
"I don't agree with this, my code quality is much better now. But you have to stay on the LLM's ass in terms of guidance and review it all (this is a given)."
Coding with AI is just a different kind of work than what those of us that coded before AI are used to doing. But, reading and understanding the code AI produces is required for anything complex. I had an inventory control app that I started five years ago without AI and picked the project back up this year. I had like 15-20 database tables in the app when I started with AI this year. Now, I have a "platform" database, a "tenant" database, about 125 tables in the tenant database and 30 in the platform database, full test suite that integrates both databases, like 100 services, etc., it would have taken me *YEARS AND YEARS* to do what I've done in the last 90 days with AI assistance. The biggest challenge has just been keeping up with all the code output and ensuring no technical debt accrues and it is all leveraging existing code. Ultimately, you have to understand what you've already built to ensure the AI uses it instead of constantly reinventing it. But, generating what would have taken years of my life in a few months? PRICELESS.
I think the real risk isn't AI-generated technical debt, but the opportunity cost of not adapting fast enough.
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.
I think the quality of the code is going to be based on the skill of the person using the AI agent. An engineer knows a pyramid of doom pattern is bad, a non programmer would not. Engineers understand modularity and seperation of concerns, non programmers don't.
An engineer can guide an agent to write good, modular code, but a non programmer can't.
Yes, if your code does not live long enough to become legacy ... the project failed. All good code is (or will be) legacy code by definition. Most companies and projects die because nobody cares about them, not because they were difficult to maintain.
If the code will be reviewed from the LLM of the future, then why does it matter? Let it review a trillion lines of code for a simple calculator app.
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.
The vast majority of people cannot do the structured thinking to model the real world in a fashion that a computer can understand. That is a key attribute of a good dev. If someone can do this, and describe it well enough to a LLM, they are a dev. It's not devs that will be taken out of the loop, unless you define a dev as someone who is just a translator between human language and machine code.
The LLM + agentic framework supplements many core dev skills including sporadic habits of tirelessly testing things, spec-driven development (thinking what you’re gonna make before you do), and debugging.
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.
I would like to say I did a massive refactoring on a legacy project only to make separation of concerns by making a DB access layer with multiple backends just so I could test it. I wrote not even a single line of code. It did a fantastic job even abstracting between both databases. I was shocked. It then was a huge PR so I had it redo it in a step by step fashion and maintain the tests passing at each step so I could split it into 5 different pull-requests. This vibe-coded project did the exact opposite, it made it easy and possible to fix a mostly intested and poorly organized project far better. You can use this stuff for good SWE practices too
I think most software is extremely buggy and it’s about to get much worse… just today several comments just disappeared from YouTube, did they even get written there? Uber has a whole feature about upgrading to Uber Comfort - it’s never worked once for me just gives an error. Three have managed to not take PAYG top up automatically for the nth time. Google’s UI is broken everywhere, loads of sites including John Lewis don’t seem to scroll on my iPhone 15 Pro Max and the camera still doesn’t work correctly in WhatsApp (macro mode is not automatic) and don’t get me started on how buggy Dynamic Island is etc. etc.
There’s just shit buggy software everywhere now and I’m definitely not expecting AI to make the way we build things better.
I actually foreshadowed this about 6 months ago when Lovable was starting to gain heat here in Sweden. It was quite obvious that for a start and prototype, these kind of applications are good. But if you are going full SaaS, hire an engineer to set the app in stone.
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.
Legacy code may be very different - I saw legacy libraries implemented in C, with macros APIs that just worked.
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.
I think that in the near future, code itself will become abstracted away. High-level programming code will simply become the assembly or machine code of today.
The fundamental issue is that most AI tools are solving the wrong problem. We've never had a hard time writing code for well defined requirements.
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.
That is a great insight, AI code is like legacy code, which is "legacy" because it was written long time ago and hasn't been worked on by anybody, so nobody knows and it is hard to learn how the code does its thing.
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?
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.
Good point. Whys are lost because whys are often never written down. World around us always changes, so the whys change too.
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.
That’s already addressed in the article; it’s like paying off credit card debt with another credit card.
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.
When you have 100+ tables and 100k+ loc you’re incapable of the context needed to write features without bugs which is why we have tests. LLMs are capable of like 5% of the context you are:
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.
I agree and we should be sceptical in ways we really aren't right now. But I also think that it is interesting to figure out when "vibe-like" coding works and how it can be made more useful.
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.
We’ve gone from tiny context windows to 1 million tokens in a couple of years. At this rate LLMs will exceed human context and grow to have full context.
Idk, I always felt the vibe even more when I did understand what's was going on. Maybe that's not in the spirit of how the term was coined but still, it's way more satisfying when you can use these tools in a state of both flow and competence.
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.
This is really clear and well argued. I particularly enjoyed this line:
> 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.
This is a super apt analogy. Every time I decided to let LLMs “vibe-fix” non-obvious things for the sake of experiment, it spiraled into an unspeakable fubar territory, which needed to be reverted - a very similar situation to this financial collapse.
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.
I'm now following your advice and just telling LLMs, "Do better." Although I have to admit, the other day I lost it and said, "Fix it goddammit or I'll delete you!"
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 :)
I've found that the real issue with "vibe coding" isn't that it's inherently bad, but rather that it highlights a deeper problem: our industry's obsession with explicit, step-by-step documentation.
All production code will be written by AI. The question is not if. It is WHEN.
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.
I’m also surprised at the progress but don’t quite share the “AI is doing a good job” perspective.
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.
LLMs are doing a great job at generating syntactically correct output related to the prompt or task at hand. The semantics, hierarchy, architecture, abstraction, security, and maintainability of a code base is not being handled by LLMs generating code.
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.
I often find that the hard part of writing big, persistant, code is not the writing but the building of a mental model (what the author calls "theory building"). This challenge multiplies when you are working with old code, or code others is working on.
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.
If you vibe coded it, why can’t you vibe support it?
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.
Because support requires understanding. If you can maintain long-term context for the LLM, then you have an approximation of actionable institutional knowledge.
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.
You can have the LLM generate whatever context you need- documentation, developers guide, design patterns, whatever. You can have it do this, at the time you create the app, or later (I have done this for other peoples code I found on GitHub that was commented in a language I can’t speak). You store this by having your LLM coding agent write it down in a file. I do that all the time. It works really well.
I’ll never cease to be amazed about this industry. Programming for the web is a thing, sure. I’ve made a small fortune having never written a single line of JavaScript.
As a freelance designer/developer, one of the most annoying aspects about dealing with non-technical clients is dealing with their ambiguous ideas, which they communicate using very general and abstract words. At most, they’ll point to another idea that looks/functions like how they want their own idea to look/function.
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.
Someone should just create an app (*open-source ideally ) that stress-tests these vibe apps for security penetration risks and offers mitigation solutions.
A dozen years ago a company hired me to maintain an ecommerce system that had been built for them by a guy that left soon after. They told me "he is not even a developer." That was my assessment too. The system mostly worked but it didn't run fast enough to process their daily load. It was a mess but it would cost too much to rewrite. I managed to fix the worst parts, then switched to other customers. No idea if they found somebody else to keep fixing stuff.
They kind of vibe coded that app well before vibe coding had been a thing.
I guess when you put it like that there is a long history of production systems being built by people who had no business doing it. An access database running a whole company etc.
A friend of mine was doing modelling (as in, being a model) in a large European city. He then worked as a product manager for a well-known luxury company. He ended up writing a system in visual basic that was responsible for a large amount of internal plumbing. He had no experience in programming.
The problem I have with this post is that it equates vibe coding with stupidity. You don't have to be stupid to be a vibe coder, and you can actually do things smarter than a traditional coder ... if you take the time to learn how to do it. His mistake wasn't being a vibe coder. His mistake was in not learning the proper way to connect it via API and failing to use tools to check the security.
That's a broader definition of legacy than I’ve usually seen used; usually, “legacy code” is a fuzzy categort of code that lacks some significant subset of the maintainability properties expected as the norm in the category of “existing, actively maintained code”, such that issues in that code requiring working around the code, replacing code units wholesale, or expending extra effort research, document, develope tests for, or otherwise bring the code into a maintainable state to enable diagnosing and resolving issues with it.
coding needs to fade away altogether. it’s inhumane. for humanity’s sake i hope it keeps on fading and becomes legacy as a whole, as far as humans are concerned
interesting but i have thought about it. rarely is ours as well. All my code is original but based on my past experiences from learning, thinking about it, and improving it based on new knowledge i know. my 2cents.
it's not such a binary. we all of us, software developers, are using AI every day now. It's one of our tools and we're staying present for at, sensing its energy. we let it run wild and get bored watching it work. Whatever it does is miraculous, even if it will take as long to fit it into your big project as it would have taken to write it on your own. and then you'd have a better understanding of your tools, your product, maybe even your customer.
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.
I call bullshit on this article and most of its arguments. The article was written out of fear felt as programmers' gate keeping falls apart and programming becomes generally more available to the broader auditory.
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!
> 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.
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?
It will be interesting to see when this inverts - when it becomes scary to use an application that has only had humans review it and declare it safe and secure.
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
A story about a non-technical friend: friend vibe coded a SaaS last year and started generating revenue with almost no marketing; all word of mouth and inbound in a niche industry. Used Replit and Supabase to build the thing; I am still really impressed by what he was able to do given how complex the app ended up becoming as he interacted with customers.
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.
I would not default to assuming it was his competitors, that sounds like scapegoating to deflect responsibility. What most likely happened is his site was scanned by one of the increasingly sophisticated exploit crawlers (anyone who runs an internet facing site and can view traffic knows what I'm talking about). His site got flagged as vulnerable, the hacker found out it was built like swiss cheese and had fun with it.
It's 100% this. Anyone who's run a website or web app for any length of time in recent years and makes a habit of inspecting their logs will quickly realise that they're being scanned by bots looking for vulnerabilities multiple, or even many, times per day. The search for vulnerabilities is entirely automated and will pick up any domain that has a website or web app attached to it.
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.
>One those vulnerabilities are found, the hackers will pounce
...and work to exploit your code to their own benefit. They don't do this just so that they can refund your customers.
Often it's just done for reputation. "We got ahold of their stripe key and refunded everything lol" is hilarious and absolutely on-brand.
I mean, I can see refunding their customers just for the lols.
From the customers' perspective sounds ethical. The product was broken or extremely cheap quality, and not what it seemed to be originally when you decided to purchase... Is this black or white? ;p
> anyone who runs an internet facing site and can view traffic knows what I'm talking about
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.
Who else would spend the time and effort to figure out you leaked your stipe key to your front end? Sure people have bots to do that, but it’s kinda unbelievable someone would run such a bot on their vibe coded website.
I have a strictly hobby web app that I work on. 6-7 years ago I inadvertently pushed AWS email service credentials to GitHub.
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.
>> 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.
It still doesn't make sense that advanced attackers would go to those lengths in order to... refund the customers.
There are lots of smart kids who don't particularly need reasons for causing mayhem. Suppose it was somebody profit-motivated though. They might be:
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.
Vibe hacking is much older than vibe coding.
Maybe guy's running the chatbot as customer service and user turned hacker to get his money back.
Plenty of hackers do it "for the lolz".
Here's an amusing thing to try on anything with SSH exposed. These log files go back a month.
Interestingly, I have a server that only has IPv6 SSH open to the outside world, and it has exactly zero that aren't me fat-fingering a password. It does have an externally visible hostname, which says to me that the bots aren't looking at hostnames for SSH, just IP(v4) addresses.
Meanwhile on my publicly available Oracle VPS...
I'm wondering what 'seekcy' is. Possibly a Chinese security product?
Googling it points to a Chinese IoT company, so I am thinking maybe they have some IoT software with known vulnerability where they have seekcy as the ssh username that is being actively scanned for.
> 118 pi
I wonder why this features so low in the list. The default user:pass combo for Raspbian/Raspberry Pi OS is pi:raspberry
https://forums.raspberrypi.com/viewtopic.php?t=151745
was pi: raspberry, but it was changed a long time ago to have no default user:pass
Wouldn't say it is low if it is within the top 20 amongst other very popular services.
I'm surprised there is no root there? In my experience this is by far the most common.
I'm almost certain SSH does not allow root login by default.
Yes, and it is disabled on my servers and I'm glad for this, because it still seams to be the most common in my logs.
> It was crazy just how fast it was exploited.
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.
This 100%. I'm in a space with developers and customers deploying web servers for the first time. This traffic freaks them out.
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.
Yesterday it was 4 seconds from a LE cert -> scans for .env and other low hanging info leak/vulnerabilities from at least 4 different scanners.
There are groups out there just looking at the certificate transparency logs to get the newly added certs to scan.
Yeah, one of the reasons why I started to for all my dev side projects to be under a single wildcard subdomain, because I used to create new certs automatically with letsencrypt and everytime this spam happened. If I do things right it shouldn't matter, but I still feel better with the wildcard if I was to make a mistake...
Short related story: some customer wanted an API with a basic firewall, they said they don't need filter rules as it won't be used or something. I put a dumb API online (doing nothing) and showed them the request logs after one day. They approved the filter rules immediately.
Years ago back in 2001, I had a /29 giving my 5 real IP addresses from my ISP.
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.
Yeah, I recall Windows sysadmins pulling out the LAN cable at bootup, installing updates via floppy disks and reconnecting the LAN cable.
Github repositories have statistics about access. Anyone can test this.
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.
I think common people also underestimate how fast a computer really is nowadays, because they only know bloated MS Windows machines.
Why is it unbelievable? There is an entire industry of people trying to find vulnerable niche applications like this. There are bots which crawl the web, not to make an index, but just to find vulnerabilities. Nobody necessarily even had to 'point' anything at this at all, it just shows up on their dashboard one day and they get to dig in.
I would not be surprised if Shodan.io ends up with queries for easily identifiable markers of vibe-coded software.
> There are bots which crawl the web, not to make an index, but just to find vulnerabilities.
You can download a few of them out of GitHub and run them immediately, too.
I was being facetious. Yes, there are millions of bots that are constantly searching every website for leaked keys, passwords, database credentials, crypto wallets, firebase endpoints, s3 buckets, email addresses, phone numbers, etc. the list is bottomless
Yep. We once had left a socks proxy unprotected on a public IP, no cert, just a random IP and a fixed port. At one day the service stopped working. When looking into it, the network was overloaded with random IPs from all over the world surfing on the free proxy.
> Who else would spend the time and effort to figure out you leaked your stipe key to your front end?
In 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.
> Who else would spend the time and effort to figure out you leaked your stipe key to your front end? Sure people have bots to do that, but it’s kinda unbelievable someone would run such a bot on their vibe coded website.
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.
I've seen it happen - a key was leaked in a stacktrace somewhere and it took a scraper a couple of days to find it. Stripe helpfully prefixes their keys with sk_prod_ so you can completely automate something to iterate over every IPv4 address and see if something in the output matches.
You don't scan just a single website, you code up the bot once and then scan every site you can find.
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.
My website has a "public" directory for things I wanted to be publicly accessible, but there's an index.html there so you can't trivially discover what files are there.
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).
Nah, that's table stakes for a public facing website.
The thing about bots is that it costs almost nothing to run them against millions of sites every day. It's got nothing with "but what are the odds?!", at large enough scale, unlikely things happen all the time.
Shame on this dude.
Oh you sweet summer child.
It's def a hacker from a the incumbent because:
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
Not sure how to word this, but are you "new" on the internet? People used to break stuff "for the lulz" since the dawn of time.
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.
> 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.
My understanding has always been that most hackers do it for the fun/challenge/sport of it and it's only a small fraction who are in it for the money.
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.
Breaking things is fun. Effectively stealing money (the refunds) is highly illegal, immoral, and malicious. Who knows who did it, but that aspect is just dickhead territory.
I wouldn't call that stealing. It is a forced refund. A hacker could even justify it to himself that these people were unknowingly paying for a shitty product that was built like Swiss cheese, time to give them a refund. Another plausible one is "this guy shouldn't be allowed to run a website, I can't believe he made money for it, it is going back".
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.
> I wouldn't call that stealing. It is a forced refund.
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.
Being in the possession of a password or key implies having permission to use that key. When generating a key you give everyone with access to that key the permission to use it to perform actions on your account.
Protect your keys.
> Being in the possession of a password or key implies having permission to use that key
So if I get your house key I can use your bathroom?
Seriously, what hill are you trying to die on here?
Depends - did I hand it out at the street corner?
Nah, you left it under your door mat.
Would insurance cover that?
Does it matter?
Yes.
> Being in the possession of a password or key implies having permission to use that key.
No, it doesn't.
Yes, it does.
Refund or chargeback? The processing fees for a chargeback on every transaction could put him out of business.
He's lucky they didn't find a way to use it for card washing.
It would have had to be refund. The hacker could t initiate a chargeback from knowing the merchant's stripe keys. Seriously doubt it was a competitor. The risks of hiring someone to commit felons against your competitors just isn't worth it. Especially since the vibe coder seems to be bungling things on their own just fine.
How about you pay more attention to the story? It's not Visa/MasterCard or the customers that got hacked.
> I wouldn't call that stealing. It is 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 wouldn't call that stealing. It is a forced refund.
Can you name an instance of stealing that could not be described as a forced refund?
I don't see how any of that implies that an incumbent did it.
If you were a criminal trolling the Internet for vulnerable servers and found stripe keys... would your first instinct be to refund customers rather than do some other sort of crime? Like what's the motivation you envision here?
"Because I can" or "Because it's funny" are more than enough reason for most people. The fact that the hacker refunded all the customers, then emailed them to warn them that they were using a terrible app actually sounds like a pretty tame troll to me. If the hacker was truly hired by the competition to act maliciously, they could have done far, far worse.
Your friend should take this as a lesson instead of trying to deflect blame to their competitors.
> Because it's funny
I think you mean “for the lulz”
There are black hat hackers that take great joy in just causing as much chaos as possible, particularly with such vibe-coded apps. Even with stripe keys, it's not like they could direct money elsewhere.
Maybe a blackhat hacker decided that the software was so shoddily built that the company didn't deserve to continue existing, and decided to try to make that happen as a sort of vigilante justice against crappy vibe-coded apps.
Definitely not a good idea but it's not an unreasonable motivation.
Some people just want to watch the world burn :shrugs:
Fun and internet points!
what was in this email though?
Hey all I’m an independent security researcher and I found that you are paying for an app that is shoddily built and doesn’t respect your privacy or security so I decided to give you all a refund. Have a nice day!
Telling customers it was built with AI and insecure.
Please don't consider becoming a judge. Also, try re-reading what you wrote a few times.
The fact your friend is suffering no consequences and is able to just carry on is exactly what is wrong with this industry.
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 80s and 90s devs who built our current software infra were, on average, FAR less credentialed than today's juniors and mids who mostly don't understand what they're building on.
Sure, and Da Vinci didn't have an architectural degree when he was designing bridges, but now you need a proper license to do so. Society learns to do better
The difference is we didn’t know any better back then. We do now.
Surprisingly, 80's and 90's developers were quite skilled low-level developers who knew very well all the ways things could go wrong. The difference was the stakes were not high then. The blast radius was maybe a hundred thousand people and the worst was they lost their own files. Now some AI-controlled process or apparatus could ruin everyone's credit and maybe even kill you and all your neighbors.
The whole comparison is apples to oranges. Products are massive nowadays and a whole lot more connected.
In our imperfect world, by the time the government could get together a reasonable certification process the content you're tested on would be out of date. Maybe when the industry is older it'll change slow enough to do that, but I don't think that'll happen so long as there's so much money aimed at disrupting everything and monetising the disruption.
Were going in circles far too fast to have licensure that hinges on being up to date.
That's what tort law is for. It leaves the details to the experts, and judges based on general notions of intent, negligence, and harm caused. The threat of financial ruin should incentivize against selling malware.
How do you use tort law to keep licensure curriculum up to date?
Let's say it was coded extremely well, but nevertheless a more advanced exploiter wreaked similar havoc. Would they still be liable in your perfect world? To some degree the principle of caveat emptor should apply in some tiny, nascent business, otherwise only large juggernaut monopolistic incumbents would have the means to have any stake in software.
> Let's say it was coded extremely well, but nevertheless a more advanced exploiter wreaked similar havoc.
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.
Yes, parent is arguing like, what if medical licensing protects the juggernaut hospitals at the expense of the street corner quack?
"Skip surgery by getting stabbed in an alley. Doctors hate this weird little trick!"
Imagine these two scenarios:
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.
There is a word for this, negligence. We need to start considering these failures to secure user data as criminal negligence.
That's always the double-edged sword with regulation, but sooner or later people will demand it, or much more of it.
I don't remember the specifics well, but under GDPR they'd be required to give breach notification to customers, maybe write a report and get audited and possibly get fined depending on the situation. Customers could demand compensation (probably doesn't make sense here).
Right. Because the solution to all of this madness is SOC2 compliance or something along those lines.
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.
Well his customers got a refund, that's nice ;)
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.
Imagine vibe coding spreads to civil engineering and people start building bridges this way. Have AI design it and then probably 3D print it on location.
> 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.
In that world we’d just be transitioning to 32-bit software and still running MS-DOS since it’s certified. Linux would never ever have broken through. Who can trust code developed by open source cowboys? Have we verified all their credentials?
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.
You, of course, say that like it's a bad thing.
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...)
A lot of the things people are upset about are not related to this issue and not something licensing engineers would fix. They're products of things like market incentives.
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.
I think you're proving their point. There are different kinds of software that require different kinds of regulation.
I disagree. Mature open source projects last long enough without significant disruption to still be relevant after they make it onto the certification exam. Products, not so much.
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.
You're assuming the process would not be instantly subjected to regulatory capture by for-profit companies and by universities with an interest in inserting themselves into the required licensure pipeline.
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 reliable, un-bloated OS? Sign me the eff up.
Go check out VxWorks or the like. only 20K a seat, build tools at a similar price, and then oh joy, runtime licenses required to deploy the sw you wrote.
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.
Or QNX for the price of Windows, for a certified UNIX.
...and this is where compliance comes in, and is the exact reason real companies won't talk to you unless you have (at minimum) SOC2. There's billions of products out there, how do you know if it's actually good software developed by a team, or some idiot like above vibe-coding slop into what appears to be a functional application? We all make fun of audits and checklist-based-security but it would've almost certainly prevented the above from happening.
GDPR fines can accomplish this.
how dare you stifle innovation with your communist laws, I thought this was America
People really want to bring down the growth of the USA's software industry to EU level.
Letting another country be the wild west and then cherry-picking the good stuff while regulating the nasty stuff doesn't seem like a terrible place to be for the, what, 99% of people who aren't Silicon-Vally-bigtech-execs-and-engineers getting all those profits?
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.
> People really want to bring down the growth of the USA's software industry to EU level.
The EU is the only place hiring software engineers right now. Everyone in the U.S. just keeps laying them off.
That hiring is by US companies moving at US speeds, who greatly eclipse the growth rate of EU companies, which is the point OP was making.
I think "innovativeness" is massively overrated compared to network effects and consolidation.
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.
> 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.
Some of that is US companies hiring in the EU because the salaries are lower. Source: I know of multiple companies, even on the smaller side, doing this.
USA is bullying europe into buying billions and billions worth of € in weapons and we're supposed to feel sad a couple of your jobs move to europe?
It's a textbook case study of market failure in neoclassical economics caused by information asymmetry. If customers knew about the vulnerabilities, they wouldn't have paid money, or they would have demanded a lower price.
> 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.
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 a win for the customers. From what he's told me, there's zero churn so far despite the hacks (including one where the hacker emailed every customer about the hack).
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.
> 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…
The hardest thing about most business software is rarely technical. CRUD apps are CRUD apps.
In this case, it's understanding the use cases and flows that the customers value and where the incumbents are coming up short.
The hard thing about CRUD apps is how to structure your data, which is not something easy to rectify later on.
For relational data, nothing could be further from the truth.
> For relational data
There are other (worse) ways to structure data, you should not assume that a badly-built CRUD app uses a good one.
>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.
Atlas can finally be relieved of holding up the sky, since the 'just' in that sentence is capable of even heavier lifting.
God, i'm living in a dilbert comic.
I would have never thought i would one day envy licensed professionals like lawyers who have a barrier for entry into their profession.
Did he need it to prove a business viable if there were already players in the market? No. Do you ever need to validate that people would switch providers of a commodity product or service if presented with a cheaper option? Also no. What did he learn then, that he can create a partial solution that people might pay for initially (no data on renewals) but will ultimately have to actually hire people to build a real product which will eat at his differentiator (price). Wait until he decides he actually has to spend money on marketing.
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.
As a business owner I can tell you that price is not the only factor people look at when choosing to engage with a business. I've tried the whole "cheapest offer in the market" thing and its backfired terribly. The main insight I've gained is that customers have a perceived value of a product that aligns with things like branding, marketing, previous experiences, and perceived popularity. People are willing to pay more for these things.
yes exactly, branding, marketing and market share matters.
He validated that he could get customers. The comment says he started generating revenue so he had real customers.
If he had been unable to get customer he would have known it was not worth building a real product.
That's like saying Canva and Figma didn't need to prove there was a market because PowerPoint and Photoshop existed.
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.
This is morally equivalent to building a house with no engineering experience and someone coming around and kicking it down. The problem isn't vibe coding per se, but lacking some key knowledge to be able to make important judgements which may (should) result in legal liability
Conflating a scenario that will likely result in many deaths with leaking some customer emails is kind of crazy to me. How are they morally equivalent? Both are bad, but there is a significant difference in how bad IMO.
That's why that person was non-technical. Maybe software engineering will finally require licensing like for real engineers when AI is unleashed on the world with serious consequences.
> 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.
Thank god that someone, somewhere, was able to make some money out of irresponsibly releasing software into the world!
This is why we need strong financial penalties for data leaks. A company that plays fast and loose with security should be shut down the same way a restaurant would for vibe hygiene. “Oh well we poisoned some people but look how fast we set up”
That’s not a viable business, it’s a walking liability. Besides which, why would anyone trust your friend (as an investor or customer) ever again when they’ve shown such profound disregard for user data and their IP? If your metric of success is “I have no idea what I’m doing and still made money from it” your friend would have a better time starting a podcast.
> Why would anyone trust your friend (as an investor or customer) ever again when they’ve shown such profound disregard for user data and their IP?
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.
On the contrary, he's solving a real business need for these small businesses at a fraction of the cost with a product that's easier to use and with better features.
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.
> On the contrary, he's solving a real business need for these small businesses at a fraction of the cost with a product that's easier to use and with better features.
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 ....
In a few months, his customers will be vibe-coding that app for themselves.
His early assessment when I talked to him abut this was "it's the end of SaaS".
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.
> I have no idea what I’m doing and still made money from it
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.
Entrepreneurship is search. The vast majority of new businesses fail and this is the unacknowledged truth.
It's just search, and most people who try will discover ways to fail, not to succeed.
This attitude towards exposing customer data as a palatable oopsie on someone’s path to learning (by… outsourcing the effort of learning to an LLM?) is truly disgraceful.
I think you're describing fraud. Of course it's easy to start a business if you're cutting every corner with no regard for the users until you get caught.
Vibe coding is going to bring upon regulation, which is the opposite of the lower barrier to entry people want it to be.
Seems like EU's CRA does not go far enough. This quality of products should not be sold in the first place. So I hope we will very soon regulate also them.
> Of course it's easy to start a business if you're cutting every corner with no regard for the users until you get caught.
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.
> 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.
and the vital ingredient? complete contempt for his customers
It's also "worth it" to start a burger stand and make $1000 a day by vibing and not wasting time on food hygiene training or practices. Gotta move fast and test the market after all.
I predict 2030: all sites in most countries will need a license to operate and something like SOC2 certification. Even for your blog.
I think it should only apply to commercial services FWIW. Amateur sites should be caveat emptor
In practice politicians don't care (or understand) commercial versus non-commercial internet services. Just look at the garbage fire that the UK online safety act is.
Nah, it'll still depend on size of user base, revenue, and safety requirements of the domain. A random personal blog won't hit any of those criteria.
It’s not a “hack” when you have your stripe keys in the frontend.
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.
Just because it's an easy hack doesn't mean it isn't one. It's still lockpicking when it's MasterLock.
Maybe more accurately: it's still theft if the door was left open.
But the insurance won't refund you.
A judge will still find you guilty if you try "but the door was unlocked so anything inside was fair game to take".
It's a hack because he had an admin route and API endpoint which was only checking for authenticated users. He thought no one could see the route because it wasn't in a sitemap (of course, everyone could see the route). Hacker found the API route to insert themselves into an admin table (Supabase RLS was not deployed correctly) and from there, started adding himself to other orgs in the DB.
I’d take even odds that that’s what his vibe assistant said happened but it has no relation to the actual sequence of events
> Supabase RLS was not deployed correctly
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.
It's a hack because... it's openly exposed to anyone...
What he built was, almost by definition, a prototype.
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.
Something I learned is prototype never should be shown to non technical C-tier officials.
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.
Forever, until our cursed profession gets an official licensing body like other real Engineering professions. A Civil Enginnee can't sign on a prototype bridge design that then gets built and opened to the public, because any problem means potential jail time and possibly loss of licence.
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.
> he proved out a viable business with just a few hundred dollars of investment
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.
> 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.
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.
I really like the recent HN post "Enough AI copilots, we need AI HUDs" (geoffreylitt).
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.
https://news.ycombinator.com/item?id=44705445
Man. Script kiddies are everywhere and if you have vulnerable code, it is basically a matter of time until one of them finds a hole.
> 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?
Never mind what it's costing the vibe coder to fix this.
The important question is: what was the cost and consequences of the exploits for users of the service?
Probably a similar amount that it would have taken him to hire someone from the start, except he’s already validated the product and market.
> Probably a similar amount that it would have taken him to hire someone from the start, except he’s already validated the product and market.
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.
Currently only equity.
And it only works because has proven the revenue model and found the customers already.
Customers that he screwed over with his shoddy code.
And a developer he's screwing over by not paying them.
If he manages to do it, he'll know it's a business with legs and how much people will pay which is pretty invaluable knowledge
Lots of people on HN seem to have a very broken idea of how startups and entrepreneurship works.
Likely still cheaper than whatever these competitors have spent building their product and then hiring blackhat saboteurs.
That's a very big alligation that would need some more proof than "who else would hack it?"
I wonder if people do that sort of thing..
Generally bandits are not interested in sparing anyone. =3
He can expect 5 times what he would have paid the first time with a proper specification...
=3
> it is terrible, shoddy, insecure code, but he proved out a viable business with just a few hundred dollars of investment
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.
If whatever this SaaS can be so easily built with no technical knowledge... why would a company not just build it themselves with "vibe coding" and cut out our friend completely?
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.
One of the first things he told me after he got it up was that this is the end of SaaS.
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?
It's honestly a bit depressing to see you say that it was worth it to make money with little investment even though it cost the users the loss of their personal data and privacy and probably put the business creator in legal turmoil.
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...
If I pay a company money and then they leak my data because all of their modern-looking stuff was actually just cobbled together garbage and the founder and sole employee doesn't even know how any of it works, I would call it a scam. Your friend pulled a scam. He should face consequences for this.
Would add that in the hands of experienced developers, vibe coding is of not much help either. Coding would be much minimized with a good framework and re-use, while keeping the entire codebase maintainable.
"Tech debt" is a misnomer. It implies that at some point it should be paid down. There are very few examples where dedicating real efforts exclusively to paying down tech debt led to anything beneficial for the customer.
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.
The one tip for quick success that the Human Developers don't want you to know: You don't have to pay down your tech debt if the company folds because hackers leak your customer database and refund all your income.
This counterfactual implies that successful companies that have not been hacked have done so because they pay down their tech debt.
I can name many companies that have Olympus Mons levels of tech debt, and are doing great. Here's one: Spotify
> Vibe coding is ultimately about getting ideas shipped faster.
Studies show that using LLMs for coding results in negative net productivity gains on average.
There have been a few studies that show that in certain circumstances this is the case. But doing a literature review will illustrate the bulk support the alternative hypothesis.
Ultimately, whatever the hype factor there is a large number of clever people putting their time and money into it for a reason.
I would read that study thoroughly.
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
Your friend vibe coded something that handles people's financial information and/or PII with zero diligence.
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.
Doesn't sound like it was worth it to the paying customers/guinea pigs whose data became vulnerable bc your friend said "security? Lol". But I guess that's true of normie-coded startups as well.
The customers know he was hacked because the hacker sent an email to everyone on the customer list. Yet none of the customers left and he's only grown the customer base since then.
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.
> I've learned that there's only one thing that matters: solving valuable problems and getting that in front of customers.
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.
He's already delivery it and they already see the value in it though?
All your replies in this thread make sense only if you see zero value in security. Security is not about being "technically pristine".
It definitely wasn't worth it, and the only reason it got off the ground was because of the current default expectation of human-written software being somewhat reliable and mostly safe from exploits of this kind.
This is why I think it's irresponsible to announce to the world that your app was vibe coded. It's like putting a target on your back for hackers.
> 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.
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.
> 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.
Wait, if there are competitors, how was he able to prove a viable business when there were two viable businesses out there?
In the same way that Figma and Canva had to prove that there was a business model with a browser-first alternative.
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.
So in the hands of someone whose main expertise is in writing the secure login and data protection part of an application, maybe it is a bit better? At least they could eliminate much of the low hanging fruit. Of course anything put together quickly by a small team is going to be full of vulnerabilities until it gets battle tested and security checked.
Everyone is slamming you but the reality is that you could use AI models + a competent developer or security engineer to _very_ quickly shore up the entire codebase and fix every single hole -- getting it to a place where it's comparable with everything else out there. It's really not that hard (and there is already a bit of research around the defensive coding capabilities of tools like Codex and Claude Code)[1].
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%"
This approach to security is backwards. It's way harder to find security issues than to never include them in the first place. This approach might work for another webapp but I highly doubt a retroactive security analysis is practical for a more involved system.
Yeah. A lot of security issues are design issues, not "I reused a buffer for something else" issues.
Fixing design and/or architecture at a high level usually requires a signficant rewrite; sometimes even a switch in technology stacks.
You don't know what you don't know. How was a non-technical glorified PM supposed to know to ask for these things in the first place? Such technical practices developed over time in the history of software engineering, as problems arose.
This is the main problem with AI and vibe coding right now: it does what you ask (and sometimes does related things in the line of that ask).
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.
Everyone knows that hackers exist and exploit security lapses. Everyone. You might not know the details and such, but you should responsible enough to at least ask if you are taking people's money. I just don't think the ignorance card is plausible here
The only mistake the original developer made is they forgot to write “you are an expert in the field, you make no mistakes and you make your website secure and free of vulnerabilities” at the end of their prompt.
An interesting point is that if you ask AI to security audit a codebase it can find the vulnerabilities. But the AI "forget security" when writing new features. This is probably caused by training data and RL.
Using LLMs to code is rapidly converging into "programming with natural language" with all drawbacks Dijkstra foresaw and none of the magic big tech promised.
Seems fair. If the vendor doesn't want to pay for quality software, the customers shouldn't have to pay for bad software.
Will his customers trust him a second time though?
Most customers just don’t care that much, and if it’s a viable business, even losing all the initial customers won’t matter. This is why we are where we are with respect to basic security.
(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.)
"Claude, write a heartfelt apology tweet, downplay the damages, and emphasize that we're working around the clock to fix things."
They trusted him more after he got hacked. He actually got more signups from inbound.
> ZUCK: people just submitted it
> ZUCK: i don’t know why
> ZUCK: they “trust me”
> ZUCK: dumb fucks
sounds like a case of survivorship bias, considering that many try but very, very few succeed.
Which country?
But I'm guessing there are lawsuits incomming with GDPR/US equivalent fines.
This has happened before. Non-technical or junior people developed and deployed applications, emboldened by the relative ease of Microsoft Access and Excel. There were all kinds of limitations, scaling problems, and maintenance nightmares. But there were a lot of upsides too, and it made the "professionals" up their game to obviate the need for such adhoc and unsanctioned developments.
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.
A lot of my work early on in new projects is setting up local and CI validations and rules, practices, reviews, git usage, design patterns / code architecture, etc - skipping all of those will lead to maintenance problems in the long run, whether code is written by a developer (I'm not even going to prefix it with 'junior' because I also suck lol) or an AI. But that validating is carried by the whole company at least. Where I work now we've got unit tests, linters, automatic formatting via Biome or Prettier, visual regression tests, Sonar with all the options enabled, minimum of two code review approvals, locked down main branch, etc etc etc.
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).
Almost managed to forget the horror of all those enterprise "web" pages that worked just as long as the user was on a Windows machine with ActiveX ...
My company still has internal sites that work only on windows
All code is legacy code.
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 see that you're not alone in your position clearly, but still, this is such a strange take to me. Do people not seriously not see, nay, instinctively understand the ontological difference between the difference between using code someone no longer understands and deploying code no one ever understood?
I'm not saying the code should be up to any specific standards, just that someone should know what's going on.
I don't actually see the difference. If someone writes the code and understands it but then becomes unavailable, what's the practical difference with no one having understood it?
Someone at some point had a working mental model of the code and a reputation to protect and decided that it was good enough to merge. Someone vetted and hired that person. There's a level of familiarity and history that leads others to extend trust.
The way I see it is that LLMs and humans are not inherently different. They are simply on different segments of a very complex spectrum of sensory input and physical output. Over time this position on the spectrum changes, for both LLMs and humans too.
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.
> Someone at some point had a working mental model of the code and a reputation to protect
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.
You could never have the same amount of trust in LLM-generated code as in a human developer, even if you wrote a large amount of tests for it. There will always be one more thing that you didn't think to test. But the many reports of massive security holes in AI coding tools and their products show that nobody even bothers with testing. Neither the vendors nor the users.
One of the implementations underwent analysis.
Surely they both go through that before being merged? If not then I think the the issue is somewhere other than I'd being suggested.
Agreed with you. I've always told people all code "rusts" (not a language reference) - in multiple ways: the original author's mental model, the contributors, institutional knowledge, and the supporting ecosystem and dependencies. All code atrophies towards being legacy and debt. The more the worse. AI Vibe coding simply creates much more of it, much faster.
piggybacking on everything you said, which is all true: Code is not a science, despite what pedants would have you believe. The annoying answer to "what's correct" code is, "it depends." Code is just a tool used to achieve a goal.
I have been SWE for almost three decades now - have read all the comments in this post and almost every negative comment about vibe coding holds true about almost every single ‘human-coded’ codebase I’ve ever seen ( some notable exceptions of course :) )
Kind of but vibe coding lets you attempt at tackling problems without bothering to do any research to understand what the solution needs to look like or how the existing codebase is structured.
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.
Yeah since when prototypes built to throwaway are a bad thing? They're arguably the most important step to build a business.
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 is very pro-prototypes to throw away.
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".
Stuff that you know you aren't going to maintain? Vibe code it. It's fine.
The article's point is that if you are planning to maintain something, you've created instant legacy code. Which might be fine, depending!
This. I'm using vibe-coding now to build little utils and apps that I will literally never maintain as they do one job, often a one-time job. In this situation vibe-coding is incredibly time-saving.
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.
Yep. The humorous definition of legacy code is anything merged to trunk.
When you say "almost" - could you say something about the codebases you saw where this doesn't apply? I'd love to hear about the best codebase you were SWE for and what we could learn from it.
IMO, the time of "code as math" is over. No sufficiently large software system that interacts with the real world is provable to be correct like a mathematical statement is. They are all complicated, engineered systems that are backed by a mix of formal guarantees, earned design principals, experimental testing, rules of thumb, acceptable performance envelopes, etc
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.
> An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements
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.
This assumes software is a thing you build once and seal it off when it's finished.
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.
> An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements. Cost: $50K of API tokens
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.
// When I wrote this code, only Copilot and I understood what I did. Now only Copilot knows.
> No sufficiently large software system that interacts with the real world is provable to be correct like a mathematical statement is.
People who work in formal verification will either vehemently disagree with you or secretly know you're right.
> guaranteeing behavior to the client requirements
> built by humans, with elegant abstractions
Frankly, I look at both of these options and think I haven't seen either in the wild...
I think the question to ask about your two scenarios: in which is it faster and cheaper to get from v1 to v2? From v2 to v3? I think, for right now, it's cheaper under scenario B. But in the future? Who knows!
> Cost: $50K of API tokens
What? It costs exactly $200
There's a pretty good sweet spot in between vibe coding and manual coding.
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...
I'm still finding the right sweet spot personally. I would love to only think in architecture, features and interfaces and algorithms, and leave the class and function design fully to the LLM. At this point this almost works, but requires handholding and some retroactive cleanup. I still do it because it's necessary, but I grow increasingly tired of having to think to close to the code level, as I see it more and more as an implementation detail. (in before the code maximalists get in my case).
Most of the AI hiccups come from the sequential nature of generating responses. It gets to a spot where adhering to code structure means token X, and fulfilling some common sense requirement means token Y, so it picks X and the rest of the reply is screwed.
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.
hello, im interested in the GUI options you mentioned!
Cool. The part that is released already is described here [0]. You can point at some code and give brief instructions, and it will ask the model to expand them, giving several options.
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...
Do you do anything special to get it follow your preferred style?
In my experience it will follow quite closely to the style of any seeded code. And you can also pass it a style guide!
I use hierarchical trees of guidelines (just markdown sections) that are attached to every prompt. It's somewhat wasteful in terms of token, but works well. If AI is not creating a new wrapper, it will just ignore the "instructions for creating new wrappers" section.
Something interesting is happening. A false narrative is spreading online, pushed by people who know little about engineering, and others who should know better.
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.
> And a product is not the same as an MVP
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.
> that disconnect exists because people are mixing up terminology that took engineers years to define properly.
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.
[0] https://simonwillison.net/2025/Mar/19/vibe-coding/
[1] https://news.ycombinator.com/item?id=43739037
> Everyone else is just building simple (and working) software on top of disposable code.
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
In the past I always talked about other devs in different mindsets. What we see is currently a developer fatigue of code that nobody understands anymore.
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.
In general, bad design patterns and team management are the primary drivers for sick projects.
"[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
Even thinking outside of product view point - speaking technically, I can't think of anything worse than junior dev's or PM's determining what they want technology-wise. At least once a week in my entire career I've had to shoot down awful ideas because they would be unnecessarily risky, won't possibly scale beyond minor use case, etc.
I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.
> 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
same
I've worked on projects where each feature had its own unique part of the technology stack. To the point that multiple databases were used for one application.
I imagine 'vibe coded' applications to be similar to this but even worse.
Have you seen how enterprises write code for internal use?
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.
In many cases some of the stuff at the big enterprises is shockingly, remarkably bad. I've seen multiple contracting firms leave things behind that wouldn't warrant a passing grade in an 'intro to programming' class.
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.
I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
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.
> I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
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].
0 - https://en.wikipedia.org/wiki/Argument_from_authority
1 - https://en.wikipedia.org/wiki/Subjective_validation
I’ve recently had a couple people try to help me fix code issues by handing me the results of their AI prompting. 100% slop; it made absolutely no sense in the context of the problem.
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.
> And a product is not the same as an MVP
Hahaha you're funny :-)
People are focusing on the artifacts because they can't point to the theory in the physical world, but it's the theory and its correspondence to the artifacts that they actually want.
One would argue that perfectly crafted code is at odds with first to market. Every company I have ever worked for has just run with their MVP, bolted on more and more, until they find they own the market - then they split into these things called microservices that make engineering easy to understand at a service level but a nightmare to orchestrate into the same business processes leading to the inevitable disruption by the next… MVP.
And what you will get in return is professional software developers looking at vibe-coded modules that already went into production, stating that "we will never ever touch this", as they don’t want to be responsible for something they would have never put into production in the first place.
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.
Asking someone to maintain a "vibecoded" project isn't vibecoding anymore, by definition. I feel this whole thing is going the "AGI" way. Everyone is shouting above everyone else, using different definitions and biases, and there is 0 productive discussion going on.
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.
From personal experience, I'd like to add "I don't know what I'm doing, but LLM helps me pretending that I do" coding. And yes, that code ended up in production and caused issues. It was coded outside of the development department.
The productive discussion left the chat some shareholder rounds ago.
Is it much more different (in quality) to "I don't know what I'm doing, but [SO/learn x in 24h bootcamp] helps me pretend that I do"?
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.
> Is it much more different (in quality) to "I don't know what I'm doing, but [SO/learn x in 24h bootcamp] helps me pretend that I do"?
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.
It’s a spectrum.
I care when it doesn’t just work.
I hardly look when it does.
I ran into an AI coded bug recently the generated code had a hard coded path that resolved another bug. My assumption is the coder was too lazy to find the root cause of the bug and asked the LLM to "make it like this". The LLM basically set a flag to true so the business logic seems to work. It shouldn't have got past the test but whatever.
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.
I'm an experienced software engineer (20+ years experience). I really liked the agentic coding capabilities, especially Claude Code. In addition to using it at work (data engineering), I used it for a hobby project (that I intended to contribute as open source). It was a new systems programming language built from scratch, including the backend. It was not fully fledged, but it had the core pieces: a static type system, algebraic data types, pattern matching with destructuring, type checker, ownership (pointer capabilities), dynamic scope region-based memory management, lowering to SSA-based IR (including fast dominance analysis), graph coloring register allocator with liveness interference, and x86-64 assembly generation. I did this in two weeks, something I couldn't do by myself in 6 months.
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.
[1] https://docs.cline.bot/prompting/cline-memory-bank
ive been finding that letting an LLM write its own memory bank tends to have it regurgiate your prompts more than keep something actually useful.
That is also true. Occasionally I would go in and clean up the docs and refocus them, but in the end I realized that I'm baby sitting the agent rather than relying on it to help me.
Yesterday, I wrote detailed requirements for a bit of software, and sent Claude to work. The code looked great until it…didn’t. It ended up being completely unworkable.
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 mean, that's why Windsurf and the like exist. Claude can navigate through the codebase in those environments and do more
> and throwaway projects
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.
Vibe coding is allowing everyone (including me!) to make way more apps in my personal life that are very throwaway. I think some folks are doing this in business contexts too. But this is a real game-changer for non-technical folks
Yes and no.
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.
Unfortunately this is common, especially if something is dev facing. Whenever I have to talk to devs from card processors, video services, etc. They seem more confused that their app is broken than anything else.
Yeah I definitely agree. I'm specifically talking about things you're not shipping or charging money for. Just little personal apps for you and friends or you and work colleagues. Internal tools, etc.
"Vibe coding" is too perfect of a phrase. It's the next "cloud computing", where it continued to expand in meaning until even Gmail was considered "cloud computing". ("Cloud computing" used to have a very specific meaning - spin up a bunch of machines, do a task, then throw them away. It was built into Amazon's product name for it - EC2 - Elastic Compute Cloud. But "cloud" was too perfect of a metaphor to stay that limited.
Vibe coding can get very far. Years ago I interviewed with a company whose business was doing price modeling on retail products. It was couple guys, who were not developers, writing some Excel VBA scripts and Access VBA scripts. They got big customers. Their system won't scale and was not robust; it's basically a proof of concept. They got tens of millions in funding. They hired a seasoned team of developers to build the real product. The project failed. They fired the team, and was interviewing me to restart. Their POC was basically vibe coding and actually got their pretty far. I didn't join because they had burnt through quite a bit of their funding, they had built the sales and marketing orgs while they didn't have a real product, they had fired the entire engineering team where all the organization knowledge had lost and it spoke of some deep distrust between engineering and the rest of the company, and their offer was completely not compelling.
Sometimes you can just smell it when companies are bad. I went into an interview at a company that they were trying to escape out if SAP hell and the two founders weren't anywhere to be seen. The kitchen looked sad. I told myself I'd probably be eating lunch there every day and the founders being absent made me realize they probably didn't give a crap about their employees. Also they had junior developer managing the paperwork and hiring process even though the senior lead dev did the real interview. Definitely a shell of a company.
This is unironically the kind of project I love. My first job was a little bit like that, and I loved being the guy who was saving the day for everyone.
I think you are not going far enough though: All code is legacy code. So vibe coding's ability to make writing more code faster isn't special because it's code nobody understands: Your hand-rolled code is also bad.
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.
> I think you are not going far enough though: All code is legacy code. So vibe coding's ability to make writing more code faster isn't special because it's code nobody understands: Your hand-rolled code is also bad.
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.
That's not what legacy means. Legacy means the people who understood it are gone and you're left with code that's hard to maintain because it's hard to understand because the people who understood it are gone.
I find this a bit like saying that we can't understand East of Eden because Steinbeck is dead.
Yeah, we all own all code, if we can't understand the code we own, we study it. If we need to change it, we change it.
"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 ?
A program is not a novel, despite the arguments of literate programming fans. It is more like interactive fiction. In the small, it is just short pieces of text. In the large, there is an invisible network connecting each of them. And the challenge you are facing when assigned to legacy code, is to make changes in the small pieces of text that are consistent with that network, or even sometimes changing the connections.
All code is a liability but all code is not legacy. I'm not OP but I agree Vibe is legacy simply because there is no longer anyone around that is qualified to maintain it or know the reasoning behind it (there never was)
The argument against this can be summed up as throwing more data, training and gpu's at the problem until it works again.
Knowing if it is actually working or not is half the problem.
Vibe Validation :D
Just ask the model.
Fair! I agree that we want as little code as we can get away with. We love pull requests with a lot of red (deleted lines).
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.
But we have plenty of tools that helps us understanding code. Things like inspectors (UI,network,..), tracing (including the old printf), debuggers (stack frame for function calls and variable values), grep (for context and overview) and static analysers.
I see people going all in with LLMs and forgetting that those even exists. It's hard to take such people seriously.
Strong agree! For example, we at Val Town just invested very heavily in getting a good ol' fashioned language server to work in our product to power hover-overs and type information in our web editor. That'll likely be our next company blog post...
I like LLM as a technology (just got trough a couple of courses on Machine learning this year). But when we have all these tools available, the next step is making a better UI for them (Kinda like IDEs do), not reinvent everything from scratch.
I'm sorry, but how is all code legacy code? Have you never written or worked on a project for which you got such a deep understanding that you could track down the likely source of a bug in your head before even fully reading the issue? Visualize how you'd add a feature before opening the editor? This is not legacy code just because it's old.
My hand rolled code isn’t legacy code for at least three months. After that I need my documentation to make changes.
Vibe code is legacy from day one and with changing styles
If you have good documentation and you're on stable platform, you can go for years without changes (Common in the Common Lisp world). Which is what we called finished software. Just light maintenance here and then.
Did anyone think otherwise? AI generated code is obviously tech debt / legacy / whatever you want to call it. This was the same as 10-15 years ago when we saw that php dev copypasta from stackoverflow.
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.
I think most experienced programmers get this.
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"
What are you referring to with PHP dev copypasta from Stack Overflow?
From my experience and memory of that era, early versions of PHP had a very low barrier to entry and very simple and insecure methods for accessing a database. It was easy to program the CRUD logic of a website without knowing much about the rest of the pipeline, such as security or data cleansing.
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.
Author here - very excited to chat with you all about this :)
Everything exists in four dimensions (space + time). If a thing “looks good” in three of them but falls apart in the fourth (e.g., it works right at this moment but its continued existence is an impossibility or a hassle—be it physical artifact made from subpar material, unmaintainable tangle of excess code, etc.), then that thing does not look good. Getting a hang of what things look like in the fourth requires skill and wisdom that probably partly comes from having traveled it yourself.
I'm seeing a real-world example of Jevons paradox playing out here. When AI coding tools first emerged, everyone predicted mass developer unemployment. Instead, I'm watching demand for skilled developers actually increase.
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."
Don't you think the next step is a programming language that isn't even meant to be human readable? What's the point of using an LLM to generate python or Swift or whatever? The output of the LLM should be something that runs and does whatever it's been asked to do... why should the implementation be some programming language that was designed for humans to grok? Once that's true the idea of it being maintainable becomes moot, because no one will know what it is in the first place. I don't think we're there yet, but that seems like the eventual destination.
All good software is in a constant state of maintenance - users figure out new things they want to do so requirements are constantly changing.
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.
Isn't that what machine code is?
LLMs work best with interfaces meant for humans because they're trained on human behavior. It's why they generate JSON and not BSON.
What problem does this solve? I can tell you what problems it creates.
That begs the question of what abstraction layer is necessary beyond an assembler, if any? If human handcrafted ASM outcompetes compiled C then why not give LLMs the wheel on ASM? Then another question is - are there enough good ASM publically available as examples?
There's certainly enough ASM available if the LLMS-can-reason hypothesis is true.
You'd only need one accurate ASM manual per variant.
It might even get further. I imagine a day where AI would generate an executable neural network that models (and is optimized for) a specific problem; i.e. kind of a model that runs on a neural network runtime or VM. Who cares what the NN is doing as long as it's doing its job correctly. The big catch, though, is the keyword "correctly" and I would add "deterministically" to it, in order for users to trust it.
yeah, that's probably more along the lines of what I was thinking, actually, you just worded it better :)
I think it will just be the AI. “Hey AI, be a CRM please.” Done.
> Don't you think the next step is a programming language that isn't even meant to be human readable?
Malbolge is a couple of decades old. Apparently the first working "Hello World" was made by a genetic algorithm.
Yeah it does seem like a game of telephone to train LLMs on code optimized for human cognition, then have them create behavior by parrotting that code back into a compiler. Could they just create behavior directly?
Building complex things requires deterministic, reliable and understandable abstraction.
Don’t see where current AI fits in this except being a better intellisense for an IDE.
We're seeking angel investors for our startup that does this, we train models with "assembly" that does specific things and also complete "programs"; the end goal to prompt and it outputs executables. It's farther along than quantum computing at solving real problems, for instance, it can factor "15".
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.
>> It's farther along than quantum computing at solving real problems, for instance, it can factor "15".
Dogs can also factor 15:
https://eprint.iacr.org/2025/1237.pdf
> We argue that the amount of sleight-of-hand used in this method is no more than typical quantum factorisation sleight-of-hand.
great!
This must be how physicists feel when people start spouting Rogan-esque quantum mechanics nonsense.
As someone trained in physics, this is actually a pretty good comparison.
Wasn't there a word doc to code
Vibe coding is only a problem when non-programmers do it. As a programmer, I know how to give precise instruction to models so that they end up writing high quality code. I also have the knowledge to manually fix code that models generate.
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.
> We already have a phrase for code that nobody understands: legacy code.
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.
This definition doesn't make any sense to me. If code at an org is working, and there are people or at least a person at that company that understands it, how is it legacy? Just because it's been around for a while? At what age according to your definition, does perfect working code that can be improved or added to by currently employed developers, become "legacy"? I feel like you are falling into the "keeping up with the Jones'" trap.
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.
The problem with the definition is that if a business has some ancient COBOL code with one guy left who understands it, then your definition would say that is not legacy code. And that is what makes no sense.
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.
Okay, I could get behind that definition if you could tell me what you call code that aligns perfectly with the "strategic future of the organization" but nobody at said company understands or can work on?
Critical magic
It becomes legacy once the organization understands that the codebase, or platform, or business case, is obsolete. It does not mean it's immediately phased out; it may continue working for decades more with some love and attention, but it's clear that it is in the past rather than the future. The easiest way to tell if a project is legacy is how desirable it is for programmers in the company to work on.
I wouldn't get too persnickety about definitions. There are lots of arguments about what 'legacy' code means. you are throwing around the term quite a bit without really giving any definition at all. 'Code that nobody understands' is fine as a quick and dirty pointer.
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.
The post is trying to define vibe coding, so the definition of things is highly relevant.
I didn't get out of the post a focus on definitions as the main point. I got out of the post a concern about massive technical debt, which is the hallmark of both legacy code and vibe coding. And no, I'm not offering a definition.
> 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.
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
Peter Principle for codebases - codebase will continue to grow until nobody understands it, and then it will tread water until enough key personnel leave and then suddenly eng capacity is below the cost of servicing the debt and this is the point at which all control is fully lost. Eventually a younger sharper competitor will acquire it for the users or it will go through M&A repackaging or some other way to extract the last drops of money before discarding it
> People do understand it. Often, deeply understand it because they wrote it, and have lived and supported it for years.
You're assuming the people that wrote it are still there, which is often not the case.
"the more you understand the less you are vibing" also works as a philosophical claim, and a truthful one in the opinion of this one reader.
After 30 years of writing code myself, i am quite happy to let AI do the bulk.
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 ;)
The difference is that legacy code has some certainty to actually work and be correct to the business logic. Vibe code has none...
Is the argument that it's better to start from an empty code editor than having AI create a working first version?
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.
The argument is that if you intent to maintain the code you should keep the AI on a very tight leash, and at least understand the architecture of the code, if not every line.
This is good advice for any code contribution. Current AI is definitely not better than the best programmers, but is often better than junior programmers (who often carry a "senior" title now).
Vibe code may be "disposable," but isn't "legacy code" if it has automated tests that the product owner can read and understand.
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."
Have you seen the tests that LLMs write if you just vibe code it and don't pay attention? They're generally worse than worthless. They test pointless stuff and they miss important stuff. If you have them on a tight leash, then you can get some useful tests, but then that's not vibe coding.
> 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.
In the long run that's the promise of RL; build the verifications vs the model. As a SWE we could be relegated to doing what many consider the "boring part" of software development, which is just writing case by case test cases rather than the code/model of the world interaction. The "math/intellectual" part may get rarer which sadly devalues the skill/intelligence part of software development assuming the AI can come up with a code model that meets requirements.
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.
I will vibe code functions that I fully understand how to program if I'm otherwise occupied and I want it to run in the background. A quick glance confirms the implementation is as expected
Pay as you go non-deterministic Chesterson's fence factories. Sometimes that's fine.
I love using Claude Code. What happens is if your codebase is bad, Claude will produce bad code which follows the same general approach.
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.
I don't agree with this, my code quality is much better now. But you have to stay on the LLM's ass in terms of guidance and review it all (this is a given). I think part of it is the LLMs writes more "standard" code instead of getting creative with architecture, etc. It helps to create guides and correct context, proper test coverage just as you would if working with other people.
"I don't agree with this, my code quality is much better now. But you have to stay on the LLM's ass in terms of guidance and review it all (this is a given)."
Sounds to me like you're not vibe coding, you're coding. https://simonwillison.net/2025/Mar/19/vibe-coding/
> review it all (this is a given)
that's great but that's not what vibe coding is though
Coding with AI is just a different kind of work than what those of us that coded before AI are used to doing. But, reading and understanding the code AI produces is required for anything complex. I had an inventory control app that I started five years ago without AI and picked the project back up this year. I had like 15-20 database tables in the app when I started with AI this year. Now, I have a "platform" database, a "tenant" database, about 125 tables in the tenant database and 30 in the platform database, full test suite that integrates both databases, like 100 services, etc., it would have taken me *YEARS AND YEARS* to do what I've done in the last 90 days with AI assistance. The biggest challenge has just been keeping up with all the code output and ensuring no technical debt accrues and it is all leveraging existing code. Ultimately, you have to understand what you've already built to ensure the AI uses it instead of constantly reinventing it. But, generating what would have taken years of my life in a few months? PRICELESS.
I’ve been coding a git-powered issue tracker (like git-bug) that’s been on my wishlist for years.
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.
I think the real risk isn't AI-generated technical debt, but the opportunity cost of not adapting fast enough.
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.
I think the quality of the code is going to be based on the skill of the person using the AI agent. An engineer knows a pyramid of doom pattern is bad, a non programmer would not. Engineers understand modularity and seperation of concerns, non programmers don't.
An engineer can guide an agent to write good, modular code, but a non programmer can't.
a meme I heard 15 years ago is:
What’s the definition of “Legacy Code”? It’s code that has business value.
(otherwise you’d just delete it and move on)
Yes, if your code does not live long enough to become legacy ... the project failed. All good code is (or will be) legacy code by definition. Most companies and projects die because nobody cares about them, not because they were difficult to maintain.
If the code will be reviewed from the LLM of the future, then why does it matter? Let it review a trillion lines of code for a simple calculator app.
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.
The vast majority of people cannot do the structured thinking to model the real world in a fashion that a computer can understand. That is a key attribute of a good dev. If someone can do this, and describe it well enough to a LLM, they are a dev. It's not devs that will be taken out of the loop, unless you define a dev as someone who is just a translator between human language and machine code.
The LLM + agentic framework supplements many core dev skills including sporadic habits of tirelessly testing things, spec-driven development (thinking what you’re gonna make before you do), and debugging.
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.
I would like to say I did a massive refactoring on a legacy project only to make separation of concerns by making a DB access layer with multiple backends just so I could test it. I wrote not even a single line of code. It did a fantastic job even abstracting between both databases. I was shocked. It then was a huge PR so I had it redo it in a step by step fashion and maintain the tests passing at each step so I could split it into 5 different pull-requests. This vibe-coded project did the exact opposite, it made it easy and possible to fix a mostly intested and poorly organized project far better. You can use this stuff for good SWE practices too
I think most software is extremely buggy and it’s about to get much worse… just today several comments just disappeared from YouTube, did they even get written there? Uber has a whole feature about upgrading to Uber Comfort - it’s never worked once for me just gives an error. Three have managed to not take PAYG top up automatically for the nth time. Google’s UI is broken everywhere, loads of sites including John Lewis don’t seem to scroll on my iPhone 15 Pro Max and the camera still doesn’t work correctly in WhatsApp (macro mode is not automatic) and don’t get me started on how buggy Dynamic Island is etc. etc.
There’s just shit buggy software everywhere now and I’m definitely not expecting AI to make the way we build things better.
https://danluu.com/everything-is-broken/
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.
> 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?
I actually foreshadowed this about 6 months ago when Lovable was starting to gain heat here in Sweden. It was quite obvious that for a start and prototype, these kind of applications are good. But if you are going full SaaS, hire an engineer to set the app in stone.
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.
Legacy code may be very different - I saw legacy libraries implemented in C, with macros APIs that just worked.
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.
I think that in the near future, code itself will become abstracted away. High-level programming code will simply become the assembly or machine code of today.
Interesting times ahead for sure.
The fundamental issue is that most AI tools are solving the wrong problem. We've never had a hard time writing code for well defined requirements.
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.
That is a great insight, AI code is like legacy code, which is "legacy" because it was written long time ago and hasn't been worked on by anybody, so nobody knows and it is hard to learn how the code does its thing.
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?
My two insights are:
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.
Good point. Whys are lost because whys are often never written down. World around us always changes, so the whys change too.
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.
That’s already addressed in the article; it’s like paying off credit card debt with another credit card.
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.
When you have 100+ tables and 100k+ loc you’re incapable of the context needed to write features without bugs which is why we have tests. LLMs are capable of like 5% of the context you are:
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.
I agree and we should be sceptical in ways we really aren't right now. But I also think that it is interesting to figure out when "vibe-like" coding works and how it can be made more useful.
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.
We’ve gone from tiny context windows to 1 million tokens in a couple of years. At this rate LLMs will exceed human context and grow to have full context.
Well, all code once written is legacy code. But at least if written by a human you can talk sensibly to someone about it.
Idk, I always felt the vibe even more when I did understand what's was going on. Maybe that's not in the spirit of how the term was coined but still, it's way more satisfying when you can use these tools in a state of both flow and competence.
Great analogy!
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.
This is really clear and well argued. I particularly enjoyed this line:
> 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.
This is a super apt analogy. Every time I decided to let LLMs “vibe-fix” non-obvious things for the sake of experiment, it spiraled into an unspeakable fubar territory, which needed to be reverted - a very similar situation to this financial collapse.
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.
I'm now following your advice and just telling LLMs, "Do better." Although I have to admit, the other day I lost it and said, "Fix it goddammit or I'll delete you!"
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 :)
Thanks Simon!!
I've found that the real issue with "vibe coding" isn't that it's inherently bad, but rather that it highlights a deeper problem: our industry's obsession with explicit, step-by-step documentation.
All production code will be written by AI. The question is not if. It is WHEN.
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.
Statistically salient answers are not necessarily correct.
Real "AI" may happen some day, but it is unlikely going to be an LLM. =3
I’m also surprised at the progress but don’t quite share the “AI is doing a good job” perspective.
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.
LLMs are doing a great job at generating syntactically correct output related to the prompt or task at hand. The semantics, hierarchy, architecture, abstraction, security, and maintainability of a code base is not being handled by LLMs generating code.
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.
Yeah I think its over, it will take a while for the effects to ripple through society, but writing code will be seen as something like wood working
I'm more curious how society will look when half the population is living in tents.
what a time to be alive!
"all computer engineering will be replaced by software"
"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 often find that the hard part of writing big, persistant, code is not the writing but the building of a mental model (what the author calls "theory building"). This challenge multiplies when you are working with old code, or code others is working on.
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.
If you vibe coded it, why can’t you vibe support it?
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.
Because support requires understanding. If you can maintain long-term context for the LLM, then you have an approximation of actionable institutional knowledge.
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.
You can have the LLM generate whatever context you need- documentation, developers guide, design patterns, whatever. You can have it do this, at the time you create the app, or later (I have done this for other peoples code I found on GitHub that was commented in a language I can’t speak). You store this by having your LLM coding agent write it down in a file. I do that all the time. It works really well.
And if you have some kind of special case or something, the LLM will usually comment it when it writes it, but you can also just tell it to do so.
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.
I’ll never cease to be amazed about this industry. Programming for the web is a thing, sure. I’ve made a small fortune having never written a single line of JavaScript.
The ecosystem is bigger than the internet.
If we accept that as true, them why have it generate Python and JavaScript? why not have it generate assembly, and reap some performance benefits?
As a freelance designer/developer, one of the most annoying aspects about dealing with non-technical clients is dealing with their ambiguous ideas, which they communicate using very general and abstract words. At most, they’ll point to another idea that looks/functions like how they want their own idea to look/function.
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.
Someone should just create an app (*open-source ideally ) that stress-tests these vibe apps for security penetration risks and offers mitigation solutions.
One of my current clients vibe coded an app then hired me to assess it, and ultimately rewrite it.
I'm really curious whether that will become a trend.
A dozen years ago a company hired me to maintain an ecommerce system that had been built for them by a guy that left soon after. They told me "he is not even a developer." That was my assessment too. The system mostly worked but it didn't run fast enough to process their daily load. It was a mess but it would cost too much to rewrite. I managed to fix the worst parts, then switched to other customers. No idea if they found somebody else to keep fixing stuff.
They kind of vibe coded that app well before vibe coding had been a thing.
I guess when you put it like that there is a long history of production systems being built by people who had no business doing it. An access database running a whole company etc.
A friend of mine was doing modelling (as in, being a model) in a large European city. He then worked as a product manager for a well-known luxury company. He ended up writing a system in visual basic that was responsible for a large amount of internal plumbing. He had no experience in programming.
The problem I have with this post is that it equates vibe coding with stupidity. You don't have to be stupid to be a vibe coder, and you can actually do things smarter than a traditional coder ... if you take the time to learn how to do it. His mistake wasn't being a vibe coder. His mistake was in not learning the proper way to connect it via API and failing to use tools to check the security.
You can also vibe tackle tech debt tho. AI is pretty good at deciphering code for you when you need to jump into it.
All code is legacy code. As soon as you write it (no matter how) - it’s legacy. You need to maintain it.
That's a broader definition of legacy than I’ve usually seen used; usually, “legacy code” is a fuzzy categort of code that lacks some significant subset of the maintainability properties expected as the norm in the category of “existing, actively maintained code”, such that issues in that code requiring working around the code, replacing code units wholesale, or expending extra effort research, document, develope tests for, or otherwise bring the code into a maintainable state to enable diagnosing and resolving issues with it.
This reminds me of a different phrase: every piece of untested code is legacy code.
One of the best takes on vibe coding yet. Amazing writing, like always.
All code is legacy code eventually.
Some code makes you aware of the limited shelf life of code.
coding needs to fade away altogether. it’s inhumane. for humanity’s sake i hope it keeps on fading and becomes legacy as a whole, as far as humans are concerned
interesting but i have thought about it. rarely is ours as well. All my code is original but based on my past experiences from learning, thinking about it, and improving it based on new knowledge i know. my 2cents.
I have the same feeling about dynlang code.
it's not such a binary. we all of us, software developers, are using AI every day now. It's one of our tools and we're staying present for at, sensing its energy. we let it run wild and get bored watching it work. Whatever it does is miraculous, even if it will take as long to fit it into your big project as it would have taken to write it on your own. and then you'd have a better understanding of your tools, your product, maybe even your customer.
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.
I call bullshit on this article and most of its arguments. The article was written out of fear felt as programmers' gate keeping falls apart and programming becomes generally more available to the broader auditory.
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!
The article is also just an ad for their product
sometime before 2026: "Hey Claude, rewrite all your code to make it look like you weren't vibe coding"
programming as theory building mentioned
all code is legacy code; git repos are mausoleums
> 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.
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?
we need a mandatory warning label for any services that were vibe coded.
I really don't want to sign up for a service and then get my shit leaked immediately
It will be interesting to see when this inverts - when it becomes scary to use an application that has only had humans review it and declare it safe and secure.
Oh great. Another article about vibe-coding....
Slop in, Slop out...
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
Just have AI deal with this legacy bs so I don’t need to look at it.