Engineering Career Ladders Still Define the Junior Rung by Work Agents Now Do

We read the entry-level definitions in three public engineering career ladders, from GitLab, Dropbox and CircleCI. None of the 3 mentions AI in its level expectations. Each one defines the junior developer career path as delivering small, well-specified code under guidance. That is now the work coding agents are best at, so the first rung of the engineering career ladder describes a job that is quietly disappearing.

Short answer: public engineering career ladders have not yet changed for AI-assisted work. The ones we read still define a junior engineer as someone who ships small, defined tasks with guidance. If agents take those tasks, rewrite the first rung around specifying work, verifying generated code, explaining every change and escalating with evidence.

What an engineering career ladder actually decides

An engineering career ladder is a written description of what each level is expected to do. Some companies call it a career framework, a competency matrix or a career progression framework. The names differ, and the job is the same.

The document is not decoration. Dropbox says its framework is used "as a reference during interviewing and hiring, performance reviews and calibrations, and the rating and promotion process", in a 2023 post explaining its update. That is four of the most consequential decisions a manager makes about a person.

So the wording of the lowest rung is load-bearing. It tells a hiring panel what to screen for. It tells a manager what to praise in a first review. It tells a new graduate what to practise. If the wording describes work nobody assigns any more, all three of those decisions drift.

My view is that the first rung matters more than any other in the document. Senior levels are defined by scope and influence, which agents have not removed. The junior level is defined by tasks, and tasks are exactly what moved.

What three public engineering ladders say about the first rung

Many companies publish their ladders. The best-known index is progression.fyi, a collection of public career frameworks that has listed companies such as Dropbox, Monzo and Medium. When we tried to open it in October 2026, the domain redirected to an unrelated company, so we went to the source documents directly.

We read three that are still public and current enough to matter. In each case we read only the level text, not company-wide paragraphs, because the level text is what calibration committees argue over.

GitLab: Associate Fullstack Engineer

GitLab's handbook is the most public engineering organisation on the internet. Its Associate Fullstack Engineer job description, last modified on 12 March 2026, asks the hire to "solve technical problems of moderate scope and complexity". The same page wants them to "confidently ship small features and improvements with minimal guidance and support from other team members".

It also asks Associates to "conduct Code Review within our Code Review Guidelines". That line is unusual for an entry level and it ages well. Review is the part of the job agents make bigger, not smaller.

The page does mention AI, but only in the company paragraph above the role. It says GitLab "embrace[s] AI as a core productivity multiplier" and that team members are "encouraged and expected to incorporate AI into their daily workflows". The responsibilities and requirements lists say nothing about it.

Dropbox: IC1 Software Engineer

Dropbox's IC1 Software Engineer page, from framework version 2.9.1, opens with a single summary line. "I deliver lots of high quality production-ready code with direction from the team". The scope line is "I execute on defined tasks and contribute to solving problems with defined solutions".

The rest of the page describes how that code should look. It should be "written to be read as well as executed". It should be "free of glaring errors". The engineer is "learning to tackle coding tasks with high throughput while maintaining appropriately high quality".

One line stands out for the agent era. The IC1 engineer is "capable of reading and navigating functions and classes/modules in a large codebase that I didn't write". In 2023 that meant colleagues' code. In 2026 a growing share of the code a junior did not write was written by a model.

CircleCI: E1 Associate Engineer

CircleCI publishes its Engineering Competency Matrix as a public spreadsheet under a Creative Commons licence. Its E1 Associate Engineer has a scope of "within task", and levels E1 to E3 share a focus on "execution of work".

The E1 expectations are craft-level. The engineer "writes code with testability, readability, edge cases, and errors in mind". They write "unit tests, sometimes with help from more senior engineers". They gain context in the team's domain "with help from more senior engineers".

Several competencies are marked "n/a (not applicable at this level)" for E1, including dealing with ambiguity. That choice made sense when juniors received well-scoped tickets. It makes less sense when the junior's main input is a model that answers ambiguous prompts with confident code.

Read in October 2026. GitLab's career matrix pages for each level exist separately from the job description; we quote the job description because its text was retrievable in full. Public versions can lag internal ones, which is discussed in the limitations section.

The junior rung is defined by supervised output

Read the three ladders together and one model of a junior engineer appears. A junior takes a task someone else has scoped. They write code for it. Someone more senior helps when they are stuck, and checks the result.

That model was never really about the code. The code was the vehicle. A junior who fixed 50 small bugs in a year learned how the codebase fits together, where tests are thin and which reviewer cares about naming. The ladder measured the output because the learning was hard to see.

This is the part I think most ladder discussions miss. The first rung was a proxy. It measured shipped tasks as a stand-in for growing judgement, and the proxy worked because the two travelled together. An engineer could not ship 50 fixes without learning something from each.

Agents break that link. A junior can now ship 50 fixes by prompting a model, and learn far less from each one. The output metric still reads green. The judgement it used to stand for may not exist.

What changed around the ladders, not in them

If the level text has not moved, where did the AI expectations go? They went into executive memos and review templates. Those documents move faster than a ladder, which needs calibration and a slow internal rollout.

Memos set a baseline the ladders do not mention

In April 2025 Shopify's chief executive, Tobi Lütke, told staff that reflexive AI use was now a baseline expectation. The memo, as reproduced by Workplace Journal on 8 April 2025, said that "before asking for more Headcount and resources, teams must demonstrate why they cannot get what they want done using AI". It also said staff could not "opt out of learning the skill of applying AI in your own craft".

In November 2025 Meta's head of people, Janelle Gale, told employees that AI-driven impact would be a core expectation in reviews from 2026. Business Insider reported the memo on 15 November 2025. It quoted Gale: "As we move toward an AI-native future, we want to recognize people who are helping us get there faster."

Neither of these is a ladder. Both change what a ladder is used to decide. A promotion committee now weighs a criterion that the level document does not describe, which is how inconsistent calibration starts.

Engineering blogs describe a different job

Dropbox's own engineering blog shows the gap inside a single company. Its May 2026 post on agent productivity says Nova, its coding agent platform, accounts for "roughly 1 in 12 pull requests". It says an engineer's role "increasingly shifts toward defining intent, mapping problems, reviewing generated changes".

The same company's IC1 page still says "I execute on defined tasks". Both documents are public. They describe different jobs, and only one of them is used in promotion decisions.

Why the old junior developer career path stops working

A ladder that lags is not automatically a problem. Plenty of ladders lag the technology and still work. This one fails for two specific reasons.

The training task is the first thing delegated

The tasks most suited to an agent are small, well-specified and easy to check. That is also the definition of a good junior ticket. Teams will route those tickets to agents because it is cheaper and faster, and they are right to do so on a cost basis.

The consequence is that the junior's curriculum shrinks while their level description stays the same. We covered the hiring side of this in the analysis of the breaking junior developer pipeline. The ladder side is quieter, because nobody files a ticket saying the training tasks have gone.

Review becomes the job, and juniors are not trained for it

Agent output is almost right more often than it is wrong. In the 2025 Stack Overflow survey, 66% of developers named "AI solutions that are almost right, but not quite" as their biggest frustration. And 46% said they actively distrust the accuracy of AI tools, against 33% who trust it.

Spotting "almost right" is a senior skill. It requires knowing what right looks like in this codebase. Yet a junior working with an agent faces almost-right code every hour. We looked at where that load lands for teams in the piece on code review as the new bottleneck.

Gergely Orosz made the same point from the employer side in The Pragmatic Engineer in January 2026. He listed skills such as verifying AI output and breaking down work. "These used to be baselines for senior or staff-level engineers at top-tier companies," he wrote, "and now will become baseline expectations for entry-level engineers".

A first rung for AI-assisted career development

If the first rung needs a new definition, here is the one I would propose. It keeps what the existing ladders get right, and replaces task volume with the judgement the tasks used to build.

The test for each line is simple. Can a manager observe it in a normal week, and does it still matter if agents get twice as good next year? Lines that fail either test do not belong in a level document.

Current wording is quoted from Dropbox IC1, CircleCI E1 and GitLab Associate. The proposed wording is ours and has not been tested in a calibration cycle.

Two things are deliberately missing. There is no line about using a particular tool, because tool names age in months. And there is no line about AI usage volume. Measuring prompts sent rewards activity rather than outcomes, a trap we examined in the analysis of performance review criteria for AI work.

The strongest single change is the "explain" line. A junior who can explain every merged line has learned from the work, whoever typed it. A junior who cannot has shipped output without growth, and the ladder should say plainly that this does not count.

The "debug unaided" line will be the most contested. Some managers will call it nostalgic. I disagree. When the model is wrong in production at 3am, the engineer on call needs a mental model of the system that did not come from the model. That has to be built somewhere, and the first rung is the only place it can start.

Where this argument is weakest

The sample is small. We read three ladders in detail, chosen because they are public and their text was retrievable. A ladder we did not read may already have changed, and three is not a survey of an industry.

Public ladders also lag internal ones. Dropbox's 2023 post says major updates need "a slow and internally publicized rollout". GitLab's Associate career matrix page exists separately from the job description we quote. A company may have an internal AI addendum and simply not have published it.

The memo route may also be correct. Shopify and Meta changed review criteria without rewriting levels, and that is arguably the right sequence. Ladders are hard to change, and you should not encode an expectation into a promotion document until you know it lasts.

The case that the old wording already covers it

A fair reader could say "deliver high quality code with guidance" is tool-neutral. A junior who uses an agent well still delivers high quality code. On this view, nothing needs rewriting, only reinterpreting.

That objection is half right. The words still parse. What they no longer do is describe the learning path, because the evidence a manager used to read from shipped tasks is now weaker. My proposed rung is a bet that writing the judgement down explicitly is better than hoping reinterpretation is consistent across managers. That bet has not been tested, and you should treat it as a starting draft.

How to change your career progression framework without breaking calibration

A ladder rewrite done badly is worse than no rewrite. Engineers promoted under the old text will feel the rules changed after the fact, and they will be right. The fix is sequencing, not speed.

First, add the new lines as additive expectations for one review cycle. Do not remove the old ones yet. That gives managers a cycle to practise observing "explain" and "verify" before those lines decide anyone's rating.

Second, change the interview loop at the same time, or the ladder and the hiring bar will disagree. A junior hired for raw coding speed and then assessed on verification has been set up to fail. We set out interview questions for this in the guide to AI fluency interview questions.

Third, publish the change if your ladder is public. LeadDev ran a piece by Subathra Thanabalan, an engineering manager at the New York Times, in August 2026 arguing that junior apprenticeships "need real senior bandwidth to catch up". A ladder is the written form of that apprenticeship. Publishing yours tells candidates what you will teach them.

Frequently asked questions

Where to start with your own first rung

Open your own ladder and find the entry-level definition. Highlight every line that an agent could satisfy on the junior's behalf. If more than half the lines are highlighted, your first rung is measuring the agent, not the person.

Then pick one line from the proposed table, most likely "explain", and pilot it with two managers for one review cycle. Ask them to record one observed example per junior each month. If neither manager can find an example, the line is too vague and needs rewriting before anyone is rated on it.

Related reading