Whose Fast Is It? An Interview With a Junior Engineer Learning a Job the Agent Already Does

For most of the history of office work, the first year of a job was a long apprenticeship in small mistakes. You wrote the boring query, broke it, and stared at the error message until it confessed. Nobody put this on a syllabus. You did the work, and somewhere around month eight you noticed the work had been teaching you.

That boring work is increasingly the first thing a machine picks up. Which leaves anyone starting out with an awkward question. If the practice reps are delegated, where does competence come from?

The research answers in two voices. At one firm's customer-support operation, an AI assistant raised novice productivity by 34%, and agents two months into the job performed like unassisted colleagues with six.¹ In a high school math experiment, students with an unrestricted chatbot did 48% better during practice and 17% worse on the exam they took alone.² Neither result is a fluke. They are timing different things. One clocks how well you perform with help. The other checks what's left in your hands after the help leaves the room.

To find out what it feels like to live between those two numbers, we sat down with Finn Rubberduck, 24, eighteen months into a junior backend role. Finn is fictional, assembled from research papers and the whine of an overworked laptop fan. He points out that this is still more structured onboarding than many real juniors get.

We met on the afternoon his team's coding agent went down for scheduled maintenance. Finn calls these days exam day. Beside a cold oat latte on his desk sat an actual yellow rubber duck.

"Heirloom," he said. "Programmers used to explain their bugs to it out loud, and halfway through the sentence the answer would show up. Now something explains my bugs to me, and the duck just watches. I think it's taking notes."

Start with an ordinary day. What does the job look like when the agent is up?

Finn: The honest version? I'm a reviewer who's never been a writer. A ticket comes in and I describe it in plain English. The agent drafts a fix, adds tests, and writes a summary in very calm paragraphs. Suspiciously calm. I poke at it, then approve it or send it back.

The tickets I was supposed to learn on, the off-by-ones and missing null checks, the small dumb bugs juniors used to collect like scout badges, get closed before my coffee is drinkable.

My manager says I'm fast. I am fast. I'm just not sure whose fast it is.

The support-center researchers think the assistant passed tacit know-how from top performers down to novices. Does that match what you feel?

Finn: Partly. The agent writes like someone who's been burned before. It checks edge cases I didn't know were edges. I've absorbed habits just by standing next to it. I name things better now. My functions have stopped being called doThing2.

But in that study, the real evidence of learning came from the outages. When the tool went quiet, workers still beat their old baseline, though the authors flag those numbers as noisy.³ Which is basically my entire situation, compressed into a footnote.

Then there's the math study, where most students simply asked the chatbot for answers and copied them down.

Finn: That one ruined a weekend. I'd rather not discuss it in front of the duck.

Today is exam day. How's it going?

Finn: Okay-ish. This morning a job started failing with timeouts in a queue worker, which is the background process that chews through a line of tasks. On a normal day I'd paste the error trace and the agent would tell me a story about it, and the story would probably be true. Today it was just me and the trace.

For the first twenty minutes I wasn't debugging. I was waiting. My hands kept expecting something to happen, like reaching for a phone that isn't in your pocket.

Then I started reading line by line, and some of it I knew. Actually knew. The retry logic, for example. I'd read the agent's explanation of that pattern maybe forty times, and at some point it stuck. I said "ha" out loud. The duck can confirm.

One layer down is how the system handles a task that gets cancelled halfway through, and there I hit a wall. A soft, humiliating wall. I'd seen every word before, and none of them connected to anything. I'd nodded along to that explanation a dozen times. Nodding, it turns out, is its own skill, and it transfers to nothing.

It took me two hours. The agent would've needed four minutes. Those two hours were the most educational thing I've done since March, and I find that sentence slightly horrifying.

Does that two-hour feeling show up anywhere in the research?

Finn: There's a randomized trial where mostly junior developers learned an unfamiliar library, some with AI and some without. The AI group scored lower on a quiz afterward, and the biggest gap was on debugging.⁴ The researchers suspect the hand-coders improved partly because they hit more errors and had to dig themselves out.

I read that and just thought, oh.

The same trial split scores by how people used the AI. Those who generated code and then asked follow-up questions to check their own understanding were among the top scorers.

Finn: Right, so I turned that into a rule. One more question. Before I approve anything, I ask why. Why this approach and not the obvious one? What breaks if I delete this line? I keep a file of the answers I couldn't have predicted. It's getting long, which is either encouraging or deeply not.

Do I know it works? No. Some of those groups had two people in them, and nobody was assigned a pattern. People chose their own. Maybe the curious ones were going to learn regardless, and the follow-up question is just what curiosity looks like from across the room. I can't rule out that I'm performing curiosity at a chatbot. It's very gracious about it either way.

The researchers say "getting painfully stuck" is likely important for mastery. The paper is blunter, saying AI productivity "is not a shortcut to competence."⁵ Do you get stuck on purpose?

Finn: I try. I have a timer. Twenty-five minutes alone with a bug before I'm allowed to ask. It feels deranged, like refusing a calculator to stay sharp at long division.

And sometimes that's exactly what it is. Some of what I'm grinding through is friction nobody will need in five years. Memorizing a deploy incantation is closer to hazing than to expertise. If I treat every old struggle as sacred, I'm basically doing historical reenactment with a laptop.

So the real skill is working out which kinds of stuck are load-bearing. Reading a trace and smelling that something's off feels load-bearing. Remembering flag syntax probably isn't.

I don't always pick right. Mostly I pick based on how tired I am.

Your actual job is review. A 2026 preprint found programmers correctly accepted valid generated test assertions 74% of the time but correctly rejected invalid ones only 49% of the time. Low-quality explanations also made them more confident and less accurate.

Finn: So, a coin flip. With extra steps.

That's the one that keeps me up. The agent's explanations sound like a senior engineer, calm and structured and a little bit kind. I've caught myself trusting the tone. If a person explained something that smoothly, I'd assume they'd earned it the hard way.

And review is the job I actually have. Doing it well takes exactly the instincts I'd have built by writing the code badly first. It's like being hired as a driving examiner before your first lesson. You can definitely tell when someone hits a mailbox. The rolling stops are another story.

Where do actual people fit into your learning?

Finn: I beg for review comments. Shamelessly. One study of software engineers at a large company found that sitting near your teammates meant more comments on your code, and younger engineers got roughly twice the average boost.⁶ That's a separate channel from the agent. The agent gives me answers. A person gives me the "hm" face, the look of someone who was wrong in exactly the way I'm about to be wrong, probably six years ago, probably on a Friday.

I've learned more from the "hm" face than from any summary.

Pilots have to log three takeoffs and landings every ninety days before they can carry passengers.⁷ Have you built yourself anything like that?

Finn: Ha. Sort of. My personal currency rule is three bugs a month, by hand, start to finish, agent off. I write down what I got wrong. It's a tiny logbook and mildly embarrassing. The duck is not allowed to read it.

Nobody dies if I misread a queue worker, obviously. What I stole was the principle underneath, that you earn the right to supervise something by regularly doing it yourself.

So. Are you getting good at this job?

Finn: I don't know.

(He picks up the duck, turns it over as if checking for a serial number, and sets it back down.)

I'm good at something. I'm faster than I'd be without the agent, and some of that speed belongs to me now. Today proved that much. But there's a version of me that only exists while the tool is running, and I can't tell where he ends and I begin until a day like this.

The evidence doesn't know either. Nobody has followed someone like me for five years. So I'm running the study on myself. Sample size of one. Duck for peer review.

Ask me after the next outage.

Footnotes

1. Brynjolfsson, Li, and Raymond, "Generative AI at Work," NBER Working Paper 31161 (published in QJE, 2025). https://www.nber.org/papers/w31161 ↩

2. Bastani et al., "Generative AI without guardrails can harm learning: Evidence from high school mathematics," PNAS (2025). https://www.pnas.org/doi/10.1073/pnas.2422633122 ↩

3. Brynjolfsson, Li, and Raymond, full working paper, including outage-period analysis. https://www.nber.org/system/files/working_papers/w31161/w31161.pdf ↩

4. Shen and Tamkin, randomized trial of 52 mostly junior software engineers learning an unfamiliar Python library (vendor-authored research; small sample; quiz taken shortly after the task). https://www.anthropic.com/research/AI-assistance-coding-skills ↩

5. Shen and Tamkin, arXiv preprint abstract. https://arxiv.org/abs/2601.20245 ↩

6. Emanuel, Harrington, and Pallais, "The Power of Proximity to Coworkers: Training for Tomorrow or Productivity Today?" NBER Working Paper 31880 (2023). https://www.nber.org/papers/w31880 ↩

7. 14 CFR § 61.57(a), recent flight experience requirements for pilots in command carrying passengers. https://www.ecfr.gov/current/title-14/chapter-I/subchapter-D/part-61/subpart-A/section-61.57 ↩