Junior engineers are skipping straight to architect-level thinking

Estimated reading time: 8 minutes

Key takeaways:

• Junior software engineers are leapfrogging to architect-level thinking, and apprenticeships need real senior bandwidth to catch up.
• Track engineering growth, learning, understanding, and judgment as primary metrics alongside output.
• AI proficiency should scale through three phases: tutor, copilot, and accelerator, with scaffolding that loosens as judgment develops.

---

In an AI-heavy engineering world, we talk a lot about speed and output. However, we’re generating code faster than we’re building the learning, understanding, and judgment junior software engineers need to grow in their career and truly own the systems they work on.

The real test of whether we’re growing our engineers shows up in critical incidents. Picture a top-severity incident (a P1), in the middle of chaos and stress: can the engineer draw on real, accumulated skill to reason through how the stack works, decide where to debug first, and make the right judgment calls – or are they just chasing whatever red flag the AI tooling surfaces?

The risk is leaning too heavily on AI without the experience to notice when it’s leading you down the wrong path. I’ve seen this pattern play out repeatedly: an early-career engineer prompts the AI tooling with what they’re observing and immediately acts on its suggestions, only for a senior engineer to step in, think through the problem, and course-correct based on their own understanding of the stack.

As an engineering manager, I care about building teams with diverse skill levels and bringing in new talent – but in a world where most of an engineer’s code is generated, that talent still has to learn to understand the systems they’re building, not just produce more of them.

That shift is pulling engineers toward architect-level thinking much earlier in their careers than it used to, leapfrogging into that role instead of growing into it gradually.

That’s why I want to treat engineering growth itself – learning, understanding, and judgment – as a primary metric, not just throughput, using humans as mentors and tooling as tutors to build that level of engineering caliber.

Growth as a metric: learning, understanding, and judgment

By engineering growth, I mean an engineer’s ability to learn, understand, and develop judgment. These are the capabilities that let someone own the systems they work on, not just ship more code.

Learning

We can be intentional about tracking what changed after each ticket or project: what did an engineer actually learn, and did AI help them learn faster, or just confuse them? Asking that explicitly helps engineers notice whether the tools are supporting their growth or just accelerating their output.

Understanding

The signal is whether an engineer truly understands the code they’re generating and merging into the shared repository, and can point to where they’re still fuzzy on the system’s design. The clearest test is whether they can walk through a recent change and explain how it works, including the core concepts behind it.

Judgment

I look at how engineers give and respond to code reviews, what questions they ask, and how they handle bugs or on-call incidents. This includes whether they’re engaged in discussions, raising risks and tradeoffs, and becoming part of the group that helps drive design, architecture, and shared understanding.

Apprenticeships and internships: building engineers, not just hiring velocity

Building that kind of learning, understanding, and judgment starts with how we bring in and grow new talent in the first place.

It’s especially important right now to provide apprenticeship and internship opportunities, since hiring has become difficult: our current interview practices are a poor way to test whether someone will succeed, especially early in their career.

For associate engineers and interns, what I look for are strong behavioral characteristics – people who are curious, open to learning, and who show accountability and integrity. Those are traits that show up over time in a longer internship or apprenticeship program, not in a short interview loop.

To make those programs meaningful, early-career engineers need teams with real bandwidth from senior engineers to mentor them, and a diverse set of work to do. That mix lets interns and associates build their skills over the course of the program, and gives them space to show they can handle both the day-to-day and the higher-stress situations while learning and working with the team.

Being a software engineer takes more than writing code: communicating with technical and non-technical partners, handling ambiguity, and showing empathy and emotional intelligence. Internships and apprenticeships are a way to see and develop those skills in context, not in isolation.

This investment also strengthens our more senior engineers. Teaching someone how to do something demonstrates – and deepens – a person’s own understanding of the system’s core concepts. Mentoring becomes part of an ecosystem we’re trying to build within the organization: having humans around to learn from can only enhance the core skills that engineers need to succeed. That’s particularly important when most of an engineer’s code is generated – humans as mentors, tooling as tutor.

How this approach evolves as junior engineers grow

Using AI is already part and parcel of the day-to-day for software engineers, but we should be intentional and thoughtful about how we use it. I see AI proficiency and an engineer’s understanding of a system evolving through three broad phases – tutor, copilot, and accelerator. The goal isn’t to lock people into a phase; it’s to make expectations and scaffolding explicit, then relax that scaffolding as engineers grow.

AI as tutor

In this first phase, the tool is used primarily to learn. Engineers ask it to explain code, patterns, and systems, and use Socratic prompts to identify gaps in their understanding.

They track those gaps rather than letting them slide, and the growth I look for shows up in their pull requests over time – clearer descriptions, better questions, improved tests.

They also regularly ask questions of their mentor and teammates to understand the stack, not just which prompt to use. Managers and mentors provide strong scaffolding: regular pairing with a named mentor, tighter review expectations on AI-heavy changes, and frequent one-on-one conversations about what the engineer is learning.

The success metric is visible learning and deepening understanding, not raw throughput. As engineers show they can reason about AI’s output, that scaffolding can loosen – pairing and close review stay available for support, rather than expected by default.

AI as copilot

In this second phase, engineers use AI to create more complex work while still owning the design decisions and edge cases themselves. 

Their pull requests meet team standards for reliability, security, and observability, and their defect rate stays within normal bounds, with no spikes tied to AI use. They can independently debug issues in areas they’ve worked on, showing they’ve developed real understanding of the system.

They also start leaving thoughtful review comments on others’ pull requests, asking the right questions and growing into a real reviewing partner. Managers and mentors loosen the scaffolding here: pairing sessions that are available rather than required, more autonomy over when and how to use AI, and more emphasis on review quality and incident handling as signals of judgment.

The learning, understanding, and judgment check-ins continue in one-on-ones, but the focus shifts toward system-level understanding and how the engineer mentors others informally – how they show up in Slack channels and in requests for comments (RFCs). Once they consistently show solid judgment and stable quality on AI-assisted work, managers can phase out the extra junior-only review steps.

AI as accelerator

This final phase is less about a title than about the trajectory we’re aiming an engineer toward, once they have real experience behind them.

They treat AI like a fast, junior partner: bringing clear requirements and plans, questioning AI’s proposals and catching red flags, especially around architecture and long-term impact, and maintaining stability and reliability while using AI to move faster.

They act as multipliers, too – mentoring early-career folks, modeling good prompts, workflows, and reviews, and participating in key design and architecture conversations.

At this level, managers should treat these engineers as part of the apprenticeship infrastructure: expecting them to mentor, review, and teach, asking them to help refine the team’s AI norms and guardrails, and continuing to support their growth on higher-level skills like system design, product thinking, and cross-team work.

Intentional, thoughtful use in a volatile space

We’ve talked a lot about treating engineering growth as a first-class metric, and how apprenticeships and internships are critical to developing a strong cohort of software engineers who can maintain the systems we’re building.

However, this is such a volatile space, and things are changing so frequently, that I’d never consider any of this a final playbook.

The most important thing is staying thoughtful and intentional about how we use these tools. It’s easy to fall into a mode of just building things rapidly, but we should pause to think about the cognitive load of moving that quickly, and design our organizations and systems so the humans within them can keep up with what we’re building – so we can maintain and grow those systems in reliable, scalable, observable ways.

The true test, I believe, will always be when a system fails – how quickly we can recover, and whether we have a team that understands, owns, and is responsible for the system’s health, sustainably.

It’s also important that we design teams so engineers are learning from each other, enhancing that learning with AI tooling – but always protecting senior engineers’ bandwidth to teach and upskill more junior engineers, so they can build the muscle that only comes with time. 

We’re expecting a lot from early-career engineers very quickly, and we have to make sure they’re getting enough exposure and experience to build the judgment necessary to be a successful software engineer.