3 ms·

> 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 m

> 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]
  - louiereederson 5mo ago
    I'm wondering if companies are 'diverting' engineering resources from core products to AI products with the view that the former are legacy. Kind of two sides of the same coin though.
    - SpicyLemonZest 5mo ago
      I'm sure there's a lot of AI investment, but I've definitely also seen fixed sets of core product engineers shipping a lot more bugs these days.
- marcosdumay 5mo ago
  The problem is worse than that. The number of edge cases in a software is not fixed at all. One of the largest markers of competence in software development is being able to keep them at minimum, and LLMs tend to make that number higher than humanely possible.
giancarlostoro 5mo ago
Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.
- HappySweeney 5mo ago
  Code review is the main thing I use LLMs for. I have found it to be remarkably candid when you tell it the code came from another LLM (even name it). I was running Kimi K2.6 Q4 locally, seeing if it could SIMD a bit-matrix transpose function, and it was slow enough that I would paste its thinking into Gemini every few minutes. Gemini was savage.
  - datsci_est_2015 5mo ago
    > Gemini was savage. Humorously, this could be the result of LLMs vacuuming up all the sentiment on the web that the code that LLMs produce is trash-tier.
- kenjackson 5mo ago
  This is it. I've had a similar experience in just playing around I asked it to clean up some code it wrote to increase maintainability and readability by humans. After a few iterations it had generated quite solid code. It also broke the code a couple of times along the way. But it does get me thinking that these pipelines with agents doing specific tasks makes a lot of sense. One to design and architect, one to implement, one to clean, one to review, one to test (actually there's probably a bunch of different agents for testing -- testing perf/power, that it matches the requirements/spec, matches the design, is readable/maintainable, etc...).
  - giancarlostoro 5mo ago
    I built GuardRails after some frustrations with Beads which I love, and this whole exchange made me realize, because I have "gates" after tasks, I could add a "Review the code" type of gate, and probably get insanely better output, I already get reasonably good output because I spec out the requirements beforehand, that's the other thing, if you can tell the LLM HOW to build before it does, you will have better output.
albedoa 5mo ago
I'm looking at that Tailwind thread. Do you really think that your comment here is a fair assessment of what you were told there? Come on now. https://news.ycombinator.com/item?id=48166334 https://news.ycombinator.com/item?id=48166334
hollowturtle 5mo ago
I'm pretty you wouldn't want the same for code that runs healthcare, banks or transport. Only useless shitty web projects could embrace what's you're saying. And no there's no "Claude review the code and improve it" magical formula
- QuercusMax 5mo ago
  I work in the health software space and there are tons of internal tools which aren't production code that can benefit massively from throwaway "write-only code". Putting a web UI on top of a management CLI tool so support ops can run things without needing an oncall engineer can be a huge win. I recently built a testing UI that doubles a demo-scenario-setup tool. Is it well-engineered? Who cares - it pokes the right things into the database and runs the right backend tasks, and has helped me catch and fix dozens of real bugs in the UIs that customers see. There is an enormous untapped market for crappy low-effort apps which previously weren't worth the time - but with the effort so low put together a simple dashboard or one-off tool it becomes much more attractive.
  - hollowturtle 5mo ago
    > internal tools which aren't production code that can benefit massively from throwaway "write-only code". First of all internal tools just prove my point. Second can't wait to hear a story of a health care production database blown away because someone was playing with generated tools that "pokes the right things". We NEED end user experiences that don't suck, and don't keep getting shittier like now, not being able to use a cli for internal tools, it's a skill issue, not everythint needs a shitty ui that taps into an os system calls and blows away as soon as the cli responds with something unexpected
    - QuercusMax 5mo ago
      You still have to do the engineering parts of software engineering, you can't just turn off your brain and vibe. Just like you can't with hand-written code. I've seen what an intern with access to prod DB can do. For example, the testing tool I built explicitly doesn't work in production environment. That was part of my design spec and I manually verified the code and behavior.
naravara 5mo ago
I have been wondering recently that if the cost of just throwing everything out and building it from scratch again gets low enough, maybe maintainability becomes less of a priority? Can we just embrace the thing like those Zen carpenters who build wooden fire shrines do where they just accept that the thing will keep burning down and they make a discipline around getting really good at rebuilding it? Granted, the load bearing thing here is whether we’re actually getting good at rebuilding up to any sort of standard of quality. Or if the tooling is even structurally capable of doing that rather than just introducing new baskets of problems with each build.
noosphr 5mo ago
The if in there is doing a lot of heavy lifting.

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]
- louiereederson 5mo ago
  I'm wondering if companies are 'diverting' engineering resources from core products to AI products with the view that the former are legacy. Kind of two sides of the same coin though.
  - SpicyLemonZest 5mo ago
    I'm sure there's a lot of AI investment, but I've definitely also seen fixed sets of core product engineers shipping a lot more bugs these days.
marcosdumay 5mo ago
The problem is worse than that. The number of edge cases in a software is not fixed at all. One of the largest markers of competence in software development is being able to keep them at minimum, and LLMs tend to make that number higher than humanely possible.

giancarlostoro 5mo ago

Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.

HappySweeney 5mo ago
Code review is the main thing I use LLMs for. I have found it to be remarkably candid when you tell it the code came from another LLM (even name it). I was running Kimi K2.6 Q4 locally, seeing if it could SIMD a bit-matrix transpose function, and it was slow enough that I would paste its thinking into Gemini every few minutes. Gemini was savage.
- datsci_est_2015 5mo ago
  > Gemini was savage. Humorously, this could be the result of LLMs vacuuming up all the sentiment on the web that the code that LLMs produce is trash-tier.
kenjackson 5mo ago
This is it. I've had a similar experience in just playing around I asked it to clean up some code it wrote to increase maintainability and readability by humans. After a few iterations it had generated quite solid code. It also broke the code a couple of times along the way. But it does get me thinking that these pipelines with agents doing specific tasks makes a lot of sense. One to design and architect, one to implement, one to clean, one to review, one to test (actually there's probably a bunch of different agents for testing -- testing perf/power, that it matches the requirements/spec, matches the design, is readable/maintainable, etc...).
- giancarlostoro 5mo ago
  I built GuardRails after some frustrations with Beads which I love, and this whole exchange made me realize, because I have "gates" after tasks, I could add a "Review the code" type of gate, and probably get insanely better output, I already get reasonably good output because I spec out the requirements beforehand, that's the other thing, if you can tell the LLM HOW to build before it does, you will have better output.

albedoa 5mo ago

I'm looking at that Tailwind thread. Do you really think that your comment here is a fair assessment of what you were told there? Come on now. https://news.ycombinator.com/item?id=48166334 https://news.ycombinator.com/item?id=48166334

hollowturtle 5mo ago

I'm pretty you wouldn't want the same for code that runs healthcare, banks or transport. Only useless shitty web projects could embrace what's you're saying. And no there's no "Claude review the code and improve it" magical formula

QuercusMax 5mo ago
I work in the health software space and there are tons of internal tools which aren't production code that can benefit massively from throwaway "write-only code". Putting a web UI on top of a management CLI tool so support ops can run things without needing an oncall engineer can be a huge win. I recently built a testing UI that doubles a demo-scenario-setup tool. Is it well-engineered? Who cares - it pokes the right things into the database and runs the right backend tasks, and has helped me catch and fix dozens of real bugs in the UIs that customers see. There is an enormous untapped market for crappy low-effort apps which previously weren't worth the time - but with the effort so low put together a simple dashboard or one-off tool it becomes much more attractive.
- hollowturtle 5mo ago
  > internal tools which aren't production code that can benefit massively from throwaway "write-only code". First of all internal tools just prove my point. Second can't wait to hear a story of a health care production database blown away because someone was playing with generated tools that "pokes the right things". We NEED end user experiences that don't suck, and don't keep getting shittier like now, not being able to use a cli for internal tools, it's a skill issue, not everythint needs a shitty ui that taps into an os system calls and blows away as soon as the cli responds with something unexpected
  - QuercusMax 5mo ago
    You still have to do the engineering parts of software engineering, you can't just turn off your brain and vibe. Just like you can't with hand-written code. I've seen what an intern with access to prod DB can do. For example, the testing tool I built explicitly doesn't work in production environment. That was part of my design spec and I manually verified the code and behavior.

naravara 5mo ago

I have been wondering recently that if the cost of just throwing everything out and building it from scratch again gets low enough, maybe maintainability becomes less of a priority? Can we just embrace the thing like those Zen carpenters who build wooden fire shrines do where they just accept that the thing will keep burning down and they make a discipline around getting really good at rebuilding it? Granted, the load bearing thing here is whether we’re actually getting good at rebuilding up to any sort of standard of quality. Or if the tooling is even structurally capable of doing that rather than just introducing new baskets of problems with each build.

noosphr 5mo ago

The if in there is doing a lot of heavy lifting.