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

111–120 of 254 posts

Re: AI makes tech debt more expensive

#111

Post by munk-a »

madeofpalk wrote: post #95
mkleczek wrote: post #91

It is a self-reinforcing pattern: the easier it is to generate code, the more code is generated. The more code is generated, the bigger the cost of maintenance is (and the relationship is super-linear). So every time we generate the same boilerplate we really do copy/paste adding to maintenance costs. We are amazed looking at the code generation capabilities of LLMs forgetting the goal is to have less code - not more…

My experience is the opposite - I find large blobs of generated code to be daunting, so I tend to pretty quickly reject them and either write something smaller by hand, or reprompt (in one way for another) for less, easier to review code.

You are an excellent user of AI code generation - but your habit is absolutely not the norm and other developers will throw in paragraphs of AI slop mindlessly.

Re: AI makes tech debt more expensive

#112

Post by true_religion »

dartos wrote: post #56
anthonyskipper wrote: post #54

Earlier quoted context omitted.

This is only partly true. AI works really well on very legacy codebases like cobol and mainframe, and it's very good at converting that to modern languages and architectures. It's all the stuff from like 2001-2015 that it gets weird on.

> AI works really well on very legacy codebases like cobol and mainframe Any sources? Seems unlikely that LLMs would be good at something with so little training data in the widely available internet.

LLMs are good at taking the underlying structure of one medium and repeating it using another medium.

Re: AI makes tech debt more expensive

#113

Post by 0xfeba »

kazinator wrote: post #84
mandevil wrote: post #46

Earlier quoted context omitted.

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. :)

It acquires bugs, security flaws, and obsolescence from the operating system itself.

Re: AI makes tech debt more expensive

#114

Post by munk-a »

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…

> Put another way, LLMs make the easy stuff easier, but royally screws up the hard stuff.

This is my experience with generation as well - but I still don't trust it for the easy stuff and thus the model ends up being a hindrance in all scenarios. It is much easier for me to comprehend something I'm actively writing so making sure a generative AI isn't hallucinating costs more than me just writing it myself in the first place.

Re: AI makes tech debt more expensive

#115

Post by _lvbh »

kazinator wrote: post #84
mandevil wrote: post #46

Earlier quoted context omitted.

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. :)

Golang really is the best when it comes to backwards compatibility. I'm able to import dependencies from 14 years ago and have them work with 0 changes

Re: AI makes tech debt more expensive

#116

Post by Halan »

It is not just the code produced with code generation tools but also business logic using gen AI.

For example a RAG pipeline. People are rushing things to market that are not built to last. The likes of LangChain etc. offer little software engineering polishing. I wish there were a more mature enterprise framework. Spring AI is still in the making and Go is lagging behind.

Re: AI makes tech debt more expensive

#117

Post by RangerScience »

randomdata wrote: post #102
vander_elst wrote: post #2

"Companies with relatively young, high-quality codebases" I thought that at the beginning the code might be a bit messy because there is the need to iterate fast and quality comes with time, what's the experience of the crowd on this?

In my experience you need a high quality codebase to be able to iterate at maximum speed. Any time someone, myself included, thought they could cut corners to speed up iteration, it ended up slowing things down dramatically in the end. Coding haphazardly can be a lot more thrilling, though! I certainly don't enjoy the process of maintaining high quality code. It is lovely in hindsight, but an awful slog in the moment…

> thought they could cut corners to speed up iteration

Anecdotally, I find you can get about 3 days of speed from cutting corners - after that, as you say, you get slowed down more than you got sped up. First day, you get massive speed from going haphazard; second day, you're running out of corners to cut, and on the third day you start running into problems you created for yourself on the first day.

Re: AI makes tech debt more expensive

#118

Post by suzzer99 »

mandevil wrote: post #74
lcnPylGDnU4H9OF wrote: post #62

Earlier quoted context omitted.

> 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 original existed in the first place. Just to emphasize the point: even if it's not obvious why there is a line of code, it should at least be obvious that the line of code does something. It's important to find…

In my refactoring I always refer to that as Chesterton's Fence. Never remove something until you know why it was put in in the first place. Plenty of times it's because you were trying to support Python 3.8 or something else obsolete, and a whole lot of the time it's because you thought that the next project was going to be X so you tried to make that easy but X never got done so you have code to nowhere. Then feel f…

I got really 'lucky' in that the first major project I ever worked on was future-proofed to high heaven, and I became the one to maintain that thing for a few years as none of the expected needs for multiple layers of future-proofing abstraction came to pass. Oh but if we ever wanted to switch from Oracle to Sybase, it would have been 30% easier with our database connection factory!

I never let that happen again.

Re: AI makes tech debt more expensive

#119

Post by lpapez »

kazinator wrote: post #84
mandevil wrote: post #46

Earlier quoted context omitted.

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. :)

> Assholes you depend on are changing language definitions, compiler behavior, and libraries in a massive effort concentrated on breaking your code. :)

Big Open Source is plotting against the working class developer.

Re: AI makes tech debt more expensive

#120

Post by MarcelOlsz »

cheald wrote: post #77
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…

The niche I've found for LLMs is for implementing individual functions and unit tests. I'll define an interface and a return (or a test name and expectation) and say "this is what I want this to do", and let the LLM take the first crack at it. Limiting the bounds of the problem to be solved does a pretty good job of at least scaffolding something out that I can then take to completion. I almost never end up taking th…

Can't tell you how much I love it for testing, it's basically the only thing I use it for. I now have a test suite that can rebuild my entire app from the ground up locally, and works in the cloud as well. It's a huge motivator actually to write a piece of code with the reward being the ability to send it to the LLM to create some tests and then seeing a nice stream of green checkmarks.
Post reply on HN