I can write small programs on my own, including simple VBA macros, school assignments, and even coding challenge problems. However, those projects were all under a few hundred lines. I'm currently interning as a software engineer and struggling to understand a much larger existing codebase without AI assistance.
Recently, I was asked to add support for a new user input format. I expected a fairly contained change, but an AI coding assistant suggested modifying more than 30 files and over 1,000 lines of code. I can understand the plan at a high level and ask the assistant to explain its choices, but when I trace the implementation in detail, I quickly lose track of how everything connects.
How did developers traditionally understand and modify large codebases before AI tools were available? Is the best approach simply to read the code, take notes, and build a mental model over time? Given how capable current AI models are, how much effort should I still spend reviewing and understanding the generated plan and code myself?
5 Answers
A new input format can legitimately affect several layers—for example, the user interface, API or parser, internal data structures, validation, and downstream handlers. But a plan that changes 30 files and 1,000 lines deserves careful investigation. Before accepting it, ask whether the feature requirements are clear, whether existing abstractions are being reused, and whether the assistant is adding unnecessary structure or duplicated logic.
The basic method hasn’t changed: read, experiment, take notes, and repeat. Run the program, use logs or a debugger to follow an actual request, and compare what you observe with your mental model. Over time, you’ll remember the important paths and recognize which details can be safely treated as implementation boundaries. AI mainly makes the first pass faster; it doesn’t remove the need to develop that model.
You don’t hold an entire 30-file change in your head at once. Break it into small pieces, trace the data flow one layer at a time, and write down what each module is responsible for. Build a rough map of the system first, then fill in the details as you work. Nobody understands a large codebase instantly; familiarity develops through repeated reading and small changes.
Use the AI as a guide, not as a substitute for understanding. Ask it to explain the existing architecture, list the files involved, and propose the smallest possible change. You can also ask it to justify every modified file and remove anything that is not required. Then inspect the relevant code yourself, add logging or tests, and verify that the implementation matches the system’s actual behavior. Reviewing generated code is part of the job, especially when you’ll be responsible for maintaining it later.
Start by identifying the boundaries: what receives the input, what parses or validates it, which internal representation is created, and where that representation is consumed. Ideally, those areas communicate through clear interfaces and can be understood independently. If every new format requires touching dozens of unrelated files, the code may have responsibilities spread too widely—or the requested change may not have been scoped clearly.
That makes sense. I was treating the generated plan as something I had to understand all at once instead of checking each boundary and following one real input through the system.