| ▲ | socalgal2 17 hours ago |
| 2 things 1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to make the transition safe. At least that's my experience. They can dig much further than I ever would. 2. Short of and maybe separate to the LLM fix, this pattern of technical debt I think is nearly inevitable, at least with humans. In a perfect world, every human and every reviewer knows exactly what architecture to write and what tests to convey all of the rules and assumptions because no matter what, people are going to leave. I've never seen that code base though. So the rules and assumptions are at best half written down, maybe in some comments or docs, comments or docs that the next person to edit that part of the code base may or may not see. And so it goes. I work on a code base that runs on Windows, Mac, Linux, Android, iOS. Those OSes change over time, their requirements change, their APIs change, the world changes and new APIs are needed for new things people do, and our original choices for cross platform solutions, no longer fit perfectly. We need to keep moving and shipping and we can't just stop the world and re-architect. Further, like the OP, not everything is written down and communicating across hundreds of programmers is hard. So yes, not every decision is perfect. It never will be. Fortunately we work to fix these things and pay down our technical debt but it can take 5 to 10 years before we can finally remove some old path while we wait on usage numbers for old OSes to go down far enough that we can remove those paths and switch everyone over to the new. And then the cycle repeats. |
|
| ▲ | edukite 17 hours ago | parent | next [-] |
| You are the very first person I encountered who claim LLM can fix technical debt. Usually I seem comments and articles saying LLM can only produce it. And I can agree with those articles and comments |
| |
| ▲ | hombre_fatal 17 hours ago | parent | next [-] | | Trivially debunked with the prompt "find technical debt to fix". https://github.com/danneu/danterm/blob/749942ffa1198f520c8b7... Here's the result of a prompt that specifically looks for correctness and simplifications to make "by construction" before I added "Design bar: ensure correctness by construction rather than by convention" to AGENTS.md: https://github.com/danneu/danterm/blob/749942ffa1198f520c8b7... | | |
| ▲ | blueline 17 hours ago | parent [-] | | Linking to an 8800 line claude written wall of text reinforces the parent's point. | | |
| ▲ | hombre_fatal 17 hours ago | parent [-] | | How? Because it found too many opportunities to improve the code beyond what we'd want to review as a human? Each file is a list of findings that includes the justification/verification of each finding in the same file. This is just what work looks like, especially tech debt repayment. It's analysis, reasoning, and justification. Those produce words. | | |
| ▲ | blueline 17 hours ago | parent [-] | | Sounds good, have fun with that. | | |
| ▲ | hombre_fatal 17 hours ago | parent [-] | | I did. Just about all of the findings were re-verified to be good and then implemented by a rigorous pipeline of clankers, and the project was improved. If it weren't for me insisting that I manually sign off on the solution of every finding, then it would have been fully automated too. |
|
|
|
| |
| ▲ | skybrian 17 hours ago | parent | prev | next [-] | | There is a lot of noise out there from anti-AI types who never seriously tried to clean up messes with AI. If you just ask for new features and never look at the code, coding agents will make a mess. If you often ask questions about how to clean up messy code, coding agents are great help for that, too. But you have to ask. | | |
| ▲ | Arainach 16 hours ago | parent | next [-] | | Agents (and humans) don't know what cleanups are safe or a good idea. They can get stuck in loops when different goals (conciseness, performance, etc.) clash. Their "improvements" can break things unintentionally. Targeted improvements can be good. Giant lists of "fix everything" are bad and will break things. Tech debt comes with insufficient tests, so you won't know what you've broken until too late in many cases. | | |
| ▲ | EPWN3D 16 hours ago | parent [-] | | Yeah that's why step 0 is to tell the LLM to write a test suite for the thing you want to rewrite. It'll do that, but it does require adult supervision. Once you have that test suite, you can send the LLM into an inner dev loop. Like human programmers, LLMs are great when they have a fast inner loop. The fact that LLMs exist doesn't mean you can just stop thinking. It mean the things you have to think about will be different. You have to treat them as savants with absolutely no ambition. | | |
| ▲ | ModernMech 16 hours ago | parent [-] | | There’s a trap here though: the LLMs if you let them will spend all their time maintaining that test suite, they can become quite rigid in the way they design them. So it’ll write some code, break a test, which breaks a contract so then it updates the test and the contract but updating the test also broke another contract… soon enough you’re spending all your tokens fixing contracts instead of writing code. In a sense the LLM having a fast inner loop is its blessing and curse. A blessing because it gets feedback quickly, but a curse because it becomes naval gazing and cannot see the forest for the trees. At least this is my experience with Sol maby other models behave differently. | | |
| ▲ | dolmen 3 hours ago | parent | next [-] | | Software engineering also applies to the test suite. So its management requires supervision. | |
| ▲ | tosti 13 hours ago | parent | prev [-] | | Sounds like one of the teams I left before project completion 13 years ago. |
|
|
| |
| ▲ | brazukadev 16 hours ago | parent | prev [-] | | asking to clean up is not enough, it is needed to understand the code and fix the things the agents are getting wrong. | | |
| ▲ | skybrian 14 hours ago | parent [-] | | It's true that you need to ask good questions to get good results. If you try to understand the code yourself, you will ask better questions. |
|
| |
| ▲ | EPWN3D 16 hours ago | parent | prev | next [-] | | Yes like any tool, LLMs can be used poorly. But they do enable large-scale rewrites or poor-quality code because they are capable of understanding it and enumerating its behaviors in a matter of minutes or hours. It's the kind of understanding that would take a human months or years to develop. Add to that their ability to basically set up what is essentially a perfect testing environment when asked, and you've got a feedback loop that lets you just step back while the agent cranks out a new implementation in a memory-safe language with a full test suite and bug-for-bug compatibility. I'm not kidding or exaggerating. This stuff is possible now, people just need to look past their anxieties about being replaced. | |
| ▲ | bcrosby95 17 hours ago | parent | prev | next [-] | | They can help with it if you point them in the right direction. | |
| ▲ | ModernMech 16 hours ago | parent | prev | next [-] | | I’ll be the second then. I’ve found it’s very good at creating debt but equally good at resolving it. The thing is the default mode is creating debt so you have to intentionally pay it down. Refactors that used to take me a month now take a week, it’s very handy. You can instruct them to move functions around, change interfaces, add or remove abstractions, remove redundant authorities, untangle spaghetti, rename identifiers across a codebase, and it will return very good results. | |
| ▲ | backlava12 17 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | SoftTalker 17 hours ago | parent | prev | next [-] |
| > an LLM, especially the more modern ones, have way more short term memory than most humans But it's not unlimited. So they can write code that they "understand" within the limits of their working context. When it grows beyond that, they can't cope with it in its entirety. And a human, at that point, has no prayer. |
|
| ▲ | ryaniscool 16 hours ago | parent | prev [-] |
| For 1, effectiveness still depends on the size and complexity of the codebase. From my experience, as complexity and size grow, each prompt takes longer, does less, and is prone to more mistakes and disruptions to other parts of the codebase. |
| |
| ▲ | socalgal2 14 hours ago | parent [-] | | The code base I work on is > 30 million lines (excluding comments and blank lines) and most (but not all) of the people on the team are finding it pretty effective. That doesn't mean it wouldn't be more effective on a smaller code base. |
|