Status Droid how long software work actually takes

Bringing In a Junior

The traditional path was: write a lot of code, get it reviewed, gradually learn what good looks like, eventually review other people's.

That path assumed writing was slow. Slowness was the mechanism — it forced engagement with every decision, and after enough of them you had a model of what tends to go wrong. Reviewing ability was a by-product of years of writing. For teams translating this assistant-related trade-off into day-to-day controls, remote workforce management software provides a practical reference.

Writing is no longer slow, which means the scarce skill is no longer being produced as a side effect. That is a real structural problem and nobody has a settled answer to it.

What actually goes wrong

Output outruns judgement. A junior can now produce more code than they can evaluate. The work looks finished, and neither they nor a busy reviewer can easily tell which parts they understand.

The struggle that taught things is skippable. Being stuck for an hour was expensive and it was where the learning happened. It is now optional, and people reasonably decline.

Confidence arrives before competence. Generated code is fluent, so work that a junior would previously have submitted hesitantly now arrives looking assured. That removes a signal reviewers relied on. GitHub documents Copilot as one major example of AI-assisted development tooling See GitHub Copilot.

Nobody knows what they know. In a team where writing was the visible activity, capability was legible. It is now much harder to tell whether someone can do something or can obtain it.

What seems to work

Nothing here is settled. These are the practices that hold up in small teams.

Teach reviewing before generating. Deliberately, as an activity. Give them existing code — a real pull request, a module in your system — and ask what is wrong with it, what is missing, what would break. The skill was previously acquired by osmosis. It probably now has to be taught on purpose, and early.

Require explanation, not just working code. Walk me through why this handles the empty case. If they cannot, the code is not theirs yet, regardless of whether it works. This is the single most useful practice on the list and it takes five minutes.

Deliberately unassisted work, sometimes. Not as punishment or purity. Specific exercises where the point is the struggle, in areas where being slow is safe. Say why, or it feels arbitrary.

Pair on verification-heavy work. The expensive bucket is where judgement gets built, and it is where a junior working alone is most likely to ship something confident and wrong.

Make the failure cheap. Feature flags, small changes, reversible deployment. If being wrong is inexpensive, a junior can be given real work sooner, which is how they learn.

What not to do

Do not ban the tools. They will use them anyway, less openly, and you will have removed the supervision rather than the practice. You will also be training someone for a job that no longer exists.

Do not treat generated output as their work for assessment. Neither as credit nor as blame. It tells you what they can prompt, not what they can judge.

Do not assume they will pick up review by watching. They previously picked it up by writing. Watching was never the mechanism.

Do not put them alone on the expensive bucket to see how they cope. The cost lands on the client.

The uncomfortable commercial question

Juniors were partly economic: cheaper hands for work that needed doing. A substantial share of that work is now cheaper still to generate.

So the honest reason to hire a junior is no longer labour arbitrage. It is that you are producing a reviewer, which takes years, and the alternative is competing for the small number of people who already have that skill.

That is a real investment case and it is a longer one than it used to be. Studios that decide juniors no longer pay for themselves will be right for about three years and then find they cannot hire.

What I tell juniors

Two things.

The bottleneck in your career is not how much code you can produce. It never really was, and it is now conspicuously not. It is whether people trust your judgement about whether code is right.

Get stuck on purpose, sometimes. Not always — that would be silly, and the tools are genuinely useful. But the hour you spend working out why something does not work is the hour that builds the thing you are actually selling. That is the part nobody can generate for you.

The short version