First Week in a New Codebase

Before changing anything in an unfamiliar codebase, take a baseline of its health. It tells you where the risk is, where the quick wins are, and it gives you something to measure against later.

The checklist

• Project structure: how it’s laid out, where the boundaries are, what’s shared.
• Dependency health: outdated or abandoned packages, and how far behind the major versions are.
• Security scan: a dependency scanner (Snyk or equivalent) plus static code scanning.
• Performance metrics: what’s measured today, and what the numbers are.
• Build time, both in CI and locally.
• PR history: typical size, review quality, how clean the git history is.
• Lint rules: what’s enforced, what’s disabled, what’s ignored inline.
• TypeScript: how strictly it’s used, and the tsconfig settings.

Why bother

The baseline doubles as evidence. “Build time went from X to Y” is a concrete, defensible win, and scan results make the case for tech-debt work far better than a feeling that “the dependencies are a bit old”. It also stops you fixing the loudest problem instead of the most important one.

It’s a good first task to hand to a coding agent too, as long as you check what it reports (Working with AI Coding Agents). Once you start changing things, keep the changes small: Slicing Pull Requests.