“We don’t need junior engineers anymore” has become one of those lines people repeat because it sounds obvious. The AI writes the code, so why pay someone to learn how to write it? On the latest Confident Commit podcast, Rob Zuber makes the case that this take is exactly backwards.

Rob sat down with two CircleCI colleagues at opposite ends of the experience spectrum. Hanabel Mengistu is a new grad less than a year into her first engineering role, part of CircleCI’s Associate Rotational Program, and already making a name for herself. Michael Webster is a staff engineer who has been writing software professionally since 2012. What comes through is that the people entering the industry right now have real advantages, and the anxieties they’re carrying are mostly solvable.

If you’re early in your career or trying to break in, here’s what to take from it, drawn from someone living it.

Watch the full episode below, or read on for the six takeaways.

The argument goes: AI writes the code, so the entry-level work disappears. It doesn’t hold up. The amount of software still to be written is enormous, and making coding more accessible only makes that pool bigger, not smaller. Someone still has to decide what to build, judge whether it’s right, and own the outcome.

What’s actually changing is the job you’re being trained to do, not whether the job exists. The manual mechanics get handed to the tools. The judgment, the product sense, the ability to solve a real problem for a real person stays with you.

Takeaway: Read the “no more juniors” headlines as a signal that the valued skills are shifting, not that the door is closed. Aim at the parts of the job AI can’t own yet:

• Reviewing generated code and judging whether it’s correct, secure, and solving the right problem
• Deciding what to test and where the edge cases hide
• Spotting the trade-offs and risks in a fast-written change
• Debugging a system the AI half-built
• Framing the problem in the first place

Our post on the risks and rewards of generative AI is a good primer on that last cluster.

A degree gives you computer science, not software engineering. You don’t learn how work gets decided, scoped, communicated, or shipped, and you definitely don’t learn how to operate inside a codebase that’s already too big to fit in your head. Hanabel and Webster went to school more than a decade apart and hit the same wall.

More than half the job turns out to be the stuff around the edges:

• How you decide what to work on
• How you talk about it with the rest of the team
• How you weigh the risk in a change
• How you build systems that hold up
• How you handle it when something breaks

You pick most of this up on the job, not in school, so it’s normal to start out feeling like you only know half of what you need.

Takeaway: Expect a gap between what you studied and what the job asks of you. That gap is normal, not a sign you fell behind. The fastest way to close it is doing the work next to people who have done it before, and treating the “edges” as the main event rather than the overhead.

Hanabel offered the clearest model for what to do with that gap. Asked how much of her CS education she’d had to unlearn, she was honest that she didn’t come in knowing much about process at all. What carried her instead was a simple habit: she’d hit a term she didn’t know in a meeting, look it up, and now she knows it. She treats not-knowing as a thing to go fix, not a thing to hide.

That habit doesn’t stop mattering with experience. Webster, years into the job, spends less time clinging to specific implementations and more time sharpening the underlying intuitions: what makes a good test, why a pattern exists, what you were actually trying to do. When the tools change this fast, the durable skill is the ability to keep learning, not any single thing you already know.

Takeaway: Treat “I don’t know that” as the start of a sentence, not the end of one. Hear an unfamiliar term, go find out, then let that answer point you at the next three things worth learning.

If you’re new, the thing you might read as inexperience is closer to an edge. You have no fixed idea of what a software team is supposed to look like, so you’re not spending energy unlearning habits that used to be load-bearing. That unlearning is real work for people further along. Webster described the hard version: the thing that saved you from production incidents and built your career might now be the bottleneck, and letting go of it is genuinely difficult.

You skip that step. You’re not fighting muscle memory. You can look at how things are done and ask why without a decade of “because that’s how we do it” pulling you back.

Takeaway: Don’t apologize for being new. Your questions surface assumptions the veterans stopped noticing years ago. Ask the naive “why do we do it this way” out loud. Half the time it’s the most useful thing said in the room.

For most engineers, the job was learned by sitting next to someone who knew more and asking questions. Hanabel described what she’s hearing from friends elsewhere in the industry: they feel like they aren’t learning as fast, and a little alone. When the reflex answer to every small question is “just ask the AI,” the mentoring relationships that used to carry juniors start to thin out.

An AI answers the exact question you typed. A good mentor does more:

• They notice why you’re asking
• They catch the piece of the puzzle you’re missing
• They open your eyes to things nearby you didn’t know to ask about

That surrounding context is what turns a junior into a senior, and it disappears when the AI becomes your only source. Hanabel’s own experience has been better precisely because she has people around her.

Takeaway: Use AI to move fast, but don’t let it become your only teacher. Keep asking people the questions that feel too small to bother them with, because those conversations are where the context lives. If your team doesn’t have a mentoring rhythm, ask for one. It’s a reasonable thing to want this early.

The tools change fast enough that everyone is back at the beginning together. Nobody has ten years of experience in something that’s a year old. That’s disorienting for veterans whose expertise just got partly reset. For someone starting out, it’s close to the best possible timing.

There aren’t many experts to defer to, because everyone is figuring it out at once. That can feel scary if you expected someone to have all the answers, but it’s also freeing: there’s far more room to contribute early, and the dynamic is collaborative rather than top-down. For Hanabel it landed as comforting, since it was good to figure things out with other people instead of feeling like she was the only one who didn’t know.

Takeaway: The playing field is more level than it’s been in a long time. Use it. Pick up the new tools without assuming the senior engineers are miles ahead, contribute in the open, and share what you learn. Right now that counts as much as tenure.

If you want to build the muscle of working alongside CI/CD the way this new generation of tooling expects, here’s a path from the inner loop out to production, all free to try:

• Validate the agent’s code as it’s written. When an AI agent is generating code, you want to catch the small mistakes before they ever reach a commit. Chunk sidecars run a fast CI-like check right inside the agent’s loop: install the CLI with brew install CircleCI-Public/circleci/chunk, run chunk init in your project, and the agent validates and fixes failures itself before handing the code back to you. It’s free for CircleCI users and works with Claude Code, Cursor, or Codex.
• Set up a pipeline for the deeper checks. Once code is committed, a pipeline handles the heavier validation and deployment: integration tests, security scans, and the steps that actually get your change to production. Connect a project, push a commit, and watch a pipeline run end to end. This is the outer loop, and seeing it run is the fastest way to understand what “shipping” really involves.
• Close the loop by connecting CI/CD back to your agent. When a build or deployment fails, the CircleCI MCP server gives an assistant like Claude Code direct access to your build logs, test results, and pipeline status, so it can read the failure, work out what broke, and push a fix without you copying logs between tabs. For a web assistant like Claude.ai, add the hosted server (https://mcp.circleci.com/v1/mcp) as a connector and sign in with OAuth. For a local editor, the server is built into the CircleCI CLI: run circleci mcp cursor enable for Cursor, circleci mcp vscode enable for VS Code, or circleci mcp claude enable for Claude Desktop.

The case against junior engineers gets the situation backwards. The work isn’t disappearing, it’s changing shape, and the traits that matter most in that new shape (curiosity, a fresh perspective, a willingness to learn in the open) are ones early-career engineers already have. As Hanabel put it, things are changing regardless of how you feel about them, so there’s little value in cynicism and a lot of value in staying positive about what you can learn and contribute right now.

Want more conversations on how software delivery is changing? Subscribe to the Confident Commit podcast and join Rob Zuber as he talks with engineers and leaders about building in the AI era. And if you’re ready to start shipping, see how CircleCI can help you build with confidence and get started for free today.