Someone Has to Be New at This

A team can complete more work with AI while weakening the path by which a new engineer learns to understand a change and take responsibility for the next problem.

AI can explain unfamiliar code, suggest a fix, and help someone get past a blank screen. I want new engineers to have that help. Starting out does not need to be harder than it already is.

But finishing a ticket is only one part of becoming capable. An engineer also needs chances to predict what a change will do, discover what they misunderstood, explain why the result works, respond to feedback, and diagnose the next failure with less help. If AI removes those opportunities, a team may produce more today while developing less of the judgment it will need later.

New engineers need consequential work with support: real problems, candid questions, feedback, revision, and progressively greater responsibility. Avoidable hardship adds nothing.

What the hiring signal does and does not show

The labor evidence makes this concern timely, but its scope matters. In an August 2026 update using payroll data through June, Stanford researchers found a widening employment gap among workers ages 22–25 in occupations with different levels of AI exposure. In the two most exposed occupational quintiles, employment for that age group fell about 11% from November 2022 through June 2026. In the three least-exposed quintiles, it grew about 10%. The researchers described the relative difference as a 19% “kept-pace” shortfall, operating mainly through reduced hiring rather than increased separations. (Stanford Digital Economy Lab)

That is a serious early-career signal, but it does not prove that AI eliminated junior jobs. The balanced panel covered roughly 3.5 million to 5 million full-time U.S. workers per month at ADP client firms. It was not nationally representative and overrepresented larger firms and AI-exposed occupations. Some divergence predates generative AI, the estimates weaken when education is controlled for, and interest rates, remote work, sample composition, and differences from national benchmarks complicate the interpretation. The authors characterize the findings as descriptive and report no evidence of widespread economy-wide displacement.

Software work also remains in aggregate demand. The Bureau of Labor Statistics projects 10% employment growth for software developers, quality assurance analysts, and testers from 2025 to 2035, with about 106,100 openings per year on average from growth and replacement needs. (BLS Occupational Outlook Handbook)

That projection does not tell us who will receive those opportunities or what an entry-level role will contain. Continued demand for software work can coexist with concentrated hiring weakness among young workers.

If that weakness persists and employers fail to create other routes to consequential experience, the future supply of experienced engineering judgment could narrow. No cited evidence shows that such a shortage exists or forecasts that it will occur. People enter the profession through jobs, school, independent projects, internal training, and other routes. The relevant question is whether those routes still let beginners do the work through which greater capability develops.

Getting help and keeping the understanding

The studies cited here do not support a universal claim that AI makes developers faster or slower. Their results depend on the people, tools, tasks, and setting.

Three randomized workplace experiments involving 4,867 developers at Microsoft, Accenture, and an anonymous Fortune 100 company found a pooled 26.08% increase in completed tasks with an AI coding assistant. Less-experienced developers adopted the tool more often and saw larger gains. The experiments were publicly reported in 2025 and published in Management Science in 2026. Individual estimates were noisy and varied. The measured outcome was completed tasks, not retained learning, unaided competence, production quality, or career development. (Management Science)

A smaller, specialized study found a different result. It followed 16 experienced open-source developers as they completed 246 tasks in mature repositories they knew well. Access to AI tools available from February through June 2025 increased completion time by 19%, although participants had expected a 24% speedup and later perceived a 20% speedup. The sample and repositories do not represent most software work, and the tools are already aging. Teams should measure what happens in their own setting instead of assuming that assistance always saves time. (METR)

Speed and completed-task counts still leave another question unanswered: what can the engineer understand and do after the assistance ends?

One randomized study examined 52 mostly junior engineers learning Trio, an unfamiliar Python library. After the task, participants took a quiz without AI. The assisted group averaged 50%, compared with 67% for the hand-coding group, while its roughly two-minute task speedup was not statistically significant. The experiment involved short tasks, a small sample, and an immediate quiz, with no delayed measure of retention. It does not demonstrate durable deskilling. It does show that, in this setting, task completion and immediate unaided understanding moved in different directions. (Anthropic)

Post hoc interaction patterns from the same experiment offer a tentative clue about how the assistance was used. Small groups centered on delegation, progressive reliance, or AI-led debugging averaged below 40% on the quiz. Groups involving conceptual questions, explanation-seeking, or independent error resolution averaged at least 65%. Those clusters contained only two to seven people, and the analysis did not establish that interaction style caused the score differences. The limited pattern gives teams a reason to notice whether an engineer remains involved in explaining and resolving the problem.

A separate 2026 experiment involving 69 bachelor’s and master’s students, researchers, and professional developers found more than double the median task completeness with AI assistance, alongside a 12.5% lower ability to answer technical questions about the resulting implementations. The study used two bounded tasks, and technical-question performance is only a proxy for code ownership. It does not measure long-term maintenance or career development. Within those limits, more complete work did not guarantee a stronger grasp of what had been built. (IEEE Transactions on Software Engineering)

From finishing a change to owning the next problem

Output becomes developmental when an engineer carries understanding and responsibility forward.

Suppose an engineer makes a small change to an unfamiliar system. The fix looks sensible and the tests pass, but the behavior differs from what they expected. The engineer can compare the result with a prediction, investigate the mismatch, receive feedback, revise the change, and explain what happened. That work builds a better starting point for the next failure.

The same ticket can close after the engineer receives a plausible answer, runs it, and moves on without understanding the behavior. The output is complete, but their ability to recognize a bad assumption, evaluate a tradeoff, maintain the result, or recover when the next answer does not fit may be unchanged.

Software engineering requires that broader capability. The BLS occupational description includes needs analysis, design, testing, maintenance, documentation, risk identification, communication, collaboration, creativity, attention to detail, and problem solving. Code production belongs to a larger job that requires people to understand systems and make responsible decisions across their lifecycle. (BLS Occupational Outlook Handbook)

Broad learning research supports several ingredients in this progression without establishing a specific formula for AI-assisted engineering. The National Academies’ How People Learn II describes how technology can support real-world problem solving, scaffold learning, and create opportunities for feedback, reflection, and revision. It also emphasizes that useful designs depend on the learners, their needs, and the context. Applying those ideas to engineering teams is a proposal, not a tested intervention for turning junior engineers into senior ones. (National Academies Press)

A completed task has developmental value when the engineer forms a model of the problem, inspects evidence, understands failures and tradeoffs, incorporates feedback, and carries some responsibility forward. The connection is practical: finish a consequential change, understand and explain its behavior, then become more capable of owning the next problem.

Use AI to widen practice, not remove it

Many developers already describe verification as part of their AI workflows. In Stack Overflow’s optional 2026 trust question, 48.0% of 14,304 respondents said they trusted AI output when they could easily verify it. Only 6.6% said they trusted it for many tasks, including important work decisions. (Stack Overflow Developer Survey)

In a separate optional, multiple-select question answered by 13,162 respondents, 76.5% reported running AI output locally, 63.9% comparing it with codebase context, and 53.0% inspecting tests or security implications. Another 9.6% reported using the output as-is. These are self-reports from a respondent sample. They do not show whether the checks were correct, whether the engineer understood the result, or whether verification developed independent judgment. (Stack Overflow Developer Survey)

Verification matters, but developing an engineer requires more from the team. AI can remain part of the work while the engineer remains part of the reasoning:

• Before running a generated change, ask the engineer to predict its behavior. Compare the prediction with the result and investigate any difference.

• When a bug appears, reproduce it and form an initial hypothesis before asking AI to lead the diagnosis. Assistance can help test that hypothesis without replacing the act of making one.

• Ask the engineer to explain the change, its risks, and its likely failure points. The purpose is to find the edge of their understanding while support is available, not to demand a polished performance.

• Check tests against the actual request, not only against the generated implementation. Passing tests can confirm what was encoded while missing what the work was supposed to accomplish.

• Let the engineer respond to review feedback and revise the change. Replacing their work may save time in the moment, but it removes the chance to connect feedback with action.

• Give beginners ownership of small, consequential areas long enough to see what happens after the first merge. Reading existing code, making a change, observing its effects, maintaining it, and handling a later problem belong to the same learning process.

These are practical proposals informed by bounded evidence, not a proven career-development formula. The responsibility cannot rest entirely on the beginner. A junior engineer facing a deadline may reasonably accept a plausible answer rather than admit uncertainty, especially when the team rewards only speed. Mentors and leaders need to preserve time to learn, make candid questions safe, provide useful feedback, and assign work whose responsibility can grow.

Support should change as capability grows. The engineer takes on less familiar problems, makes more decisions, and needs less help deciding what to inspect. They may continue using AI throughout. Progress appears in what they can explain, what they can diagnose independently, and how much responsibility they can carry.

A future with room for beginners

I want these tools to help us go further. I like the thought of people building things that once felt out of reach, perhaps, one day, even reaching other worlds. That is an aspiration, not evidence about where current tools or careers will lead.

Teams have a practical choice now. They can use AI while continuing to assign consequential work, ask for explanations, support independent diagnosis, provide feedback and revision, and increase responsibility as understanding grows.

Someone still has to be new at this. Our use of AI should help that person finish today’s change and become more capable of owning tomorrow’s problem.