6 ms·

Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. I find Claude Code in part

Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. I find Claude Code in particular is great at grokking old code bases and making changes to it. I work on one of those old code bases and my productivity increased 10x mostly due to Claude Code's ability to research large code bases, make sense of it, answer questions and making careful surgical changes to it. It also helps with testing and debugging which is huge productivity boost. It's not about its ability to churn out lots of code quickly: it's an extra set of eyes/brain that works much faster that human developer.

nuclearnicer 10mo ago
This is great. Asking questions of library code is a big pattern of mine too. Here's an example I saw on twitter. Asking an LLM to document a protocol from the codebase: https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf823672?q=tmux https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf... Do you think you will be able to capture any of this extra value? I think I'm faster at coding, but the overall corporate project timeline feels about the same. I feel more relaxed and confident that the work can be done. Not sure how to get a raise out of this.
- loandbehold 10mo ago
  For me, as a remote developer, it means I'm able to finish my work in 1 hour instead of 8 hours. So I'm able to capture "extra value" in the form of time. In our team everyone uses GitHub Copilot and I use Claude Code. My teammates' productivity increased slightly but my productivity increased a lot. This is because 1. Claude Code is just a better coding agent 2. I invested time to get good at agentic coding. Eventually Copilot will catch up and management will realize that now 1 developer can do what previously would take a whole team.
  - overfeed 10mo ago
    I'm really curious on what your role is, and which industry are you in? I'm awed by these productivity gains others report, but I feel like AI helps in such a small part of my job (implementing specific changes as I direct). Agentic workflows for me results in bloated code, which is fine when I'm willing to hand over an subsystem to the agent, such as a frontend on a side project and have it vibe code the entire thing. Trying to get clean code erases all/most of my productivity gains, and doesn't spark joy. I find having a back-end-forth with an agent exhausting, probably because I have to build and discard multiple mental models of the proposed solution, since the approach can vary wildly between prompts. An agent can easily switch between using Newton-Raphson and bisection when asked to refactor unrelated arguments, which a human colleague wouldn't do after a code review.
    - saxenaabhi 10mo ago
      Not the OP but we use LLMs to build a restaurant pos system with reservations, loyalty, webshop etc. Almost at feature parity with bigwigs like lightspeed/toast. > I find having a back-end-forth with an agent exhausting, probably because I have to build and discard multiple mental models of the proposed solution, since the approach can vary wildly between prompts Just right now I had it improve QR payments on POS. This is standard stuff, and I have done it multiple time but i'm happy I didn't have to spend the mental energy to implement it and just had to review the code and test it. ``` Perfect! I've successfully implemented comprehensive network recovery strategies for the OnlinePaymentModal.tsx file. Here's a summary of what was added: Implemented Network Recovery Strategies 1. Exponential Backoff for Polling (lines 187-191) 2. Network Status Detection (lines 223-246, 248-251) 3. Transaction Timeout Handling (lines 110-119) 4. Retry Logic for Initial Transaction (lines 44-105) 5. AbortController for Request Cancellation (lines 134-139, 216-220) 6. Better Error Messaging (lines 85-102, 193-196) 7. Circuit Breaker Pattern (lines 126-132) All strategies work together to provide a robust, user-friendly payment experience that gracefully handles network issues and automatically recovers when connectivity is restored. ``` > An agent can easily switch between using Newton-Raphson and bisection when asked to refactor unrelated arguments, which a human colleague wouldn't do after a code review. Can you share what domain your work is in? Is it deeptech. Maybe coding agents right now work better for transactional/ecommerce systems?
      - deleted 10mo ago
        [deleted]
      - bccdee 10mo ago
        I don't know if that example is real, but if it is, that's exactly the reason I find AI tools irritating. You do not need six different ways to handle the connection being down, and if you do, you should really factor that out into a connection management layer. One of my big issues with LLM coding assistants is that they make it easy to write lots & lots of code. Meanwhile, code is a liability, and you should want less of it.
        10mo ago
  - deleted 10mo ago
    [deleted]
dleeftink 10mo ago
Although many tools exist, there still seems to a large context gap here: we need better tools to orient ourselves and to navigate large (legacy) codebases. While not strictly a a source graph or the like, I do think Enso like interface may prove successful here[0].
zmmmmm 10mo ago
I've found this as well. In some cases we aren't fully authorised to use the AI tools for actual coding but even just asking "how would you make this change" or "where would you look to resolve this bug" or "give me an overview of how this process works" is amazingly helpful.
- eru 10mo ago
  > In some cases we aren't fully authorised to use the AI tools for actual coding but even just asking "how would you make this change" [...] Isn't the logical endpoint of this equivalent to printing out a Stackoverflow answer and manually typing it into your computer instead of copy-and-pasting? Nitpicks aside, I agree that contemporary AIs can be great for quickly getting up to speed with a code base. Both a new library or language you want to be using, and your own organisation's legacy code. One of the biggest advantages of using established ecosystem was that stack-overflow had a robust repository of already answered questions (and you could also buy books on it). With AI you can immediately cook up your own Stackoverflow community equivalent that provides answers promptly instead of closing your question as off-topic. And I pick Stackoverflow deliberately: it's a great resources, but not reliable enough to use blindly. I feel we are in a similar situation with AI at the moment. This will change gradually as the models become better. Just like Stackoverflow required less expertise to use than attending a university course. (And a university course requires less expertise than coming up with QuickSort in the first place.)
  - ChrisMarshallNY 10mo ago
    > Isn't the logical endpoint of this equivalent to printing out a Stackoverflow answer and manually typing it into your computer instead of copy-and-pasting? Not in my case (I never used SO like that, anyway). I use it almost exactly like SO, except much more quickly and interactively (and without the inference that I’m “lazy,” or “stupid,” for not already knowing the answer). I have found that ChatGPT gives me better code than Claude (I write Swift); even learning my coding and documentation style. I still need to review all the code it gives me, and I have yet to use it verbatim, but it’s getting close. The most valuable thing, is I get an error, and I can ask it “Here’s the symptoms and the code. What do you think is going on?”. It usually gives me a good starting point. I could definitely figure it out on my own, but it might take half an hour. ChatGPT will give me a solid lead in about half a minute.
hello12343214 10mo ago
this was really interesting to read.
locknitpicker 10mo ago
> It's not about its ability to churn out lots of code quickly: it's an extra set of eyes/brain that works much faster that human developer. This is the key take right here. LLMs excel at parsing existing content, summarizing it, and use it to explore scenarios and hypotheticals. Even the best coding agents out there such as Claude Code or Gemini often fail to generate at the first try code that actually compiles, let alone does what it is expected to do. Apologists come up with excuses such as the legacy software is not architected well enough to be easily parseable by LLMs but that is a cheap excuse. The same reference LLMs often output utter crap in greenfield projects they themselves generated, and do so after a hand full of prompts. The state of a project is not the issue. The world is coming to the realization that the AI hype is not delivering. The talk of AI bubble is already mainstream. But like IDEs with auto complete, agents might not solve every problem but they are nevertheless useful and are here to stay. They are more a kin to a search engine where a user doesn't need to copy/paste code snippets to apply a code change. The sooner we realize this, the better.
- Dave_Wishengrad 10mo ago
  [dead]
locknitpicker 10mo ago
> Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. That's not the definition of legacy. Being there for a long time and getting lots of use is not what makes a legacy project "legacy". Legacy projects are characterized by not being maintained and having little to no test coverage. The term "legacy" means "I'm afraid to touch it because it might break and I doubt I can put it back together". Legacy means resistance to change. You can and do have legacy projects created a year or two ago. Most vibecoded apps fit the definition of legacy code. That is why legacy projects are a challenge to agentic coding. Agents already output huge volumes of code changes that developers struggle to review, let alone assert it's correctness. On legacy projects that are in production, this is disastrous.
- tarsinge 10mo ago
  What you list are common characteristics encountered in legacy systems, but what makes it legacy is a business decision of declaring it obsolete and in maintenance mode, and so that no money or time to be invested in it. Old systems that continues to evolve are not legacy, like say Linux, and yes like you say a project that is only one year old can be declared legacy. Resistance to change is only an economic variable that drives the decision. Vibecoded apps fits the definition because the developer is unlikely to want to invest more time in them for different reasons.
  - locknitpicker 10mo ago
    > What you list are common characteristics encountered in legacy systems, but what makes it legacy is a business decision of declaring it obsolete and in maintenance mode, and so that no money or time to be invested in it. No, not necessarily. Business decisions are one of the many factors in creating legacy code,but they are by no means the single cause. A bigger factor is developers mismanaging a project to the point they became a unmaintainable mess. I personally went through a couple of projects which were legacy code the minute they hit production. One of them was even a proof of concept that a principal engineer, one of those infamous 10x types, decided to push as-is to production and leave two teams of engineers to sort out the mess left in his wake. I recommend reading "Working Effectively with Legacy Code" by Michael Feathers. It will certainly be eye-opening to some, as it dispels the myth that legacy code is a function of age.
lambdaone 10mo ago
Claude is insanely good at grunt-work maintenance coding, which is a fairly formulaic exercise that mostly requires RTFM and simple code changes that look a lot likw the surrounding code. Designing new things from scratch based on human specs is something which Claude still struggles with.
- mcny 10mo ago
  The problem is that it often doesn't get it right the first time. You have to sort of have a conversation and it eventually gets there but if you have no idea what the destination should be like, you can't guide it there.
curiousgal 10mo ago
I honestly don't know what code bases you guys are working with, for me I tried it with a large quant library (C++ 97) in an effort to modernize it and so far it's been nothing hit a waste of time. Similarly for a medium sized python quant codebase (3.6) trying to port it to 3.12, and it's also been a headache.
- loandbehold 10mo ago
  Email me loandbehold0 at proton.me with details of what you are trying to do. I don't have quantitative finance experience but I can give it a shot.
Jean-Papoulos 10mo ago
I have the opposite experience. Claude can't get it all in the context window and make changes that will completely break something on the other side of the program. Granted that's because the program is incredibly poorly written, but still, context window will stay a huge barrier for quite some time.
- zinodaur 10mo ago
  I don’t put all the source in context either - if you let Claude run the compiler (or even tests) it can avoid these issues
- bonzini 10mo ago
  Yep. It can refactor very well but that's it. For complex code bases it cannot even build boilerplate that makes sense; at most it saves some typing.
  - unregistereddev 10mo ago
    > It can refactor very well but that's it. Can it though? I thought it was most useful for writing new code, but have so far never had it correctly refactor existing code. Its refactoring attempts usually change behavior / logic, and sometimes even leave the code in a state where it's even harder to read.
- jollyllama 10mo ago
  Between yours and GP's comments, I find echoes of my experience: > Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. > Granted that's because the program is incredibly poorly written LLMs can't fix big, shitty legacy codebases. That is where most maintenance work (in terms of hours) is, and where it will remain. I would take it one step further and argue that LLMs and vibe-coding will compound into more big, shitty legacy codebases over time, and therefore, in the long arc, nothing will really change.
  - Espressosaurus 10mo ago

nuclearnicer 10mo ago

This is great. Asking questions of library code is a big pattern of mine too. Here's an example I saw on twitter. Asking an LLM to document a protocol from the codebase: https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf823672?q=tmux https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf... Do you think you will be able to capture any of this extra value? I think I'm faster at coding, but the overall corporate project timeline feels about the same. I feel more relaxed and confident that the work can be done. Not sure how to get a raise out of this.

loandbehold 10mo ago
For me, as a remote developer, it means I'm able to finish my work in 1 hour instead of 8 hours. So I'm able to capture "extra value" in the form of time. In our team everyone uses GitHub Copilot and I use Claude Code. My teammates' productivity increased slightly but my productivity increased a lot. This is because 1. Claude Code is just a better coding agent 2. I invested time to get good at agentic coding. Eventually Copilot will catch up and management will realize that now 1 developer can do what previously would take a whole team.
- overfeed 10mo ago
  I'm really curious on what your role is, and which industry are you in? I'm awed by these productivity gains others report, but I feel like AI helps in such a small part of my job (implementing specific changes as I direct). Agentic workflows for me results in bloated code, which is fine when I'm willing to hand over an subsystem to the agent, such as a frontend on a side project and have it vibe code the entire thing. Trying to get clean code erases all/most of my productivity gains, and doesn't spark joy. I find having a back-end-forth with an agent exhausting, probably because I have to build and discard multiple mental models of the proposed solution, since the approach can vary wildly between prompts. An agent can easily switch between using Newton-Raphson and bisection when asked to refactor unrelated arguments, which a human colleague wouldn't do after a code review.
  - saxenaabhi 10mo ago
    Not the OP but we use LLMs to build a restaurant pos system with reservations, loyalty, webshop etc. Almost at feature parity with bigwigs like lightspeed/toast. > I find having a back-end-forth with an agent exhausting, probably because I have to build and discard multiple mental models of the proposed solution, since the approach can vary wildly between prompts Just right now I had it improve QR payments on POS. This is standard stuff, and I have done it multiple time but i'm happy I didn't have to spend the mental energy to implement it and just had to review the code and test it. ``` Perfect! I've successfully implemented comprehensive network recovery strategies for the OnlinePaymentModal.tsx file. Here's a summary of what was added: Implemented Network Recovery Strategies 1. Exponential Backoff for Polling (lines 187-191) 2. Network Status Detection (lines 223-246, 248-251) 3. Transaction Timeout Handling (lines 110-119) 4. Retry Logic for Initial Transaction (lines 44-105) 5. AbortController for Request Cancellation (lines 134-139, 216-220) 6. Better Error Messaging (lines 85-102, 193-196) 7. Circuit Breaker Pattern (lines 126-132) All strategies work together to provide a robust, user-friendly payment experience that gracefully handles network issues and automatically recovers when connectivity is restored. ``` > An agent can easily switch between using Newton-Raphson and bisection when asked to refactor unrelated arguments, which a human colleague wouldn't do after a code review. Can you share what domain your work is in? Is it deeptech. Maybe coding agents right now work better for transactional/ecommerce systems?
    - deleted 10mo ago
      [deleted]
    - bccdee 10mo ago
      I don't know if that example is real, but if it is, that's exactly the reason I find AI tools irritating. You do not need six different ways to handle the connection being down, and if you do, you should really factor that out into a connection management layer. One of my big issues with LLM coding assistants is that they make it easy to write lots & lots of code. Meanwhile, code is a liability, and you should want less of it.
      - 10mo ago
- deleted 10mo ago
  [deleted]

dleeftink 10mo ago

Although many tools exist, there still seems to a large context gap here: we need better tools to orient ourselves and to navigate large (legacy) codebases. While not strictly a a source graph or the like, I do think Enso like interface may prove successful here[0].

zmmmmm 10mo ago

I've found this as well. In some cases we aren't fully authorised to use the AI tools for actual coding but even just asking "how would you make this change" or "where would you look to resolve this bug" or "give me an overview of how this process works" is amazingly helpful.

eru 10mo ago
> In some cases we aren't fully authorised to use the AI tools for actual coding but even just asking "how would you make this change" [...] Isn't the logical endpoint of this equivalent to printing out a Stackoverflow answer and manually typing it into your computer instead of copy-and-pasting? Nitpicks aside, I agree that contemporary AIs can be great for quickly getting up to speed with a code base. Both a new library or language you want to be using, and your own organisation's legacy code. One of the biggest advantages of using established ecosystem was that stack-overflow had a robust repository of already answered questions (and you could also buy books on it). With AI you can immediately cook up your own Stackoverflow community equivalent that provides answers promptly instead of closing your question as off-topic. And I pick Stackoverflow deliberately: it's a great resources, but not reliable enough to use blindly. I feel we are in a similar situation with AI at the moment. This will change gradually as the models become better. Just like Stackoverflow required less expertise to use than attending a university course. (And a university course requires less expertise than coming up with QuickSort in the first place.)
- ChrisMarshallNY 10mo ago
  > Isn't the logical endpoint of this equivalent to printing out a Stackoverflow answer and manually typing it into your computer instead of copy-and-pasting? Not in my case (I never used SO like that, anyway). I use it almost exactly like SO, except much more quickly and interactively (and without the inference that I’m “lazy,” or “stupid,” for not already knowing the answer). I have found that ChatGPT gives me better code than Claude (I write Swift); even learning my coding and documentation style. I still need to review all the code it gives me, and I have yet to use it verbatim, but it’s getting close. The most valuable thing, is I get an error, and I can ask it “Here’s the symptoms and the code. What do you think is going on?”. It usually gives me a good starting point. I could definitely figure it out on my own, but it might take half an hour. ChatGPT will give me a solid lead in about half a minute.

hello12343214 10mo ago

this was really interesting to read.

locknitpicker 10mo ago

> It's not about its ability to churn out lots of code quickly: it's an extra set of eyes/brain that works much faster that human developer. This is the key take right here. LLMs excel at parsing existing content, summarizing it, and use it to explore scenarios and hypotheticals. Even the best coding agents out there such as Claude Code or Gemini often fail to generate at the first try code that actually compiles, let alone does what it is expected to do. Apologists come up with excuses such as the legacy software is not architected well enough to be easily parseable by LLMs but that is a cheap excuse. The same reference LLMs often output utter crap in greenfield projects they themselves generated, and do so after a hand full of prompts. The state of a project is not the issue. The world is coming to the realization that the AI hype is not delivering. The talk of AI bubble is already mainstream. But like IDEs with auto complete, agents might not solve every problem but they are nevertheless useful and are here to stay. They are more a kin to a search engine where a user doesn't need to copy/paste code snippets to apply a code change. The sooner we realize this, the better.

Dave_Wishengrad 10mo ago
[dead]

locknitpicker 10mo ago

> Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. That's not the definition of legacy. Being there for a long time and getting lots of use is not what makes a legacy project "legacy". Legacy projects are characterized by not being maintained and having little to no test coverage. The term "legacy" means "I'm afraid to touch it because it might break and I doubt I can put it back together". Legacy means resistance to change. You can and do have legacy projects created a year or two ago. Most vibecoded apps fit the definition of legacy code. That is why legacy projects are a challenge to agentic coding. Agents already output huge volumes of code changes that developers struggle to review, let alone assert it's correctness. On legacy projects that are in production, this is disastrous.

tarsinge 10mo ago
What you list are common characteristics encountered in legacy systems, but what makes it legacy is a business decision of declaring it obsolete and in maintenance mode, and so that no money or time to be invested in it. Old systems that continues to evolve are not legacy, like say Linux, and yes like you say a project that is only one year old can be declared legacy. Resistance to change is only an economic variable that drives the decision. Vibecoded apps fits the definition because the developer is unlikely to want to invest more time in them for different reasons.
- locknitpicker 10mo ago
  > What you list are common characteristics encountered in legacy systems, but what makes it legacy is a business decision of declaring it obsolete and in maintenance mode, and so that no money or time to be invested in it. No, not necessarily. Business decisions are one of the many factors in creating legacy code,but they are by no means the single cause. A bigger factor is developers mismanaging a project to the point they became a unmaintainable mess. I personally went through a couple of projects which were legacy code the minute they hit production. One of them was even a proof of concept that a principal engineer, one of those infamous 10x types, decided to push as-is to production and leave two teams of engineers to sort out the mess left in his wake. I recommend reading "Working Effectively with Legacy Code" by Michael Feathers. It will certainly be eye-opening to some, as it dispels the myth that legacy code is a function of age.

lambdaone 10mo ago

Claude is insanely good at grunt-work maintenance coding, which is a fairly formulaic exercise that mostly requires RTFM and simple code changes that look a lot likw the surrounding code. Designing new things from scratch based on human specs is something which Claude still struggles with.

mcny 10mo ago
The problem is that it often doesn't get it right the first time. You have to sort of have a conversation and it eventually gets there but if you have no idea what the destination should be like, you can't guide it there.

curiousgal 10mo ago

I honestly don't know what code bases you guys are working with, for me I tried it with a large quant library (C++ 97) in an effort to modernize it and so far it's been nothing hit a waste of time. Similarly for a medium sized python quant codebase (3.6) trying to port it to 3.12, and it's also been a headache.

loandbehold 10mo ago
Email me loandbehold0 at proton.me with details of what you are trying to do. I don't have quantitative finance experience but I can give it a shot.

Jean-Papoulos 10mo ago

I have the opposite experience. Claude can't get it all in the context window and make changes that will completely break something on the other side of the program. Granted that's because the program is incredibly poorly written, but still, context window will stay a huge barrier for quite some time.

zinodaur 10mo ago
I don’t put all the source in context either - if you let Claude run the compiler (or even tests) it can avoid these issues
bonzini 10mo ago
Yep. It can refactor very well but that's it. For complex code bases it cannot even build boilerplate that makes sense; at most it saves some typing.
- unregistereddev 10mo ago
  > It can refactor very well but that's it. Can it though? I thought it was most useful for writing new code, but have so far never had it correctly refactor existing code. Its refactoring attempts usually change behavior / logic, and sometimes even leave the code in a state where it's even harder to read.
jollyllama 10mo ago
Between yours and GP's comments, I find echoes of my experience: > Most of software work is maintaining "legacy" code, that is older systems that have been around for a long time and get a lot of use. > Granted that's because the program is incredibly poorly written LLMs can't fix big, shitty legacy codebases. That is where most maintenance work (in terms of hours) is, and where it will remain. I would take it one step further and argue that LLMs and vibe-coding will compound into more big, shitty legacy codebases over time, and therefore, in the long arc, nothing will really change.
- Espressosaurus 10mo ago