Leading people through the change

Leading people through the change to agentic engineering means three moves in a fixed order: publish a clear AI stance, answer the replacement question honestly, and widen agent use only as fast as verification can absorb it. DORA lists a clear and communicated AI stance first among the seven capabilities in its AI Capabilities Model, and it is the only one leadership alone can deliver.

This page is for the executive who sponsors the change, the CTO who owns it and the tech lead who has to say it out loud on Monday. The situation it solves: licenses went out, a vendor executive said on a podcast that the software engineer title will disappear, and your best senior engineer asked in the all-hands whether the team is being replaced. Half the engineers now use agents quietly and tell nobody, the other half refuse, and nobody knows what “good” looks like anymore.

What you can adopt from this change-leadership guide

A one-page AI stance template you can publish this week, with the eight clauses engineers ask about
A decision table for what you can honestly promise about jobs, and the words for each case
A message table for engineering, product, finance, HR and customers
A six-step sequence that keeps change-fail rate and review time at baseline while adoption grows
Settings that make the stance visible inside Claude Code, Codex and Cursor
Four metric definitions and a pulse survey that tell you whether the change is landing
One copy-paste prompt that drafts your stance from the policies you already have

Why the people side decides whether quality holds

Agents change what a change costs to produce, not what it costs to verify. The 2025 DORA report (Google Cloud, 23 September 2025) found “a positive relationship between AI adoption on both software delivery throughput and product performance” and, in the same release: “However, AI adoption does continue to have a negative relationship with software delivery stability.” Its central theme explains why: “AI doesn’t fix a team; it amplifies what’s already there.”

People are the part of the system that decides which way the amplifier points. Three behaviours break quality during an adoption, and each is a leadership failure before it is a tooling one:

Hidden use. Without a stance, engineers who use agents do not say so, so reviewers cannot adjust how carefully they read.
Unverified trust. Sonar’s survey of over 1,100 developers (8 January 2026) found “96% of developers do not fully trust AI-generated code, and only 48% always verify it before committing.” Distrust without a verification habit is the worst combination.
Fear-driven output. Engineers who believe they are being measured against the agent optimise for visible volume. Volume is what review cannot absorb.

The job itself moves too. Anthropic’s internal study of 132 engineers and researchers (2 December 2025, self-reported) found engineers describing themselves as “manager[s] of AI agents”, with some saying their work shifted “70%+ to being a code reviewer/reviser rather than a net-new code writer.” Engineers feel this shift before leadership names it. Naming it first is most of the stance’s job. The human’s job describes the work that remains in detail.

Why the AI stance comes first

DORA’s AI Capabilities Model (Google Cloud, 23 September 2025), built from 78 in-depth interviews and a survey that “reached almost 5,000 respondents”, lists seven capabilities that amplify the benefits of AI. The first is a clear and communicated AI stance. DORA’s own rationale (Nathen Harvey and Allison Park, 10 December 2025): “Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively.”

The other six (healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, user-centric focus and quality internal platforms) are engineering work. The stance is the one capability only leadership can deliver, and it costs a page. The DORA AI capabilities self-assessment scores all seven.

A stance is not the usage policy. The usage policy is the enforceable rulebook for tools, data and licensing. The stance is the short public answer to “what does leadership want, and what happens to me?”, written so an engineer can read it in three minutes. Link the policy from it; do not paste the policy into it.

OUR STANCE ON AI AGENTS IN ENGINEERING        Version 1 · Owner: CTO · Review: quarterly

1. What we want. We expect every engineer to use coding agents where they help,
   and to say when they did. Using an agent is never something to hide.
2. What agents may do. Agents may write code, tests, docs and pull requests in
   the approved tools (list in the usage policy). They run with the permissions
   the platform team configures, not personal tokens.
3. What stays human. A named person is accountable for every merged change.
   Agents are delegated work; they are never the owner of it.
4. How quality is judged. We judge a change by its evidence (acceptance
   criteria, tests the agent cannot edit, CI, review), not by who typed it.
   A change without evidence does not merge, whoever wrote it.
5. What we will not measure. We do not rank people by agent usage, prompts,
   lines generated or "% of code by AI". Those numbers never enter a
   performance review.
6. Jobs and headcount. [Pick one sentence from the decision table.]
7. Skills. Every engineer gets [N] hours per month of protected learning time,
   and early-career hiring continues.
8. How to disagree. Raise concerns with your tech lead or in #ai-stance. We
   publish what we changed because of them at each quarterly review.

Links: usage policy · governance and autonomy tiers · career ladder

Replace [N] with a real number before you publish, and fill clause 6 from the next section. Every clause is a promise someone will test, so leave out any clause you cannot keep.

What to tell engineers who fear being replaced

Engineers read the same press you do. The San Francisco Standard (19 February 2026, reporting a Y Combinator podcast second-hand) quoted Boris Cherny of Anthropic: “We’re going to start to see the title of software engineer go away.” Pretending engineers have not heard this costs you the room.

An honest answer has three parts: what you know, what you do not know, and what decides the outcome. Use the case you are actually in.

Your real situation	What you can say	What you must not say
The board has committed in writing to no AI-driven reductions for a period	“No role will be cut because of agents before [date]. After that, headcount follows the process in the stance, reviewed quarterly.”	“Nobody will ever lose their job.” Commit only to the period that is written down.
No commitment exists, and headcount follows measured constraints	“I can’t promise headcount. I can promise how it’s decided: from eight weeks of review, quality and backlog data, through hiring and attrition first, at a quarterly review you’ll see.”	“Don’t worry about it.” Reassurance without a mechanism reads as a warning.
Reductions are already planned for business reasons	Tell affected people first, through HR, before any AI announcement. Do not frame the cut as an agent success.	Linking layoffs to an adoption you still need people to lead. It turns every remaining engineer against the tool.

How teams, roles and headcount change shape gives the measured-constraint table behind the second row: which signal means review binds, which means intent binds, and when capacity is genuinely freed.

Then answer the questions that follow the first one. These come up in every all-hands:

Question engineers ask	Honest answer to adapt
“What is my job now?”	Deciding what to build, specifying it so an agent cannot misread it, designing the checks that prove it works, and owning the result. The typing moved; the accountability did not.
“Will I be judged against the agent?”	No. Clause 5: usage and volume never enter a review. You are judged on outcomes and on the quality of the evidence behind your changes.
“What about juniors?”	We keep hiring early-career engineers, and we changed how they learn. See the junior plan.
“What if I think it makes things worse?”	Then help us measure it. Skeptics design the checks for their own area and run a pilot on their own tasks.
“Who is liable when the agent is wrong?”	The named human who merged it, which is why nothing merges without evidence. Linear put the principle plainly: “an agent cannot be held accountable” (1 August 2025).

Two neighbours carry the detail: growing junior developers when agents write the code for the pipeline question, and bringing skeptics and senior engineers along for the one-to-one conversation.

What to tell the rest of the company

Each function hears the same change as a different risk. Say the part that is theirs, with the metric they will see.

Audience	Their question	The message	Metric they will see
Product	“Will engineering ship everything faster now?”	Build time drops; deciding what to build and writing acceptance criteria becomes the bottleneck. Product owns intent more directly than before.	Lead time from accepted spec to production
Finance	“Where is the saving?”	Time saved is not cash saved. We report cost per accepted change, including review and rework.	Cost per accepted change, per quarter
HR and people	“Which roles and ladders change?”	Roles shift toward specifying and verifying; the ladder rewards evidence quality and judgment, not output volume.	Regretted attrition; learning hours used
Security and legal	“What leaves the building?”	Agents run on approved tools with managed policy and service identities; the usage policy governs data.	Policy violations; secrets exposed in sessions
Customers	“Is AI writing our software?”	Every change is verified against the same evidence standard, whoever wrote it. Disclose agent use where your contracts require it.	Change-fail rate; incident trend

Product’s side of the shift is covered in product management when build time collapses; finance’s in the economics of agent-built software.

Sequence the change so quality does not dip

The order matters more than the speed. Each step below has an exit condition, and the next step starts only when it is met.

Publish the stance (week 1). The CTO publishes the one-page stance, the executive sponsor endorses it in writing, and every tech lead reads it with their team in a meeting, not only by email. Exit: every team has discussed it, and the questions are logged.
Listen and baseline (weeks 1–3). Run the pulse survey below and record each team’s change-fail rate, median time in review and pull request size. Exit: a baseline per team, written down before anything else changes.
Put skeptics in charge of the checks (weeks 2–6). Ask the most skeptical senior in each area to define what “verified” means there, and to run a measured pilot on their own tasks with pilot design. Exit: at least one check per area that fails on a known-bad example and blocks the merge in CI.
Build verification before autonomy (weeks 4–12). Protect the tests from agent edits, require an evidence bundle on every pull request, and set pull request size budgets so review keeps up. Exit: time in review and change-fail rate at or better than baseline for four weeks.
Widen by loop, not by decree (month 3 onward). Move one delivery loop at a time up the autonomy ladder, through the trust transfer protocol. Exit per loop: its gate evidence, signed by a named person.
Change the ladders and reviews (by month 6). Update career ladders and performance criteria so they reward specification, verification and judgment, and remove any output-volume measure. Exit: the next review cycle runs on the new criteria.

Any team that shows a stop signal returns to the previous step: change-fail rate above baseline for two weeks, median time in review rising for four weeks, or an escaped defect traced to an unverified agent change. Report the rollback in the same channel as the advances, so rolling back reads as the process working. The organization-wide roadmap runs the same gates at company scale over 12 months.

Make the stance visible in each tool

A stance engineers read once is forgotten by the next sprint. Put the parts that apply to every session where the session starts, and the parts the agent must follow into its instructions. The mechanisms differ per tool; the stance does not.

Managed settings (a managed-settings.json file, MDM, or server-managed settings from the claude.ai console (Team and Enterprise)) override every user and project setting. companyAnnouncements shows your organization’s announcements at startup; with several entries, Claude Code picks one at random per session and shows the first on a person’s very first launch.

{
  "companyAnnouncements": [
    "Our AI stance: use agents and say so in the PR. Nothing merges without evidence. https://wiki.example.com/ai-stance"
  ],
  "availableModels": ["opus", "sonnet"],
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Put the agent-facing clauses (disclose agent authorship in the pull request description, never edit protected tests) in the repository’s CLAUDE.md. Settings keys checked against the Claude Code settings reference on 2026-09-26 (v2.1.283).

Codex separates defaults a user can change (config.toml) from constraints an administrator sets (requirements.toml), which users cannot override. Constraints make clause 2 of the stance (“agents run with the permissions the platform team configures”) true by mechanism:

# requirements.toml — admin-enforced
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approval_policies = ["untrusted", "on-request"]
allow_managed_hooks_only = true

allowed_sandbox_modes constrains the legacy sandbox axis. Permission profiles (beta) are the newer control, and requirements.toml can pin permission_profile instead; pick one system, because OpenAI says the profile and legacy sandbox systems “do not compose”.

Codex reads AGENTS.md before doing any work, so put the agent-facing clauses there: state agent authorship and the checks run in the pull request description, and never modify files under the protected test paths. Key names checked against the openai/codex source on 2026-09-26 (CLI 0.157.1).

Cursor’s shared controls are Rules, Hooks and Plugins; a plugin packages rules, skills, agents, commands, MCP servers and hooks into one distributable bundle (checked in Cursor’s documentation on 2026-08-28). Put the agent-facing clauses of the stance in a project rule committed to the repository. Protect the test paths outside the tool, with CODEOWNERS and required CI checks, so the protection holds whichever agent opened the pull request.

Cursor’s organization-level admin controls could not be verified from the writing environment on 2026-09-26. Confirm in your Cursor admin console which settings your plan enforces before you describe them in the stance.

Enforcing one policy across every coding agent compares the full control plane of all three tools.

Draft the stance from what you already have

Most organizations already have an acceptable-use policy, a security standard and a career ladder. The stance should agree with all three. This prompt works in Claude Code, Codex or Cursor’s agent, run in a folder that holds those documents.

Read every document in this folder: our acceptable-use policy, security standard,
career ladder and any existing AI tool guidance.

Draft a one-page "stance on AI agents in engineering" with exactly these eight
clauses: what we want, what agents may do, what stays human, how quality is judged,
what we will not measure, jobs and headcount, skills, how to disagree.

Rules:
- Every clause must be consistent with the source documents. Where a clause would
  contradict one, write the contradiction as an open question instead of a clause.
- Clause 5 must exclude usage counts, lines generated and "% of code by AI" from
  performance reviews. If the career ladder rewards output volume, flag it.
- Leave clause 6 as "[LEADERSHIP DECISION REQUIRED]". Do not invent a commitment.
- Maximum 400 words. Plain sentences, no marketing language.

Then list every open question, each with the source document and section that
caused it. Do not edit any source file.

How you know the change is landing without a quality dip

Nobody reads every diff to judge the rollout. Judge it on four measures from the forge, CI, the incident tracker and a short survey, and treat any gain in adoption that comes with a loss in quality as a failure.

Measure	Definition	Target during the change	Owner
Change-fail rate	Deployments causing a rollback, hotfix or incident ÷ deployments, per team	At or below the step-2 baseline	Tech lead
Median time in review	Pull request opened → approved, per team	Not rising for four consecutive weeks	Engineering manager
Stance clarity	Share answering “agree” or “strongly agree” to Q1 and Q2 of the pulse survey	Rising each quarter	CTO
Hidden use	Share answering “agree” or “strongly agree” to Q4	Falling toward zero	CTO

Metrics frameworks holds the canonical definitions of change-fail rate and review time; use those, not local variants.

Answer each on a 5-point scale: strongly disagree … strongly agree.

Q1. I know what I am allowed to do with coding agents at work.
Q2. I know how the quality of an agent-written change is judged here.
Q3. I believe headcount decisions here are made the way the stance describes.
Q4. I use agents in ways I have not told my team about.
Q5. I have the time I need to learn to work this way.
Q6. When an agent's change is wrong, I can tell before it merges.

Free text: What would you change in our AI stance?

Report results per team only where at least five people answered, so no answer is attributable. Q3 and Q6 are the leading indicators: low trust in the process predicts attrition, and low confidence in catching errors predicts incidents.

Who owns each part of the change

Decision	Executive sponsor	CTO	Tech lead	HR
The stance and its clause on headcount	Accountable	Responsible	Consulted	Consulted
What each team treats as “verified”	Informed	Accountable	Responsible	—
Stop signals and rollbacks per team	Informed	Accountable	Responsible	—
Career ladder and review criteria	Informed	Accountable	Consulted	Responsible
Answering replacement questions in the room	Responsible	Responsible	Responsible	Consulted

The last row is deliberate: every leader answers the question with the same words, from the same decision table.

What goes wrong when leaders announce the change?

The announcement promises speed. Symptom: engineers hear “we expect you to be faster” and output volume rises while review time climbs. Recovery: restate that quality is judged by evidence and that no output metric enters a review, then enforce pull request size budgets.

Leadership over-reassures. Symptom: “nobody will lose their job” is said without a written commitment, and trust collapses at the first unrelated reduction. Recovery: correct it publicly and replace it with the process sentence from the decision table. A corrected promise costs less than a broken one.

A usage leaderboard appears. Symptom: a dashboard ranks people or teams by agent sessions or AI-authored lines. Recovery: take it down the same day. It violates clause 5 and rewards the volume that review cannot absorb.

Adoption is mandated before verification exists. Symptom: change-fail rate rises within weeks of a top-down rollout. Recovery: send the affected teams back to step 4 and report the rollback openly.

Skeptics are managed around, not involved. Symptom: seniors comply in public and stop reviewing agent changes carefully in private. Recovery: give them ownership of the checks for their area, as in step 3.

Juniors disappear from the plan. Symptom: hiring requisitions for early-career roles are quietly closed. Recovery: restore clause 7 and follow the junior plan. Anthropic’s internal study names the risk as a “paradox of supervision”: oversight needs the skills that over-delegation erodes.

Where to go next with leading the change

How teams, roles and headcount change shape The measured-constraint table behind every headcount answer.

Bringing skeptics and senior engineers along The one-to-one conversation and a pilot on the senior's own tasks.

The organization-wide roadmap The same gates run at company scale over 12 months.

The DORA AI Capabilities Model Score the other six capabilities after the stance.

Growing junior developers Keep the talent pipeline alive when agents write the code.

Reporting AI engineering to the board Report the change with quality and people measures side by side.

Frequently asked questions

What should leaders do first when rolling out coding agents?

Publish a one-page AI stance: what agents may do, what stays human, how quality is judged and how headcount decisions are made. DORA lists a clear and communicated AI stance first among the seven capabilities in its AI Capabilities Model.

Should a CTO promise engineers that nobody will lose their job to AI?

Only if the board has committed to it in writing, with a date. Otherwise say what does decide headcount, when it is reviewed, and what support people get, and never promise more than you control.

How do you stop quality dipping while teams adopt agents?

Build verification before autonomy: protected tests, evidence on every pull request and stop signals per loop, and widen agent use only when change-fail rate and time in review hold at baseline.