Juniors without tickets: growing engineers when agents take the starter work

My last essay, “Code Is the New Grammar”, argued that we should hire engineers the way we hire editors: test whether they can read code, judge it and own it, not whether they can type it from memory. It ended with “hire the editor.”

That essay left a hole, and it’s the obvious one. Editors learn to edit by writing first. Senior engineers learned judgment by shipping a lot of small, boring, well-specified changes and getting them reviewed. That’s exactly the work agents now absorb. If the junior never writes the boring change, where does the next editor come from?

This piece is my answer. It covers what the starter ticket was quietly teaching, what the research says about learning with an assistant in the loop, and the starter work I’d give a junior instead. For the worked example I use the study tools I built for myself, because they enforce the one rule that matters most here: you answer before the machine does.

The starter ticket was a training program nobody wrote down

Nobody designed the junior ticket as curriculum, but it worked like one. A well-specified ticket (“add a field to this form, validate it, add a test”) made a new engineer read an unfamiliar codebase to find where the field goes. It gave them a small blast radius, so mistakes were cheap. It produced a pull request, so a senior engineer explained what was wrong with it in writing. And it produced bugs the junior had caused, which is the best possible introduction to debugging, because you know the author.

That ticket is now the easiest thing to hand an agent. The spec is clear, the scope is small and the tests are obvious. Every reason it was good for a junior also makes it good for an agent.

The hiring numbers point the same way. Indeed’s Hiring Lab reported in July that entry-level roles were 4.5% of US software development postings in Q1 2026, the lowest share of any sector it listed, while senior roles were 69.3%, the highest. Across all occupations, entry-level postings were 46%. Stanford’s Digital Economy Lab revised its “Canaries in the Coal Mine?” paper in August 2026: employment of workers aged 22 to 25 in AI-exposed occupations “now stands 19% below” where it would be if it had kept pace with less-exposed peers, and it “operates primarily through reduced hiring of young workers rather than increased separations.”

The authors call these “early, descriptive indicators”, not causal estimates, and I’ll hold them to that. The hiring evidence makes the training question harder to ignore, but it doesn’t measure whether employed juniors are losing starter tickets.

Hiring juniors is necessary, and it isn’t enough

The best-known defense of junior hiring came from AWS CEO Matt Garman, who said on a podcast in August 2025 that replacing junior staff with AI was “one of the dumbest things I’ve ever heard”. His reasons were practical: juniors are among the least expensive people you employ, they tend to be the most engaged with AI tools, and if you stop hiring them, nobody learns anything for the next ten years.

I agree with all of it, and it still leaves the hard part open. Hiring a junior and handing them an agent plus the old ticket queue doesn’t produce a senior engineer. It produces someone who has merged a lot of code they couldn’t rewrite. The pipeline argument says hire them. It doesn’t say what they should do on Monday.

What one trial measured: 50% vs 67%, and debugging took the hit

The most useful evidence I’ve found is a small randomized trial Anthropic published in January. Its researchers recruited 52 software engineers who had used Python weekly for over a year but had never used Trio, an async library. Everyone built two small features with Trio, then took a quiz without help. Half had an AI assistant in the sidebar that “could at any time produce the correct code if asked.”

The assistant group averaged 50% on the quiz. The hand-coding group averaged 67%. The study’s own summary: “using AI assistance led to a statistically significant decrease in mastery.” The largest gap was on debugging questions. And the speed payoff was small: the AI group finished about two minutes faster, and that difference wasn’t statistically significant.

The part I’d put in front of every engineering manager is the breakdown by how people used the assistant.

Those groups are small, and the authors say plainly that their analysis “does not draw a causal link between interaction patterns and learning outcomes.” Still, the shape is hard to ignore. “AI delegation”, where participants “wholly relied on AI to write code,” was the fastest pattern and landed in the low-scoring tier at 39%. “Conceptual inquiry”, where people asked only conceptual questions and wrote the code themselves, scored 65%. The two people who generated code and then asked follow-up questions to understand it scored 86%.

One more caveat from the authors, and it cuts the uncomfortable way: the trial used a chat sidebar, not an agent that edits files on its own. They expect agentic tools to have “more pronounced” effects on skill development than what they measured.

Answering first is the part the agent removes

None of this surprised me, because learning research has known it for a long time. In a 2006 study, Roediger and Karpicke had students either reread prose passages or take practice recall tests on them. Rereading won on a test five minutes later. Practice testing won a week later. Retrieval is slower and feels worse while you’re doing it, and it’s the version that sticks.

Reading an agent’s answer can resemble rereading. Even when the answer is correct, reading it can feel like understanding. The effortful step, producing an answer before you see one, is exactly what an always-available assistant lets you skip. Nobody skips it on purpose. It’s just one click away, every time.

So the design question for junior work isn’t “AI or no AI.” It’s where the attempt goes. An attempt that comes before the answer is a lesson. An answer that comes before any attempt is reading.

I built answer-first into my own study tools

I’ve been studying for an infrastructure certification and learning inference serving, and I built two tools for it. Both make the attempt come first, and both enforce it in code rather than by asking nicely.

The first is a phone app for exam practice: photograph a question, then check your answer, ask for an explanation or get quizzed on it. Since 6f54c40 Study: Expo app and Worker backend for NCP-AIO prep , the backend refuses to grade anything you haven’t answered yourself:

if ((action === 'check' || action === 'quick') && !myAnswer)
  return json({ error: 'Commit your own answer before checking' }, 400);

The app enforces the same rule in the interface. On a multiple-choice photo, Explain stays locked until you’ve checked an answer, because an explanation of a multiple-choice question gives the answer away. There’s no mode that shows the answer first, and that’s deliberate.

The second is a learning app with interactive 3D walkthroughs. In 2553751 Learn: interactive 3D walkthroughs for the KV cache module , a walkthrough step gained an optional predict block: the scene stops, asks what will happen, and won’t play until you pick an answer. The content now has 42 of these predict-first steps across 22 walkthroughs and 6 modules, after c81e1cb Learn: interactive 3D walkthroughs and quizzes for all four remaining modules and 1ecab46 Learn: add Conversational turn-taking module (sixth module) .

The Learn app also asks how sure you are before you submit. Since cc85a12 Learn app at /app: WASM core, offline PWA, access-code sign-in , every answer carries a confidence (guess, fairly sure or certain), and the scoring makes honesty pay. In the code’s own words: “Wrong but honestly unsure (confidence 1): +2, so calibration pays.” Wrong and certain earns nothing. A hint halves the base points and removes the confidence bonus; an incorrect low-confidence answer still earns 2 points. A calibration score compares your stated confidence with your actual accuracy, so overconfidence shows up as a number.

These tools don’t prove much yet. They’re two apps with one user. What they show is that the gate is cheap to build. Each is a few lines and a disabled button, and it changes what the tool teaches.

Starter work that keeps the attempt

If the agent takes the ticket, the junior needs work that keeps the useful part of the ticket: an attempt, a small blast radius, written feedback and their own mistakes to debug. Here’s what I’d give them instead, mapped against what the old ticket taught.

1. Predict before you run. Before reading an agent’s diff, the junior writes down which files it should touch and what the tests should check. Then they compare. Misses are the lesson.
2. Write the spec first. The junior writes the task for the agent: the problem, non-goals and risk areas. A senior writes one too, separately, and they compare the two before anything runs. This is the decomposition skill from the hiring piece, practiced daily instead of tested once.
3. Defend every accept and reject. The junior reviews agent pull requests and has to give a reason for each decision. The senior grades the reasons, not the verdict.
4. Debug before you ask. When something breaks, the junior gets a fixed window to form a hypothesis and write a failing test before involving the agent. The Anthropic trial’s largest gap was debugging, so this is where I’d spend the protected time.
5. Say how sure you are. On reviews and predictions, the junior records guess, fairly sure or certain. Over a month, a manager can see whether their confidence tracks their accuracy, the same way the Learn app does.

The agent stays in the loop for all of it. It writes the code; the junior does the thinking around the code that a senior used to do and the junior never got to practice.

The plan review is the junior skill nobody teaches

On my own projects, the most useful review I’ve done recently was of a plan. I wrote about it in Architect of Intent: b41d261 the first build of a drafting tool followed a written handoff faithfully, and 0ae265d the second replaced it with a standalone CLI, because the plan itself was the wrong shape. Nothing in the first build was wrong. An agent can check code against a spec. Passing that check doesn’t establish that the spec was the right one.

That’s a judgment juniors used to absorb slowly, by watching seniors push back on tickets in planning. With agents, the cost of a bad plan shows up faster and bigger, because the agent builds it faithfully in an afternoon. So I’d put juniors in the room for plan review early, give them a plan to critique before the senior does, and compare notes. It’s the same pattern as everything above: their attempt first, then the expert’s.

Make the learning mode a setting, not a habit

The tools are starting to support this directly. Claude Code ships a Learning output style that handles routine implementation but stops and asks you to write some of the code yourself, marking the spot with a TODO(human) comment and reviewing what you write before it continues. That keeps the learner involved, though the trial did not test this output style.

I’d make that the default for a junior’s first months, as a team setting rather than a personal virtue. The trial’s high scorers didn’t have better tools; they used the same tool differently. A setting is how you make “differently” the normal case instead of relying on willpower at 4 p.m. on a Friday.

The same goes for rules. My writing rules live in a file, added in af270ec blog-writing skill: framing, numbers, polish bar , because I learned that a rule I only say out loud gets broken. A team’s learning rules for juniors belong in the same place: the repo’s agent instructions, the review template and the onboarding doc, where the agent and the junior both read them.

What I didn’t check

• The trial is small and short. 52 people, one task with a 35-minute limit and a quiz right afterward. The authors say it doesn’t show whether the gap lasts or fades as people gain fluency. The pattern groups are 2 to 7 people each.
• The employment numbers are descriptive. Stanford’s authors call their findings “early, descriptive indicators”, not causal estimates, and say some trends predate generative AI. I quote their August 2026 revision, which uses a different figure (19%) from the 2025 version most articles cite (13%).
• Indeed’s categories are classifier labels. Entry, mid and senior come from Indeed’s text classifier, not job titles, and Indeed doesn’t publish the mid-level share for software.
• My tools have one user. I have no measured outcome from the answer-first gates, only the design. The Learn app’s 6 modules are all still marked unreviewed in the content file.
• I haven’t run this program with a junior team. The starter-work list is a proposal built from the evidence above, not a result.

A checklist for growing engineers without starter tickets

1. Decide, in writing, what a junior’s first 90 days should teach, since the ticket queue no longer teaches it by default.
2. Put the attempt before the answer: a prediction before reading the diff, a spec before the agent runs, a hypothesis before asking for help.
3. Protect debugging time, where the evidence shows the biggest gap.
4. Have juniors critique plans before seniors do, then compare.
5. Record stated confidence on predictions and reviews, and look at the calibration monthly.
6. Turn on a learning mode in the agent for new engineers as a team default.
7. Grade reasons, specs and predictions. Don’t grade merge counts.
8. Write these rules where the agent and the junior both read them: agent instructions, review templates, onboarding docs.

If you’re working out how to keep a junior pipeline healthy on a team that has adopted agents, here’s how I work.

---

AI-assisted, human-reviewed.

Related: Architect of Intent: software engineering isn’t ending, the typing is and Hand the next owner a broken run.