←back to thread

Some thoughts on LLMs and software development

(martinfowler.com)
416 points floverfelt | 4 comments | 28 Aug 25 18:52 UTC | HN request time: 0s | source
Show context
jeppester ◴[28 Aug 25 21:56 UTC] No.45057505[source]▶
In my company I feel that we getting totally overrun with code that's 90% good, 10% broken and almost exactly what was needed.

We are producing more code, but quality is definitely taking a hit now that no-one is able to keep up.

So instead of slowly inching towards the result we are getting 90% there in no time, and then spending lots and lots of time on getting to know the code and fixing and fine-tuning everything.

Maybe we ARE faster than before, but it wouldn't surprise me if the two approaches are closer than what one might think.

What bothers me the most is that I much prefer to build stuff rather than fixing code I'm not intimately familiar with.

replies(8): >>45057537 #>>45058508 #>>45061118 #>>45061272 #>>45061732 #>>45062347 #>>45065856 #>>45070745 #
epolanski ◴[28 Aug 25 22:00 UTC] No.45057537[source]▶
As Fowler himself states, there's a need to learn to use these tools properly.

In any case poor work quality is a failure of tech leadership and culture, it's not AI's fault.

replies(1): >>45058751 #
FromTheFirstIn ◴[29 Aug 25 00:53 UTC] No.45058751[source]▶
It’s funny how nothing seems to be AI’s fault.
replies(5): >>45060536 #>>45060602 #>>45060685 #>>45061146 #>>45062496 #
1. Cthulhu_ ◴[29 Aug 25 07:15 UTC] No.45061146{3}[source]▶
That's because it's software / an application. I don't blame my editor for broken code either. You can't put blame on software itself, it just does what it's programmed to do.

But also, blameless culture is IMO important in software development. If a bug ends up in production, whose fault is it? The developer that wrote the code? The LLM that generated it? The reviewer that approved it? The product owner that decided a feature should be built? The tester that missed the bug? The engineering organization that has a gap in their CI?

As with the Therac-25 incident, it's never one cause: https://news.ycombinator.com/item?id=45036294

replies(3): >>45061350 #>>45063842 #>>45083830 #
2. wk_end ◴[29 Aug 25 07:49 UTC] No.45061350[source]▶
Blameless culture is important for a lot of reasons, but many of them are human. LLMs are just tools. If one of the issues identified in a post-mortem is "using this particular tool is causing us problems", there's not a blameless culture out there that would say "We can't blame the tool..."; the action item is "Figure out how to improve/replace/remove the tool so it no longer contributes to problems."
3. Jensson ◴[29 Aug 25 13:28 UTC] No.45063842[source]▶
> You can't put blame on software itself, it just does what it's programmed to do.

This isn't what AI enthusiasts say about AI though, they only bring that up when they get defensive but then go around and say it will totally replace software engineers and is not just a tool.

4. FromTheFirstIn ◴[31 Aug 25 15:18 UTC] No.45083830[source]▶
Blame is purely social and purely human. “Blaming” a tool or process and root causing are functionally identical. Misattributing an outage to a single failure is certainly one way to fail to fix a process. Failing to identify faulty tools/ faulty applications is another way.

I was being flippant to say it’s never AI’s fault, but due to board/C-Suite pressure it’s harder than ever to point out the ways that AI makes processes more complex, harder to reason about, stochastic, and expensive. So we end up with problems that have to be attributed to something not AI.