The First 90 Days as an AI Engineer: A 30-60-90 Plan

What success actually looks like in the first 90 days

Most advice aimed at AI engineers is about getting hired: the portfolio, the take-home, the system-design interview. Almost none of it covers what happens once you have the badge and the laptop. That gap matters, because the first quarter is where a strong interview performance either converts into a strong hire or quietly does not — and unlike the interview, nobody is grading you against a fixed rubric anymore. You have to build your own.

• Day 30 is about understanding, plus one small proof point. You should be able to explain the system to a peer, run the team's existing evaluation harness yourself, and point to one small, reviewed, shipped change.
• Day 60 is about ownership. You should have taken at least one feature or workstream from problem statement to production, and touched the team's eval or quality infrastructure directly rather than working around it.
• Day 90 is about autonomy that has actually been tested. You should have proposed and shipped something nobody assigned you, and understand what happens — including the incident and on-call process — when your own change breaks something.
• Throughout, visibility is not optional. What you build only counts toward your case for the role, your performance review and your future portfolio if someone else can see and check it.

This structure borrows from Michael Watkins's widely used management-transition framework, The First 90 Days, which argues the actions a person takes in their first three months in a new role — learning the system, then securing early wins, then accelerating — largely determine whether the transition succeeds. Watkins wrote it for leadership transitions specifically; what follows adapts the same logic to the concrete, checkable milestones of an individual-contributor AI engineering role, whether that is a first job, a lateral move, or a jump from classical software engineering into an AI-native team.

Days 1–30: understand the system before you touch it

The instinct to prove yourself immediately is strong, and it is the wrong instinct for the first thirty days. Engineering-onboarding research consistently frames this period as a listening phase: understand the system, the team's norms and the actual shape of the problem before trying to change any of it. The engineers who spend this window listening earn the credibility to act decisively in months two and three; the ones who skip it usually end up redoing work once they understand why things were built the way they were.

Concretely, in the first thirty days you should be reading the eval harness before you read the model code, because the eval harness tells you what the team actually considers "correct" — a detail rarely fully captured in a design doc. You should be shadowing at least one code review cycle end to end, including how disagreements get resolved. You should know where the data comes from, who owns it, and what its known failure modes are, because in most AI teams data quality issues, not model choice, are what actually break production. And you should have shipped at least one small, real, reviewed change — not a toy script, a change that went through the team's normal review and deploy process.

Time-to-first-commit is a reasonable rough proxy here, and it varies a great deal by team. One widely cited engineering-metrics analysis puts a strong benchmark at a first commit within three to five days, against a median across the industry closer to two to three weeks — and treats a small feature shipped within the first month, followed by genuinely independent work by month three, as the realistic best-practice milestone shape. Treat any specific day-count as directional rather than a hard deadline: a 400,000-line monorepo with a bespoke data platform will reasonably take longer to get productive in than a green-field service, and that difference says more about the codebase than about you.

What "day 30 done" looks like

• You can draw or narrate the system's architecture and data flow from memory, without notes.
• You can run the existing eval suite or test harness yourself, and explain in plain terms what it measures and why.
• You have identified who owns each adjacent system and data source, and have working access to what you actually need — or have escalated the gap.
• At least one small, real change is merged and shipped under normal review, not as a special exception.
• You have sent your manager a short written note — even five bullet points — on what you have learned and where you are stuck.

Days 31–60: own a feature end to end

Month two is where the emphasis flips from observation to contribution. You now have enough context to stop asking "how does this work" and start asking "what should we do about this." The clearest sign of progress by day 60 is ownership of a feature, bug or workstream from a rough problem statement through design, implementation, code review and shipping — with you making the implementation calls, not someone else making them for you and having you execute.

For an AI-specific role, the second, equally important marker is contact with the team's evaluation or quality-measurement infrastructure. This might mean adding a new eval case that catches a regression nobody had a test for, tuning a prompt or a retrieval step and measuring the before-and-after with a real number, or fixing a broken or misleading metric that was quietly giving the team false confidence. If your team runs evals in CI, this is the point at which you should have a merged pull request touching that pipeline — see our companion guide on putting evals in CI for prompt and agent regression for what a healthy version of that infrastructure looks like, if you want the fuller picture. Engineers who route around the eval harness instead of engaging with it tend to look productive in week five and look risky by week ten, once their untested changes start causing regressions nobody predicted.

What "day 60 done" looks like

• You own at least one feature, service or workstream end to end, including the decisions inside it.
• You have made at least one contribution — a new eval case, a metric fix, a prompt or model change with a measured delta — to how the team measures quality.
• You can explain a design trade-off you made and why, not just what you built.
• Your manager or lead has reviewed and approved your work through the normal process, with no special scaffolding.
• You have written up or demoed what you shipped, even informally, to at least one person outside your immediate reviewer.

Days 61–90: prove you can operate without hand-holding

The final stretch is where autonomy gets tested, not assumed. The clearest marker by day 90 is that you proposed an improvement — a refactor, a new eval, a cost or latency fix, a data-quality catch — that nobody explicitly assigned you, got it reviewed on its merits, and shipped it. That single act demonstrates judgement in a way that executing assigned tickets, however well, cannot: it shows you can independently spot what matters and build a case for it.

The second marker, often skipped by engineers who come from a pure research or data-science background, is understanding your team's incident and on-call process before you need it in a crisis. Even if you are not yet on the on-call rota yourself, by day 90 you should know what happens when a model or pipeline change causes a production issue: who gets paged, how a rollback works, what the escalation path looks like, and what "sev" levels mean at your company. Waiting until an actual incident to learn this is a genuinely bad way to learn it.

What "day 90 done" looks like

• You have proposed and shipped at least one improvement that was not assigned to you.
• You understand your team's incident, rollback and on-call process well enough to describe it to someone else.
• Your manager needs progressively less context from you to trust your judgement on a design decision.
• You have a running, written record — notes, a demo, an internal doc — of what you have shipped since day one.
• You could walk into your first formal performance conversation with concrete evidence, not a summary from memory.

The 30-60-90 milestone table, side by side

Use this as a working checklist in your own one-to-ones — most managers will happily co-create or adjust it with you if you bring a draft rather than waiting to be handed one.

Dimension	Day 30	Day 60	Day 90
Codebase & data	Read access secured; can explain architecture and data flow to a peer	Owns at least one module or service; understands the data pipeline end to end	Could help onboard the next hire into this area unassisted
Shipped work	One small, reviewed fix merged through normal process	One feature or workstream owned end to end, shipped to production	Proposed and shipped an improvement nobody assigned
Evals & quality	Can run the existing eval suite and explain what it measures	Added, fixed or improved one eval case tied to a real regression	An eval or metric change with a documented before-and-after number
Autonomy	Asks good questions; escalates blockers the same day	Makes implementation decisions inside a reviewed pull request unaided	Understands incident/on-call process; needs minimal check-ins on a small workstream
Visibility	Short written learning notes shared with manager	Demo or internal write-up of the shipped feature	A running record cited as evidence in the first performance conversation

Common failure modes that quietly sink a strong hire

None of these are exotic. They are the same handful of patterns that show up, in slightly different clothes, at a five-person seed-stage team and a thousand-person enterprise AI division alike.

Failure mode	What it looks like in practice	The fix
Going quiet	Disappears into a ticket for two weeks; no visible update until asked directly	Send a short written update every week, even "still stuck on X, here's what I've tried"
Over-promising early	Commits to a timeline in week one before understanding the system, then slips it	Give ranged estimates; flag complexity risk the moment you notice it, not after the deadline
Ignoring existing eval infra	Builds a parallel, private test script instead of learning the team's harness	Spend day one to two asking "how do we know if this worked" before writing code
Not asking about data access early	Waits weeks for credentials or a dataset instead of escalating the blocker	Raise access gaps to your manager in writing on the day you hit them, not the week after
Skipping the incident/on-call picture	Ships changes without knowing how rollback or escalation actually works	Shadow an on-call rotation or incident review before you ship anything customer-facing
The premature rewrite	Proposes replacing a working system in week two, before earning any credibility	Bank a few small, visible wins first; save the ambitious proposal for after day 60

The honest self-assessment: rate yourself before your manager does

Run this against yourself at each thirty-day mark, ideally in writing, before the formal check-in happens. The value is not in a perfect score — it is in noticing where you are honestly unsure, because that is exactly what a good manager will ask about anyway.

• Can I explain, out loud, what our eval harness actually measures and why it was built that way?
• Have I shipped something real through the normal review process, without special exceptions made for me?
• Do I know who owns each system and dataset I depend on, and do I have working access to what I need?
• Have I raised every blocker the same day I hit it, in writing, rather than sitting on it?
• Can I point to a specific, measurable improvement I am responsible for — not just a ticket I closed?
• Do I understand what happens, technically and procedurally, if my change breaks something in production?
• Have I proposed at least one thing nobody explicitly asked me to build?
• Is there a written or demoable record of what I have done, or does it all live only in my own memory?

Answering "not yet" to several of these at day 30 is completely normal. Answering "not yet" to most of them at day 90 is the pattern worth raising directly with your manager, before a performance cycle raises it for you.

Build the track record before the performance review needs it

The evidence above — the shipped feature, the eval contribution, the proposed improvement — only helps you if it is visible to someone other than you. Left undocumented, a genuinely strong first ninety days can still evaporate into "I think I did well, broadly" by the time a formal review rolls around six months later, because neither you nor your manager can recall the specifics with any precision. The fix is unglamorous and cheap: write a short note after anything non-trivial you ship, keep a running list of what you touched and why it mattered, and demo real work to people outside your immediate reviewer whenever you get the chance.

This habit pays twice. It gives your manager concrete material for your first performance conversation instead of a vague impression. And it becomes the raw material for your next move, whenever that is — the same shipped feature, eval contribution or incident write-up that supports this year's review is also exactly the kind of proof-of-work that makes a portfolio credible the next time you are job-hunting, whether that is at your current employer or somewhere new. A public Verified Builder profile is a natural home for that record: a place to lay out what you actually shipped in a form a manager, a promotion panel or a future employer can check, rather than take on trust. If you are already thinking about where this role leads next, our guide to the AI engineer career ladder from junior to Staff maps out what "more autonomy" looks like once the first ninety days are behind you — and if you are the one designing the process a new hire is walking into, our companion piece on hiring, or becoming, a team's first AI engineer covers the other side of exactly this problem.

So — are you on track?

There is no single universally correct pace, and probation structures differ by market and company size: India-based roles commonly run a three-to-six-month probation window with a shorter notice period during it, while UK contracts typically guarantee at least one week's notice once you are past the first month, with many employers extending informal check-ins well past the ninety-day mark for genuinely complex roles. What does not vary by market is the underlying test: did you move from understanding to ownership to autonomy, and can anyone other than you see that you did?

If you are still mostly reading code and asking questions at day 45, that is not automatically a problem — codebases, data platforms and team norms vary enormously in how long they take to absorb, and a harder system honestly deserves a longer runway. What is worth addressing directly, and early, is silence: if you cannot point to a shipped change, a documented blocker you raised, or a question you asked about the eval harness and data access in your first month, that is the pattern to fix immediately, not the exact day-count. Treat this plan the way Watkins intended the original — a direction and a set of checkable milestones to revisit and adjust, not a contract to recite back verbatim at your ninety-day review.