Live data from Hacker News

AI makes tech debt more expensive

gauge.sh

51–60 of 254 posts

Re: AI makes tech debt more expensive

#51
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 languages they are most suited to assist with.

Re: AI makes tech debt more expensive

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

Re: AI makes tech debt more expensive

#53

... until it won't. A mature code-base also has (or should have) strong test coverage, both in unit-testing and comprehensive integration testing. With proper ci/cd pipelines, you can have a small team update and upgrade stuff at a fraction of the usual cost (see amazon going from old java to newer versions) and "pay off" some of that debt. The tooling for this will only improve.

According to Ilya Sutskever: "results from scaling up pre-training have plateaued". https://www.reuters.com/technology/artificial-intelligence/o...

They're trying other techniques to improve what we already have atm, but we're almost at the limit of its capabilities.

Re: AI makes tech debt more expensive

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

Re: AI makes tech debt more expensive

#55
post #34

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.

Honestly, this bit about genAI being good at generating boilerplate is correct, but it always makes me wonder... is this really a thing that would save a ton of time? How much boilerplate are people writing? Only a small fraction of code that I write involves boilerplate.

Re: AI makes tech debt more expensive

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

Re: AI makes tech debt more expensive

#57
post #34

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.

When I try to read code on GitHub that has the var or val keyword, I have no fucking idea what the types of the variables are. Sure, the compiler can infer, since it’s just ingested your entire code base, but I have a single page of text to look at.

Some boilerplate is good.

Re: AI makes tech debt more expensive

#58
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…

Eh, it’s been kinda nice to just hit tab-to-complete on things like formulaic (but comprehensive) test suites, etc. I never wanted the LLM to take over the (fun) part - thinking through the hard/unusual parts of the problem - but you’re also not wrong that they’re needed the least for the boilerplate. It’s still nice :)

True, if you're using LLMs as a completion engine or to generate scaffolding it's still very useful! But we have to acknowledge that's by far the easiest part of programming. IDEs and deterministic dev tools have done that (very well) for decades.

The LLM gains are in efficiency for rote tasks, not solving the other hard problems that make up 98% of the day. The idea that LLMs are going to advance software in any substantial way seems implausible to me - It's an efficiency tool in the same category as other IDE features, an autocomplete search engine on steroids, not even remotely approaching AGI (yet).

Re: AI makes tech debt more expensive

#59

"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?

> what's the experience of the crowd on this?

It's very hard to retrofit quality into existing code. It really should be there from the very start.

Re: AI makes tech debt more expensive

#60
post #38
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…

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.

Post reply on HN