I recently moved from data science into AI engineering. I can write code, but I have less experience with traditional software engineering, so I often use AI to help implement features and explain unfamiliar code. I can usually follow individual lines, but I struggle to retain the larger picture: the architecture, data flow, dependencies, and reasons behind design decisions. What routines or exercises help with reading unfamiliar code, reviewing changes, tracing execution, and building a lasting mental model of a system? How do experienced developers approach a new codebase without becoming dependent on an AI assistant for every step?
4 Answers
A debugger is a great bridge between knowing individual lines and understanding the whole system. Put a breakpoint in an important function, inspect the call stack to see how execution got there, and step into functions to follow dependencies. Watch the values change as the request moves through the system. Starting from an open bug or a small feature is often more productive than trying to understand the entire repository at once. Use an AI assistant to point out possible routes or symbols, but verify the explanation by tracing the code and running it yourself.
Use two reading modes. First, skim the project to locate the important areas, such as routes, commands, event handlers, or other entry points. Treat each entry point like a small main function and trace it through to its return or output. Once you find relevant code, switch to detailed reading or run it under a debugger, stepping through the execution line by line. Starting with a real behavior or API makes the architecture much easier to understand than reading files in arbitrary order.
Pick one concrete behavior, such as processing a request or generating a result, and explain what you expect the system to do. Find the code that produces the final result, then work backward through its inputs and assumptions. At each step, check whether the upstream code actually provides what you expected. You can also make a small change, predict its effect, and run the tests or program to verify your prediction. Explaining the flow aloud to yourself, a colleague, or even a rubber duck helps turn passive reading into an actual mental model.
Before diving deeply into application code, get a basic map of the frameworks, libraries, and recurring patterns it uses. Identify the main modules, configuration, routes, data stores, background jobs, and test structure. Those conventions explain many design choices. For decisions that still seem strange, inspect the history: git blame can show when a line was introduced, and git log -p for a file often reveals the original reasoning better than the current code comments.
The entry-point approach makes sense. I still need some help identifying those points, but I can use that as a specific thing to look for instead of asking for a general explanation.