[HN Gopher] Vibe code is legacy code
___________________________________________________________________
Vibe code is legacy code
Author : simonw
Score : 172 points
Date : 2025-07-30 21:13 UTC (1 hours ago)
(HTM) web link (blog.val.town)
(TXT) w3m dump (blog.val.town)
| pyman wrote:
| 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.
| JohnMakin wrote:
| 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 wrote:
| > 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 wrote:
| same
| ryandv wrote:
| > 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
| msgodel wrote:
| 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.
| mirkodrummer wrote:
| > 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
| ravenstine wrote:
| > 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.
| reactordev wrote:
| 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.
| cookiengineer wrote:
| 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.
| exasperaited wrote:
| > And a product is not the same as an MVP
|
| Hahaha you're funny :-)
| calrain wrote:
| 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.
| stevekrouse wrote:
| Author here - very excited to chat with you all about this :)
| hibikir wrote:
| 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.
| mrits wrote:
| 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 wrote:
| The argument against this can be summed up as throwing more
| data, training and gpu's at the problem until it works again.
| mrits wrote:
| Knowing if it is actually working or not is half the
| problem.
| lawlessone wrote:
| Vibe Validation :D
|
| Just ask the model.
| croes wrote:
| 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 wrote:
| 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.
| stevekrouse wrote:
| 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 wrote:
| 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 wrote:
| 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...
| skydhash wrote:
| 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.
| WD-42 wrote:
| 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.
| exasperaited wrote:
| > 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 wrote:
| 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.
| simonw wrote:
| 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.
| stevekrouse wrote:
| Thanks Simon!!
| pyman wrote:
| 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 :)
| ay wrote:
| 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.
| MrGilbert wrote:
| 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 wrote:
| 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.
| zabzonk wrote:
| Well, all code once written is legacy code. But at least if
| written by a human you can talk sensibly to someone about it.
| henriquegodoy wrote:
| 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."
| codingdave wrote:
| > 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.
| bluefirebrand wrote:
| > 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
| WD-42 wrote:
| 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.
| codingdave wrote:
| 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.
| WD-42 wrote:
| 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?
| flyinglizard wrote:
| 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.
| cortical_iv wrote:
| 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.
| benatkin wrote:
| The post is trying to define _vibe coding_ , so the
| definition of things is highly relevant.
| dustingetz wrote:
| 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
| wubrr wrote:
| > 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.
| xnx wrote:
| 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.
| stevekrouse wrote:
| 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.
| xnx wrote:
| 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).
| iambateman wrote:
| 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.
| airstrike wrote:
| I mean, that's why Windsurf and the like exist. Claude can
| navigate through the codebase in those environments and do more
| dabber21 wrote:
| 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
| dweekly wrote:
| 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.
| tux1968 wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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.
| stevekrouse wrote:
| 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
| ChrisMarshallNY wrote:
| 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.
| 8thcross wrote:
| 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.
| extr wrote:
| 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.
| trip-zip wrote:
| > 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...
| skydhash wrote:
| > _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.
| kidbomb wrote:
| // When I wrote this code, only Copilot and I understood what I
| did. Now only Copilot knows.
| emehex wrote:
| 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!
| jes5199 wrote:
| 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)
| ridruejo wrote:
| 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.
| whatever1 wrote:
| 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.
| zizee wrote:
| 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.
| bobjordan wrote:
| 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.
| user3939382 wrote:
| 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.
| worldsayshi wrote:
| 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.
| cpursley wrote:
| 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.
| drdrey wrote:
| > review it all (this is a given)
|
| that's great but that's not what vibe coding is though
| strogonoff wrote:
| 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.
| khaledh wrote:
| 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
| hugs wrote:
| "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.
| andy_ppp wrote:
| 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.
| worldsayshi wrote:
| > 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?
| mr_donk wrote:
| 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.
| khaledh wrote:
| 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.
| mr_donk wrote:
| yeah, that's probably more along the lines of what I was
| thinking, actually, you just worded it better :)
| adriand wrote:
| I think it will just be the AI. "Hey AI, be a CRM please."
| Done.
| ge96 wrote:
| Wasn't there a word doc to code
| genewitch wrote:
| 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.
| simonw wrote:
| 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.
| CharlieDigital wrote:
| 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.
| starkparker wrote:
| > 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?
| CharlieDigital wrote:
| Currently only equity.
|
| And it only works because has proven the revenue model and
| found the customers already.
| singpolyma3 wrote:
| 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
| keerthiko wrote:
| Likely still cheaper than whatever these competitors have
| spent building their product and then hiring blackhat
| saboteurs.
| Joel_Mckay wrote:
| I wonder of people do that sort of thing..
|
| Generally bandits are not interested in sparing anyone. =3
| Joel_Mckay wrote:
| He can expect 5 times what he would have paid the first time
| with a proper specification...
|
| =3
| mrmincent wrote:
| 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.
| isaacvando wrote:
| programming as theory building mentioned
| jus3sixty wrote:
| Cool story bro...
| TrackerFF wrote:
| 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.
| arduanika wrote:
| Wait, didn't all the code already get abstracted away back in
| the year of the Linux desktop?
| Joel_Mckay wrote:
| 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 posers that rely on LLM. The age of Spam
| exceeding content is upon us. =3
| matt_cogito wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-30 23:00 UTC)