I can write small programs on my own—I used to make simple VBA macros, completed most of my school assignments with little AI assistance, and even enjoy solving coding problems. However, those projects were all under roughly 300 lines of code. Now that I'm interning as a software engineer, I'm struggling to understand a much larger existing codebase without AI explaining it to me.
Recently, I was asked to add support for a new user input format. I expected it to be a fairly contained change, but an AI coding assistant produced a plan involving more than 30 files and over 1,000 lines of changes. I can follow the overall explanation and ask the assistant why it made certain choices, but when I trace the actual code, I quickly lose track of how everything fits together.
How do experienced developers build and maintain a mental model of a large system? What techniques help with understanding which parts of the code affect one another? Is it still worth spending the time to review and understand the implementation in detail when modern AI tools can explain or generate so much of it?
5 Answers
Use practical tools instead of relying only on memory: search for references, inspect call hierarchies, add temporary logging, run focused tests, and step through the code with a debugger. You only need a detailed understanding of the paths involved in your current change. Learn the rest as needed, while keeping a high-level map of the major components.
You don’t try to hold an entire 30-file change in your head at once. Read the system in small pieces, take notes, trace the data flow, and build a map of the important modules and boundaries over time. Comments, diagrams, tests, logs, and a debugger can all help. Large changes become manageable when you understand one layer at a time.
A plan touching 30 files may be justified, but it can also indicate that the feature request was underspecified, the codebase has too many cross-cutting responsibilities, or the AI is adding unnecessary complexity. Ask for a minimal implementation, limit changes to existing patterns, and have the tool explain why each file is needed. Then verify the result yourself rather than treating the generated plan as authoritative.
People learned this by reading code, writing code, debugging failures, and gradually forming a mental model of the system. It is slower at first, especially compared with having an AI summarize everything, but the skill develops through repetition. Start with a small task, follow one request from entry point to result, write down what you discover, and update your notes as your understanding improves.
Break the feature into responsibilities and ask what each part is supposed to do. For a new input format, that might include the UI or configuration, parsing and validation, conversion into an internal representation, business logic, and output handling. Ideally those pieces communicate through clear interfaces instead of reaching into one another directly. Once you understand those interfaces, you don’t need to remember every line of implementation.
Even if the assistant produces the code, understanding the design and reviewing the behavior is still part of the job. Generated code can compile while violating the project’s conventions, hiding edge cases, or making future maintenance harder.