Ask HN: How are you LLM-coding in an established code base?

We use claude code, running it inside a docker container (the project was already set up so that all the dev tools and server setup is in docker, making this easy); the interface between claude code and a developer is effectively the file system. The docker container doesn't have git credentials, so claude code can see git history etc and do local git ops (e.g. git mv) but not actually push anything without a review. Developers review the output and then do git add between steps, or instruct Claude to refactor until happy; then git commit at the end of a longer task.

Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production. We already had existing rules for how the project is organized and how to write code and tests in CONTRIBUTING.md, making this relatively easy, but this file then co-evolved with Claude. Every time it did something unexpected, we'd tell it to update contributing rules to prevent something like that from happening again. After a while, this file grew considerably, so we asked Claude to go through it, reduce the size but keep the precision and instructions, and it did a relatively good job. The file has stabilized after a few months, and we rarely touch it any more.

Generally, tasks for AI-assisted work start with a problem statement in a md file (we keep these in a /roadmap folder under the project), and sometimes a general direction for a proposed solution. We ask Claude code to an analysis and propose a plan (using a custom command that restricts plans to be composed of backwards compatible small steps modifying no more than 3-4 files). A human will read the plan and then iterate on it, telling Claude to modify it where necessary, and then start the work. After each step, Claude runs all unit tests for things that have changed, a bunch of guardrails (linting etc) and tests for the wider project area it's working in, fixing stuff if needed. A developer then reviews the output, requests refactoring if needed, does git add, and tells claude to run the next step. This review might also involve deploying the server code to our test environment if needed.

Claude uses the roadmap markdown file as an internal memory of the progress and key conclusions between steps, and to help with restoring the progress after context resets. Pretty much after the initial review, Claude only uses this file, we don't look at it any more. Once done, this plan file is thrown away - tests and code remain. We occasionally ask it to evaluate if there are any important conclusions to record in the architectural design records or contributing guide.

This small piece of text is the best guide to use LLM for coding I have seen so far.

One thing I think people confuse with context is they see an LLM has say 400k context and think their codebase is way bigger than that, how can it possibly work. Well, do you hold a 10 million line codebase in your head at once? Of course not. You have an intuitive grasp of how the system is built and laid out, and some general names of things, and before you make a change, you might search through the codebase for specific terms to see what shows up. LLMs do the same thing. They grep through the codebase and read in only files with interesting / matching terms and only the part of the file thats relevant, in much the same way you would open a search result and only view the surrounding method or so. The context is barely used in these scenarios. Context is not something that’s static, it’s built dynamically as the conversation progresses via data coming from your system (partially through tool use).

I frequently use LLMs in a VS Code workspace with around 40 repos, consisting of microservices, frontends, nuget and npm packages, IaC, etc. altogether its many millions of lines of code. and I can ask it questions about anything the codebase and it has no issues managing context. I do not even add files manually to context (this is worse actually because it puts the entire file into context even if it’s not all used). I just refer to the files by name and the LLM is smart enough to read them in as appropriate. I have a couple JSON files that are megs of configuration, and I can tell it to summarize / extract examples out of those files and it’ll just sample sections to get an overview.

Why not? Cost? Inexperience? Bad outcomes?

will email! Your homepage doesn't make the environment part clear - it reads like it's akin to cursor multiple agent mode (Which I think you had first, FWIW).