A Question I Keep Getting

I receive some version of this message a few times a month:

“Given where technology/AI is today, what does a Junior Software Engineer actually need to bring to the table to be worth having on your team?”

I appreciate when the question is honest about what it’s really asking.

Sometimes it is. And sometimes, there’s a hook in the water.

Either way, the question deserves a real answer because it’s a genuinely hard question for 2026, and most of the advice floating around is either catastrophizing or hollow.

Let me give you the answer I actually believe.

First: The Doom Is Not Wrong

I know people who have stopped writing code entirely.

Not because they got lazy or lost interest. But because agentic programming systems are now faster, cheaper, and more consistent than any individual programmer for a large class of tasks. These people are 50x, 100x more productive than they were before.

They describe the shift the way you describe waking up with different eyes.

I cannot underline this enough: This is real.

Here is what is also real: the creative energy didn’t go anywhere:

  • The tool changed.
  • The desire to build things didn’t.

I have watched the same transition happen before: First with image manipulation, then with design, then with writing, now with code.

The grief is the same each time: So is the recovery, for the people who actually make it through. What changes is not the value of building things:

What changes is what “building” means.

So when someone tells you programming is dead: don’t dismiss them.

They are pointing at something real:

The execution bottleneck has collapsed. What used to take a week now takes hours. What used to require three engineers now requires one with the right setup.

That part of the job has been automated.

But Here Is What the Doom Gets Wrong

The doom crowd focuses on “execution” because execution was always the most visible part of the job. It was also, quietly, never the important part.

I wrote about this years ago: Code is nothing.

Not in a defeatist way. In the most liberating way possible:

What you create with your code is everything.
The way you share your knowledge is everything.
The value you add to the community is everything.

The code was always the output of the thinking.

The thinking is what we actually hired you for.

A junior who could write syntactically correct Java but couldn’t debug a production incident, couldn’t explain the trade-off between two architectural options, couldn’t read a codebase they hadn’t written: That junior was never particularly valuable to begin with. AI made that obvious.

A junior who could do those things: That person’s leverage just multiplied by a factor that would have seemed science fiction five years ago.

The bottleneck moved from execution to judgment.

Ever Heard of Chickens and Eggs?

But… what if you are the junior? You don’t have judgment yet? No?

This is the actual hard question. The doom crowd doesn’t answer it because it complicates their narrative.

Judgment comes from getting your hands dirty:

  • From shipping something and watching it fail.
  • From reading codebases you didn’t write until your eyes hurt.
  • From debugging an issue for three hours and finally understanding why the system behaves the way it does.

AI can short-circuit all of that. And if you let it: if you go straight from “I have a problem” to “accept AI’s solution” without ever building the mental model; you become what I’ve seen described as a slop cannon:

Producing an enormous volume that nobody, including you, can evaluate.

The trap is seductive. The output looks correct. It often even is correct.

But you have no basis for knowing whether it is, because you never did the work that builds taste.

“AI makes skilled workers prolific. It makes unskilled workers pollutants.”

That’s not my line, but I would have written something similar too.

What I Actually Want from a Junior in 2026

I want someone who is deliberately building their own judgment.

Here is what that looks like in practice:

Read code until it’s boring: Not just tutorials. Real codebases. The ones that are ugly and overgrown and have six different naming conventions because six different developers touched them over six years. That’s where you learn to read a system, not just code.

Break things manually first, then let AI fix them: If you’re learning databases, write the SQL by hand before you ask an agent to generate it. If you don’t understand what it produced, you have no basis for trusting it. The mental model has to come first. AI is a multiplier, and a multiplier applied to zero is still zero.

Learn to switch resolution deliberately: Sometimes you need the satellite view: how does this system fit into the architecture? What problem does this codebase exist to solve? Sometimes you need the dewdrop view: exactly which line is allocating the memory that’s leaking? The skill that matters is knowing which level you’re at and choosing it, not drifting between them because the task handed it to you.

Own outcomes, not tasks: A task is “implement the auth flow”. An outcome is “users can log in reliably and securely, and the team understands what we built and why”. Junior engineers who optimize for tasks ship tickets. Engineers with real leverage optimize for outcomes. This shift is possible earlier than most people think, but it requires thinking about it.

Build the thing you care about: Not to put it on your resume. Because you care about it, and you want to see if you can: The motivation has to be intrinsic, because, the external reward structure for junior engineering is hostile right now and will remain so for the foreseeable future.

If you are here because it’s a stable career path, I’m sorry, but this isn’t that anymore.

If you are here because you can’t imagine doing anything else, you’re in the right place.

The Networking Thing (Since We’re Being Honest)

Most of the people who ask me this question are also, somewhere in the message, asking me to refer them.

I understand. I would probably do the same.

But I’d encourage you to read what I wrote about that: Build Strong Connections to Land Your Dream Job.

The short version: a cold referral request from someone I don’t know is worth nothing to me and costs me something. A warm referral from someone whose work I admire, whose judgment I’ve seen in action, whose name I’d put next to mine: That’s worth its weight in gold.

The way to get that conversation is not to ask for it. It’s to be the kind of person who makes the people around them better. Online or in person. Through what you write, what you build, what you share, what you’re honest about when it doesn’t go well.

Ship things. Write about what you learned. Make it public. Help someone who is two steps behind where you are now.

Do that consistently for a year, and you won’t need to ask for referrals: They will appear.

The Timeless Parts

Here’s what I think doesn’t change:

Systems thinking scales: The ability to look at a complex system, understand how it fails, identify the root cause, and reason about trade-offs: this is as valuable as it has ever been, and AI cannot do it for you without your intellectual scaffolding.

Communication compounds: The ability to write clearly about technical topics, to explain a decision with its context and rationale, to make your work legible to others: this was always important and is now a primary differentiator.

Curiosity is the engine: Every good engineer I know is curious in a way they can’t really turn off. Not about everything: about this thing, whatever this thing is right now. If you don’t have that, the rest of this advice probably won’t help much.

You are not your stack: The language you know, the framework you use, the toolchain you learned in your bootcamp: none of that is your identity or your moat. What is your moat is how you think, what you can figure out, and what you do with problems that nobody handed you a solution to.

So: Is It Worth Starting?

Absolutely and unequivocally yes.

With full awareness of what you are signing up for.

The floor has moved: The jobs that used to be entry-level (write CRUD apps, translate specs into code, fix bugs someone else diagnosed); many of those are gone or going. The field is smaller at the bottom than it was, and it’s not recovering to what it was.

But the ceiling is higher than it has ever been: A single person with good judgment, good taste, and strong command of these tools can build things that would have required a team of ten five years ago. That’s not hyperbole. I’ve watched it happen.

The question is whether you are going to be the person who does that, or whether you are going to spend the next few years being anxious about whether you are keeping up.

You can’t do both.

“All great fighting is the same, Eragon, even as all great warriors are the same. Past a certain point, it does not matter whether you wield a sword, a claw, a tooth, or a tail. It’s true, you must be capable with your weapon, but anyone with the time and inclination can acquire technical proficiency. To achieve greatness though, that requires artistry.”

Christopher Paolini – The Inheritance Cycle

The weapon changed. The artistry is still the job.

May the source be with you 🦄.

Continue Reading