Jason JunJason Jun

What should junior engineers learn now?

29 April 2026

Recently I've been thinking about what it means to become a junior software engineer now.

Not which language or framework to learn. How does someone actually become experienced when so much of the beginner work can now be done by AI?

From what I hear, getting a job as a junior engineer already looks hard. But even when someone gets one, I wonder what they are actually given. What kind of mistakes are they allowed to make? What guidance do they receive? What work is still left for learning?

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

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 the 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 showed me how the footer did not fit them. Data was sitting inside the component, logic in the client forced the whole thing to render client-side, and 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 things. 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, that same refactor could probably be done by a senior engineer with AI in one shot. Why spend two weeks of junior time on it?

Companies used to turn low-risk work into training. Now the senior time spent coaching a junior through that kind of task can look like waste. That is where the learning path starts to break.

Juniors today have plenty of access to answers. AI can explain concepts, generate examples, fix errors, summarise code, and suggest designs. There has never been more help available.

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

An experienced engineer is not someone who has read enough engineering books. They are someone whose judgement has been shaped by consequences. You write code and someone explains why it does not fit the system. You make an assumption and later find out it was wrong. You ship something and an edge case comes back. You choose an abstraction and months later realise it made future changes harder. The lesson is rarely the right answer. It is usually why your first answer was wrong.

This kind of learning does not require a senior team or established engineering standards. Plenty of engineers grew up in agencies, small startups, freelance work, or messy projects where speed mattered more than quality. A messy codebase can still teach you something, as long as the consequences are real. The client changes their mind, the deployment breaks, the bug comes back, someone has to maintain the code later.

AI changes how that practice works.

Learning to code now means having AI available at every step. It is useful, and you would be foolish to ignore it. But if you lean on it for every problem, you may get the answer without ever developing your own sense of the work.

AI can write the function, explain the error, generate the schema, create the tests, and suggest the refactor. That also means a junior can keep moving forward without ever pausing long enough to understand what just happened, producing convincing code before they understand it.

A polished demo is not the same thing as engineering maturity. Vibe coding feels productive because the demo works. Engineering begins when the first edge case breaks it.

The useful question for a junior is shifting from "Can you write the code?" to "Can you tell whether this code should exist?" Answering the second question takes judgement, and that judgement grows slowly, in the gap between code that works and code that fits the system around it.

So the answer cannot be to avoid AI. That would be unrealistic. It also cannot be to let AI carry you through every hard part. Use AI in a way that keeps you involved in the thinking. If it writes an auth flow, understand where permissions are checked. If it adds state to a component, understand whether that component should own it. If it writes tests, ask what the tests are missing. If it refactors code, ask what trade-off it made. Each time, the goal is to surface what you still do not understand, so you can go and learn it.

The harder problem is motivation. Struggle used to be the only way forward. Now it is optional. When a magic button gives you the solution in seconds, choosing to sit with not knowing has to be a deliberate act. And while you are sitting with it, your peers are shipping apps and side projects that look more impressive than anything you would have built the slow way.

It is also not obvious how much of what you would learn the slow way will still matter in a few years. Some of it might be done better by the next model. The difficulty of learning the hard way is higher now, not lower, and the choice to do it has to be made on purpose.

This also changes what a junior should show when applying for jobs. A portfolio that only says "I built an app, and here's the repo" is weaker now, because AI made code cheap. The output alone does not say enough. A stronger portfolio shows what you built, what failed, what you changed, and why. That tells the reader how you think, and whether you met reality, learned from it, and improved the work.

So what should junior engineers learn now?

I think the fundamentals still matter, and so does learning AI tools. But what might be more valuable now is building yourself a feedback loop strong enough to replace some of what a good team used to give a junior.

What I would want to keep, if I were starting now, is the habit of asking how something works after it already works. AI makes that the easiest habit to drop. It is the one most worth keeping.