Not Hiring Junior Developers Will Hurt Your Business

I recently talked with a computer science student at an AI event at Yale, and I came away sad about how much fear there is in computer science departments right now.

Students are afraid there won't be a junior job waiting for them when they graduate. The people running the programs seem just as panicked. They're scrambling to work out what AI means for their curriculum, how their students learn, and how to teach and grade. Those departments are in chaos.

The fear has a basis. New-grad and entry-level hiring at the biggest tech companies is down about 65% from 2019, according to SignalFire's 2026 State of Talent report. At early-stage startups it's down about 76%. Stanford researchers working from payroll data found that employment for 22- to 25-year-olds in jobs exposed to AI is 19% below where it would have been if it had kept pace with workers in less-exposed jobs.

I think companies that stop hiring junior developers are making a big mistake. It's a business risk, and it won't show up on this year's numbers.

Plenty of engineering leaders have made this case. I want to make it as a business leader. I've spent my career straddling business and technology, with time in engineering leadership but more of it on the business side. Business leaders need to hear this more than developers do. When budgets get tight, engineering answers to the business, and the engineering leaders who would make this argument are the ones under pressure to cut.

Why I'd Still Hire Developers

I build software with AI agents, tools that write and run code on their own, and I'd still hire developers. Good AI-assisted code needs judgment that only comes from experience:

Architecture judgment. Someone has to decide how the pieces of a system fit together. One shared component instead of ten copies is efficient, but it can become a single point of failure, one part that takes everything down when it breaks. Choosing on purpose, and knowing what could change later, is a skill.
Keeping code clean. As systems change and old parts get retired, leftover code piles up. Cleanup has to be part of every change, the way you keep a house clean by staying on top of it.
Context the code doesn't carry. Companies run systems of different ages and quality, often for a reason: a constraint, a business decision, an old use case still in play. None of that is written in the code, so someone on the team has to know it.
Owning risk. Security, accessibility, regulations and contract terms all sit around the code. A person has to think them through, put protections in place and be accountable when something goes wrong.
No black boxes you can't afford. Picture a business owner who turns invoicing over to an employee for a couple of years. The laws change, the employee quits, and the owner no longer understands the invoices. Wherever losing a system would hurt, you need a person who understands it well enough to fix it. I still hire people because there are some black boxes I can't afford to build.
Cost and efficiency. An agent can reach an outcome by trying over and over until something works, and that isn't the same as one thoughtful hour from a person, in time or in money. The companies selling the models make more when you use more, so they have no reason to make you efficient.
Variety over monoculture. People who do things differently, and even wrong, create the variation new ideas come from. Let machines do everything long enough and you get a monoculture, like a single crop that's one disease away from being wiped out.

Agents Checking Agents Won't Save You

I've heard people say they fully automated their coding and handled the risk by stacking agents: one writes the code, one reviews it, one writes the tests and another checks the tests. Enough layers of checking, the thinking goes, will shake out the problems.

I don't believe that works, especially at scale. Different AI models can cover each other's blind spots, so that part has an engineering fix. What breaks the setup is self-auditing, a system checking its own work. It's the police policing the police, an internal affairs problem. The humans in these setups still review, but they don't do any of the work. They review the work and review the reviewers.

It also brings back the pipeline problem. If people stop writing and fixing code themselves, where do tomorrow's reviewers come from?

Where Junior Developers Fit Now

When people say AI writes the code now, it sounds like engineering went away. The work moved to different tasks. Choosing libraries (prebuilt packages of code), setting the architecture and curating standards is still engineering, even when no one types the code by hand. There are entry-level and mid-level jobs in all of it:

Discovery: meeting with the business to draw out what's being built and why. Seniors guide, juniors learn, and juniors bring that context into the work that follows.
Context engineering: keeping up the standards, architecture notes and project details the agents work from, and improving them as new models come out.
Cost engineering: deciding which tasks go to cheaper models and which need the expensive ones, because the agents have no reason to save you money.
Refactoring: going back over what got built quick and dirty to fix cost, speed, security and long-term upkeep. What team doesn't have a backlog of things it wants to clean up, and how often does it get to them?
Review and retrospectives: checking the output, looking back after each project, and feeding what you learn into the next one.
Agent setup: building and maintaining the tools, the notes agents keep between sessions and the environment they run in, which changes fast and has plenty of junior tasks in it.

What Schools Should Teach

To the computer science departments scrambling right now: keep teaching coding by hand first. It's the alphabet before reading and writing. Once the fundamentals are locked in, teach students how to direct AI agents, and keep bringing code review back so the basics don't fade.

Almost every job on that list depends on reading code and judging whether it's any good. Students who learn the fundamentals and then how to work with agents are what companies will need, if companies keep hiring them.

Why the C-Suite Has to Make This Call

Right now companies are over-rotating, hiring only senior engineers and leaning on them for everything. Some will get good results for a while. But plenty are already building black boxes, fragile code and risk they can't see yet. Skip juniors and you're fine until your seniors move on or retire. Then you're paying a premium for scarce talent and paying for a major cleanup, because you've got corporate technical black mold in the basement.

AWS CEO Matt Garman called replacing junior staff with AI "the dumbest thing I've ever heard". Snowflake's SVP of Engineering wrote in Fast Company that junior engineers make up 70 to 80 percent of the company's current hiring. Even SignalFire's report warns that cutting the entry-level pipeline boosts short-term margins and sets up a leadership and talent crisis five to ten years out.

Your default with AI should be more productivity or better quality. Unless your business problem was specifically that costs were too high and everything else was great, I don't see how cutting costs grows or strengthens a business. Put the gains back into growth and quality with the people you have, who bring knowledge, experience and context no agent has.

No single hiring manager can justify juniors on this quarter's budget, which is exactly why the call can't be left to them. It belongs to the CEO and the CFO. Keep hiring junior developers, give them entry-level work directing agents, and in ten years you'll have the senior people your competitors are trying to hire away.

P.S. The Sales Pitch

Helping leadership teams plan how their companies work with AI is my job now at wespomeroy.com. That includes AI strategy, redesigning how teams do their work, and coaching executives through decisions like this one.