Back to Blog

AI Is the Best and Worst Thing to Happen to Junior Engineers

I've been thinking about something that's been bothering me for a while. Junior engineers in 2026 can ship features faster than I could after three years of experience. That's incredible. It's also a problem.

They're fast because the tools are good. Copilot, Cursor, Claude - these things genuinely work. A junior can scaffold a service, wire up an API, and push a working PR in an afternoon. When I was at that stage, building the banking app at Vibe Tecnologia, that same task would've taken me a week. Maybe longer. And most of that time would've been spent staring at Angular docs, misunderstanding reactive patterns, breaking things, and slowly piecing together how it all fit.

Nobody enjoyed that process. But it built something that no shortcut can replace: intuition.

Intuition is knowing something is wrong before the tests fail. It's reading a PR and feeling the future bug before you can articulate why. It's that voice in your head during a design review that says "this will break at scale" three weeks before it actually does. You don't get that from autocomplete. You get it from six hours of debugging a problem that turned out to be a missing await. You get it from reading stack traces until your eyes bleed. You get it from staring at someone else's code and slowly, painfully, learning how it thinks.

I'm not saying junior engineers should suffer on purpose. The suffering was never the point. The understanding was. And right now, we're stripping out the understanding and keeping the output.

I see it in code reviews. PRs that look clean, pass all checks, follow conventions perfectly - and yet something feels off. The code works but the person who wrote it can't explain what happens when the database connection drops. They can generate clean abstractions but can't read someone else's messy ones. They pass reviews because the code looks right, not because they understand why it's right.

That's not their fault. That's our failure as an industry. We gave them a jetpack and forgot to teach them how to land.

When I was at Finetune working on the assessment platform, the thing that made me actually grow as an engineer wasn't the code I wrote. It was the three days I spent tracking down why responses were occasionally duplicating under load. No AI could have taught me what I learned in those three days - how to read database logs, how to reason about race conditions, how to hold a mental model of a distributed system while eliminating possibilities one by one. That experience is worth more than a thousand generated solutions.

The junior engineers who will thrive in this era won't be the fastest prompters. They'll be the ones who still bother to ask "why does this work?" after the AI already gave them the answer. They'll be the ones who turn off Copilot once in a while, not because they're masochists, but because they understand that the struggle is where the career gets built.

If you're a junior engineer reading this: use the tools. Ship fast. Absolutely take advantage of what previous generations didn't have. But every once in a while, turn it all off. Break something. Fix it yourself. Sit with the discomfort of not knowing. That feeling is not a bug in your learning process. It's the whole point.

And if you're leading an engineering team right now, this is your problem to solve. Not theirs. They don't know what they're missing because they've never had it. It's on us to build environments where understanding is valued as much as output, where asking "why" is as respected as shipping "what." We're the ones who have to figure out how to preserve the parts of the old process that actually mattered while embracing the parts of the new one that are genuinely better.

We haven't figured that out yet. And it shows.