Identity Struggles

Before you can create the moment at scale, you need to understand who you’re creating it for. Some people will take to agentic coding fast. Others will resist, even when they’re objectively good with the tools. The pattern isn’t about skill or seniority. It’s about identity — how a developer thinks of themselves and what they value about their work.

Treat the people pushing back as obstacles and you’ll lose some of your best people. Treat them as people working through a meaningful change and most come out the other side, often becoming your strongest advocates.

Two ends of a spectrum

It’s an over-generalization based on patterns I’ve seen, but a useful one. Most developers fall between two poles:

Craft-focused developers enjoy the practice of writing code. High bar for quality. Value elegant, idiomatic solutions. Code is the work; there’s an optimal version worth aiming for.

Product-focused developers enjoy what gets built. Code is a means to an end. “Good enough” is good enough. Iteration speed and reduced non-value time are what matter.

Both can be excellent at agentic coding. They struggle with it for different reasons.

What craft-focused developers feel

The craft-focused developer’s work is partly about it being theirs. They wrote it. They chose the patterns. The code reflects their judgment, and that judgment is part of how they know they’re good.

Agentic coding scrambles this. The agent makes the small decisions. The code is workable rather than optimal. The work gets done, often faster, but it doesn’t feel like theirs.

This isn’t irrational. It’s a real loss, and ignoring that makes it worse.

What helps is acknowledging the loss and showing where their craft matters more, not less. The high bar didn’t become useless when agents started writing code. It moved. The agent will produce something workable; the craft-focused developer notices when “workable” isn’t actually right, pushes back on subtle architectural mistakes, and maintains the standard for what good looks like across many people doing the writing. That’s a more leveraged role than they had before.

Culture → Craft is something craft-focused developers have always expanded. New languages, new paradigms, better tools — each one initially looked like a shortcut and ended up part of the work. Agentic coding is no different. Help them see it as the next chapter of their craft, not the end of it.

What product-focused developers feel

Product-focused developers usually take to agentic tools fast. The speed gains are immediately appealing. The tools amplify what they were already trying to do.

The risk isn’t resistance. It’s the opposite. They race ahead in ways that compound problems for everyone else. Quality drops when nobody’s watching. Architecture drifts. Code review gets cursory because reviewers can’t keep up with the volume. They experience this as productivity. The codebase experiences it as accumulating technical debt.

What helps is making sure the quality bar travels with the speed. Pair them with craft-focused developers. Make code review a real activity. Watch what’s happening in the codebase, not just what’s shipping.

Watch out → A team where everyone is product-focused will ship faster for a while and pay for it later. If you’ve shifted toward all-product-focused thinking because it’s been working, that’s the signal to slow down and check the foundation.

People who care deeply

Cutting across the craft/product spectrum is a third pattern: people who care deeply — about their work, their team, doing things right. High purpose, high empathy, high conscientiousness. Often among your best contributors.

They can also take longest to embrace the change.

Because they care, they ask hard questions. They worry about consequences others don’t. They notice losses others miss. They don’t switch positions casually. This can look like resistance. It usually isn’t; it’s processing.

What helps is time, honesty, and some control. Give them time to work through it. Be honest about what’s uncertain. They’ll spot dishonesty and trust will be hard to recover. Give them some control over how the change happens for them or their team. The thing they care about most might be the place to let them lead.

When this is done well, the people who took longest often become the most invested advocates. When they finally commit, they commit fully. They become the people who carry the change forward when you’re not in the room.

Stalled → If your transformation has lost the people who care deeply, you have a serious problem upstream of the tools. Something about how the change was led signaled that what they care about doesn’t matter. Address it directly.

Signals to watch for

A few patterns that say someone is struggling with the identity dimension, regardless of which group they’re in:

• Polite under-engagement. Doing what’s asked, not pushing back, not really showing up. The most common signal and the easiest to miss.
• Quality loss without acknowledgment. Code quality dropping but nobody saying so. Often craft-focused people checking out rather than fighting.
• Volume without meaning. Lots of pull requests, lots of agent activity, no real change in what’s getting shipped.
• Quiet conversations you’re not part of. When the most invested people are talking to each other instead of to you, the leadership relationship is breaking down.

None of these are problems you fix with a process. They’re problems you fix with attention and individual conversation.