| ▲ | adamddev1 2 hours ago |
| Excellent post. People always defend agentic/LLM-driven development by saying, "Well it's good enough", or "It works most of the time." That may be tolerable for some user-facing app. But what if we start normalizing failures in the libraries, the infrastructure, and the compilers? Everything descends into a mess of unreliability, and that slows EVERYTHING and EVERYONE down. |
|
| ▲ | Root_Denied 2 hours ago | parent | next [-] |
| Banking/Finance is the one industry I've seen push back against this type of thinking. Transactions must be handled in a perfect and repeatable way, or the system is unusable as far as the company is concerned. There's definitely still AI/LLM integration happening, but is kept out of specific areas of the business. |
| |
| ▲ | ryandrake an hour ago | parent | next [-] | | Same with aviation and safety. I honestly believe all programmers should, early in their careers, do a brief "tour of duty" in an industry where the stakes are high and "good enough" isn't good enough. You might not choose to make it your entire career, but at least you're exposed to the discipline, however briefly. Most software developers today have never in their lives worked on a project where defects were taken seriously and where there was process and documentation designed to reduce their occurrence. | | |
| ▲ | Defletter 7 minutes ago | parent [-] | | To be fair, I'm inclined to believe that most of this pressure to lean (if not rely) on LLMs is not coming from programmers, but rather from middle and upper management: banks are resisting this not because their programmers are holding some kind of line, but because management is not giving-in to the LLM siren call. So that tour of duty, while a good idea, would be more about teaching management skills than anything else. The normalisation of inexplicable failures is, in my opinion, the consequence of programmers being unable to refuse their managers who have fallen for the LLM siren call, lest they lose their jobs. |
| |
| ▲ | geraneum 6 minutes ago | parent | prev | next [-] | | I think the failures matter in non-sensitive environments as well albeit with a different threshold. If you randomly screw up customer orders (think of DoorDash or an online shop or Airbnb). They lose trust in you and you lose your business to the competition. Going happy go lucky and being irresponsible in the business can bankrupt most* businesses. * well, of course except the criminal empires which are bailed out by our tax money. | |
| ▲ | torben-friis an hour ago | parent | prev [-] | | I've been seeing the very opposite. Fintech companies treating design of financial systems with the casualness of a frontend aesthetic change. And tons of business people integrating their vibecoded POCs with financially sensitive data sources. |
|
|
| ▲ | 30 minutes ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | jtafurth an hour ago | parent | prev | next [-] |
| However, we are not (yet) building probabilistic libraries right? Even if AI is used, the code it builds is still deterministic and will fail in a way that can be fixed. Not unlike legacy code, where the original developers are long gone and no one knows when that system breaking bug is about to wake up. Even in the best of cases tho, fully human written and reviewed code will still fail eventually. So I would say we are not normalizing failures (yet) but rather normalizing legacy. |
| |
| ▲ | drzaiusx11 an hour ago | parent | next [-] | | It's also worth noting that LLM are fairly well suited to finding and documenting "load bearing" legacy bugs (when set out to do exactly that.) I know because I've spent the better part of a year having them do exactly this as a precursor to rewrites in more perfomant tech stacks. Once this research is done, it's a fairly safe and mechanical translation job. | |
| ▲ | joe_the_user 19 minutes ago | parent | prev [-] | | Even if AI is used, the code it builds is still deterministic and will fail in a way that can be fixed. Say that with confidence now. You'll say with shock and incredulity later, "It can be fix? Right?!?!" (Cue some meme). Reproducing bugs is often hard for well designed systems. For randomly designed systems, it's a nightmare. Fixing software is hard and fixing bad software is harder and fixing software where you didn't even think at the time how to make it maintainable is hardest. Legacy systems are usually systems that were well designed at the time. That's why it's worth fixing them now. --> And none of this is saying AI designed systems are bad. But if the only criteria is "code is deterministic by default, it works and we can fix problems later" then AI seems likely a terribleness accelerator. |
|
|
| ▲ | psadri an hour ago | parent | prev | next [-] |
| Write tests first. Have agent iterate until they are satisfied. The point is that it boils down to writing the tests correctly, regardless of who is implementing the actual code. Hand-written code without test coverage has the same problems as AI generated code. |
| |
|
| ▲ | gr_norm 2 hours ago | parent | prev | next [-] |
| Exactly. Reliable abstractions are more important than ever. They're the dues the rest of us must pay to support vibe coding. |
|
| ▲ | 2 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | brookst an hour ago | parent | prev [-] |
| Counterpoint: software has always had bugs. People are fallible. Perhaps designing with assumptions that the entire stack is imperfect is the route to higher quality, along the lines of chaos monkey, which randomly kills processes on production boxes… which ensures resilience is real. Even without AI our tech stack is so deep it’s hard to imagine every feature at every layer being provably correct. |
| |
