AI Impact on Career Ladders

Start with what the industry already has. Three career ladders: IC engineering, engineering management, and product. Each one is a stack of levels, and the main structural event in a career is the fork between IC and management, asked somewhere around year ten. For a while there were more ladders - DevOps, infra, QA ran as separate tracks - but platform tooling has been folding those back into the main lanes for years.

Levels tell you how senior someone is. They tell you almost nothing about what the person actually does all day - and for most of the ladder, the industry has been comfortable with that. A mid-level engineer is a mid-level engineer; the level is treated as the full description.

The one place shape has a name

There is exactly one spot where the industry admits that role shape matters as much as role level: staff engineering. Will Larson’s four archetypes - tech lead, architect, solver, right hand - became canon because everyone who reached that level noticed the same thing: two staff engineers with identical titles were doing four different jobs, and teams that staffed without knowing which one they needed kept hiring the wrong one.

Notice how isolated that is. Archetypes exist at one level, of one ladder. Below staff and outside engineering, shape has no vocabulary at all.

The disciplines, restated as distance

We described the Three Disciplines in working terms: how much autonomy the AI gets, and where the human review boundary sits - line, outcome, or product behavior. That is the right lens for a task. For a career, the same three positions restate as something simpler: distance to code.

AI-augmented work is in the code - every line read, judgment applied at the closest possible range. Outcome-led work stands at the boundary - tests, acceptance criteria, the outline of the change, without holding every line. Product-led work stands at the feature - what should exist and whether it behaves, with the code itself out of view. Autonomy and review depth were always the mechanics; distance to code is what they add up to. And while a discipline is chosen per task, a distance - held across enough tasks, for enough years - becomes what a person is.

New splits at the intersections

Lay that axis across the existing ladders and something appears that the ladders cannot describe: splits, at specific role intersections. Not every role forks - engineering management, for instance, changes surface but stays one job. The claim is narrower and more interesting: at several intersections of ladder and level, one role is quietly becoming two.

The IC split: in the code, or at the boundary

The classic IC role is not splitting into new titles - the role stays the same. What splits is the mix. Every engineer’s work is now some blend of two activities: time in the code - the architecturally dense work, the patterns being established, the places the model is known to be blind - and time at the boundary - outcomes defined, validation held, features shipped through the machine without reading every line. AI did not invent the two activities; it made the ratio between them a career fact. One engineer drifts toward the code as AI takes the volume; another drifts toward the boundary. Same role, same ladder - you just do more of one than the other, and over enough years the ratio becomes the job.

Both mixes run the full ladder - two senior engineers can hold the same level with opposite ratios, and they have different skill curves. One refinement matters: a junior starts at the boundary. They cannot yet hold a line-level review, so their first real AI work is outcome-led - testable results, not code judgment. Some will move toward the code as they build that judgment; others will stay at the boundary and deepen there. The question that once arrived at the staff level - what shape is your work? - now arrives at the first promotion.

The product split: planners and builders

The product ladder forks on the same axis, expressed differently: do you plan, or do you build? The planner uses AI tooling to become a dramatically better strategist - sharper definition, faster research, specs and value streams at a quality one person could not previously produce - and may never touch the build. The builder is the genuinely new role: the product person who ships. Product-led work means a PO with a clear definition and a strong validation boundary can implement - not prototype, implement. A role that was definitionally non-technical now has a technical archetype.

A PM starts as a planner - definition, research, strategy. The builder fork appears at senior, when the product person has enough context and validation skill to ship working software, not just specify it. Two senior PMs with the same title: one is an exceptional strategist who never builds, the other delivers working software. Same ladder, different jobs. At the top, the fork closes again - a group-level product leader directs planners and builders both.

The part nobody has words for

This is an awareness piece, so here is the awareness: job postings, org charts, comp bands, and interview loops all assume that ladder and level describe a person. They now miss a dimension. Hire "a senior engineer" and you are actually hiring a ratio - mostly in the code, or mostly at the boundary - and the two interview differently, ramp differently, and fill different gaps. Your two mid-levels with identical titles may have diverged a year ago, and that difference is worth naming.

The staff archetypes took a decade to get named, and the naming is what made them usable - you could finally staff a team knowing which of the four you needed. The same naming work is now due at more intersections of the ladder, because the question that used to arrive at year ten - IC or management? - has been joined by one that arrives at the first promotion: how close to the code do you want to be?