Laurence Tratt
One of the interesting consequences of LLMs/agents is that the short-term costs of boilerplate in code have plummeted. An interesting question is whether those costs are simply shunted to the future or whether they are permanently reduced.
Mar 4 at 10:19amWeb
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Mar 4

@ltratt

The question is how well an LLM can rewrite boilerplate for new boilerplate when the underlying API changes. Boilerplate is usually bad because it's inflexible: you're making ever user of an API write almost the same thing, rather than giving them an abstraction, which means you're forcing them to provide all of the defaults. When something new requires a default, or when the right choice for a default changes, you require every single consumer of your API to change their code.

From what I've seen of LLMs, they'll be very good at this kind of change in 90+% of the cases and catastrophically (and non-obviously) wrong in the rest.

Show threadLaurence TrattMar 4
@david_chisnall Indeed, that's one of the things that might just be shunted to the future. Or their understanding may improve to the point that that they catch all (or nearly all) the hard cases. Some people are implicitly making big bets on the good case happening, and they may well end up being right, but I think only time will tell!
Show threadPer VognsenMar 4
@ltratt I'd say the short-term costs of boilerplate were always very low. But yes, they certainly have an appetite for spewing that stuff.
Show threadLaurence TrattMar 4
@pervognsen Before good code navigation, I think the short term costs were surprisingly high. I remember working out the (approximate) productivity of programmers in the "Java Enterprise Beans" era and it was not pretty (in no small part because looking up what boilerplate was needed was hard). But I agree, short term boilerplate costs have been on a downwards trajectory for some time even before LLMs.
Show threadIan WagnerMar 4
@ltratt @pervognsen completely agree here. Many if the things I hear people using LLMs for are things like this. Which frankly modern IDE tooling does better overall, esp in the past 10 years or so.
Show threadLaurence TrattMar 4
@ianthetechie @pervognsen I think this is overstating it. LLMs can do very different things to even the best IDE / LSP. Whether those things turn out to be useful over time is, IMHO, something we will find out in due course.
Show threadIan WagnerMar 4

@ltratt @pervognsen yeah fair enough. I agree they are different. An IDE / LSP can’t give more than surface level understanding of code at a glance. LLMs can thrn code into plain English. And it’s pretty reliable for smallish sections of code even spanning multiple modules. (Breaks down pretty quickly when you get into weeds but this is still valuable).

But on the other hand, IDE tools / LSPs are significantly more reliable at understanding relationships, static analysis, refactoring, etc.

Show threadIan WagnerMar 4

@ltratt I’ve said many times that LLMs provide the greatest productivity boost where the **accidental** complexity of your language, tooling, framework, etc. are high.

What if we just invested in better tools, better abstractions, etc. that reduce the accidental complexity. That’s the real problem to solve for!

LLMs are not a particularly huge multiplier when it comes to the essential complexity in my experience. It’s not nothing, but it’s not 2x either. Mostly helps me poke holes in ideas.