Nobody Is Coming to Save Junior Developers

I want to write something honest today, which means it won’t be comfortable.

The conversation happening in tech right now around AI and jobs has two modes. The first is dismissive: “AI can’t really code, it makes mistakes, you still need humans, don’t worry.” The second is catastrophist: “all programmers will be replaced within two years, learn to farm.”

Both are wrong. But the dismissive version is doing more damage, because it’s being said by people in positions of authority to people who are early in their careers and making decisions right now about what to learn, what to build, and how to position themselves.

So here’s what I actually think is happening.

The entry-level market has already changed

Not is changing. Has changed.

Eighteen months ago, a junior developer’s primary value was execution. A senior engineer would scope a ticket — break down a feature into specific, well-defined tasks, identify the edge cases, think through the architecture — and a junior would implement it. Write the component. Add the API endpoint. Hook up the tests. The work was real and it took real skill, but the judgment and the design came from someone else.

AI does that work now. Not perfectly. Not without supervision. But well enough that one senior engineer with good AI tooling can do what previously required a senior plus two juniors. The arithmetic on entry-level hiring changed overnight and most companies have not said this out loud.

Look at the actual numbers. Engineering hiring across the industry is down significantly from its 2022 peak. New graduate placement rates have dropped. The teams that are still growing headcount are growing at the senior and staff level, not at the entry level. This is not a coincidence.

The reason companies aren’t saying this explicitly is that it’s awkward to say. “We’re not hiring juniors because AI does junior work” is an uncomfortable position to defend publicly. So instead there’s vague talk about “market conditions” and “restructuring” and the implication that things will return to normal once the cycle turns.

They won’t. The cycle has not turned. The underlying economics have changed.

What junior work actually was

To understand what’s at risk, it’s worth being precise about what junior developer work consists of, because “junior work” encompasses a wider range than people usually acknowledge.

There’s mechanical work: implementing a specified feature in a known framework, writing CRUD endpoints, adding fields to a database schema, wiring up a UI component to an existing API. This is the category that AI handles most confidently right now, and it’s a large fraction of what junior developers have historically spent their time on.

There’s learning work: reading codebases, understanding existing systems, building the mental model of how a product actually works. This is not something AI does for you. It is also the thing that turns a junior into a mid-level engineer. It’s the investment period.

There’s judgment work: understanding requirements, knowing when to push back on a spec, recognizing when a simple solution is better than a clever one. This develops slowly, through experience, through making mistakes in production, through watching senior engineers make decisions and understanding why. It cannot be shortcut.

The problem is that a lot of the mechanical work — the work juniors used to do while they were building the learning and judgment muscles — has been automated. The on-ramp to judgment is missing a crucial section. You used to build taste by doing a lot of mediocre work under supervision and having it reviewed. That path is narrower now.

The skills that are not compressible

Here’s what I’ve noticed about the developers who are thriving right now, regardless of experience level.

Debugging real systems. AI is remarkably good at generating code and remarkably bad at diagnosing why a distributed system is behaving wrong in production. Reading traces, correlating logs, reasoning about timing and state across services — this requires a depth of systems understanding that doesn’t come from prompting a model. Developers who can walk into a production incident and actually figure out what’s happening are worth more than they were two years ago, not less.

Understanding before building. The failure mode of AI-assisted development is building the wrong thing very fast. The skill of understanding what’s actually needed — talking to users, reading between the lines of requirements, identifying the three different things that a vague spec might mean — is entirely human. It doesn’t compress. Developers who are good at this are force multipliers on AI output, because they ensure the AI is building toward the right thing.

Knowing when the output is wrong. This is the underrated one. AI generates confident output regardless of whether the output is correct. The developer who can quickly assess “this looks right but it’s actually subtly broken” is doing something that requires deep knowledge of the domain, the system, and the failure modes. This is taste, and taste takes time to develop and cannot be acquired from a model.

Systems thinking. How does this decision affect the part of the system we’re not looking at right now? What are the second-order consequences of this architectural choice? What breaks when this scales by 10x? These questions require holding a lot of context in your head simultaneously and reasoning about interactions and consequences. AI is getting better at this but it’s not there, and the developers who are good at it are doing something valuable.

Working with people. Gathering requirements. Running technical discussions with non-technical stakeholders. Explaining a system’s behavior to someone who doesn’t read code. Disagreeing constructively with a senior engineer about an approach. None of this is automatable. A surprising amount of a developer’s actual value comes from this category and it’s almost never what people mean when they say “software development.”

The honest advice for people starting out

I want to be careful here because I’m aware this is easy advice to give from a position of already having a career.

Take the long view on what you’re building. The skills that matter are not framework knowledge or language syntax or even knowing which tools to use. Those things shift constantly. What you’re actually building, over years, is taste — the ability to look at a system and understand whether it’s good. You build taste by reading a lot of code, writing a lot of code, having it reviewed, and doing that over and over. AI doesn’t shortcut this. In fact the developers who lean too heavily on AI output in their early years may be slower to develop taste because they spend less time in direct contact with problems and solutions.

Get obsessed with a domain, not just a stack. A developer who deeply understands healthcare workflows, or financial systems, or supply chain logistics, or legal document processing — and can also write software — is doing something qualitatively different from a developer who knows React and TypeScript but has no particular domain depth. Domain knowledge compounds. Stack knowledge depreciates. The most defensible position over a twenty-year career is being the person who understands both the domain and how to build systems in it.

Contribute to real systems. Open source, internships, contract work, building things for actual users — anything that puts you in contact with production systems and real feedback. The learning that happens when something you built breaks in production, or when a user uses your software in a way you didn’t anticipate, is irreplaceable. Tutorials and courses and side projects that nobody uses are a fraction as valuable as real systems with real consequences.

Learn to use AI as a force multiplier, not a crutch. The developers who are going to do well are the ones who can direct AI effectively — who know enough to evaluate its output, catch its mistakes, and push it toward the right solution. This is different from the developers who use AI because they don’t want to think. The former are more productive than any developer was five years ago. The latter are building on a foundation that won’t hold.

Be honest with yourself about whether you’re learning. There’s a version of AI-assisted development where you ship things quickly and feel productive but your own understanding isn’t growing. It feels fine until it doesn’t — until you’re in an interview, or a production incident, or a design discussion, and you realize that the model has been doing the thinking and you’ve been approving the output. The discipline of sometimes doing things the slow way, of understanding what the AI generated before you ship it, is important and increasingly rare.

What the industry owes people starting out

Something that doesn’t get said enough: the compression of the entry-level market is a structural problem, not just a market cycle. The traditional path from junior to senior was a specific kind of apprenticeship. You did supervised execution work. You made mistakes in low-stakes environments. You gradually took on more judgment. Senior engineers invested time in your growth because your execution work freed them for higher-leverage problems.

That loop is broken. And the industry has not replaced it with anything.

Companies benefit from AI productivity gains and simultaneously reduce the number of entry-level positions where the next generation of senior engineers would be developing. This is a short-term optimization with long-term costs that won’t be visible for five to ten years, when the pipeline of experienced engineers runs thin because nobody invested in building them.

This is not a problem that individuals starting their careers can solve. It’s a collective problem. The honest thing is to name it, not to pretend the market will correct itself, and not to tell people that if they just learn the right framework everything will be fine.

The version of this that isn’t bleak

I’ve been in this industry long enough to have watched several things that were supposed to end programming not end programming. Low-code platforms. Visual programming tools. Offshore outsourcing. Each one changed the shape of the job without eliminating it.

AI is different in magnitude. But the thing that persists across all of these transitions is this: the demand for people who deeply understand complex systems and can reason about how to build, fix, and improve them has never gone away. The form of the work changes. The underlying thing the best developers do — think clearly about hard problems and turn that thinking into working systems — has not been automated and shows no signs of being automated.

The path in right now is narrower. The expectations are higher from the start. The tolerance for someone who is purely executing specified tasks without building judgment is lower. None of that means the career isn’t worth pursuing. It means the career requires more intentionality than it did when the market was forgiving enough to let you figure it out slowly.

Figure it out faster. Focus on the things that don’t compress. Build taste. Get in contact with real systems as early as possible.

Nobody is coming to save you — but the work is still worth doing.