Vibe code is legacy code
440 comments
·July 30, 2025CharlieDigital
WD-42
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.
bartread
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.
pydry
>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.
graemep
> 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.
eddythompson80
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.
JackFr
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.
achierius
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.
benterix
> 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.
phatskat
> 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.
WJW
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.
jamesfinlayson
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.
exe34
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.
null
CharlieDigital
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
doix
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.
chillfox
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.
anamexis
I don't see how any of that implies that an incumbent did it.
8note
what was in this email though?
csomar
Please don't consider becoming a judge. Also, try re-reading what you wrote a few times.
doesnt_know
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.
__MatrixMan__
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.
gowld
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.
woooooo
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.
cguess
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
stouset
The difference is we didn’t know any better back then. We do now.
atleastoptimal
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.
Frieren
> 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.
rsynnott
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.
pishpash
That's always the double-edged sword with regulation, but sooner or later people will demand it, or much more of it.
parliament32
...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.
kalaksi
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).
conradfr
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.
null
null
dashdotme
> 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.
CharlieDigital
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.
BoxOfRain
>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.
randmeerkat
> 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…
oc1
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.
zerotolerance
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.
phyzix5761
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.
returnInfinity
yes exactly, branding, marketing and market share matters.
graemep
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.
CharlieDigital
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.
bschwindHN
> 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!
Ferret7446
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
darick
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.
null
pishpash
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.
sublinear
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.
Ekaros
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.
NoGravitas
> 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.
rainonmoon
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.
CharlieDigital
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.
lelanthran
> 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 ....
gowld
In a few months, his customers will be vibe-coding that app for themselves.
mschild
> 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.
willjp
> 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.
rainonmoon
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.
esulteric
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.
tux1968
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.
Cthulhu_
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).
lonelyasacloud
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 ...
Sateeshm
My company still has internal sites that work only on windows
apimade
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%.
QuiDortDine
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.
AlecSchueler
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?
fc417fc802
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.
chrisrogers
One of the implementations underwent analysis.
minaguib
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.
rolha-capoeira
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.
extr
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.
skydhash
> 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.
lifeformed
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.
lmm
> 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.
kidbomb
// When I wrote this code, only Copilot and I understood what I did. Now only Copilot knows.
dehrmann
> 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.
trip-zip
> 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...
emehex
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!
oc1
> Cost: $50K of API tokens
What? It costs exactly $200
bdangubic
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 :) )
vlovich123
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.
raincole
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.
ZeroGravitas
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".
roywiggins
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!
qingcharles
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.
Arubis
Yep. The humorous definition of legacy code is anything merged to trunk.
cadr
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.
dneighbo
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.
sysmax
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...
danielbln
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).
sysmax
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.
stevage
Do you do anything special to get it follow your preferred style?
sysmax
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.
msephton
In my experience it will follow quite closely to the style of any seeded code. And you can also pass it a style guide!
pyman
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.
ravenstine
> 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.
ryandv
> 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.
mirkodrummer
> 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
JohnMakin
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.
bluefirebrand
> 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
JohnMakin
same
sidewndr46
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.
cookiengineer
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.
Joel_Mckay
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
calrain
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.
nyarlathotep_
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.
0x500x79
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.
AdieuToLogic
> 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].
null
omgwalt
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.
MrGilbert
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.
NitpickLawyer
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.
MrGilbert
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.
NitpickLawyer
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.
sshine
It’s a spectrum.
I care when it doesn’t just work.
I hardly look when it does.
alzoid
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.
phplovesong
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.
phire
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"
usui
What are you referring to with PHP dev copypasta from Stack Overflow?
Karawebnetwork
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.
hibikir
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.
exasperaited
> 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.
asadotzler
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.
ggregoryarms
I find this a bit like saying that we can't understand East of Eden because Steinbeck is dead.
astrobe_
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.
xwolfi
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 ?
stevekrouse
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.
skydhash
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.
stevekrouse
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...
WD-42
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.
mrits
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)
lawlessone
The argument against this can be summed up as throwing more data, training and gpu's at the problem until it works again.
mrits
Knowing if it is actually working or not is half the problem.
croes
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
skydhash
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.
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.