An Engineering Director Watches Her Junior Developers Forget How to Debug

Pip Okafor-Reyes is a fictional engineering director. Her situation is not.

She runs a 60-person engineering organization at a healthcare SaaS company in Toronto. The kind of mid-stage startup where the engineering ladder exists because she built it herself, four years ago, on a whiteboard in a conference room that has since been converted into a "focus pod." She came into software through a coding bootcamp in 2012, which makes her either the perfect person or the worst person to talk about shortcuts in developer education. She'd say both.

We wanted to talk to someone living inside a problem that the research is only beginning to name. A January 2026 study from Anthropic found that developers using AI assistance scored significantly lower on debugging and comprehension assessments, with the largest gaps appearing in exactly the diagnostic skills needed to oversee AI-generated code.¹ A separate controlled experiment found that developers with unrestricted AI access had a 77% failure rate when asked to maintain their own code without the tool.² Junior developer hiring, meanwhile, has dropped nearly 20% among 22-to-25-year-olds since 2023, according to Stanford payroll data.³

Those numbers describe a system. Pip describes what it feels like to manage inside one.

You built your company's engineering growth framework. When did you start noticing it wasn't working the way it used to?

Pip: Late 2025, maybe? There wasn't a single moment. We do quarterly growth reviews, and I kept reading self-assessments from developers who'd been with us for 14, 15 months. They were listing features they'd shipped. Long lists. Impressive lists, honestly. But when I'd ask their leads about readiness for the next level, I kept hearing this same hesitation. "They're productive, but..." And nobody could finish the sentence cleanly.

It took me a while to figure out what the "but" was. The code was fine. Sometimes better than fine. It was that they couldn't walk you through it. You'd ask, "why did you choose this approach?" and you'd get a pause that was a little too long. They could explain the what perfectly. The why was a different story.

That's a subtle thing to catch.

Pip: Incredibly subtle. And that's what made it so slow to recognize. If someone's shipping clean, tested features on schedule, your pattern-matching says "this person is growing." The engineering ladder I wrote literally has "ships features independently" as a milestone. They were hitting milestones. They just weren't becoming engineers at the rate I expected. Which is a weird thing to say about people who are, by every visible measure, engineering.

You came up through a bootcamp yourself. How do you think about the difference between that shortcut and the AI shortcut?

Pip: Oh, I've thought about this a lot, because the obvious criticism is "you took a shortcut too, Pip, get over yourself." And fair enough. I did. But the bootcamp shortcut skipped theory. It skipped the computer science degree, the four years of algorithms and operating systems. What it didn't skip was the struggle. I still had to debug my own garbage code at 2 AM. I still had to read stack traces until my eyes bled. I still had to sit with a broken deployment and figure out what went wrong with nothing but logs and stubbornness.

The AI shortcut skips the struggle. And I'm increasingly convinced the struggle was where most of the learning actually happened. Not in the bootcamp curriculum. Not in the lectures. In the three hours you spent chasing a bug that turned out to be a missing await.

The research calls that "incidental learning," knowledge you acquire as a byproduct of effortful problem-solving.⁴

Pip: Yes! That's exactly it. Nobody teaches you to debug. You debug because your code is broken and you need it to not be broken. And somewhere in that process, you build a mental model of how systems fail. You start to develop what I call a "smell." You look at a piece of code and something feels off before you can articulate why.

That smell is what I'm not seeing develop.

What does the absence of that instinct look like in practice?

Pip: I'll give you a specific one. We had an incident in March. Data sync issue between two services. Not catastrophic, but tricky. The kind of thing where you need to trace state through three systems to find where it diverged. I asked one of our stronger junior developers to lead the investigation. She'd been with us 16 months, shipping great work, good reviews.

She opened her AI assistant and started prompting it with the error logs.

And look, that's not wrong. I use AI for debugging too. But she went straight there. Didn't read the logs herself first. Didn't form a hypothesis. Didn't pull up the service diagram and think about where state could diverge. Just: "here are the logs, what's wrong?" And when the AI gave her three possible causes, she didn't know how to evaluate which one was most likely. Because she didn't have a mental model of how those services talked to each other.

She's smart. She's capable. She'd just never had to build that model, because for 16 months she'd had a tool that let her skip that step.

Did you say anything to her?

Pip: I sat with her and we debugged it together. Old school. No AI. Took two hours. She was frustrated for the first 45 minutes and then something clicked and she got excited. She said, "Oh, I didn't realize this service was doing its own caching."

And I thought: how could you not know that? You've been shipping features that touch this service for months. But she'd been shipping features through the AI. She'd never had to understand the system underneath.

That must be uncomfortable, given that you're the one who gave the team these tools.

Pip: [laughs] Yeah. I championed the AI tooling rollout. I was excited about it. And the productivity gains were real, especially in the first six months. Our time-to-first-commit for new hires dropped from about three weeks to four days. I thought we were revolutionizing onboarding.

Now I think we were fast-forwarding past the part where people learn where the bathrooms are. They could commit code without understanding the codebase. And for a while that looked like efficiency.

So what are you doing about it?

Pip: Still figuring it out, honestly. We've started what I'm calling "unplugged rotations." One week per quarter where junior developers work on maintenance tasks without AI assistance. It is not popular. One of my developers called it "engineering Amish country," which I thought was funny enough that I almost made it the official name.

But the feedback after the first round was interesting. Several people said it was the first time they'd actually read the codebase. Not prompted about it. Read it. Like a book, with their eyes.

We're also experimenting with pairing seniors and juniors specifically on debugging, not on feature work. On incidents. The idea being that debugging is where the mental models form, so that's where the mentorship should concentrate.⁵

Is it working?

Pip: Ask me in a year.

That's the hard part, isn't it? The timeline.

Pip: That's the whole problem. The AI gives you measurable productivity gains in weeks. The skill development I'm worried about takes years. And I report to a CEO who can see the sprint velocity charts. I can't show her a chart that says "debugging instinct formation: 34% complete."

There's no metric for engineering judgment. There never has been. We just used to be able to assume it was developing because people were doing the work that builds it. Now they're doing different work. Faster work. But I'm not sure it's building the same thing.

Last question. You took a non-traditional path into engineering. Do you think the developers on your team will be able to say the same thing in ten years, that they found their own way to real expertise, just differently than you did?

Pip: I want to say yes. I really do. Because I believe in people finding unconventional paths. That's my whole career story.

But I keep coming back to something. When I was coming up, the shortcut I took still left me alone in a room with broken code. The shortcut my juniors are taking doesn't. And I don't know what replaces that experience. I don't think anyone does yet.

Maybe they'll find a different path to the same place. Maybe the "same place" won't exist in ten years and the question is irrelevant. But right now, today, I have developers who are 18 months in and can't debug a caching issue in a system they've been shipping to for a year.

Footnotes

1. Shen, J. H. and Tamkin, A. "How AI Impacts Skill Formation." arXiv:2601.20245. January 2026. https://arxiv.org/abs/2601.20245 ↩

2. Sankaranarayanan, S. "Mitigating 'Epistemic Debt' in Generative AI-Scaffolded Novice Programming using Metacognitive Scripts." arXiv:2602.20206. https://arxiv.org/html/2602.20206v2 ↩

3. Russinovich, M. and Hanselman, S. "Redefining the Software Engineering Profession for AI." Communications of the ACM, 2026. https://dl.acm.org/doi/10.1145/3779312 ↩

4. "Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development." arXiv:2607.06101. https://arxiv.org/html/2607.06101 ↩

5. The preceptorship model described by Russinovich and Hanselman envisions senior engineers pairing with juniors specifically to observe and develop judgment in AI-assisted workflows. https://www.infoq.com/news/2026/04/junior-developer-pipeline-crisis/ ↩