Hacker News Reader

Comment by emtel | Hacker News Reader

You’re technically correct, but the vast majority of software has never been built to the kinds of standards you are describing. LLMs are not displacing that kind of work!

View on HN

The person they responded to refers specifically to "healthcare, finance, automotive, defense, power plans, aviation, manufacturing", areas where I'd at least hope that we aspire to understand what the code does.

Having worked in software for healthcare, defense and finance I guarantee you we don't

Do you agree that this isn't a desirable state of affairs?

I have also done those three and we definitely did!

TLA+

TLA+ ensures your model is correct, not that the code is correct

I worked briefly in heath care and the code is so brittle and so poorly understood that almost everyone is afraid to touch anything and instead it's just layers and layers of stuff trying to patch around existing code.

I know this is true. But I don’t think “Some parts of important codebases are black boxes. Therefore it’s fine if all of that code base becomes a far bigger black box” sounds like a good argument.

Also, there was probably some human at some point that had some understanding of what they were trying to do and why. The black boxes generally get programmed around after they long left but at the time they had bugs ironed out over decades. (Yes I know sometimes true slop is done over a short period of time and the programmer leaves. But I’ve generally seen the black box built over decades instead).

I worked briefly in aviation and the part I've seen was very understandable and easy to extend and modify in understandable way. Some parts were hard, but by necessity. We also had very good tests. But maybe that one software was just a good exception.

In many codebases when you see this happening it is because someone reported a bug and the dev fixed the narrowest instance they could. Typically if(some specific case) do_fix() else do_normal(). Over time this fragments meaning in the source and makes it harder to reason about until it is a giant pile of slop.

The thing the dev should do that often doesn't get done is to take the information about the undesired behavior back up to the design/spec level and rework the definition to account for it. This doesn't normally get done because it takes longer and it is conceptually more difficult than the patch.

This is something that LLMs can accelerate significantly and the result is a shallower gradient of technical debt over the long term.

> back up to the design/spec level and rework the definition to account for it.

> his doesn't normally get done because it takes longer and it is conceptually more difficult than the patch.

This usually isn't done, because design/spec no longer exists.

Sometimes this also happens because the design/spec never existed, but hopefully not in the industries under discussion.

I worked for a reinsurance company and their main pricing tool is a huge brittle excel file full of spaghetti VBS code. And yet, they manage to underwrite billions.

When the derecho came through Iowa and many businesses were out of power for up to multiple weeks, the very large organization I was working for at the time in the insurance space got to discover just how many of their processes relied on machines sitting under people’s desks. Business critical servers and processing just chilling on a PC under someone’s desk. Also tens of billions of dollars in revenue a year.

Also software like SQLite:

" SQLite is built using a DO-178B-inspired process. The testing standards for SQLite are among the highest for commercial software.

SQLite is open-source but it is not open-contribution. All the code in SQLite is written by a small team of experts. The project does not accept "pull requests" or patches from anonymous passers-by on the internet. "

https://sqlite.org/hirely.html

https://sqlite.org/testing.html

Healthcare has featured many a time on thedailywtf, because a lot is (or at least was) written in MUMPS[0]. An example: https://thedailywtf.com/articles/A_Case_of_the_MUMPS

[0] https://en.wikipedia.org/wiki/MUMPS

yeah, the llm approach is incredibly wasteful wrt pretty much everything. Performance, RAM, Development (Tokens).

But it does give you surprisingly stasble rube-goldberg machines.

And thats basically what 95-99% of enterprises want from their software.

It annoyed me to no end when i began my career, but at this point ive accepted it and can definitely still have fun developing software with llms. As a matter of fact, as my perfectionism approach to software in my earlier years was never really appreciated... So i dont really mind the new MO.

I still occasionally hand write though, esp. at the dayjob where ive got super small token budgets while continuously being told to use more AI. But that's normal, employers usually give off bipolar vibes with multiple stakeholders wanting to advance each of their bonus package KPI of any given quarter

> yeah, the llm approach is incredibly wasteful wrt pretty much everything.

Everything except what matters most: human time.

well, depends on how rich you are

Oh, it wastes so, so much of that...

The vast majority of software is not that important. I don’t really care about easytag (which I use for flac metadata), but I do care about xterm and tmux.

Reply on news.ycombinator.com