the-author-s-dilemma-your-developers-won-t-be-replaced-they-ll-be-asked-to-become-someone-else

Home / Blog

8 JULY 2026

The Author’s Dilemma: Your Developers Won’t Be Replaced - They’ll Be Asked to Become Someone Else

Author: Ken Sherman

Every stage of an AI-SDLC roadmap is a technology milestone on paper and, in practice, a renegotiation of identity and trust. That human transition, not model capability, sets your real pace.

Somewhere around month four of every AI transformation I’ve managed, the mood shifts. The demos worked. The licenses were bought. The productivity charts even ticked up for a fortnight. And then the numbers sag, the channels go quiet, and a senior engineer you respect says some version of: “I didn’t get into this to babysit a bot’s pull requests.”

That moment isn’t a tooling failure. It’s the sound of a profession renegotiating what it is. We spend enormous energy debating whether AI will replace developers, and almost none on the harder, nearer question: how quickly can developers become what the new SDLC needs them to be? The ceiling on your transformation isn’t model capability. It’s human adaptation and most roadmaps don’t have a single line for it. That adaptation has two faces: the identity your developers must give up, and the trust they must learn to place in the machine. Neglect either and the roadmap stalls.

The Bottleneck Isn’t Capability. It’s Identity.

Here’s the uncomfortable truth most transformation plans dodge: today’s coding agents can already do more than your organization will let them. The gap between what the model can do and what your teams will trust it to do is where every stalled program lives.

The maturity model most of us are working from, with foundation, assisted coding, agentic workflows, autonomous delivery, self-healing operations, and closed-loop product, gets read as a technology progression. But you don’t climb it at the speed of the tools. You climb it at the speed of people renegotiating their relationship to their craft.

Identity is the real rate limiter. A developer’s sense of self is welded to authorship: I build things. I write the code. When the code starts writing itself, that isn’t a feature upgrade; it’s an existential edit. Plan this as a rollout instead of a role transition, and you will stall. Reliably.

Read the Roadmap Again as a Ladder of Roles

Take the same six stages and track the human instead of the technology. Watch what the developer actually does at each rung:

  • Foundation: skeptic → curious. The real work here is belief and psychological safety, not procurement.

  • Assisted coding: author → pair. You still hold the pen, but you’re no longer alone with the page and sometimes the assistant is simply better than you at the next line.

  • Agentic workflows: author → reviewer. The pen changes hands. Humans review; they don’t author. This is the hinge of the entire journey.

  • Autonomous delivery: operator → policy setter. You stop running the pipeline and start defining the guardrails it runs inside.

  • Self-healing operations: firefighter → fire marshal. The 3 a.m. page — a strange badge of honor in our culture goes to an agent first.

  • Closed-loop product: implementer → director. What’s left is judgment: strategy, ethics, novel architecture, the customer relationship.

The whole arc in one line: author → pair → reviewer → policy setter → supervisor → director. Every rung trades a tactile, hard-won competence for a higher-leverage but less viscerally satisfying one. Each step asks people to stop doing the very thing they got good at. That’s not irrational resistance, it’s a sane response to being asked to set build mastery.

Trust Is Earned One Rung at a Time

If identity is what your developers give up as they climb, then trust is what they must extend to the machine to take the next step. And here is what leaders consistently underestimate: you can mandate adoption, but you cannot mandate trust. You can put a license on every desk and require daily usage, and still have your best engineers quietly routing around the agent because they don’t believe it yet. Trust is the real currency of progress up the ladder — and the AI has to earn it, rung by rung.

Watch how the nature of that trust changes at each stage:

  • Assisted coding — “check everything.” The developer verifies every suggestion. The agent earns micro credibility one correct completion at a time, and that’s exactly as it should be.

  • Agentic workflows — “trust, but verify.” The agent owns a bounded task and opens a PR, but a named human still signs off. Trust is granted by policy, not by faith.

  • Autonomous delivery — trust the system, not the output. You stop inspecting every decision and start trusting the guardrails: the risk scoring, the automated holds, the rollback logic.

  • Self-healing operations — trust it to act while you sleep. The hardest trust of all: letting an agent respond at 3 a.m. before any human is in the loop. That is only ever extended after the agent has proven itself at every lower rung.

The asymmetry is the whole point: trust is earned in increments and lost in one incident. A single unexplained autonomous action that breaks production can reset an organization’s confidence to zero and knock it back two stages. That is why three mechanics are non-negotiable at every rung: transparency (you can see exactly what the agent did and why), reversibility (you can undo it in one move), and a bounded blast radius (the worst case is survivable). These aren’t compliance checkboxes. They are the trust infrastructure that lets a human let go.

One caution: the goal isn’t maximal trust. Over-trust is its own failure mode, the automation complacency that waves a plausible-looking wrong answer through a rubber-stamp review. What you’re coaching for is calibrated trust: extending exactly as much as the agent’s demonstrated reliability has earned, and no more. Teach engineers to trust an agent the way a good lead trusts a talented junior — delegate the routine, scrutinize the high stakes, and always know which is which.

The J-Curve Is Grief, Not Just a Learning Curve

Every honest roadmap warns of a dip in the productivity J-curve somewhere around months three to nine. It’s usually explained as ramp up: new tools, new prompts, new muscle memory. That’s half the story.

The other half is lost. When you ask a craftsperson to trade authoring for reviewing, you’re asking them to set down a skill that took a decade to build and that they are, quite reasonably, proud of. Nobody grieves a deprecated framework. People will grieve this.

So name it and don’t spin it. The fastest way to deepen the dip is to insist the transition is all upside. Engineers have finely tuned detectors for that; the moment leadership starts sounding like a brochure, trust dissolves, and trust is the actual fuel of adoption. The teams that climb out of the J-curve quickest are the ones whose leaders said the quiet part aloud: yes, the job is changing; yes, some of what you loved is moving to the machine; here is the more valuable thing we’re asking you to become, and here is how we’ll help you get there.

What Actually Moves People Up the Ladder

Once you accept that the transition is human, the interventions that matter look different from a tooling plan:

  • Make the new role prestigious, not a demotion. If reviewing an agent’s PR is framed as lower status than writing it, your best people will quietly opt out. Orchestration, judgment, and system-level review are craft: resource them, promote on them, and celebrate them as such.

  • Use champions as social proof, not just training. Adoption spreads peer-to-peer. One credible champion per ten or so engineers, running office hours and prompt clinics, outperforms any mandate. People adopt what respected peers vouch for.

  • Make “upskill, don’t replace” a promise you visibly keep. The phrase is on every strategy slide and is worthless until an engineer watches a colleague redeployed to higher-value work rather than being shown the door. The first real example sets the tone for the whole program.

  • Let the agent earn trust where people can see it. Champions and clinics build peer trust; transparent, reversible agent actions build machine trust. Both compounds are only visible when they’re not; nobody witnessed changes, no one’s mind.

  • Measure the human, not just DORA. Baseline developer confidence and trust in the tooling, alongside cycle time and defect rate. If velocity climbs while confidence craters, you haven’t succeeded; you’ve built a debt you’ll repay in attrition.

Six Things to Do Differently on Monday

  • Plan the transition as a role change, not a tool rollout. Put “what each person becomes” next to every stage of your roadmap.

  • Treat trust as earned capital, not a mandate. Let the agent prove itself one rung at a time; keep every action transparent and reversible, and never let a usage mandate outrun the trust the AI has actually earned.

  • Say the quiet part out loud. Name the loss inside the J-curve; teams trust leaders who don’t oversell.

  • Re-status the new work. Make review, orchestration, and judgment visibly prestigious, or your strongest engineers will disengage.

  • Keep the reskilling promise in public. One real redeployment does more than a hundred slides saying “we won’t replace you.”

  • Instrument morale, not only metrics. If satisfaction isn’t on your dashboard, you’re blind on the one variable that gates your pace.

The Most Human Work Software Has Ever Asked For

Here’s the twist the anxiety keeps missing. Follow the ladder all the way up and look at what’s left for humans at the top: strategy, ethical judgment, novel architecture, the customer relationship, and the calls that carry real consequence. Strip out the mechanical authoring, and what remains is the most human work software has ever asked of us.

That’s the opportunity and the challenge in a single breath. The organizations that win the next few years won’t be the ones with the best models; those will be table stakes. They’ll be the ones whose people renegotiated who they are the fastest and learned to trust the machine exactly as much as it had earned, and led through that renegotiation with honesty rather than hype. The technology will be ready before your people are. So the real question isn’t “when will the tools arrive?” It’s “how good are we at helping humans become someone new?”

About the Author:

Ken Sherman is an AI-focused engineering executive who has led enterprise AI transformation and scaled global engineering organizations of 150+ across regulated industries, including healthcare, finance, and SaaS. He advises leaders on taking AI from experimentation to production-grade delivery, with a focus on governance, developer experience, and the human side of adoption.

@ 2026 Harness Inc.