Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI makes tech debt more expensive

gauge.sh

Post reply on HN
Print view View original

81–90 of 254 posts

Re: AI makes tech debt more expensive

#81

Post by kazinator »

dkdbejwi383 wrote: post #8

> However, in ‘high-debt’ environments with subtle control flow, long-range dependencies, and unexpected patterns, they struggle to generate a useful response I'd argue that a lot of this is not "tech debt" but just signs of maturity in a codebase. Real world business requirements don't often map cleanly onto any given pattern. Over time codebases develop these "scars", little patches of weirdness. It's often temptin…

Code that has thorough unit and integration tests, no matter how old and crusty, can be refactored with a good deal of confidence, and AI can help with that.

Re: AI makes tech debt more expensive

#82

Post by tux1968 »

This type of analysis is a mirror of the early days of chess "AI". All kinds of commentary explaining the weaknesses of the engines, and extolling the impossible-to-reproduce capabilities of human players. But while they may have been correct in the moment, they didn't really appreciate the march toward utter dominance and supremacy of the machines over human players.

While there is no guarantee that the same trajectory is true for programming, we need to heed how emotionally attached we can be to denying the possibility.

Re: AI makes tech debt more expensive

#83

Post by stego-tech »

While this primarily focuses on the software development side of things, I’d like to chime in that this applies to the IT side of the equation as well.

LLMs can’t understand why your firewall rules have strange forwards for ancient enterprise systems, nor can they “automate” Operations on legacy systems or custom implementations. The only way to fix those issues is to throw money and political will behind addressing technical debt in a permanent sense, which no organization seemingly wants to do.

These things aren’t silver bullets, and throwing more technology at an inherently political problem (tech debt) won’t ever solve it.

Re: AI makes tech debt more expensive

#84

Post by kazinator »

mandevil wrote: post #46
bunderbunder wrote: post #33

Earlier quoted context omitted.

I recently watched a team speedrun this phenomenon in rather dramatic fashion. They released a ground-up rewrite of an existing service to much fanfare, talking about how much simpler it was than the old version. Only to spend the next year systematically restoring most of those pieces of complexity as whoever was on pager duty that week got to experience a high-pressure object lesson in why some design quirk of the…

Hahaha, Joel Spolsky predicted exactly that IN THE YEAR 2000: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Times have changed. Code now does acquire bugs just by sitting there. Assholes you depend on are changing language definitions, compiler behavior, and libraries in a massive effort concentrated on breaking your code. :)

Re: AI makes tech debt more expensive

#85

Post by cloverich »

perrygeo wrote: post #6

> Companies with relatively young, high-quality codebases benefit the most from generative AI tools, while companies with gnarly, legacy codebases will struggle to adopt them. In other words, the penalty for having a ‘high-debt’ codebase is now larger than ever. This mirrors my experience using LLMs on personal projects. They can provide good advice only to the extent that your project stays within the bounds of well…

For me same experience but opposite conclusion. LLM saves me time by being excellent at yak shaving, letting me focus on the things that truly need my attention.

It would be great if they were good at the hard stuff too, but if I had to pick, the basics is where i want them the most. My brain just really dislikes that stuff, and i find it challenging to stay focused and motivated on those things.

Re: AI makes tech debt more expensive

#86

Post by randomdata »

irrational wrote: post #51
perrygeo wrote: post #6

> Companies with relatively young, high-quality codebases benefit the most from generative AI tools, while companies with gnarly, legacy codebases will struggle to adopt them. In other words, the penalty for having a ‘high-debt’ codebase is now larger than ever. This mirrors my experience using LLMs on personal projects. They can provide good advice only to the extent that your project stays within the bounds of well…

I was recently assigned to work on a huge legacy ColdFusion backend service. I was very surprised at how useful AI was with code. It was even better, in my experience, than I've seen with python, java, or typescript. The only explanation I can come up with is there is so much legacy ColdFusion code out there that was used to train Copilot and whatever AI jetbrains uses for code completion that this is one of the lang…

Perhaps it is the reverse: That ColdFusion training sources are limited, so it is more likely to converge on a homogenization?

While, causally, we usually think of a programming language as being one thing, but in reality a programming language generally only specifies a syntax. All of the other features of a language emerge from the people using them. And because of that, two different people can end up speaking two completely different languages even when sharing the same syntax.

This is especially apparent when you witness someone who is familiar with programming in language X, who then starts learning language Y. You'll notice, at least at first, they will still try to write their programs in language X using Y syntax, instead of embracing language Y in all its glory. Now, multiply that by the millions of developers who will touch code in a popular language like Python, Java, or Typescript and things end up all over the place.

So while you might have a lot more code to train on overall, you need a lot more code for the LLM to be able to discern the different dialects that emerge out of the additional variety. Quantity doesn't imply quality.

Re: AI makes tech debt more expensive

#87

Post by mdtancsa »

irrational wrote: post #51
perrygeo wrote: post #6

> Companies with relatively young, high-quality codebases benefit the most from generative AI tools, while companies with gnarly, legacy codebases will struggle to adopt them. In other words, the penalty for having a ‘high-debt’ codebase is now larger than ever. This mirrors my experience using LLMs on personal projects. They can provide good advice only to the extent that your project stays within the bounds of well…

I was recently assigned to work on a huge legacy ColdFusion backend service. I was very surprised at how useful AI was with code. It was even better, in my experience, than I've seen with python, java, or typescript. The only explanation I can come up with is there is so much legacy ColdFusion code out there that was used to train Copilot and whatever AI jetbrains uses for code completion that this is one of the lang…

similar experience with perl scripts being re-written into golang. Crazy good experience with Claude

Re: AI makes tech debt more expensive

#88

Post by croes »

holoduke wrote: post #26
dcchambers wrote: post #23

LLM code gen tools are really freaking good...at making the exact same react boilerplate app that everyone else has. The moment you need to do something novel or complicated they choke up. This is why I'm not very confident that tools like Vercel's v0 ( https://v0.dev/ ) are useful for more than just playing around. It seems very impressive at first glance - but it's a mile wide and only an inch deep.

If can you can create boilerplate code, logging, documentation, common algorithms by AI it saves you a lot of time which you can use on your specialized stuff. I am convinced that you can make yourself x2 by using an AI. Just use it in the proper way.

Tested code libraries save time, AI generated code saves time at writing but the review takes more time because it’s foreign code.

Re: AI makes tech debt more expensive

#89

Post by justincormack »

leptons wrote: post #12

I asked the AI to write me some code to get a list of all the objects in an S3 bucket. It returned some code that worked, it would no doubt be approved by most developers. But on further inspection I noticed that it would cause a bug if the bucket had more than 1000 objects because S3 only delivers 1000 max objects per request, and the API is paged, and the AI had no ability to understand this. So the AI's code would…

Claude did the simple version by default but I asked it to support more than 1000 and it did it fine

Re: AI makes tech debt more expensive

#90

Post by awkward »

leptons wrote: post #12

I asked the AI to write me some code to get a list of all the objects in an S3 bucket. It returned some code that worked, it would no doubt be approved by most developers. But on further inspection I noticed that it would cause a bug if the bucket had more than 1000 objects because S3 only delivers 1000 max objects per request, and the API is paged, and the AI had no ability to understand this. So the AI's code would…

Most AI code is kind of like that. It's sourced from demo quality examples and piecemeal paid work. The resulting code is focused on succinctly solving the problem in the prompt. Factoring and concerns external to making the demo work disappear first. Then any edge cases that might complicate the result get tossed.
Post reply on HN