Adopting AI: An Engineer's Guide

My previous entry is a dossier: thoroughly researched, carefully cited, and written for the people and organizations trying to understand how AI adoption is going and what lessons are already on the record. This one is for the engineer who has to live through it.

So these are positions, not a survey: what I believe you should actually do. Each one ends with its footing: how firmly I hold it, and why. The evidence stays in the dossier; this entry only borrows its conclusions. Nothing here asks for a particular tool or any enthusiasm about AI; it just asks you to be deliberate.

Two things the evidence says to expect from the organization around you. First, AI amplifies what an organization already is: strong review and feedback loops get multiplied, and vague requirements turn into confidently wrong code faster. If adoption feels messy where you are, the mess was probably already there; it's just moving quicker now. Second, the rollouts that worked were sequences, not switches: they started small, led with guardrails, measured as they went, and expanded deliberately. Yours may look nothing like that; plenty of organizations hand everyone the tool at once. If that's where you are, the pattern still tells you something useful: what's missing, and the most important missing pieces (working agreements, review norms, machine-checkable verification) are things a single team can build without waiting for the organization.

The practical move is the same either way: get involved early. The norms for how AI is used where you work are being written right now, deliberately or by default, and they'll be written whether or not you're in the room.

With AI in the mix, the skills you've spent years building matter more, not less. You are still designing, testing, debugging, and solving problems; you're just applying that craft through the tool as well as directly in the code. The precedent is test automation: it took the repetitive part of the tester's job and made the judgment part the job. Software engineering is at the front edge of the same passage.

Even successful agentic sessions get steered ("I intervened, corrected and steered all the time," one honest practitioner writeup admits), and Anthropic's own teams report first-attempt success on small-to-medium pull requests about one-third of the time. So expect to be in the loop: that's the job working, not failing. And steering isn't hovering; good patterns put the human at the few points that need one (the plan, the first wrong turn, the final judgment) and let the rest run. Directing well is just your old skills pointed at a new target: decompose the problem, make intent precise, build the checks. If you can't state what done looks like, you've found the actual blocker, and it wasn't the AI.

The measured gains are task-shaped, and the spread is enormous: on the order of 40% on simple, well-specified work, near zero on complex work deep in an existing codebase. Every headline win in the record is a migration, a conversion, a repetitive change with a machine-checkable finish line. So before reaching for the tool, ask two things:

• Is the task bounded and well-specified? Migrations, test scaffolding, boilerplate, format conversions, documentation drafts: hand them over freely. Design decisions inside a system only you understand: keep your hands on the wheel and use AI as a sounding board.
• Can a machine tell you whether it worked? If there's a test suite, a typecheck, a build that fails loudly, delegation is cheap to verify. If the only check is your own careful reading, you haven't saved verification time; you've moved all of it to yourself.

This predicts something worth noticing: two engineers of identical skill will get wildly different value from the same tool depending on what they point it at. When someone says they tried it and it was useless, my first question is no longer about the tool. It's about the task.

Most opinions about AI's value, including yours and mine, start as feelings: the session went smoothly, so it must be helping; it fumbled, so it must not be. The evidence says that's exactly the signal not to trust. In a Stanford study, only one engineer in three estimated their own productivity within a quartile. In METR's randomized trial, developers believed AI had sped them up by 20% while measurement showed the work taking longer (METR has since revised the result upward; the gap between belief and measurement is the part that survives). And it cuts both ways: the colleague who's sure AI makes them faster and the one who's sure it doesn't are making the same kind of estimate.

So the position is simple: AI's value is something you measure, not something you feel. You'll recognize the moment this one becomes yours: you hear yourself telling someone the tool is saving you hours and realize you're quoting a feeling, not a number. I've said something very similar myself, numerous times, and that's the day to start keeping cheap receipts: how often delegated output survived to merge without rework, where the time actually went. Nothing heavyweight; just enough that your opinion of the tool is anchored to data instead of to how the session felt. (For what it's worth, I take this one further than the position requires: I've built tooling around my own AI interactions that keeps these receipts for me. You don't need to go that far.)

So is the over-reliance worry real? Honestly, yeah, a pattern is forming. In the one randomized trial we have on engineers, the people who learned a new library with AI in hand scored nearly two letter grades worse on mastery afterward (50% versus 67%), and the biggest gap was in debugging. Student studies keep landing in the same place: scores go up, learning stays flat. There's survey work showing the more people trust the tool, the less they think critically. And the old automation research explains why: the thinking skills you stop using are the ones that fade. Nobody's measured long-term atrophy in working engineers yet, in either direction. But everything nearby points the same way: lean on it wrong, and something real slips.

It's sharpest for juniors, because the skills that don't form are the ones that make you a senior later: debugging, root-cause instinct, knowing why the code works. In that same trial, the people who delegated everything finished fastest, "at the cost of learning the library." And the trap wasn't just delegation: the group that wrote their own code but handed the debugging to AI landed near the bottom too. When someone worries out loud that AI could stunt junior growth, this is the substance behind it.

Here's the hopeful part, and I think it's the right read: the deciding factor was how people engaged, not whether they used AI. The highest scorers used it heavily, for concepts, and wrote the code themselves. Deskilling isn't a law of nature (calculators taught alongside real instruction actually improved arithmetic). It comes down to how deliberately you design your working habits around the tool, and that's in your hands.

I believe that everything above compresses into a small set of practices, and that position is supported by the measured engagement patterns in the research, the playbooks practitioners keep publishing, and my own use, though the footing at the end is honest about how uneven that last part is. The practices differ by what mode you're in, not by your title; a principal engineer learning a new domain is, for that domain, junior again. And none of it will take until you're using the thing in earnest, on real work: every opinion about these tools, mine included, is vibes until your own use starts confirming or breaking it. The habits below attach to what that use serves up, in whatever order it serves them.

When you're learning the thing

This is the mode the over-reliance position was about, so these habits are the protection.

• Use AI as a tutor, not a typist. Ask it concepts, tradeoffs, why this instead of that; then write the code yourself.
• Attempt first, always, with a real timebox. The attempt is where the learning lives, even when it fails. Especially when it fails.
• Never outsource the debugging of the thing you're trying to learn. It feels responsible ("I wrote the code myself!"), and it's still the trap: debugging is where mastery forms.
• Keep some reps with no assistance at all. Read the full error, open the actual documentation, feel where you're weak. The code from those sessions will be worse, and you'll know why every line of it is there.
• Turn on your tool's learning mode, if it has one. Making yourself write the load-bearing lines is exactly the engagement pattern the trial rewarded.

When you're producing

This is most of the day: the routing and steering positions turned into habit, and the mode your first weeks of playing will teach fastest.

• Route by shape. When it nails something you expected to take an hour and then confidently botches something trivial, that's not moodiness; those are different kinds of task, and it's reliably strong at one and weak at the other. Delegate the bounded and checkable (migrations, test scaffolding, boilerplate, conversions); keep your hands on the wheel wherever the real context lives in your head.
• Argue about the approach before the code exists. If you keep interrupting mid-flight ("no, not like that"), that argument was always coming; it's cheaper up front. Flip the conversation: have it interview you until it can write the plan, then let it build against the plan (a lot of how I work here is derived from Matt Pocock's seven phases and his skills repo: good starting points to adapt). If you can describe the diff in one sentence, skip the ceremony.
• Give every delegation a check the machine can run. Without one you haven't delegated; you've handed off the typing and kept the verification. Name the command that proves it worked, make the agent run it as it goes and show evidence rather than assert success (Anthropic's best-practices doc is where that rule comes from), and commit checkpoints so a wrong turn costs a revert instead of an argument.
• Review what's left like a confident stranger wrote it, because one did. Machine checks first; your reading is for what no check was ever going to see, and I've had exactly that kind of bug reach the main branch. Read for the tells: duplicated code where reuse existed, brute-force fixes that dodge the root cause, tests that assert nothing, any weakening of CI (a hard stop). When you do catch something, write down the instruction or check that would have caught it for you (GitHub's ten-minute review protocol is the checklist version of this hunt).
• When the same wrong turn shows up twice, stop patching. The second time the same mistake comes back, the thing that breaks isn't the session; it's your trust in it, and from there "done" is just a claim it has to prove. Reset with a better prompt that carries what you learned, or take the work back yourself; starting over beats wrestling more often than it feels like it should (Fowler's piece on steering is where the stopping rule comes from). Knowing when not to believe it is the skill that compounds.

When you're responsible for other engineers

This mode starts earlier than the org chart suggests: the first time you try to bring another engineer along. Doing that with friends has taught me it splits people. One of mine is getting it: seeing the value, learning, visibly improving. Another decided early that he wants nothing to do with it, and no argument I've made has moved him. I've stopped trying; the experiences above have to happen to you. So start smaller than evangelism: help someone pick one bounded task, and get out of the way. And if other engineers' growth actually is your job, the junior concern above is yours to design for.

• Don't strip-mine the training ground. The bounded tasks agents do best are the same ones juniors have always learned on; keep some for the humans still forming, and call it a training budget rather than an inefficiency.
• Keep pairing and review human where formation is the point. A review culture that asks why does this work is now load-bearing for skill formation, not just quality.
• Write the working agreements down, and pull the whole team into writing them. The norms are getting set right now, deliberately or by default.
• Make the countermeasures normal, not remedial. Explain-it-back moments, critique-the-AI passes, the occasional from-scratch build: when everyone does them, they read as staying sharp and they stick; reserve them for juniors and they read as punishment and die.