undefined | Better HN

0 pointsgibspaulding9mo ago0 comments

> Where AI-agents are the most useful for us is with legacy code

I’d love to hear more about your workflow and the code base you’re working in. I have access to Amazon Q (which it looks like is using Claude Sonnet 4 behind the scenes) through work, and while I found it very useful for Greenfield projects, I’ve really struggled using it to work on our older code bases. These are all single file 20,000 to 100,000 line C modules with lots of global variables and most of the logic plus 25 years of changes dumped into a few long functions. It’s hard to navigate for a human, but seems to completely overwhelm Q’s context window.

Do other Agents handle this sort of scenario better, or are there tricks to making things more manageable? Obviously re-factoring to break everything up into smaller files and smaller functions would be great, but that’s just the sort of project that I want to be able to use the AI for.

0 comments

devjab9mo ago

We use co-pilot through our azure license in VSC. My personal workflow is that I'll write a VIBE.md with very specific information on what I want and what I rexpect. Then in the actual code file I'll add a comment like "COPILOT: this is where I want you to do X". I'll then grant the agent access to the necessary files for the context. With big files it gets trickier because the prediction engine fails to distinguish between relevant and irrelevant context. I have the most success with incremental changes where the agent has to do one task at a time, and you can outline that in the VIBE.md + the comments where you add "COPILOT: This is step X...". In my coordinate example it actually had to change quite a lot of things, but that is still what I consider one task.

Context size matters a lot in my experience, but I'm not sure if it matters whether your 100k lines are in a single or multiple files. I tend to cut down what I feed the agent to the actual context, so if I have a 100k line file, but only 3000 lines matter, then I'll only feed those 3000 lines to the AI. Even in a couple of small files with maybe 200 lines of code in total, I'll only give the AI access to the 40 line which is the context it needs to work on.

English isn't my first language, so when I say context, what I mean is everything which is related to the change I want the agent to do. I will use SQLC as an example. Even though I feed the AI the Go model generated, I'll also give it access to the raw SQL file.

> Obviously re-factoring to break everything up into smaller files and smaller functions would be great, but that’s just the sort of project that I want to be able to use the AI for.

I'm guessing here, but I think part of our success is also our YAGNI approach. AI seem to have an easier time with something like Go where everything is explicit, everything is functions and Go modules live in isolation. Similarily AI will do much better with Python that is build with dataclasses and functions, and struggle with Python that is build upon more traditional OOP hierarchies. We've also had very little success with agents on C#. I have no idea whether that is because of C#'s inherrent implicity and "black magic" or because of the .net > .net core > .net framework > .net + whatever I forgot journey confusing the prediction engine.

> Do other Agents handle this sort of scenario better

I don't know. I've only used the sanctioned co-pilot agent professionally. I believe that is a GPT-4 model, but I'm not exactly sure on the details. For personal projects I use both the free version of GPT-4 in co-pilot and Claude Sonnet 4, and I haven't noticed much of a difference, but I have no hobby projects which are compareable.

j / k navigate · click thread line to collapse