Week 2

Unfamiliar codebases

Not breaking things

Feature isolation and boundaries

Practice

Assignment

Back to Track

How the agent reads an unfamiliar codebase

There's no magic. The agent doesn't hold the whole project in its head — it works through the context window (Week 1) and pulls files in as needed:

1. Looks at the folder structure to get the map.
2. Reads entry points (main files, configs, package manifests).
3. Searches by keywords — function and class names, error strings.
4. Follows imports from the files it has opened.

That's it. It reads what looks relevant, not everything.

Two consequences you will hit this week

1. It can duplicate code it hasn't read. If the project already has a formatDate() helper and the agent never opened that file, it will happily write a second one. This isn't stupidity — it literally doesn't know. The fix is yours: point it to what exists.

2. Precise direction beats broad requests. "Add date formatting to the profile page" makes the agent guess where things live. "Add date formatting to the profile page — use the existing helper in src/utils/date.ts, the page component is src/pages/Profile.tsx" removes the guessing. The more of the map you give it, the less it improvises.

Start every session in a new codebase the same way

Before asking for any change, make the agent build its map — and check it against reality:

• "Give me an overview of this project: structure, main technologies, where the app starts."
• "How does [the area you'll touch] work here? Which files are involved?"
• "What conventions does this codebase follow?"

Then verify one claim yourself — open one of the files it names and check. Week 1's rule applies: confident ≠ correct.

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.