The first thing an engineer faces on a new project is unfamiliar code: hundreds of files, someone else's decisions, zero context. This used to take weeks. An agent that can read a repository cuts it to hours — but only if you use it right, rather than asking "explain the whole project".

Go top-down

Don't start with details. Ask the agent to build understanding in layers, from general to specific:

  1. A map of the project. "Describe the structure: what modules exist, what each is responsible for, where the entry points are." This gives the skeleton.
  2. Key flows. "Trace the path of a create-order request: from the controller to the database, which classes take part." This is how you see how the parts connect.
  3. A concrete piece. "Break down what this method does and who calls it." Now you have somewhere to plug your work in.

This order mirrors a healthy ramp-up into a project: first the map, then the routes, then the house. The reverse order (straight into details) leaves you with fragments and no picture.

Ask questions, not just "explain"

The agent is most useful not as a narrator but as an answerer of concrete questions:

  • "Where is order cancellation handled?"
  • "What happens if an empty list arrives here?"
  • "Who changes the order status, and in which places?"
  • "Why are there two different ways of doing the same thing here?"

These are the same questions you'd ask a colleague who knows the project. The difference is that the agent answers in seconds and doesn't tire of "dumb" questions.

Check answers against the code

The key caveat: the agent can confidently be wrong. It can retell logic that isn't there, or skip a branch. So:

  • Ask for links to specific files and lines — "show me where exactly this happens". An answer with no anchor in the code is a reason to be wary.
  • Verify yourself on the important things: open the named file, check that it really contains what the agent said.
  • Don't accept architectural conclusions blindly — "this is bad design, it needs a rewrite" may be true or a hallucination. Check before acting.

An agent that reads code directly (via tools — search, reading files) is more reliable than a model answering "from memory": it relies on the real code, not a guess.

Where it especially helps

  • Legacy without documentation — the agent reads what nobody described.
  • Fast ramp-up — a new person understands in a day what used to take a week.
  • Locating a problem — "where is this sum computed?" instead of manually grepping the whole repository.
  • Before a change — "what will I affect if I change this method?" reduces the risk of breaking neighbors.

What this means in practice

The agent turns someone else's codebase from a wall into a map you can ask questions of. A product engineer uses it to get, in hours, a picture that used to cost weeks — but checks the key answers against the code itself, because a confident retelling and the truth aren't the same thing. Understood the system → you can change it deliberately.

What's next

Having understood how the project is built, you move to changes: developing features through plans and brainstorming and finding and fixing bugs.