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

171–180 of 254 posts

Re: AI makes tech debt more expensive

#171

Post by kemiller »

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…

This is true, but I look at it differently. It makes it easier to automate the boring or annoying. Gotta throw up an admin interface? Need to write more unit tests? Need a one-off but complicated SQL query? They tend to excel at these things, and it makes me more likely to do them, while keeping my best attention for the things that really need me.

Re: AI makes tech debt more expensive

#172

Post by ImaCake »

> In essence, the goal should be to unblock your AI tools as much as possible. One reliable way to do this is to spend time breaking your system down into cohesive and coherent modules, each interacting through an explicit interface.

I find this works because its much easier to debug a subtle GPT bug in a well validated interface than the same bug buried in a nested for loop somewhere.

Re: AI makes tech debt more expensive

#173

Post by MrMcCall »

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?

Hard work is no secret, it's just avoided by slackers at all costs :-)

What I'm really saying is that our software development software is missing a very important dimension.

Re: AI makes tech debt more expensive

#174

Post by ImaCake »

inSenCite wrote: post #168

On one hand I agree with this conceptually, but on the other hand I've also been able to use AI to rapidly clean up and better structure a bunch of my existing code. The blind copy-paste has generally been a bad idea though. Still need to read the code spit out, ask for explanations, do some iterating.

Yeah LLMs are pretty good at doing things like moving a lambda function to the right spot or refactoring two overlapping classes to a base class. Often it only saves five minutes but that adds up over time.

Re: AI makes tech debt more expensive

#175

Post by skydhash »

fny wrote: post #170
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…

> They work best where we need them the least. Au contraire. I hate writing boilerplate. I hate digging through APIs. I hate typing the same damn thing over and over again. The easy stuff is mind numbing. The hard stuff is fun.

You write these once (or zero time) by using a scaffolding template, a generator, or snippets.

Re: AI makes tech debt more expensive

#177

Post by skydhash »

slt2021 wrote: post #148
marcosdumay wrote: post #106

Earlier quoted context omitted.

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

I am proponent of Clean and Simple architecture that follows standard patterns. because they are easier to maintain, there should be no clever tricks or arch. all software arch should be boring and simple, with as few tricks as possible, unless it is absolutely warranted

Simplicity is hard. And difficulty is what almost everyone using LLMs is trying to avoid. More code breed complexity.

I read somewhere that 1/6 of the time should be allocated to refactoring (every 6th cycle). I wonder how that should be done with LLMs.

Re: AI makes tech debt more expensive

#178

Post by xnx »

MrMcCall wrote: post #60
comboy wrote: post #38

Earlier quoted context omitted.

Same experience, but I think it's going to change. As models get better, their context window keeps growing while mine stays the same. To be clear, our context window can be really huge if you are living the project. But not if you are new to it or even getting back to it after a few years.

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.

LLMs might be a good argument for documenting more of the "why" in code comments.

Re: AI makes tech debt more expensive

#179

Post by [deleted] »

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

[deleted]

Re: AI makes tech debt more expensive

#180

Post by hn_throwaway_99 »

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…

There is a pretty well known essay by Joel Spolsky (which is now 24 years old!) titled "Things You Should Never Do" where he talks about the error of doing a rewrite: https://www.joelonsoftware.com/2000/04/06/things-you-should-... . While I don't necessarily agree with all of his positions here, and given the way most software is architected and deployed these days some of this advice is just obsolete (e.g. relatively little software is complete, client-side binaries where his advice is more relevant), I think he makes some fantastic points. This part is particularly aligned with what you are saying:

> Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

> Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

> When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Post reply on HN