The Faster AI Gets, the Further Behind Juniors Fall

Seniors Are Slammed. Juniors Have Nothing to Do.

I run a small software company. We build battery management systems (BMS), automotive software, and embedded devices running Linux or RTOS — the kind of technology most universities don't really teach, in a market most people don't want to go into.

Lately I've been dealing with a problem. Not a technical one — a people problem.

People who join the company are finding themselves with less and less to do. More precisely, less and less meaningful work. Instead of opportunities to learn new skills and grow, they get the leftover tasks. Do enough of those and your skills stop developing. Skills stagnate, and it becomes harder to hand them anything more important, which means even more time sitting around without much to do.

Meanwhile the seniors are busier than ever. All that work that used to be distributed has been absorbed by the experienced engineers — who are handling it alone, or alongside AI agents. And honestly, I get it from their side too. Walking a junior through something takes twice the time and twice the stress. Just doing it yourself with AI is the rational call. It's become a situation where that judgment makes perfect sense.

The Paradox AI Created

AI is moving fast in our corner of embedded systems — a market people usually avoid, which ironically means the AI boost hits harder. When a senior pairs up with AI, their productivity jumps noticeably. The domain knowledge is in the senior's head; the code writing and repetitive work gets handled by AI.

The problem is that this productivity gain eats away at the junior's reason for existing.

It used to be natural: seniors design, juniors implement. Juniors stumbled through implementation, asked questions, got code reviews, and grew from the process. The stumbling itself was the education. But now AI does that implementation faster and more accurately. From the senior's perspective, explaining work to a junior, waiting for them to finish, and then reviewing it takes longer than just finishing it with AI.

The result is this vicious cycle:

1. AI boosts senior productivity
2. The "meaningful work" that would go to juniors dries up
3. Juniors don't develop skills; motivation drops
4. Seniors find it even harder to hand work to juniors
5. Seniors handle even more work alongside AI
6. Back to step 1

This basic structure existed before AI too. But AI has dramatically accelerated the speed of the cycle.

The Particular Pain of Korean Small-Scale Embedded

There are reasons this hits especially hard here.

First, schools don't teach this stuff. Expecting a new hire to have experience with RTOS or BMS is wishful thinking. Even if we set aside computer architecture, it's not unreasonable to hope someone with a CS degree has at least some C — but often that's not the reality either. A new graduate who's used Python but has never touched pointers needs to start from the ground up. The gap is enormous. AI can help bridge some of it, but knowing what you need to learn is itself something that comes from experience. It's not a complete fix.

Second, there's no budget for training. Large companies can run three- or six-month onboarding programs. Small companies structurally don't have that luxury. New people need to contribute from day one, but getting to the point where that's possible takes time. Juniors end up stuck in an awkward in-between — neither fully trained nor immediately useful.

Third, the market is small. The talent pool for embedded work in Korea — especially BMS and automotive software — isn't large. Hard to find experienced engineers, hard to grow new ones. The load ends up concentrated on a small number of seniors, and that becomes the permanent structure.

I Asked AI About It

I threw this problem at an AI. Explained my situation, asked if there was any way out. A few of the suggestions were interesting.

"Give juniors the areas AI can't touch." Embedded is different from web development. AI can write BMS firmware, but it can't pick up an oscilloscope, probe a signal, and track down a timing problem. Give juniors ownership of hardware debugging, testing, and validation, and they're not doing busy work — they're building hands-on experience in exactly the areas where AI is weakest. I thought that was a sharp observation. The physical-world interface of embedded work could actually be a training asset.

"Shift the senior's role from 'teacher' to 'reviewer'." Give juniors a small but real product problem, let them work through it with AI, and have seniors only review the result. The senior's time investment drops from "eight hours teaching" to "one hour reviewing." AI acts as an infinitely patient teaching assistant. The key is concentrating the senior's experience on defining the problem well and making the review count.

"Use documentation as a training tool." Assign juniors the task of analyzing existing systems with AI and documenting them. To document a system accurately you need to understand it, so asking the right questions forces learning to happen. And the output — the documentation itself — has real value in paying down the company's technical debt.

"Develop juniors as AI tooling specialists." Seniors have deep domain knowledge but may be slower to adopt new AI tools. Give juniors ownership of building AI pipelines, automating workflows, and prompt engineering. They can contribute value immediately and also act as a productivity multiplier for seniors.

Still No Answer

Honestly, none of these suggestions produced an "aha, that's it" moment. Each has merit, but they vary in how directly applicable they are to our specific situation.

Still, I noticed one thread running through all of them. The junior role needs to be completely redefined — not as a smaller version of the senior, but as something altogether different. Juniors used to grow by doing what seniors do, just at a smaller scale. Now AI sits in the path of that progression. The same road doesn't work anymore. A different road is needed.

The fact that embedded work is grounded in the physical world might actually be an advantage over other software fields. AI can write the code, but figuring out why the LED on the board isn't lighting up, or why packets are getting dropped on the CAN bus — that requires getting your hands on the thing. There might still be space in that interface for juniors to grow.

The immediate problem in front of me — solving it for our company — matters, of course. But stepping back a little, this clearly isn't just our problem. Embedded or web, large company or small, any organization where AI is boosting senior productivity is probably building the same kind of structure. That's what scares me more.

Engineers have DNA for this, in a way. When there's a bug, you track down the cause. When a system is slow, you find the bottleneck. When requirements change, you redesign. But facing a problem like "a structure in which people don't grow" — that DNA doesn't seem to kick in as naturally. You can fix code. You can't debug people and organizations.

I want to spend more time thinking about what a concrete path forward looks like and write a follow-up. For now, having clearly identified the problem feels like at least one step forward. I hope an answer emerges — and if it doesn't, maybe just sharing the struggle has its own value.