7 ms·

I had an Iron Man moment last week where I was “vibe coding” a UI design with component tests live on the other screen. Iterating by asking it to move things, r

I had an Iron Man moment last week where I was “vibe coding” a UI design with component tests live on the other screen. Iterating by asking it to move things, reduce emphasis of an element, exploring layout options, etc. The loop was near realtime and felt amazing. The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer). And then I had a reference design and I manually implemented it with better code (the part I am good at).

snarf21 5mo ago
I feel the same but the question I struggle most with is this: "Does it matter when the people who are going to come along and maintain this are just going to use AI to fix or adjust this maintenance nightmare?"
- Waterluvian 5mo ago
  At that point the code becomes a compile target, and then you need a new source of truth. Which I think is perfectly worthy of exploration. Some people want to check in the prompts. Or even better, check in a plan.md or evenest betterest: some set of very well-defined specifications. I'm not sure what the answer will be. Probably some mix of things. But today it is absolutely imperative that the code I write for the case I wrote it in is good quality and can be maintained by more than just me.
  - user34283 5mo ago
    I don't see the benefit of checking in either prompts or specs. I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines. And there are hundreds of lines, nearly always with major inaccuracies. For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works. When I want to add more functionality or change it, I just tell the agent what I want changed. I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.
    - macintux 5mo ago
      I value traceability, and I value understanding the "why" of the code. For me, the prompts are useful for both.
    - gbear0 5mo ago
      Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.
      - jmcodes 5mo ago
        Do you rewrite the specs with new requirement changes if they've already been implemented? How do you supercede a spec? I've been using LLMs daily and I spun up a few spec driven flows once or twice but like the person above I think the code is the source of truth. Also why wouldn't you use TDD to enforce the 'spec' then?
  - ff317 5mo ago
    When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others). It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output? Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown. If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos. And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).
  - Shorel 5mo ago
    > At that point the code becomes a compile target, and then you need a new source of truth. The problem is that there won't be a single source of truth left. Everything will have to be reverse engineered each time, which is extremely wasteful in my opinion.
- flyinglizard 5mo ago
  The problem is that technical debt is compounding. Bad LLM architectural and implementation decisions just blend in to the background and you build layer upon layer of a mess. At some point it becomes difficult and expensive (token wise) to maintain this code, even for an agent. I mitigate this by few things: 1. Checkpoints every few days to thoroughly review and flag issues. Asking the LLM to impersonate (Linus Torvalds is my favorite) yields different results. 2. Frequent refactors. LLMs don't get discouraged from throwing things out like humans do. So I ask for a refactor when enough stuff accumulates. 3. Use verbose, typed languages. C# on the backend, TypeScript on the frontend. Does it produce quality code? Locally yes, architecturally I don't know - it works so far, I guess. Anyway, my alternative is not to make this software I'm writing better but not making it at all for the lack of time, so even if it's subpar it still brings business value.
- mehagar 5mo ago
  Same. Messy code makes it harder for us to understand and thus maintain the code (which is why people often refer to code as a liability), but is that the case for AI tools as well? If not, it seems like clean code may not matter as much anymore.
- n_e 5mo ago
  The problem with crappy frontend code is not only the maintenance. It's that stuff such as responsive design, accessibility or cross-browser compatibility that work nearly for free with elegant code won't work at all.
worldsayshi 5mo ago
> The code it generated was awful. I suppose you could solve that in two ways. Manually rewrite it as you did. Or formalize an architecture and let the AI rewrite it with that in mind. I suspect that either works.
- bentcorner 5mo ago
  I suspect at some point AI-written code will be eventually artifacts generated build-to-build. The design docs and UI tests are the source and the model follows instructions to generate the product. If you make the models deterministic then model improvements give you code improvements across your entire codebase "for free".
the__alchemist 5mo ago
Tangent: I never learned how to make the sorts of websites people find "professional" or "pretty" I could make functional and easy-to-use webapps, but not something people would think looks good or like something they would want to use. LLMs crushed this, without performance overhead; can still be HTML/CSS/targetted JS.
dylan604 5mo ago
> But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer). I'm not a designer either, but I've been around designers long enough to recognize when something is bad but just not know what is needed to make it better/good. I've taken time to find sites that are designed well and then recreated them by hand coding the html/css to the point that I consider myself pretty decent at css now. I don't need libraries or frameworks. My css/html is so much lighter than what's found in those frameworks as well. I still would not call myself a designer, but pages look like they were designed by a mediocre designer rather than an engineer :shrug:
akersten 5mo ago
> The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked up, if it works it works and if it stops working tell the AI to fix it. It's kind of liberating I guess. I'm not sure if I've reached AI nirvana on accepting this yet, but I do think that moment is close.
- m463 5mo ago
  > "write-only code" so... perl?
- simmerup 5mo ago
  The problem is it’s impossibly hard to test all the edge cases Which is probably why so many random buttons in microsoft/apple/spotify just stop working once you get off the beaten path or load the app in some state which is slightly off base
  - disgruntledphd2 5mo ago
    Yeah, the biggest thing I've noticed from LLMs is that large tech products now have even more bugs. Turns out the humans weren't so bad after all...
    - michaelcampbell 5mo ago
      > Turns out the humans weren't so bad after all... The people pushing AI _over_ humans never thought they were. They just don't care about 'good' or 'bad', only 'time-to-market'. A bad app making money is better than a good one that isn't deployed yet. And who cares about anything past the end of the quarter? That's the next guy's problem.
      - deleted 5mo ago
        [deleted]
jvanderbot 5mo ago
I wonder how much of this is momentum. At the moment, we understand the basic tech, could reasonably DIY, but choose not to knowing full well there's a mess of understandable code somewhere we could go clean up but dont want to. We accept fast iterations because we know roughly the shape of how it "should be" and can guide an automated framework towards that. This is especially true on our own projects or something we built originally! Stark/Iron man knew/moved, the suit assisted by adding momentum. We're riding our "knowledge momentum". If companies can hold out long enough, that knowledge completely fades, and the tool is all you have. At that point, they are locked in. Then it's not Iron man, it's an Iron lung (couldn't resist!)
- Waterluvian 5mo ago
  Yeah that’s my main concern. It feels so so easy to be lazy and do a bad job now. And then my skills weaken and what makes me valuable fades. I love the Iron lung reference. Perfect.
- lelanthran 5mo ago
  The blog post is spot on: AI is exactly like an Iron Man suit - if you never take it off your muscles will atrophy to nothing!
HikeThe46 5mo ago
If you are just blindly vibe coding without any parameters, guardrails, architecture, or broad guidance; you're going to have a mess of slop. the power comes from creating the machine you can steer. Treat AI like an over eager college intern who you need to hand hold, but do tasks.
eithed 5mo ago
That's the model I've arrived to as well: - first I've created a skill how the architecture of the system should look like - I'll tell the LLM to follow the guidelines; it will not do that 100%, but it will be good enough - I'll go through what it produced, align to the template; if I like something (either I've not thought about the problem in that way, or simply forgot) I add that to the skill template - rinse and repeat This is not only for architecture of the system, but also when (and how to) write backend, frontend, e2e tests, docs. I know what I want to achieve = I know how the code should be organized and how it should work, I know how tests should be written. LLMs allow me to eliminate the tediousness of following the same template every time. Without these guardrails it switches patterns so often, creating unmaintainable crap Bear in mind - the output requires constant supervision = LLM will touch something I told it not to touch, or not follow what I told it to do. The amount of the output can also sometimes be overwhelming (so, peer review is still needed), but at this point I can iterate over what LLM produces with it, with another LLM, then give to a human if it together makes sense
wiseowise 5mo ago
> I had an Iron Man moment Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.
- etiam 5mo ago
  He was presumably also not constructing a powered exoskeleton of from fictional materials or a physically implausible power source, but since you obviously caught the reference, how about some benevolent interpretation instead, for a decent shorthand about working smoothly with AI assistance. (And on a personal note, I'm glad we don't have a publicly released Jarvis before we get our act together about the use.)
- Supermancho 5mo ago
  >> I had an Iron Man moment > Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment. Like an LLM, you misunderstood the context. The voyeuristic experience doesn't require fiction to be reality.
gbear0 5mo ago
Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code? I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this. There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though? The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well. This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.
- otabdeveloper4 5mo ago
  > Why was it a maintenance dead end? LLMs have a limit to how deep they can understand and refactor architectural issues. That limit is far, far lower than a human's.
- ttd 5mo ago
  > the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this. This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code. I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
  - empath75 5mo ago
    Yeah I have had claude take over multiple internal (human written) projects that were in a dire state and spent a week just completely refactoring them and adding exhaustive tests before doing any new features. It's worth starting from a clean slate.
EasyMark 5mo ago
Did you try to have it clean up the code and refactor? I find while the code is usually low to mid tier that it’s a lot better than the first pass. I of course back up the working version lol. Usually I can coax something better out of it
theptip 5mo ago
We collectively have to re-learn what operations are expensive and what are cheap. Prototypes are practically free now. You can ask the AI try each architectural or stylistic option and just see which code you like better. To your point, another interesting note is that rewriting and rearchitecting are also very good. One pattern I like is to vibe code a set of solutions, pick the approach, then backfill tests and do major refactors to make it maintainable. Here the skill is knowing what good architecture looks like, and knowing how to prompt and validate (eg what level of tests will speed up the feedback cycle or enable me to make the LLM’s changes legible). To be fair the “ready, fire, aim” approach of rapid prototyping has been known for a long time, but you need to be quite quick at coding in old world for it to work well IMO.
- iwiwk 5mo ago
  Free? Lol
adjejmxbdjdn 5mo ago
Could it be that the fact that the thing you’re an expert at looked like garbage to you, but the things you’re not an expert at, looked just fine, is not a coincidence? You can talk to a bunch of designers who will say the opposite. Claude Design Studio generated this garbage UI, that I fixed manually, but it created great code j never could have that made it work.
- reactordev 5mo ago
  This is the juxtaposition the general public is in. They don’t have advanced tech skills to know any better so they see an output that they can’t produce from their skills and think it’s great. Maybe it is, maybe it isn’t. What does the code look like?
  - genxy 5mo ago
    Both had a working prototype. The flaw everyone is making is that they are over focusing on the artifact and not that they have a shared tangible object that they can both editorialize and iterate on. These systems should allow rapid iteration on discovery and thinking. One can now make a prototype a day that would have taken a week. That means that we should be able to converge on a much better design in the same amount of time it would have taken to make a v0 that turns how to have systemic flaws. AI should scale our understanding of systems, not just shovel out half baked features and apps.
    - bluejellybean 5mo ago
      Road to hell is paved with a lot of 'shoulds' reality is a very different place filled with piles of trash and half baked ideas.
  - deleted 5mo ago
    [deleted]
  - lobf 5mo ago
    This is where I’m at. I’ve always been a computer tinkerer but a novice coder at best. I work in the film industry, so I don’t need to know how to code. Where I’m at when building personal applications for my home / life is: does the code execute and perform the desired task? If so, what do I care how shitty it is? I’m not publishing these projects (for the most part… I have one joke application up at songshift.reachnick.co) so efficient, clean, secure code are not really a priority for me.
dawnerd 5mo ago
[dead]
neals 5mo ago
Very recognizable and hard to reason about! I did something similar, but while looking at the code, it looked so procedural, hardly abstract, no vision. How was I ever going to maintain this? I guess Ai will do it forever?
threethirtytwo 5mo ago
Well here's the million dollar question. It's a maintenance dead end for humans to read and edit. But for an LLM, is it a maintenance deadend? Could the LLM iterate on that same code base and be highly effective on it?
- hollowturtle 5mo ago
  Yes it is a maintenance deadend for LLMs it's notorious codebases start accumulating enormous amount of tech debt and that it gets almost impossible to unravel it even with the best agent
  - threethirtytwo 5mo ago
    I've never seen it happen. You say this and it's likely one anecdotal claim. At the same time there's counter points like Bun getting rewritten in rust. This is talk and talk is cheap. Prove it, otherwise it's still a million dollar question... unanswered. HN is notoriously mentally deficient when it comes to AI. They were wrong about self driving cars (I sit in AI cars daily), they were wrong about AI getting used for coding (I don't use an IDE or type code anymore as a SWE). So I have to say unless there's something evidence based or substantial here it's likely given HN track record that most people here will end up being another wrong, baseless and over confident answer. I'm looking for legit answers not confidently biased statements with no evidence.
    - rustyminnow 5mo ago
      Bun getting rewritten in Rust is not really the counter point you think it is. The rust version hasn't shipped yet, so there hasn't even been a chance to see if the code can be maintained. It's an impressive feat no doubt, but until they've maintained it on a months to years timeline, it's also just talk with no evidence.
      - hollowturtle 5mo ago
        His comment doesnt even seem written by him, too busy doing nothing in a self driving car while codex work for him
ios-contractor 5mo ago
I used AI to write code (features) then I used AI to refactor the architecture using best practices and get rid of the technical debt. I don't remember the last time I modified code by hand honestly.
- danielmarkbruce 5mo ago
  This is the part people are missing. I spend 30-40% of my time "vibe coding" doing "vibe clean up". It's fine, I'm still 10x more productive than I ever was.
nomel 5mo ago
> But it was instantly a maintenance dead end. I gave up on this recently. It achieved the goal now, and in a year or two, when you actually want to add whatever feature, the SOTA AI will probably be able to clean it up as it does so. What does "maintain" even mean anymore? If you don't agree, how many years into the future do we need until you would agree?
- dbingham 5mo ago
  The problem is that people keep saying this, but the code keeps being bad. Every time I commit myself to trying to build something with AI, I end up wasting a ton of time and backing it out or completely rewriting it without the AI. The code it generates just isn't where it needs to be. And people have been saying this exact thing for years now. Someone said this very thing two years ago. And we're still at the "maintenance dead end" stage. So let me flip it back on you: how many years are we going to pour an obscene amount of resources into this thing that is always going to be able to clean up its own messes "in a year or two" before we realize its a dead end (at best) and we need to be using those resources elsewhere? And, similarly, what happens to you when the SOTA AI in two years can't clean up the code it wrote for you two years ago, but people are depending on it and your still on the hook for maintaining it?
  - nomel 5mo ago
    > If you don't agree, how many years into the future do we need until you would agree? Respectfully, I asked first. ;) > before we realize its a dead end (at best) You've declared the future, which doesn't leave much room for a conversation. So, cheers!
    - dbingham 5mo ago
      > You've declared the future, which doesn't leave much room for a conversation. So, cheers! I just flipped your own rhetorical devices back on you. If you don't think they left much room for conversation, then that's a chance for you to look at yourself in the mirror and examine your own behavior ;) To honestly answer your question in good faith, it's not about years, it's about results. I don't see AI improving exponentially or even linearly. I see it's capability gains logarithmically flattening out. And it's still a ways out from actually writing maintainable code. I honestly don't believe we are going to reach this point you are saying is "a few years out" with the current architecture. We're throwing an obscene amount of resources at it and we're just not getting there. And all of this is just about the practical "does it work?" question. We're not even touching on the ethical, environmental, resource use, or societal impact questions at work here.
znpy 5mo ago
> The kind of garbage that people who don’t know any better would ship: it looked right and it worked. I feel what you write, but then again: every now and then i write small greasmonkey scripts to remove annoyances from webpages, and to do so i have to look at the html and the kind of trash you describe is already there.
onlyrealcuzzo 5mo ago
I'm trying to test if vibe coding can actually scale... And man is it painful. AI is great at creating slop that almost works. But, my god, it is terrible at following clear as day instructions on how to cleanup slop. It wrote 150k lines of code that almost works in 2 months. It's taken 1 month to delete about 2000 lines of broken architecture and fix it, and it still hasn't gotten it done, despite nonstop repeated efforts to do something not that hard. I definitely could've fixed it less time then I've spent prompting at this point (but no way I'd have gotten the other 150k lines). But doing it myself is not the point. It's to see if it can actually scale. The answer is yes... But my god is it agonizing. The creating garbage part that almost works is fun. The inevitable cleanup is not. And unfortunately I don't see this aspect materially improving in the short term. If you want it to code you something about 5-10k lines of code that's already been done 1000 times before or only slightly different, it's great. Most people want more than that.
noosphr 5mo ago
This isn't an indictment of how good AI is but how poor our tools are. We had gui makers in 1996 that made slop which allowed you to iterate in real time. They didn't need a datacenter worth of compute and a nuclear reactors worth of power to run.
- rightbyte 5mo ago
  I really miss those tools. They were magic but need for responsive design messed them up...
onion2k 5mo ago
But it was instantly a maintenance dead end. It doesn't really make sense to suggest AI can work on something any make it now and work correctly, and at the same time say it's unmaintainable. It is maintainable with AI. The real question is whether or not you're happy to ship AI-generated code that you can't modify to production unless you use AI. Few developers are there yet, plenty of non-tech people are there already. I don't know which group is actually wrong.
m463 5mo ago
I kind of wonder if we could have the equivalent of "authors" to style the code in. Sort of like LLMs can be prompted "in the style of Charles Bukowski" write blah blah maybe "in the style of core freebsd code" to make things tighter or maybe a specific git author who checks things in
kokekolo 5mo ago
So you iterated on the design but not on the code? You have to do with the code what you did with the design. Review, adjust (or ask AI to adjust), rinse, repeat. I've found that Claude can write code that's on par with what an average SE can produce, but you have to guide it. Write instructions, but also ask it to propose and assess multiple options, even ask it to run a code review and refactoring every so often. Yes, the code is unlikely to be approved by Linus Torvalds, but so is the code that's made by many humans that is still merged and shipped.
rtgfhyuj 5mo ago
[flagged]

snarf21 5mo ago

I feel the same but the question I struggle most with is this: "Does it matter when the people who are going to come along and maintain this are just going to use AI to fix or adjust this maintenance nightmare?"

Waterluvian 5mo ago
At that point the code becomes a compile target, and then you need a new source of truth. Which I think is perfectly worthy of exploration. Some people want to check in the prompts. Or even better, check in a plan.md or evenest betterest: some set of very well-defined specifications. I'm not sure what the answer will be. Probably some mix of things. But today it is absolutely imperative that the code I write for the case I wrote it in is good quality and can be maintained by more than just me.
- user34283 5mo ago
  I don't see the benefit of checking in either prompts or specs. I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines. And there are hundreds of lines, nearly always with major inaccuracies. For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works. When I want to add more functionality or change it, I just tell the agent what I want changed. I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.
  - macintux 5mo ago
    I value traceability, and I value understanding the "why" of the code. For me, the prompts are useful for both.
  - gbear0 5mo ago
    Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.
    - jmcodes 5mo ago
      Do you rewrite the specs with new requirement changes if they've already been implemented? How do you supercede a spec? I've been using LLMs daily and I spun up a few spec driven flows once or twice but like the person above I think the code is the source of truth. Also why wouldn't you use TDD to enforce the 'spec' then?
- ff317 5mo ago
  When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others). It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output? Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown. If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos. And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).
- Shorel 5mo ago
  > At that point the code becomes a compile target, and then you need a new source of truth. The problem is that there won't be a single source of truth left. Everything will have to be reverse engineered each time, which is extremely wasteful in my opinion.
flyinglizard 5mo ago
The problem is that technical debt is compounding. Bad LLM architectural and implementation decisions just blend in to the background and you build layer upon layer of a mess. At some point it becomes difficult and expensive (token wise) to maintain this code, even for an agent. I mitigate this by few things: 1. Checkpoints every few days to thoroughly review and flag issues. Asking the LLM to impersonate (Linus Torvalds is my favorite) yields different results. 2. Frequent refactors. LLMs don't get discouraged from throwing things out like humans do. So I ask for a refactor when enough stuff accumulates. 3. Use verbose, typed languages. C# on the backend, TypeScript on the frontend. Does it produce quality code? Locally yes, architecturally I don't know - it works so far, I guess. Anyway, my alternative is not to make this software I'm writing better but not making it at all for the lack of time, so even if it's subpar it still brings business value.
mehagar 5mo ago
Same. Messy code makes it harder for us to understand and thus maintain the code (which is why people often refer to code as a liability), but is that the case for AI tools as well? If not, it seems like clean code may not matter as much anymore.
n_e 5mo ago
The problem with crappy frontend code is not only the maintenance. It's that stuff such as responsive design, accessibility or cross-browser compatibility that work nearly for free with elegant code won't work at all.

worldsayshi 5mo ago

> The code it generated was awful. I suppose you could solve that in two ways. Manually rewrite it as you did. Or formalize an architecture and let the AI rewrite it with that in mind. I suspect that either works.

bentcorner 5mo ago
I suspect at some point AI-written code will be eventually artifacts generated build-to-build. The design docs and UI tests are the source and the model follows instructions to generate the product. If you make the models deterministic then model improvements give you code improvements across your entire codebase "for free".

the__alchemist 5mo ago

Tangent: I never learned how to make the sorts of websites people find "professional" or "pretty" I could make functional and easy-to-use webapps, but not something people would think looks good or like something they would want to use. LLMs crushed this, without performance overhead; can still be HTML/CSS/targetted JS.

dylan604 5mo ago

> But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer). I'm not a designer either, but I've been around designers long enough to recognize when something is bad but just not know what is needed to make it better/good. I've taken time to find sites that are designed well and then recreated them by hand coding the html/css to the point that I consider myself pretty decent at css now. I don't need libraries or frameworks. My css/html is so much lighter than what's found in those frameworks as well. I still would not call myself a designer, but pages look like they were designed by a mediocre designer rather than an engineer :shrug:

akersten 5mo ago

> The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked up, if it works it works and if it stops working tell the AI to fix it. It's kind of liberating I guess. I'm not sure if I've reached AI nirvana on accepting this yet, but I do think that moment is close.

m463 5mo ago
> "write-only code" so... perl?
simmerup 5mo ago
The problem is it’s impossibly hard to test all the edge cases Which is probably why so many random buttons in microsoft/apple/spotify just stop working once you get off the beaten path or load the app in some state which is slightly off base
- disgruntledphd2 5mo ago
  Yeah, the biggest thing I've noticed from LLMs is that large tech products now have even more bugs. Turns out the humans weren't so bad after all...
  - michaelcampbell 5mo ago
    > Turns out the humans weren't so bad after all... The people pushing AI _over_ humans never thought they were. They just don't care about 'good' or 'bad', only 'time-to-market'. A bad app making money is better than a good one that isn't deployed yet. And who cares about anything past the end of the quarter? That's the next guy's problem.
    - deleted 5mo ago
      [deleted]

jvanderbot 5mo ago

I wonder how much of this is momentum. At the moment, we understand the basic tech, could reasonably DIY, but choose not to knowing full well there's a mess of understandable code somewhere we could go clean up but dont want to. We accept fast iterations because we know roughly the shape of how it "should be" and can guide an automated framework towards that. This is especially true on our own projects or something we built originally! Stark/Iron man knew/moved, the suit assisted by adding momentum. We're riding our "knowledge momentum". If companies can hold out long enough, that knowledge completely fades, and the tool is all you have. At that point, they are locked in. Then it's not Iron man, it's an Iron lung (couldn't resist!)

Waterluvian 5mo ago
Yeah that’s my main concern. It feels so so easy to be lazy and do a bad job now. And then my skills weaken and what makes me valuable fades. I love the Iron lung reference. Perfect.
lelanthran 5mo ago
The blog post is spot on: AI is exactly like an Iron Man suit - if you never take it off your muscles will atrophy to nothing!

HikeThe46 5mo ago

If you are just blindly vibe coding without any parameters, guardrails, architecture, or broad guidance; you're going to have a mess of slop. the power comes from creating the machine you can steer. Treat AI like an over eager college intern who you need to hand hold, but do tasks.

eithed 5mo ago

That's the model I've arrived to as well: - first I've created a skill how the architecture of the system should look like - I'll tell the LLM to follow the guidelines; it will not do that 100%, but it will be good enough - I'll go through what it produced, align to the template; if I like something (either I've not thought about the problem in that way, or simply forgot) I add that to the skill template - rinse and repeat This is not only for architecture of the system, but also when (and how to) write backend, frontend, e2e tests, docs. I know what I want to achieve = I know how the code should be organized and how it should work, I know how tests should be written. LLMs allow me to eliminate the tediousness of following the same template every time. Without these guardrails it switches patterns so often, creating unmaintainable crap Bear in mind - the output requires constant supervision = LLM will touch something I told it not to touch, or not follow what I told it to do. The amount of the output can also sometimes be overwhelming (so, peer review is still needed), but at this point I can iterate over what LLM produces with it, with another LLM, then give to a human if it together makes sense

wiseowise 5mo ago

> I had an Iron Man moment Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.

etiam 5mo ago
He was presumably also not constructing a powered exoskeleton of from fictional materials or a physically implausible power source, but since you obviously caught the reference, how about some benevolent interpretation instead, for a decent shorthand about working smoothly with AI assistance. (And on a personal note, I'm glad we don't have a publicly released Jarvis before we get our act together about the use.)
Supermancho 5mo ago
>> I had an Iron Man moment > Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment. Like an LLM, you misunderstood the context. The voyeuristic experience doesn't require fiction to be reality.

gbear0 5mo ago

Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code? I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this. There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though? The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well. This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.

otabdeveloper4 5mo ago
> Why was it a maintenance dead end? LLMs have a limit to how deep they can understand and refactor architectural issues. That limit is far, far lower than a human's.
ttd 5mo ago
> the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this. This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code. I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
- empath75 5mo ago
  Yeah I have had claude take over multiple internal (human written) projects that were in a dire state and spent a week just completely refactoring them and adding exhaustive tests before doing any new features. It's worth starting from a clean slate.

EasyMark 5mo ago

Did you try to have it clean up the code and refactor? I find while the code is usually low to mid tier that it’s a lot better than the first pass. I of course back up the working version lol. Usually I can coax something better out of it

theptip 5mo ago

We collectively have to re-learn what operations are expensive and what are cheap. Prototypes are practically free now. You can ask the AI try each architectural or stylistic option and just see which code you like better. To your point, another interesting note is that rewriting and rearchitecting are also very good. One pattern I like is to vibe code a set of solutions, pick the approach, then backfill tests and do major refactors to make it maintainable. Here the skill is knowing what good architecture looks like, and knowing how to prompt and validate (eg what level of tests will speed up the feedback cycle or enable me to make the LLM’s changes legible). To be fair the “ready, fire, aim” approach of rapid prototyping has been known for a long time, but you need to be quite quick at coding in old world for it to work well IMO.

iwiwk 5mo ago
Free? Lol

adjejmxbdjdn 5mo ago

Could it be that the fact that the thing you’re an expert at looked like garbage to you, but the things you’re not an expert at, looked just fine, is not a coincidence? You can talk to a bunch of designers who will say the opposite. Claude Design Studio generated this garbage UI, that I fixed manually, but it created great code j never could have that made it work.

reactordev 5mo ago
This is the juxtaposition the general public is in. They don’t have advanced tech skills to know any better so they see an output that they can’t produce from their skills and think it’s great. Maybe it is, maybe it isn’t. What does the code look like?
- genxy 5mo ago
  Both had a working prototype. The flaw everyone is making is that they are over focusing on the artifact and not that they have a shared tangible object that they can both editorialize and iterate on. These systems should allow rapid iteration on discovery and thinking. One can now make a prototype a day that would have taken a week. That means that we should be able to converge on a much better design in the same amount of time it would have taken to make a v0 that turns how to have systemic flaws. AI should scale our understanding of systems, not just shovel out half baked features and apps.
  - bluejellybean 5mo ago
    Road to hell is paved with a lot of 'shoulds' reality is a very different place filled with piles of trash and half baked ideas.
- deleted 5mo ago
  [deleted]
- lobf 5mo ago
  This is where I’m at. I’ve always been a computer tinkerer but a novice coder at best. I work in the film industry, so I don’t need to know how to code. Where I’m at when building personal applications for my home / life is: does the code execute and perform the desired task? If so, what do I care how shitty it is? I’m not publishing these projects (for the most part… I have one joke application up at songshift.reachnick.co) so efficient, clean, secure code are not really a priority for me.

dawnerd 5mo ago

[dead]

neals 5mo ago

Very recognizable and hard to reason about! I did something similar, but while looking at the code, it looked so procedural, hardly abstract, no vision. How was I ever going to maintain this? I guess Ai will do it forever?

threethirtytwo 5mo ago

Well here's the million dollar question. It's a maintenance dead end for humans to read and edit. But for an LLM, is it a maintenance deadend? Could the LLM iterate on that same code base and be highly effective on it?

hollowturtle 5mo ago
Yes it is a maintenance deadend for LLMs it's notorious codebases start accumulating enormous amount of tech debt and that it gets almost impossible to unravel it even with the best agent
- threethirtytwo 5mo ago
  I've never seen it happen. You say this and it's likely one anecdotal claim. At the same time there's counter points like Bun getting rewritten in rust. This is talk and talk is cheap. Prove it, otherwise it's still a million dollar question... unanswered. HN is notoriously mentally deficient when it comes to AI. They were wrong about self driving cars (I sit in AI cars daily), they were wrong about AI getting used for coding (I don't use an IDE or type code anymore as a SWE). So I have to say unless there's something evidence based or substantial here it's likely given HN track record that most people here will end up being another wrong, baseless and over confident answer. I'm looking for legit answers not confidently biased statements with no evidence.
  - rustyminnow 5mo ago
    Bun getting rewritten in Rust is not really the counter point you think it is. The rust version hasn't shipped yet, so there hasn't even been a chance to see if the code can be maintained. It's an impressive feat no doubt, but until they've maintained it on a months to years timeline, it's also just talk with no evidence.
    - hollowturtle 5mo ago
      His comment doesnt even seem written by him, too busy doing nothing in a self driving car while codex work for him

ios-contractor 5mo ago

I used AI to write code (features) then I used AI to refactor the architecture using best practices and get rid of the technical debt. I don't remember the last time I modified code by hand honestly.

danielmarkbruce 5mo ago
This is the part people are missing. I spend 30-40% of my time "vibe coding" doing "vibe clean up". It's fine, I'm still 10x more productive than I ever was.

nomel 5mo ago

> But it was instantly a maintenance dead end. I gave up on this recently. It achieved the goal now, and in a year or two, when you actually want to add whatever feature, the SOTA AI will probably be able to clean it up as it does so. What does "maintain" even mean anymore? If you don't agree, how many years into the future do we need until you would agree?

dbingham 5mo ago
The problem is that people keep saying this, but the code keeps being bad. Every time I commit myself to trying to build something with AI, I end up wasting a ton of time and backing it out or completely rewriting it without the AI. The code it generates just isn't where it needs to be. And people have been saying this exact thing for years now. Someone said this very thing two years ago. And we're still at the "maintenance dead end" stage. So let me flip it back on you: how many years are we going to pour an obscene amount of resources into this thing that is always going to be able to clean up its own messes "in a year or two" before we realize its a dead end (at best) and we need to be using those resources elsewhere? And, similarly, what happens to you when the SOTA AI in two years can't clean up the code it wrote for you two years ago, but people are depending on it and your still on the hook for maintaining it?
- nomel 5mo ago
  > If you don't agree, how many years into the future do we need until you would agree? Respectfully, I asked first. ;) > before we realize its a dead end (at best) You've declared the future, which doesn't leave much room for a conversation. So, cheers!
  - dbingham 5mo ago
    > You've declared the future, which doesn't leave much room for a conversation. So, cheers! I just flipped your own rhetorical devices back on you. If you don't think they left much room for conversation, then that's a chance for you to look at yourself in the mirror and examine your own behavior ;) To honestly answer your question in good faith, it's not about years, it's about results. I don't see AI improving exponentially or even linearly. I see it's capability gains logarithmically flattening out. And it's still a ways out from actually writing maintainable code. I honestly don't believe we are going to reach this point you are saying is "a few years out" with the current architecture. We're throwing an obscene amount of resources at it and we're just not getting there. And all of this is just about the practical "does it work?" question. We're not even touching on the ethical, environmental, resource use, or societal impact questions at work here.

znpy 5mo ago

> The kind of garbage that people who don’t know any better would ship: it looked right and it worked. I feel what you write, but then again: every now and then i write small greasmonkey scripts to remove annoyances from webpages, and to do so i have to look at the html and the kind of trash you describe is already there.

onlyrealcuzzo 5mo ago

I'm trying to test if vibe coding can actually scale... And man is it painful. AI is great at creating slop that almost works. But, my god, it is terrible at following clear as day instructions on how to cleanup slop. It wrote 150k lines of code that almost works in 2 months. It's taken 1 month to delete about 2000 lines of broken architecture and fix it, and it still hasn't gotten it done, despite nonstop repeated efforts to do something not that hard. I definitely could've fixed it less time then I've spent prompting at this point (but no way I'd have gotten the other 150k lines). But doing it myself is not the point. It's to see if it can actually scale. The answer is yes... But my god is it agonizing. The creating garbage part that almost works is fun. The inevitable cleanup is not. And unfortunately I don't see this aspect materially improving in the short term. If you want it to code you something about 5-10k lines of code that's already been done 1000 times before or only slightly different, it's great. Most people want more than that.

noosphr 5mo ago

This isn't an indictment of how good AI is but how poor our tools are. We had gui makers in 1996 that made slop which allowed you to iterate in real time. They didn't need a datacenter worth of compute and a nuclear reactors worth of power to run.

rightbyte 5mo ago
I really miss those tools. They were magic but need for responsive design messed them up...

onion2k 5mo ago

But it was instantly a maintenance dead end. It doesn't really make sense to suggest AI can work on something any make it now and work correctly, and at the same time say it's unmaintainable. It is maintainable with AI. The real question is whether or not you're happy to ship AI-generated code that you can't modify to production unless you use AI. Few developers are there yet, plenty of non-tech people are there already. I don't know which group is actually wrong.

m463 5mo ago

I kind of wonder if we could have the equivalent of "authors" to style the code in. Sort of like LLMs can be prompted "in the style of Charles Bukowski" write blah blah maybe "in the style of core freebsd code" to make things tighter or maybe a specific git author who checks things in

kokekolo 5mo ago

So you iterated on the design but not on the code? You have to do with the code what you did with the design. Review, adjust (or ask AI to adjust), rinse, repeat. I've found that Claude can write code that's on par with what an average SE can produce, but you have to guide it. Write instructions, but also ask it to propose and assess multiple options, even ask it to run a code review and refactoring every so often. Yes, the code is unlikely to be approved by Linus Torvalds, but so is the code that's made by many humans that is still merged and shipped.

rtgfhyuj 5mo ago

[flagged]