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.
AI makes tech debt more expensive
231–240 of 254 posts
Re: AI makes tech debt more expensive
#232Earlier 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.
Re: AI makes tech debt more expensive
#233Earlier 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.
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…
> 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
#235Earlier 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.
That’s not test driven development.
Re: AI makes tech debt more expensive
#236Earlier 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.
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
#237Re: AI makes tech debt more expensive
#238Earlier 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"?
Re: AI makes tech debt more expensive
#239Earlier 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,…
Re: AI makes tech debt more expensive
#240Earlier 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.