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

101–110 of 254 posts

Re: AI makes tech debt more expensive

#101

Post by eqvinox »

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…

That's great, but a sample size of 1, and AI utility is also self-confirmation-biasing. If the AI stops providing useful output, you stop using it. It's like "what you're searching is always in the last place you look". After you recognize AI's limits, most people wouldn't keep trying to ask it to do things they've learned it can't do. But still, there's an area of things it does, and a (ok, fuzzy) boundary of its capabilities.

Basically, for any statement about AI helpfulness, you need to quantify how far it can help you. Depending on your personality, anything else is likely either always a success (if you have a positive outlook) or a failure (if you focus on the negative).

Re: AI makes tech debt more expensive

#102

Post by randomdata »

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. I suspect that is why startups often need to sacrifice quality: The aforementioned thrill is the motivation to build something that has a high probability of being a complete waste of time. It doesn't matter how fast you can theoretically iterate if you can't compel yourself to work on it.

Re: AI makes tech debt more expensive

#103

Post by mkleczek »

bob1029 wrote: post #28

> Not only does a complex codebase make it harder for the model to generate a coherent response, it also makes it harder for the developer to formulate a coherent request. > This experience has lead most developers to “watch and wait” for the tools to improve until they can handle ‘production-level’ complexity in software. You will be waiting until the heat death of the universe. If you are unable to articulate the e…

Well, increasing temperature (ie. adding some more randomness) for sure is going to magically generate a solution the customer wants. Right? /s

Re: AI makes tech debt more expensive

#104

Post by marcosdumay »

thfuran wrote: post #92
MrMcCall wrote: post #60

Earlier quoted context omitted.

Here's the secret to grokking a software project: a given codebase is not understandable without understanding how and why it was built; i.e. if you didn't build it, you're not going to understand why it is the way it is. In theory, the codebase should be, as it is, understandable (and it is, with a great deal of rigorous study). In reality, that's simply not the case, not for any non-trivial software system.

So your secret to understanding code is: Abandon hope all ye who enter here?

Oh, you will understand why things were built. It's inevitable.

And all of that understanding will come from people complaining about you fixing a bug.

Re: AI makes tech debt more expensive

#105

Post by btbuildem »

I recently started playing with OpenSCAD and CadQuery -- tried a variety of the commercial LLMs, they all fall on their face so hard, teeth go flying.

This is for tiny code snippets, hello-world size, stringing together some primitives to render relatively simple objects.

Turns out, if the codebase / framework is a bit obscure and poorly documented, even the genie can't help.

Re: AI makes tech debt more expensive

#106

Post by marcosdumay »

slt2021 wrote: post #52
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…

maybe its a signal that you software should be restructured into modules that fit well-established patterns. its like you are building website thats not using MVC and complain that LLM advice is garbage...

No, you shouldn't restructure your software into highly-repetitive noise so that a dumb computer can guess what comes next.

Re: AI makes tech debt more expensive

#107

Post by danielbln »

dijksterhuis wrote: post #99
asabla wrote: post #31

Earlier quoted context omitted.

at some extent I do agree with the point you're trying to make. But unless you include pagination needs to be handled as well, the LLM will naively just implement the bare minimum. Context matters. And supplying enough context is what makes all the difference when interacting with these kind of solutions.

not parent, but > I asked the AI to write me some code to get a list of all the objects in an S3 bucket they didn’t ask for all the objects in the first returned page of the query they asked for all the objects . the necessary context is there. LLMs are just on par with devs who don’t read tickets properly / don’t pay attention to the API they’re calling (i’ve had this exact case happen with someone in a previous tea…

LLMs differ though. Newest Claude just gave me a paginated solution without further prodding.

In other more obscure cases I just add the documentation to it's context and let it work based on that.

Re: AI makes tech debt more expensive

#108

Post by danenania »

endemic wrote: post #34
holoduke wrote: post #26

Earlier quoted context omitted.

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.

I feel like we should get rid of the boilerplate, rather than have an LLM barf it out.

There's an inherent tradeoff here though. Beyond a certain complexity threshold, code that leans toward more boilerplate is generally much easier to understand and maintain than code that tries to DRY everything with layers of abstraction, indirection, and magic.

Re: AI makes tech debt more expensive

#110

Post by bunderbunder »

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…

Incidentally the person who really convinced me to stop trying to future-proof made a point along those lines. Not in the same language, but he basically pointed out that, in practice, future-proofing is usually just an extremely efficient way to litter your code with Chesterton's Fences.
Post reply on HN