Last year, a recent graduate of a well-regarded coding bootcamp spent months doing everything the program had trained him to do. He finished the capstone project. He practiced interviews. He polished his online presence. He applied broadly and persistently. Over the following year, he sent out more than three hundred applications and got four first-round interviews. None turned into an offer.
What stayed with him was not the rejection itself. He had expected the market to be rough. What stayed with him was the shape of the feedback when it came. Hiring managers were not saying his code was poor. They were saying he lacked a feel for how software systems behave under real conditions: how things break, how changes ripple, how decisions have to be made before code is ever written. One interviewer put it with a bluntness he still thinks about: “We need someone who’s already been through some fires.”
But that, of course, was supposed to be what the entry-level job was for.
A manager at a midsize software company described the other side of that equation in equally stark terms. Her team had hired junior engineers a few years ago and then stopped. It was not simply that budgets had tightened, though they had. It was that the work itself had changed. Tasks she once could have handed to someone with six months of experience—wiring up a form, implementing a straightforward endpoint, writing a batch of tests—were now being completed by senior engineers in a fraction of the time with AI coding tools. The category of bounded work that once justified bringing in a beginner was still there, but it had shrunk. And once it shrank, so did the rationale for paying someone to grow into it.
She did not pretend this was painless. She had once been a junior engineer herself. Someone had decided to absorb the inefficiency of her early mistakes because that was how people became useful. Now she found herself on the other side, asking candidates for evidence they could already operate in the world: that they had shipped something, dealt with real users, made a bad call and recovered from it. When I asked her what she was really looking for, she was direct about it. “I need to see scar tissue,” she said.
There is something circular in this, and it is worth lingering over. Companies say they want judgment. Judgment comes from experience. But the work that once provided that experience is being compressed by the same tools that make senior engineers more productive. The institution that once grew its own talent now expects talent to arrive pre-grown, then frames that expectation in the neutral language of merit.
For roughly two decades, the software industry operated on an implicit arrangement with its newcomers. You learned the basics, and then you were hired to do work that was real but bounded: boilerplate code, features built from someone else’s specification, tests for modules someone else had designed. The work served two purposes at once. It was productive for the company, and it was formative for the engineer. You made mistakes in an environment that could absorb them, and through deployments that went sideways and design choices that turned out to be wrong, you developed the instincts that made you worth more.
Two feeder systems prepared people for this arrangement in different ways. Universities offered formation: broad education, analytical habits, and the understanding that a degree was a foundation, not a guarantee. Coding bootcamps, which proliferated in the 2010s, offered conversion: the promise that in a matter of months, for significant tuition, you could become employable. Their websites featured six-figure salary projections and elite company logos. Their business model depended on entry-level hiring remaining abundant.
When the market was absorbing every developer it could find, both approaches worked well enough. The difference between them became dangerous only once the absorption stopped.
That danger is now visible in the bootcamp sector itself. Rithm School, a small and well-regarded coding bootcamp, said in 2024 that the market for early-career engineers was the worst it had seen and later announced that, after seven years, it would close and cancel future cohorts because changes in the bootcamp market and the broader tech market had made the business no longer viable. Even on its way out, the school’s own materials reflected the tension of the moment: it continued to publish transparent outcomes data while acknowledging a sharply changed hiring environment.
Inside the companies that had long served as destination employers, the pipeline has been thinning in quieter ways. SignalFire found that new graduates accounted for about 7 percent of hires at large tech firms in 2024, down from roughly 15 percent five years earlier. A cyclical downturn explains part of this. The industry overhired during the pandemic and then corrected sharply. But cyclical explanations do not fully capture what many managers are describing. They are not only describing fewer seats. They are describing a change in the nature of the work those seats once existed to do.
The shift is real, though unevenly distributed. It is most advanced at large companies and among engineers working with frontier AI tools. It has not reached every team. Most engineers have not stopped typing code by hand. But that is not the most important question. What matters is whether the category of work that once trained beginners is shrinking. It is. At Google, Sundar Pichai said in April 2025 that the share of code involving developers accepting AI-suggested solutions had risen from about 25 percent to well over 30 percent. Stack Overflow’s 2024 developer survey found that 76 percent of respondents were using or planning to use AI tools in their development process.
At the frontier, the shift is starker still. Andrej Karpathy described a workflow in early 2026 in which he was running multiple AI agents in parallel and intervening mainly at the level of architecture, direction, and quality. That kind of workflow is not yet ordinary everywhere. But it is no longer strange enough to dismiss. When a tool can draft in hours what once took weeks, the bottleneck moves. The scarce thing is no longer producing code. It is knowing whether code is correct, safe, and appropriate, and making the surrounding decisions: when to deploy, how to stage the rollout, what might break, what has broken before.
That is what so many employers now mean when they talk about judgment. And it is, by definition, the thing a beginner has not yet had a chance to develop, because it forms not through study but through the accumulated weight of things going wrong.
The software industry likes to describe its preference for experienced hires as pragmatic. AI changes the work. The work demands more seasoned people. Seasoned people get hired. But this framing skips a step. When a profession says it values judgment above all, it is also making a claim about who has had the opportunity to develop it.
The computer-science senior at a top university who interned at brand-name firms has judgment, or at least its legible markers. The career-switcher from a community college, who may be equally intelligent and equally capable, often does not, because she has never been given the environment in which judgment forms. The more the industry relies on judgment as a hiring criterion without investing in the conditions that produce it, the more it risks encoding existing advantage as earned distinction. A call for people who have already “been through fires” sounds like a neutral standard. In practice, it favors those who already had access to the institutions, networks, and financial stability that let them get near the fire in the first place.
In the absence of reliable institutional pathways, some aspiring engineers are improvising. One recent computer-science graduate, unable to land a role and lacking internship experience, stopped treating side projects as résumé ornaments and started treating them as substitutes for apprenticeship. She built a small web application around a problem from her own life, shipped it, and gradually found herself dealing with the kinds of constraints that school had not prepared her for: real users, edge cases, bugs, the anxiety of fixing one thing without breaking another. She described the turning point as the moment a stranger filed a bug report. “That was when it stopped being a portfolio piece,” she said. “It was a real person with a real problem and I had to fix it without breaking the thing for everyone else.” Eventually she wrote publicly about the tradeoffs she had navigated, and a startup hiring manager who read the post reached out with contract work.
Stories like that are encouraging, but they should not be romanticized. What made that path possible was not just effort. It was also time, luck, and enough financial stability to spend months building without pay. Some employers do now treat sustained public work as a meaningful signal. Cal.com, for example, has used open-source contribution history as part of its hiring pipeline. But a system that depends on individual initiative, visible side work, and fortunate discovery is not an apprenticeship. It is a workaround.
What these young engineers are doing is building, on their own, the feedback loops an employer once provided: ship something real, expose it to consequences, learn under pressure, repeat. The lesson is genuine. So is the unfairness. It asks people who have already invested in education to invest again, without institutional support, in the hope that visible work will substitute for the credential the market no longer fully trusts.
That is why the language of apprenticeship matters here, even though the software industry has rarely used it. Apprenticeship names something markets do not automatically provide: a protected space in which inexperience is treated as development rather than disqualification.
Hospitals do not expect residents to arrive fully formed; residency is the structure through which competence is built. Law firms have traditionally hired first-year associates knowing they will be inefficient for months, because training them is part of the point. Even within tech, a few deliberate exceptions survive. LinkedIn’s REACH program is a multi-year apprenticeship that hires people from nontraditional backgrounds into technical roles, gives them full-time employment, formal mentorship, and dedicated development time, and treats the work of formation as part of the company’s hiring rhythm rather than as charity. LinkedIn says the program has grown into a recurring pipeline and, as of recent cohorts, expects to bring on roughly 10 to 15 apprentices per cycle. That is real. It is also small enough to stand out precisely because it is unusual.
That is the point. Apprenticeship is becoming an edge case when it used to be a standing assumption.
What makes the software industry’s version of this problem so visible is that the technology compressing entry-level work is the same technology the profession builds. The engineers creating AI coding tools are automating the ground on which the next generation would once have trained. Not out of malice. AI-assisted productivity is genuinely valuable, and any individual firm’s decision to adopt it is rational. But the aggregate effect is that the old subsidy for developing new engineers is eroding, and nothing has replaced it at scale.
The senior engineers of 2040 will have to come from somewhere. If the industry that needs them will not bear the cost of their formation, that cost falls to newcomers: their savings, their time, their willingness to build in public with no guarantee that anyone is watching. Some will manage it. Many will not.
The future junior engineer may have to train herself in the open, by building things that matter enough to fail. Whether that amounts to a new beginning or a closing door is a question the industry has barely begun to ask.