Engineering Onboarding in the Age of AI

(This post is adapted from a document I wrote for new engineers at Notion.)

As agentic coding tools have exploded in power, they’ve become an incredible superpower for engineers onboarding onto a new codebase. They allow a new engineer to quickly build a high level understanding of a new system, and execute major changes without having to wade through a confusing maze of unfamiliar code.

However, we’ve also started to observe some negative impact from an over-reliance on AI tools, both from new engineers and their teammates. In this post, we’ll discuss those effects and how we could mitigate them from an engineering culture standpoint.

Over the next 5-10 years, it’s quite possible that we’ll get to a point where humans no longer need to be reviewing AI-generated code, in the same way we no longer need to review compiler-generated machine code. But we’re not there right now. With the current state of AI tools and production codebases, it’s extremely easy for AI tools to generate code that is subtly incorrect, performs poorly, is excessively complex or verbose, or goes against established conventions and best practices. Human review is still required to ship a high quality product to real customers. While we are in this state of affairs, it’s critically important for every engineer to build and maintain proficiency in reviewing code generated by AI tools, in the same way that we’d review code written by human teammates.

Building proficiency

It’s exhilarating to start shipping PRs in a new job right away. However, with the current state of AI tools, the engineer wielding them still needs to build general proficiency in an existing codebase to operate productively.

The problem we’re seeing is that relying on agentic coding tools to generate code too much too soon, without having invested in building your own proficiency first, can actually hurt your productivity and growth in the long run. We’ve been hearing from new engineers “I feel like I still have no clue what I’m doing” despite already shipping PRs.

This corroborates evidence from industry research: engineers who are more proficient are better able to leverage AI coding tools [1] [2], but over-reliance on AI coding tools can hamper the ability to build that proficiency in the first place [3]:

Our results suggest that incorporating AI aggressively into the workplace, particularly with respect to software engineering, comes with trade-offs. The findings highlight that not all AI-reliance is the same: the way we interact with AI while trying to be efficient affects how much we learn. Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of skill development—and notably the ability to debug issues when something goes wrong.

Though preliminary, these results suggest important considerations as companies transition to a greater ratio of AI-written to human-written code. Productivity benefits may come at the cost of skills necessary to validate AI-written code if junior engineers’ skill development has been stunted by using AI in the first place. Managers should think intentionally about how to deploy AI tools at scale, and consider systems or intentional design choices that ensure engineers continue to learn as they work—and are thus able to exercise meaningful oversight over the systems they build.

Why is this the case?

We learn through repetition. A new engineer naturally learns core abstractions, best practices and caveats / quirks through the repeated process of reading and writing code. What we’re seeing is that over-reliance on AI tools to generate code early on can impede this process, and make it slower for a new engineer to internalize knowledge and calibrate their own judgement. So even though eventually we’ll all be spending more time reviewing code from AI tools rather than writing code by hand, the latter remains the fastest way to get yourself ready for the former.

Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery. [3]

We learn accidentally, not just intentionally. Writing code by hand is slower partially because it forces you to read related existing code and docs and think through every decision. For instance, you might have to read through similar components to look for patterns, helpers, or conventions, and think about other considerations like testing and observability. This in turn helps you organically discover and absorb core abstractions and best practices you didn't initially set out to learn, which eventually help you become a better well-rounded engineer. But over-reliance on AI tools to generate code eliminates such opportunities for organic learning. You arrive straight at the destination, and miss out on all the potential learnings along the way.

So the lesson here is: as a new engineer, prioritize learning over velocity. Take the time to invest in your own proficiency. Learn how to build something right, then how to build it fast.

Building trust

It’s an adage that it’s harder to read code than write it [4]. With agentic coding tools, writing code becomes cheap, but reviewing code only becomes more expensive. In fact, in the not too far future, our overall productivity is likely to be more bottlenecked by reviewing code than writing code.

This is particularly apparent when a new engineer attempts large, complex AI-generated PRs that they themselves don’t have enough proficiency to review. These situations can easily lead to conflict and negatively impact the new engineer’s ability to build trust with the team. Typical feedback from teammates might look like the following:

I’m getting hit with an 800 line PR from [new engineer] with duplicative helpers and tests, unnecessary new abstractions, unjustified lint ignore comments, and obvious issues like not being properly feature flagged. The AI-generated PR description just mechanically lists out the changes without explaining the underlying motivation, thought process, how it’s been tested, etc.

It’s exhausting and demotivating to have to point out each of these problems when it’s clear [new engineer] hasn’t invested effort in learning about the codebase and reading through their own AI-generated code.

But I feel uncomfortable giving this feedback because I don’t want them to feel like I’m hazing or intentionally blocking them, and because as a company we’re explicitly promoting AI coding tool adoption.

As a new engineer, you’re still building proficiency and calibrating your own judgement. It’s very likely that you aren’t going to do a good job reviewing AI-generated code, and are instead passing on that burden to your teammates. However, a large, complex AI-generated PR will incur a high cost on the reviewer. So rather than demonstrating productivity, your PR could actually have the opposite effect of highlighting your lack of context and understanding, creating resentment and potential tension with your teammates.

Consider this diagram from the book The First 90 Days:

Even though it might be tempting to fire off Claude Code to solve a major challenge on your first day, it’s important to understand that it could just as well lead you into the vicious cycle on the left.

The better approach as a new engineer is to start small and aim for a virtuous cycle of early wins, as shown on the right. Start with small, carefully thought through PRs that are easy to reason through and verify. Avoid abruptly introducing major new abstractions or breaking with conventions. Use AI tools to research and plan the changes, but make sure you’ve made the effort to fully understand the surrounding context around each line of change. Demonstrate humility and willingness to learn by proactively reaching out and soliciting feedback from your teammates before and after sending out a PR.

The Plan

Putting all of the above together, here’s my recommendation for how to best use AI tools during your onboarding journey. Note it’s just an example — your actual timeline will be quite different, depending on your prior experience as well as the task at hand. The key is to think of your onboarding process as a crawl-walk-run progression as you build your own proficiency.

Month 1 - Crawl

Use AI to build proficiency, don’t outsource understanding and thinking. Prefer to write code yourself (especially for larger, more complex changes), which forces you to think about the logic, the impact, coding style etc. and helps you learn through repetition. Make sure you feel comfortable with every line of change before sending out for review, both for your own learning and to help build trust with your teammates. Use each PR as an opportunity to read and reason through the surrounding code, as well as relevant technical documents. Take the time to think about every line in your PR and its potential impact.

DO use AI tools to explore the codebase, plan changes, making small changes, or creating a first draft.

DON’T use agentic tools to autonomously make large, complex changes you wouldn’t feel comfortable reviewing yourself.

Month 2 - Walk

Use AI to automate your workflow, but don’t sacrifice learning for velocity. Start incorporating agentic coding tools into your core workflow, but continue to use each PR as an opportunity to improve your own understanding, and continue to take the time to think about every line in your PR and its potential impact.

DO use agentic tools to automate increasingly larger, more complex changes.

DON’T stress about fully automating or parallelizing your workflows yet. Make sure you can confidently do things right before trying to do them fast.

Month 3-4 - Run

Use AI to fully automate tasks, and experiment! Start thinking about further improving velocity. Use the proficiency you gained from the previous stages to review AI-generated code as if it came from a newly onboarded teammate.

DO explore the frontier of AI coding tools, help improve both your own workflow as well as the team’s!