Recently I have been thinking about what it means to become a junior software engineer now. How does someone become experienced when so much beginner-level work can now be done by AI?

Getting a first engineering job already seems harder than it used to. But the problem does not end once someone gets a junior role. What work are they trusted to do? What mistakes are they allowed to make? What guidance do they receive?

When I was a junior engineer at Envato, one of my first tasks was a small change to the website footer. It was a perfect junior task.

I put up a small PR with the change. The lead engineer came back and suggested I look into the underlying design problem of the footer instead of just making another change on top of it.

At the time, I could not really see the problem. He asked me to have a chat and walked me through the team's engineering standards and design principles. Then he showed me how the footer did not fit them. Data was sitting inside the component. The whole thing was forced to render client-side. Display code was tangled with business logic.

So the task became a refactor. I spent around two weeks on it. I paired with other engineers, got PR feedback, asked questions, and watched experienced engineers explain their thinking. Along the way I learned about component structure, data flow, rendering, trade-offs, and how seniors actually look at a codebase.

The task was valuable not because of the code I shipped, but because I was close to the thinking around the code. I got to see how seniors noticed problems, questioned design, and decided what was worth changing.

Today, it would be tempting for a senior engineer with AI to just do that refactor themselves. It would definitely be faster. So why spend two weeks of junior time on it?

Companies used to turn low-risk work into training. Now coaching a junior through it can look like inefficiency next to a senior plus AI finishing the same task in an afternoon. That is where learning starts to break.

Juniors today have plenty of access to answers. But access to answers is not the same as access to experience.

Experience is not information. Experience is being wrong in contact with reality.

You write code and someone explains why it does not fit the system. You ship something and an edge case shows up in production. You choose an abstraction and months later realise it made future changes harder.

The lesson is rarely just the correct answer. More often, it is understanding why your first answer was wrong.

AI quietly removes most of those moments. It writes the function, explains the error, generates the schema, creates the tests, and suggests the refactor. The risk is that you produce convincing code without knowing why it is correct, where it is fragile, or what trade-offs it made.

The way to build judgement is to use AI without handing over the thinking. If AI writes an auth flow, understand where permissions are checked. If it adds state to a component, ask whether that component should own it. If it refactors something, work out which trade-off it made and whether you would have made the same one.

Each time, the goal is not only to get the code working. The goal is to surface what you still do not understand.

It also changes what a portfolio is worth. 'Here is an app I built' is a weak signal now. Code is the cheap part. What you struggled with, what failed, and what you changed says more.

The hardest part is wanting to learn. Struggle used to be unavoidable. Now it is optional. When a tool can give you a solution in seconds, choosing to sit with not knowing becomes a deliberate act. And while you are sitting with it, your peers may be shipping apps and side projects that look more impressive than anything you would have built the slow way.

But what looks impressive is not the same as engineering maturity. Engineering begins when the first edge case breaks it.

So what should junior engineers learn now? Maybe what matters most is the habit of asking how something works after it already works. AI makes that one of the easiest habits to drop, because the code already runs and the question feels optional. It is also the habit most worth keeping, because it is what turns shipping into judgement.