Developer in a quiet booth, head in hand, staring at a screen

In my day job we lead operational work across a large public-sector portfolio — hundreds of repositories, everything from modern greenfield applications to aging monoliths. The full range of tech stacks, architecture patterns, documentation quality — some repos have thorough ADRs, others have documentation that hasn’t been touched in years.

When the agent-first conversation started going, I was genuinely excited. This is where AI should shine, right? Massive codebase, endless maintenance backlog, developers stretched thin across too many systems. Point the agents at the problem and let them work.

Turns out it doesn’t work like that.

In a portfolio like ours, systems don’t exist in isolation — they have tight coupling, shared dependencies, implicit contracts between services that were never documented. Navigating those relationships requires judgment and taste that’s genuinely hard to externalize, no matter how good your docs are.

The agents exposed how much institutional knowledge lives outside of the systems. In my previous essay, I described an agent that built a fully tested product with no way to actually start it — because “the application needs a runtime entry point” was too obvious to put in the spec. That’s the gap. Agents do what the instructions say. Everything else doesn’t exist.

That realization — that the agent transition is fundamentally a human transition, not a technology upgrade — sent me into the research. What I found was both uncomfortable and encouraging: this transition is well-studied in other fields, the failure patterns are documented, and the teams that navigate it deliberately have a real advantage over the ones that pretend it’s just a new tool.

The craft problem

Here’s a number that surprised me: 52% of developers code recreationally after work. Not because they have to. Because they want to. JetBrains found this across tens of thousands of developers.

More than half of us don’t just do this for a living — we do it for fun. Coding isn’t just our job. It’s our identity, our craft. We built careers around the satisfaction of solving problems elegantly, and that satisfaction goes deep.

Now introduce AI agents that handle the mechanical parts of that craft. The logical response is “great, I’ll focus on higher-level work.” The emotional response is messier — because the mechanical parts are where the dopamine lives.

When you write code, you get progressive certainty. Each line that works confirms the previous one. You’re building something and you can feel it taking shape. When you direct an agent, the reward is different: “the system I set up produced a correct result.” That’s real — but it’s psychologically distant. The tight loop that kept you in flow for years is replaced by something looser and more abstract.

The number that changed my thinking

Anthropic ran a study in 2026 on developers learning a new async library (Trio) with AI assistance. The developers who used AI scored 17 percentage points lower on comprehension tests than those who worked without it. The ones who passively accepted agent output — just took what it gave them — dropped below 40% comprehension. The ones who used AI to ask conceptual questions about the material stayed above 65%.

That gap between 40% and 65% is the whole story. Same tool, completely different outcomes depending on how you engage with it.

A Microsoft Research study (Lee et al., presented at CHI 2025) found the same pattern from a different angle: workers with higher confidence in AI applied less critical thinking to its output. The more you trust the tool, the less you question it. Two independent research teams, same conclusion.

We’ve seen this before

Here’s what caught me off guard: this transition already has a name. It’s been studied for decades — just not in software.

Linda Hill at Harvard followed new managers through their first year and found that a central challenge wasn’t learning new skills — it was letting go of the old identity. The thing that made you successful as an individual contributor — doing the work yourself, and doing it well — is the exact thing that holds you back as a manager.

Sound familiar? Writing a spec that produces correct code is a completely different skill than writing the code yourself. And the instinct to just do it yourself — because you know you’d do it better — is what Marshall Goldsmith calls ”adding too much value” — one of the most common habits that derails people in new leadership roles. CCL research found that roughly half of managers are rated ineffective by their organizations, and nearly 60% receive no training for the transition.

We’re running the same experiment with AI — on two levels. Every developer directing agents is going through the contributor-to-manager transition personally: learning to specify instead of implement, to review instead of build. And every organization adopting agents needs to support that transition the same way they’d support a new manager — with deliberate preparation, not just a new tool and “good luck, have at it!”. Right now, most are getting neither. But the playbook exists — we just need to apply it.

The quiet erosion

Here’s what’s worth being honest about: the transition doesn’t just change what you do. It changes what you’re capable of doing. Samuel Greengard wrote about this in Communications of the ACM, calling it the “AI deskilling paradox” — short-term efficiency gains that hollow out deeper expertise without anyone noticing.

The mechanism plays out in stages:

You stop writing. Not all at once. You just write less, because the agent handles it. Reasonable.

Your instincts start fading. The feel for how code should flow — the pattern recognition built from thousands of hours of being wrong — thins out. Not dramatically. Not overnight. But steadily.

Your reviews get weaker. Because the ability to write is what enables you to catch what’s wrong. The errors in agent output are subtle — wrong field name, off-by-one boundary, a nullability assumption. The code compiles. Tests pass.

You trust yourself less. Things slip through that wouldn’t have before. You know it, even if nobody else does yet.

You delegate more. Which accelerates every stage above.

Aviation calls this “children of the magenta line” — pilots who grew up on autopilot and can’t hand-fly when they need to. The consequences in software are less severe than in aviation, but the mechanism is the same.

Dusty piano keys untouched — craft gathering dust

A 2025 field study found that experienced professional developers already sense this — they don’t passively accept agent output. They employ deliberate strategies to control and constrain agent behaviour, maintaining their expertise as the quality gate (Huang et al., 2025). That instinct to maintain control isn’t resistance. It’s self-preservation.

This isn’t a reason to avoid agents. It’s a reason to be deliberate about the transition — and to invest in the structural safeguards that catch what eroding instincts miss.

Where this gets real

Here’s a pattern I see regularly.

A junior developer gets assigned a task. They spin up an agent, feed it the requirements, and the agent produces a solution. It compiles. Tests pass. PR submitted.

Then a senior reviews the PR and sees what the agent — and the junior — couldn’t see. The task didn’t need a patch. It needed a new logic layer, or a rewrite because the existing pattern had outgrown the library it depended on, or it touched something that should have been flagged as code debt. The agent followed its instructions perfectly. The junior didn’t have the context to know the instructions were wrong.

Now the senior is faced with choices, and none of them can be delegated. The senior has to go hands-on — except now they’re untangling a confident-looking wrong approach, which is harder than building the right one from nothing.

This is the identity shift in action. The senior’s value isn’t in the code they write. It’s in the judgment that prevents wrong code from being written in the first place. That judgment is the scarcest resource in the entire agent-era equation — and it only works if you’re close enough to the code to exercise it.

The maker-to-director transition isn’t something that happens once. It happens every PR review where you have to decide: do I fix this myself, or do I invest the time to teach the junior (and the agent) why this was wrong? One is faster. The other is sustainable.

What helps

This isn’t about resisting AI. It’s about navigating the transition deliberately — and the research gives us footholds at both the personal and structural level.

Acknowledge the disorientation. The research is clear: acknowledgment helps people process identity shifts more effectively. If you feel a sense of loss around not writing code anymore, that’s normal. It’s a rational response to losing the activity your professional identity was built around. Naming it takes away most of its power.

Redefine the craft. A well-written spec that produces correct code on first pass IS craftsmanship. The elegance moved upstream — from the implementation to the specification. Spec writing is a learnable craft with its own sub-skills, from ambiguity detection to edge case anticipation — and it’s a craft that most of us haven’t been formally trained in.

Andrej Karpathy — who coined “vibe coding” a year ago — now calls the mature version “agentic engineering”: “engineering to emphasize that there is an art & science and expertise to it.” That framing matters. This isn’t about giving up your craft. It’s about the craft evolving. When the output isn’t what you wanted, fix the spec, not the code.

Keep writing code deliberately. Not because the agent can’t — because the ability to write is what enables you to review. Periodically do the work yourself. Stay sharp on the framework APIs, the language idioms, the things that atrophy fastest.

Build structural safeguards, not just habits. This is the part that personal discipline alone won’t solve.

  • When you review agent output, don’t ask “does this work?” — ask “how could this fail?” That single reframe activates a different cognitive mode — one of the most effective debiasing techniques in the literature.

  • Use generation-then-comprehension: have the agent generate, then actively question how it works and why — this achieves 86% comprehension vs 40% for passive acceptance.

  • Keep changes small — Google’s code review research found that smaller changes consistently get better reviews.

These aren’t suggestions — they’re the structural interventions that the research says actually work.

The opportunity nobody is talking about

As an industry, we’re not prepared for this transition. There are no workshops on “how to navigate a professional identity shift.” No onboarding for “you’re a director now.” We hand developers AI tools and expect them to figure it out — exactly the way we’ve always handled the manager transition, where roughly half are rated ineffective.

The organizations that treat this as a human challenge — not just a tooling upgrade — will retain the senior engineers whose judgment makes AI actually useful. And the work itself is genuinely interesting: figuring out how to transfer decades of institutional knowledge into governance artifacts, how to structure human-agent collaboration at enterprise scale, how to maintain deep expertise while leveraging agent speed. It’s not a lesser form of engineering. It’s a harder form.

Which brings me back to the portfolio I work on every day — hundreds of repos, undocumented decisions, and developers navigating an identity shift that most of the industry hasn’t even named yet. The agents aren’t the hard part. The hard part is everything the agents revealed about how we’ve been working all along. And figuring that out is genuinely the most interesting engineering challenge I’ve worked on.

When was the last time you actually wrote code yourself? And how confident are you that you still can?

This is the second piece in a series on what evidence-based research actually says about human-agent collaboration. The first — The Perception Gap — covers the 39-point gap between perceived and actual AI productivity. Next: how AI agents systematically agree with you instead of challenging you, and why that’s more dangerous than any bug they could write. The research behind this series is collected in The Agent-Era Handbook — an open-source framework for teams navigating this shift.

Sources