The Junior Engineer After Code: Growing Engineers When Agents Do the Implementation

A demo compares the visible artifact: whether a feature, interface, test, or configuration exists. A production system asks a different question: did the engineer understand the intent, verify the result independently, carry the change through release, and remain accountable for what followed? The central mistake in conversations about agentic development is to mistake the first, already-automated layer for engineering work as a whole.010101I covered Google's May whitepaper on the new SDLC on my channel. It states the same shift more compactly: for decades a developer's interface to the machine was syntax, and now it is intent. What matters to me is that a human still has to formulate the intent.Knizhny kub · The New SDLC: from vibe coding to agentic engineering01I covered Google's May whitepaper on the new SDLC on my channel. It states the same shift more compactly: for decades a developer's interface to the machine was syntax, and now it is intent. What matters to me is that a human still has to formulate the intent.Knizhny kub · The New SDLC: from vibe coding to agentic engineering

I separate the work into three layers. The first produces an artifact. The second closes a work episode from intent to an observable result. The third evolves a system through trade-offs, boundaries, migrations, incidents, and decisions that may need to be revisited a year later. Agents have discounted the first layer most sharply. Farther to the right, outcomes depend increasingly on knowledge of the specific system and the engineering loop around the model.

The attenuation is visible in aggregate data. An NBER matched event study published in 2026 covered more than 100,000 GitHub developers and estimated much larger gains in commits than in projects and releases. A 2026 Microsoft preprint found that early adopters of Claude Code and Copilot CLI merged roughly 24% more pull requests than their estimated counterfactual over four months. That is meaningful evidence of output, but the authors explicitly use merged pull requests as a proxy. Adoption was not random, and a merge does not tell us whether the change created value, remained stable, or developed the engineer who made it.

net team value = accepted outcome − review − rework − operating risk − human steering

This is not an accounting formula. It is a reminder that first useful output and independent ownership are two different dimensions of progress. In an observational sample of 22,953 AI-assisted pull requests, pull requests from contributors classified as less experienced through indirect proxies received 4.52 times as many review comments, had a 31% lower acceptance rate, and remained open 5.16 times longer. Projects and tasks differed, so this does not prove that AI caused a review tax. It shows why the whole work episode belongs in the denominator. Available evidence gives us reasons to expect improvement in the first. It does not yet settle the second.

Discussions about AI development become unreliable when a field experiment, vendor telemetry, a manager survey, and a hiring trend are treated as equivalent proof. The best evidence supports a narrower claim: assistance often improves output on bounded work, and less-experienced developers can capture a large share of that gain. It does not establish that they acquire judgment at the same speed.

The 2026 CodeFuse paper is especially useful because it resists a simple story. In a quasi-experiment with 1,219 Ant Group developers, access to the 2023 assistant was associated with a 55% increase in code output overall and 67% among employees with a year or less of experience; for senior programmers the gain was not statistically significant, and juniors used the system far more. That is strong evidence that a structured enterprise assistant can increase a junior's near-term contribution. Its primary result is measured in lines of code; additional models confirm more completed tasks, but still do not measure quality or product value.

A much smaller controlled PACIS study from 2026 compared an agent with an ask-mode assistant on one existing-codebase task. Across 24 developers, mean task time fell 61.7% and reported workload fell 57.4%, but correctness did not improve significantly. This is useful evidence about one agent-versus-assistant workflow, not AI versus no AI or production onboarding over time.

Other studies pull in different directions. The three field RCTs published by Cui and colleagues in 2026 found larger gains for less-experienced developers. A peer-reviewed 2026 Science study of more than 30 million commits to open-source Python projects on GitHub found that nearly all measurable output and library-adoption gains accrued to more experienced developers, although less-experienced contributors appeared to use AI more; gains for that group were not statistically significant. METR's 2025 randomized study put experienced maintainers on 246 real tasks in repositories they knew well and found them 19% slower with early-2025 tools, even as they believed they were faster. A 2026 METR update measured returning participants at roughly 18% faster with newer tools but declined to call that a precise uplift: participant and task self-selection push the estimate in one direction, so the authors treat it as a lower bound.020202I wrote about this experiment separately, and at first I did not want to: a sample of 16 engineers felt thin for loud conclusions. I changed my mind once the headlines started overselling it, and read all 50 pages. A good illustration that you have to reconstruct the boundary of a finding yourself.Knizhny kub · a walkthrough of the METR experiment02I wrote about this experiment separately, and at first I did not want to: a sample of 16 engineers felt thin for loud conclusions. I changed my mind once the headlines started overselling it, and read all 50 pages. A good illustration that you have to reconstruct the boundary of a finding yourself.Knizhny kub · a walkthrough of the METR experiment

These results do not need to be averaged into one magic number. They involve different tools, tasks, populations, and denominators. The honest summary is simpler: local acceleration is better established than system benefit; system benefit is better established than faster learning; faster career maturity is barely measured at all.

Routine work used to generate a large number of cheap learning repetitions. A junior attempted a change, met a failure, formed a hypothesis, read the system, received review, and tried again. The work was sometimes inefficient, but it continuously exposed the difference between a plausible answer and reality.

An agent can bypass the expensive middle of that loop. The artifact appears, the generated tests pass, and the engineer moves on without building a durable model. In Anthropic's small randomized study published in 2026, AI users finished only about two minutes faster—a non-significant difference—but scored 50% rather than 67% on an immediate quiz about the unfamiliar library. The largest gap was in debugging. Post-hoc interaction patterns also mattered: conceptual questions and requests for explanation were associated with better learning than complete delegation, but those clusters were not randomly assigned and should not be read causally.

A small CHI 2026 study adds a plausible mechanism: experienced engineers retained agency through detailed, bounded, and verifiable delegation, while juniors oscillated between dependence and avoiding AI. Yu and Moon describe a related mechanism they call Absorption: routine work can shift to a senior engineer using AI, removing tasks through which juniors used to learn. Their July 19, 2026 preprint, accepted at AIES 2026, rests on 14 interviews in South Korea. It identifies an organizational risk, not an industry-wide effect.

The answer is not to worship struggle or ban the tool. Productive difficulty has become a resource to allocate deliberately. The organization must reconnect delivery and development: require a first hypothesis, compare the output with that hypothesis, verify independently, debrief failures, and test whether the idea transfers to the next task.030303We discussed this on a Research Insights Made Simple stream with Evgeny Sergeev, working through Anthropic's 2026 paper on persistent returns to expertise. My main takeaway: expertise there means knowledge of the specific task, not a job grade or years served.Knizhny kub · why coding agents do not replace expertise03We discussed this on a Research Insights Made Simple stream with Evgeny Sergeev, working through Anthropic's 2026 paper on persistent returns to expertise. My main takeaway: expertise there means knowledge of the specific task, not a job grade or years served.Knizhny kub · why coding agents do not replace expertise

Imagine two juniors fixing duplicate payment events in an existing service. Both ask an agent for help. Both eventually produce the same small patch. One first traces delivery and retry behavior, asks whether the operation must be idempotent, identifies the persistence boundary, and defines a test that replays the event. The other asks the agent to fix the ticket, accepts a deduplication cache, and presents a green suite. The code can look identical; the engineering signal is not.

A strong junior is not expected to know everything. A precise boundary of knowledge is a positive signal: “I do not yet know why this cache is safe under redelivery, so I am not proposing merge.” The central skill is calibrated delegation—knowing what was handed off, how the result is constrained, what evidence would falsify it, and when to stop.040404I covered an honest counterargument to this section too. Kitze argues you should never hand-fix code a model wrote — make it redo the work, or you lose the speed. For speed that works. For forming an engineer it is exactly the loop I call fragile.Knizhny kub · From Vibe Coding To Vibe Engineering04I covered an honest counterargument to this section too. Kitze argues you should never hand-fix code a model wrote — make it redo the work, or you lose the speed. For speed that works. For forming an engineer it is exactly the loop I call fragile.Knizhny kub · From Vibe Coding To Vibe Engineering

A small CHI 2026 study described a related pattern: experienced engineers retained agency through detailed delegation and active verification, while juniors oscillated between avoidance and overreliance. Its proposed practice, prompt-and-code review, is useful when applied selectively: review the critical framing, decision pivot, debugging exchange, and risk acceptance—not every token in every session.

The wrong rule is “write every line by hand.” Syntax, scaffolding, mechanical transformations, API lookup, documentation drafts, and candidate tests are good objects for aggressive delegation. What must remain human is the independent judgment loop around the generated work.

Frame the problem and build the first system model

Before generation, the junior states the goal, acceptance criteria, constraints, unknowns, and non-goals. They read the critical code path, interfaces, data model, and canonical documentation. The agent may challenge or extend the map, but it should not be the only source of that map.

Choose the oracle independently

An agent can write tests; the engineer decides what they prove. The positive path, negative path, invariant, compatibility boundary, security property, and failure mode cannot all be delegated to the same generator that is trying to pass them. A green suite is evidence only when the oracle represents the real requirement.050505I went through SWE-PRBench: it measures not whether a model can write a patch but whether it can judge someone else's pull request, using real human review comments as ground truth. That a separate benchmark was needed for this says a lot about why the generator should not be the sole authority on what counts as correct.Knizhny kub · SWE-PRBench and the quality of AI review05I went through SWE-PRBench: it measures not whether a model can write a patch but whether it can judge someone else's pull request, using real human review comments as ground truth. That a separate benchmark was needed for this says a lot about why the generator should not be the sole authority on what counts as correct.Knizhny kub · SWE-PRBench and the quality of AI review

Reproduce and localize before asking for repair

Before “fix this,” the junior reproduces the defect, gathers facts, names at least one hypothesis, and narrows the likely cause. The agent is then excellent at proposing instrumentation, alternatives, and counterexamples. The loop “paste error → accept patch” may repair software while leaving debugging skill untouched.

Own wide effects and what happens after merge

Architecture boundaries, permissions, privacy, data migrations, irreversible actions, release gates, and rollback remain human decisions. The junior should participate in deployment, inspect telemetry, repair their own regression, and join incident review in a safe role. Finally, they should be able to explain the causal chain, trade-offs, breakpoints, and rollback without asking the model to speak for them.

Do not fully delegate a step whose result you cannot yet independently falsify.

Calendar-based progression was imperfect before AI; it is weaker now. Two engineers can spend the same six months producing similar volumes of code while accumulating very different experience. The better progression axis is the growing unit of accountability.

The transitions matter more than the labels. A guided learner becomes a change owner when they can turn a defined task into a small, independently verified change without continuous decomposition by a mentor. A change owner becomes an episode owner when responsibility no longer ends at merge: the engineer plans the release, observes the result, repairs a regression, and leaves the system legible. The working boundary of mid-level begins when this becomes repeatable for a bounded component under moderate ambiguity.

Open career frameworks point in the same direction. Monzo explicitly calls its framework a compass rather than a GPS. It marks scope separately at each level—from a task to a project or feature and beyond—and structures each level around Impact, Technical Skills, and Behaviours. Dropbox's IC2 definition expects an engineer to choose solutions with high-level guidance, ship sustainable projects, debug other people's code, and handle operational resolution. AI does not invalidate that model. It makes code volume an even weaker proxy for it.060606Of the books on this ladder, Gergely Orosz's The Software Engineer's Guidebook comes closest — I reviewed it on my channel. Its middle → senior → tech lead → staff blocks build on each other, and each transition is described through scope of responsibility rather than elapsed time.Knizhny kub · The Software Engineer's Guidebook06Of the books on this ladder, Gergely Orosz's The Software Engineer's Guidebook comes closest — I reviewed it on my channel. Its middle → senior → tech lead → staff blocks build on each other, and each transition is described through scope of responsibility rather than elapsed time.Knizhny kub · The Software Engineer's Guidebook

This is earned autonomy, not a six-month promise. Permissions, scope, and agent freedom expand as the engineer demonstrates understanding and control. Asking for help is not failure; hiding uncertainty to make a dashboard look autonomous is.

One generated application proves little. Growth should be calibrated across a portfolio of comparable feature, defect, maintenance, review, release, and support episodes. The useful question is whether responsibility expands while the severity of required human correction falls.

Human steering cost is a program-level calibration signal, not a surveillance metric. Counting every question would teach juniors to conceal risk. Look instead at a sequence: are questions sharper, are the same error classes disappearing, and does guidance move from step-by-step instruction to occasional trade-off review as task complexity grows?

Lines of code, prompt count, percentage of AI-generated code, agent count, raw pull-request volume, and self-reported hours saved are poor promotion signals. They describe tool activity or output, not retained understanding and accepted outcomes.070707In August I recorded a Code of Leadership episode about a “digital tech lead” — a system that promises to score developer effectiveness straight from the code. The conversation is about exactly this boundary: code is an important result, but architectural decisions, helping the team, review, and prevented mistakes never show up in it.Knizhny kub · can an engineer be measured from code07In August I recorded a Code of Leadership episode about a “digital tech lead” — a system that promises to score developer effectiveness straight from the code. The conversation is about exactly this boundary: code is an important result, but architectural decisions, helping the team, review, and prevented mistakes never show up in it.Knizhny kub · can an engineer be measured from code

Banning AI tests a job the candidate will not perform. Letting an agent produce a polished take-home repository and scoring only the artifact reveals almost as little. A better assessment is a small episode in an existing codebase with a visible process.

• —Give an incomplete or mildly contradictory requirement and real surrounding code.
• —Allow the candidate's normal agent, while keeping the interaction history visible.
• —Ask for assumptions, acceptance criteria, an oracle, and a plan before generation.
• —Introduce a hidden invariant, a failing test, or a log that supports a plausible wrong hypothesis.
• —Change one requirement after the first solution and ask the candidate to adapt it.
• —Use a short no-AI segment for code reading, explanation, or initial bug localization.
• —Give specific feedback and observe the second iteration.

Score five things: framing and decomposition; system and product understanding; verification and debugging; quality, safety, and operations; and learning, communication, and accountability. Do not reward secret prompt formulas. A strong candidate may use simple instructions because they first narrowed the problem and assembled the right context. A weak candidate may orchestrate five agents and never notice that the system solves the wrong problem.080808I wrote separately about how multi-stage hiring is built: a large company hires into the company rather than into a team, and each stage checks its own competency. A work episode with a visible process fits that scheme well — as one stage, not as a replacement for the rest.Knizhny kub · hiring processes and interview types08I wrote separately about how multi-stage hiring is built: a large company hires into the company rather than into a team, and each stage checks its own competency. A work episode with a visible process fits that scheme well — as one stage, not as a replacement for the rest.Knizhny kub · hiring processes and interview types

The small no-AI segment is not a purity test. It checks whether the mental model remained with the person after the tool disappeared and whether feedback transferred beyond the original chat.

LinkedIn REACH offers a useful real-world reference: after a take-home exercise, candidates explain and extend their solution. As of August 2026, the program page did not confirm an open application window, so this is an assessment-design example rather than a claim about a live role.

My answer is yes—if the company intends to buy future expertise, not a cheaper senior with an agent. The short-term business case is real: bounded work can reach first value sooner, and CodeFuse gives unusually direct evidence that junior employees can capture meaningful output gains. The strategic case is larger: every company still needs people who will understand the history of its systems three years from now and make decisions when an agent is confidently wrong.

The labor-market signal is nevertheless uncomfortable. An IZA working paper estimated a 14–15% relative decline in US junior software vacancies versus senior vacancies after ChatGPT, using Lightcast data and a difference-in-differences design. Experience requirements increased even within unchanged job titles, while the remaining junior vacancies more often asked for problem solving, communication, and attention to detail—not AI-specific skills. The Stanford Digital Economy Lab update from August 12, 2026 reports a 19% relative employment gap for workers aged 22–25 in the most AI-exposed occupations through June 2026, primarily through hiring. Early-career software developers are one important part of that broader signal.

That 19% is descriptive, not causal: it is a gap against the trajectory of less-exposed occupations, not a claim that 19% of all entry-level jobs disappeared. The ADP sample is not nationally representative, and the comparison mixes many occupations. The patterns attenuate when controlling for education, and some divergent trends predate generative AI. Interest rates, post-pandemic overhiring, and the broader technology contraction also matter. This is a reason to take the pipeline problem seriously, not proof that agents eliminated junior work.

SignalFire's proprietary Beacon data suggests that the entry funnel kept shrinking after generative AI arrived: new graduates accounted for only 7% of Big Tech hires in 2024, and the number hired fell 25% year over year; at startups they represented under 6% of hires, with startup new-graduate hiring down 11% from 2023. SignalFire itself treats AI as one factor alongside expensive capital, layoffs, and 2020–2022 overhiring. Surveys also diverge. Among more than 880 engineering leaders in LeadDev, 54% expected less junior hiring in the long run and 38% agreed that AI tools had reduced the amount of direct mentoring junior engineers receive. In Strada Education Foundation's survey of nearly 1,500 US executives and senior talent leaders across industries and firm sizes, 2.7 times as many senior talent leaders expected AI use to increase entry-level hiring in 2026 as expected it to reduce hiring. These are different populations, and Strada measures intentions rather than realized hiring.090909I covered Y Combinator's Lightcone panel on building a career in the AI era. It reaches the same fork from the other side: US unemployment among computer science graduates came out higher than among art history graduates, and the bet they propose is on agency rather than on a diploma.Knizhny kub · How to Spend Your 20s in the AI Era09I covered Y Combinator's Lightcone panel on building a career in the AI era. It reaches the same fork from the other side: US unemployment among computer science graduates came out higher than among art history graduates, and the bet they propose is on agency rather than on a diploma.Knizhny kub · How to Spend Your 20s in the AI Era

Hire when

• —an experienced core has real capacity for mentorship and review;
• —the task queue contains real, bounded, and reversible work episodes;
• —tests, CI, observability, and clear boundaries create fast feedback;
• —the junior will participate in releases, support, and incident learning;
• —learning time is protected and success is measured beyond one quarter;
• —the company needs an internal pipeline of future mid-level, senior, and technical leaders.

Wait when

• —the immediate need is an independent owner of a critical area;
• —senior engineers are already the bottleneck for review;
• —the system has no automated checks, observability, or safe blast radius;
• —the role is implicitly a cheap senior-with-agent position;
• —output metrics reward pull requests while someone else absorbs every consequence;
• —the junior will be kept away from production and expected to learn from generation alone.

Company announcements point to both strategies. In May 2026, Salesforce said its Builder program was recruiting 1,000 graduates and interns across engineering, product, sales, and other functions. In the same announcement, its Emerging Talent Playbook recommended that employers assess AI fluency and cognitive adaptability and use structured onboarding and reverse mentorship. On July 15, 2026, Cognizant announced a plan to hire 1,500 US graduates by the end of the year through university and apprenticeship pathways. LinkedIn's REACH apprenticeship continues to combine real projects, mentorship, and protected development time. These are first-party examples, not independent evaluations, and the roles are not all software engineering. They prove that an AI-centered company does not logically have to abandon entry-level hiring; they do not prove that every such program works.

By AI apprenticeship I mean a development model in which the agent is present in both work and learning but never closes the loop of understanding and verification by itself. This does not restore a pyramid of cheap manual work. It creates a small, controlled system for producing both accepted outcomes and future judgment.

At task level, the junior first records intent, constraints, unknowns, the affected system path, and the proof they will accept. The agent receives a bounded part of the work. The junior keeps the change small, uses AI review for cheap mechanical findings, and brings architecture, product intent, and risk to human review. They then join the release and inspect post-release telemetry rather than handing the final consequence back to the mentor.

At program level, every junior needs a named mentor and explicit learning outcomes. Mentor time is a budgeted program cost, not invisible generosity. Tasks should rotate across features, defects, maintenance, support, review, release, and incidents. Permissions and blast radius grow through demonstrated control. Important decisions remain in pull requests, design notes, ADRs, and runbooks instead of disappearing into private chats.

DORA's 2025 report describes AI as an amplifier of an engineering organization's existing strengths and weaknesses. For junior development, that mechanism is literal: small changes, fast CI, reliable tests, documentation, clear boundaries, and live review turn agent speed into feedback; weak context and missing verification turn it into faster uncertainty. The report combines nearly 5,000 survey responses with more than 100 hours of qualitative data, so these are organizational associations and self-report rather than causal estimates.101010I worked through onboarding as a measurable process in the Developer Productivity for Humans series. It names the usual causes of slow ramp-up: thin documentation, absent mentorship, and unclear expectations of the engineer. An agent closes none of them on its own.Knizhny kub · onboarding and ramp-up10I worked through onboarding as a measurable process in the Developer Productivity for Humans series. It names the usual causes of slow ramp-up: thin documentation, absent mentorship, and unclear expectations of the engineer. An agent closes none of them on its own.Knizhny kub · onboarding and ramp-up

Every few weeks, calibrate a portfolio of episodes on outcome, understanding, verification, operations, and human steering. The program has two output lines: useful accepted work now and expanding independent accountability later. If only the first line is measured, removing the learning pipeline will always look efficient for one quarter.

Agents did not erase the difference between junior and senior engineers. They erased several old signals of that difference. Project size, typing speed, framework recall, and even a green test suite now say less. Framing intent, recovering context, choosing an independent check, updating a wrong model, protecting architecture, and staying accountable after merge say more.

A strong junior in 2026 is neither a miniature senior nor a prompt operator. It is an engineer whose task-specific expertise grows quickly, whose unit of accountability expands from patch to work episode and component, and whose need for human steering declines on comparable work without concealing uncertainty.

The deepest reason to hire juniors is therefore not that an agent lets them produce useful code earlier, although it often can. It is that someone must become the next person able to explain why the system looks this way, change it safely, and reject a persuasive machine answer when the evidence says no.

Code got cheaper. Reproducing engineering judgment did not.