The AI engineering ladder: what each level's week looks like

Job ladders describe levels in abstractions like “scope”, “ambiguity” and “influence”. Those words are accurate and nearly useless when you are trying to decide what to do on Monday. This post describes the same ladder in terms of what your calendar and your pull requests look like, specifically for engineers building with language models, and what evidence moves you up a rung. Titles and bands differ between companies; the shape below holds across most of them.

Every level is defined by the size of the problem you can be handed and trusted to finish without someone else re-scoping it. A Budding engineer is given a task. A Mid-level engineer is given a feature. A Senior engineer is given a system and its operational health. A Staff engineer is given a problem that spans systems or teams, and is often the person who noticed it was a problem.

Most of the week is building against a spec someone else wrote: wiring a model call into an endpoint, writing the ingestion script for a new document source, adding a field to a prompt template, fixing a flaky test. A healthy Budding week also includes reading other people's code reviews, pairing for an hour, and running the team's evaluation set locally to see what it actually checks.

Evidence that gets you promoted: tasks closed without rework; pull requests that arrive with tests and a short note on how you verified them; and, the signal reviewers notice most, questions that got sharper over the quarter. Asking “what should the model do when retrieval returns nothing?” before writing code is a Mid-level habit showing up early.

You own a feature from design note to launch: say, citation links in an internal-wiki assistant. Monday is a one-page design. Tuesday to Thursday is building and, crucially, building the measurement: a golden set of 50 to 100 real questions with known answers, and a script that scores the feature on it. Friday is reading failures, which is error analysis: sorting wrong answers into buckets such as “retrieval missed”, “right chunk, wrong answer”, “question was ambiguous”, and fixing the largest bucket first.

Evidence that gets you promoted: a feature that shipped and stayed shipped; a before-and-after number on a golden set you built; a design note that a Senior engineer approved with few changes. The jump from Budding to Mid is the jump from “it works on my examples” to “here is how often it works, and here is how I know”.

You own a system and its health. Some of the week is still code, typically the hardest part. The rest is operational: reading dashboards against the system's SLOs, deciding whether last night's latency spike needs action, reviewing three Mid engineers' designs, and running a model or prompt migration behind an eval gate so a regression cannot reach users silently. When something breaks, you lead the response and write the postmortem, focusing on the mechanism that let it happen rather than the person who typed the command.

Evidence that gets you promoted: incidents that did not recur because of a fix you designed; migrations that landed without a quality drop; engineers you reviewed who now produce designs you approve unchanged; and cost or latency moved by a stated amount on a system you own.

Calendar time shifts towards writing and conversations. A Staff week might include a decision document comparing building a shared model gateway against each team calling providers directly; an hour with a security lead about how agents get credentials, which is about limiting blast radius; reviewing two teams' evaluation methods so their numbers can be compared; and a short, high-leverage piece of code, such as the reference implementation other teams will copy.

Evidence that gets you promoted (or hired) at Staff: a decision that several teams adopted; a written trade-off that was later proved right or was revised openly when data changed; problems that stopped happening across an organisation, not just in your system. Will Larson's interviews with Staff engineers describe recurring archetypes, such as the tech lead, the architect, the solver and the right hand, and the common thread is the same: their output is measured through other teams.

Promotion committees read artefacts, not intentions. Keep a running “brag document”: a dated list of what you shipped, what number it moved, and a link to the design note or pull request. When you start something, ask what artefact will prove it happened. For AI work, the strongest artefacts are almost always measurements: an evaluation set, a cost breakdown, a latency graph before and after.

The handbook has one reading track per level, on the Tracks page. Each mixes long reads, term pages with quizzes, and banks of interview questions. They are designed to be used like this:

• Read your own level's track fully. It covers what you should already be doing well. Gaps here are the fastest wins.
• Read the next level's track for vocabulary. You do not need to master it yet. You need to recognise the problems so you can volunteer for them.
• Use the quizzes as a check, not a score. If you miss a calculation question, redo the worked example in the term page by hand.
• Turn one post into one artefact per month. After the evaluation post, build a golden set for your own feature. After the production RAG post, add retries and tests to your own pipeline. That artefact is your promotion evidence.
• Practise the interview questions out loud, in the format the interview pages describe. Being able to explain a trade-off clearly is a Staff skill, and it is learnable at any level.