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.

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.

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

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

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.

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

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

this was really interesting to read.

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.