First 90 days as a junior engineer on an AI-heavy team: what to learn first

You took the offer. The team uses Cursor or Copilot for almost every PR, runs an internal RAG bot over the docs, and at least one senior engineer is building agent workflows on the side. Your onboarding doc is half-written because the person who owned it left, and the codebase has roughly 40% more surface area than the org chart suggests, because LLMs have made it cheap to ship adapters, scripts, and one-off services nobody fully owns.

This is the environment most junior engineers walk into in 2026. The traditional advice — read the codebase, ask questions, find a mentor — still applies, but it doesn’t tell you what to prioritize when the senior engineers around you are visibly faster than you because they’ve internalized tools you’ve never touched. Below is a 90-day plan that assumes you have decent fundamentals (you can write a function, you understand HTTP, you’ve used git) but you’re new to working in a codebase where AI is a first-class collaborator.

Days 1-30: read more than you write, and read what the AI reads

The biggest mistake juniors make in AI-heavy teams is opening Cursor on day three and trying to ship a feature. You will produce code that compiles, passes the obvious tests, and quietly violates three conventions nobody wrote down. Your PR will get approved by a tired senior because rejecting AI-generated junior code costs political capital. You will learn nothing.

Instead, spend the first month doing three things in roughly equal proportion:

1. Read the codebase the way the AI reads it. Look at how the repo is structured for retrieval. Most AI-heavy teams have a CLAUDE.md, .cursorrules, AGENTS.md, or an internal RAG index. These files encode the conventions, the patterns the team wants reinforced, and — critically — the things the team has had to tell the AI not to do. Forbidden patterns are usually the result of an incident. Read them. Ask which incident produced each one.

2. Read closed PRs, not open ones. Open PRs are noisy. Closed PRs from the last 90 days show you what the team actually merges, what gets rejected, and what review comments look like. Sort by author and read every PR from the two engineers whose taste you trust most. You’ll learn more about the team’s house style in a weekend than in a quarter of pairing.

3. Read your own AI-generated code with hostility. When you start writing, generate aggressively, then delete aggressively. The skill you’re building this month isn’t “how to prompt Cursor” — it’s how to recognize when the LLM has produced something that looks reasonable but doesn’t fit. Read every diff line by line. If you can’t explain why a line is there, don’t ship it.

Days 31-60: pick one system and go deep

In month two, the temptation is to keep grazing — touch the frontend on Monday, the data pipeline on Wednesday, write a small Lambda on Friday. AI tools make this kind of surface-level work feel productive. It isn’t. You need at least one system in the codebase where you are the person on the team with the most loaded context.

Pick something with these properties: it’s not glamorous, it has clear inputs and outputs, it gets touched roughly weekly, and one specific senior engineer cares about it. Examples: the authentication flow, the job queue, the billing reconciliation script, the search ranker. Avoid anything labeled “AI” or “ML” for now — those systems are over-staffed with senior attention and you won’t get repetitions.

Once you’ve picked it, do the unglamorous work:

• Map every entry point. Write the map down in your own notes.
• Read every test. Run them locally. Break them on purpose to see what they catch.
• Find the three most recent bugs in this system and read the fixes. Were they regressions? Edge cases? Bad assumptions?
• Ship two or three small changes to it — a refactor, a test, a config tweak — without using AI assistance. Then ship two or three with AI assistance. Notice the difference in how confident you feel.

The goal of month two isn’t to become an expert. It’s to have one area where, when a Slack message comes in about a weird behavior, you can confidently say “I’ll look” instead of “can someone else take this.” That single shift — from generalist consumer of AI output to specific owner of one corner — is what separates juniors who get promoted from juniors who get quietly managed out.

Days 61-90: learn the team’s evaluation taste

By now you’ve shipped enough that people have opinions about your work. Month three is when you stop treating every PR as a task and start treating it as a data point about the team’s standards.

The skill that will compound for your entire career — and which AI tools cannot do for you — is taste. Taste in this context means: knowing what “good” looks like for your specific team before you write the code. AI can generate ten plausible implementations. Only a human who has internalized the team’s values knows which one to pick.

Start building this deliberately:

• Before opening Cursor on a ticket, sketch the approach in plain text. What are you going to change, why, and what alternatives did you consider? Two paragraphs. Show it to a senior before writing code on anything non-trivial.
• Keep a private doc (Notion, Obsidian, a flat markdown file — doesn’t matter) of every piece of review feedback you’ve received. Re-read it monthly. Patterns emerge.
• Pair on at least one debugging session per week with someone senior. Not coding — debugging. Watching a senior engineer form a hypothesis, narrow it down, and verify it is the single highest-leverage thing you can do in your first year. AI tools are bad at debugging. Humans who are good at it are the ones who get hard problems routed to them.

A practical note on AI tools specifically: by day 90, you should be able to articulate which parts of your work AI accelerates and which parts it actively slows you down. For most juniors on most teams, the honest answer is that AI is great for boilerplate, scaffolding tests, and explaining unfamiliar code, and worse than useless for architectural decisions, debugging subtle bugs, and writing code in unusual parts of your stack. Knowing the boundary is the skill.

Don’t let anyone — especially your own anxiety about not being fast enough — push you into using AI for the parts of the job where it makes you worse. The seniors on your team know the difference. You’ll be evaluated on whether you do too.