Live data from Hacker News

AI makes tech debt more expensive

gauge.sh

231–240 of 254 posts

Re: AI makes tech debt more expensive

#231
post #56

Earlier quoted context omitted.

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

Assuming both mediums are reasonably well represented in the dataset, which brings me back to my comment

Re: AI makes tech debt more expensive

#232

Earlier quoted context omitted.

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.

Exactly that. LLMs generate a lot of simple and dumb code fast. Then you need to refactor it and you can't because LLMs are still very bad at that. They can only refactor locally with a very limited scope, not globally. Good luck to anyone having to maintain legacy LLM-generated codebases in the future, I won't.

I’ve noticed LLMs quickly turn to pulling in dependencies and making complicated code

Re: AI makes tech debt more expensive

#233

Earlier quoted context omitted.

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.

IME that kind of thing is more likely to make it 300% harder.

This idea of easy, worry-free database replatforming strikes me as kind of a shibboleth for identifying people who’ve never done it before. In reality they all have subtle differences in semantics and query optimization behavior that mean that every touch point needs close attention to make sure you understand how the behavior in that part of the system changes (assume it will change) and if that change is acceptable. Thinking abstraction layers can eliminate the need for close attention to a DBMS port is the software engineering equivalent of thinking adaptive cruise control means you can play Slay the Spire while driving to the office.

Re: AI makes tech debt more expensive

#234

> There is an emerging belief that AI will make tech debt less relevant. Wow. It's hard to believe that people are earnestly supposing this. From everything we have evidence of so far, AI generated code is destined to be a prolific font of tech debt. It's irregular, inconsistent, highly sensitive to specific prompting and context inputs, and generally produces "make do" code at best. It can be extremely "cheap" vs tr…

Guy I know n days ago:

> I let AI write the parsing and hoooo boy do I regret it.

He's kindly fixed the server 500's now though xD

Re: AI makes tech debt more expensive

#235

Earlier quoted context omitted.

More importantly I have a French cleat wall to finish, a Christmas present to make for my wife, and a toddler and infant to keep from killing themselves. But I also have a day job and I can’t even begin to imagine how much extra work someone doing “TDD” by writing a function and then fixing it in place with a whole suite of generated tests would cause me. I’m fine with TDD. I do it myself fairly often. I also go back…

Like I said above, I like the ability to scaffold tests using english and tweaking from there. I'm still not sure what point you're trying to make.

Your original point was that it was great to “write some code then send it to the LLM to create tests.”

That’s not test driven development.

Re: AI makes tech debt more expensive

#236

Earlier quoted context omitted.

I had Codeium add something to a function that added a new data value to an object. Unbidden it wrote three new tests, good tests. I wrote my own test by cutting and pasting a test it wrote with a modification, it pointed out that I didn’t edit the comment so I told it to do so. It also screwed up the imports of my tests pretty bad, some imports that worked before got changed for no good reason. It replaced the JetBr…

Try using Cursor with the latest claude-3-5-sonnet-20241022.

Seconding Cursor. I have a friend who used Copilot 6 mo. ago and found it vaguely helpful... but turned him on to Cursor and it's a whole new ballgame.

Cross between actually useful autocomplete, personalized StackOverflow and error diagnosis (just paste and error message in chat). I know I am just scratching the usefulness and I pretty much never do changes across multiple files, but I definitely see firm net positives at this point.

Re: AI makes tech debt more expensive

#238

Earlier quoted context omitted.

Ironically enough I’ve always found LLMs work best when I don’t know what I’m doing

I find this perspective both scary and exciting. I'm curious, how do you validate the LLM's output? If you have a way to do this, and it's working. Then that's amazing. If you don't, how are you gauging "work best"?

I gauge what work's best if I can already do what I am asking it to do, and that comes from years of studying and trial and error experience without LLMs. I have no way of verifying what's a hallucination unless I am an expert

Re: AI makes tech debt more expensive

#239
post #185

Earlier quoted context omitted.

A piece of advice I heard many years ago was to not be afraid to throw away code. I've actually used that advice from time to time. It's not really a waste of time to do a `git reset --hard master` if you wrote shit code, but while writing it, you figured out how you should have written the code.

Very much yes. There's little reason to try to go straight for the final product when you don't know exactly how to get there , and that's frequently the case. Build toys to learn what you need efficiently, toss them, and then build the real thing. Trying to shoot for the final product while also changing direction multiple times along the way tends to create code with multiple conflicting goals subtly encoded in it,…

Came across the idea of "probe" (awhile ago) as a name for this.

Re: AI makes tech debt more expensive

#240

Earlier quoted context omitted.

Like I said above, I like the ability to scaffold tests using english and tweaking from there. I'm still not sure what point you're trying to make.

Your original point was that it was great to “write some code then send it to the LLM to create tests.” That’s not test driven development.

Sure if you want to take the absolute least charitable interpretation of what I said lol.
Post reply on HN