Executive Summary

“Agent Shepherd” is a useful metaphor for one possible change in software work, but it is not a universal destination or a replacement for engineering. A more precise description is Agent orchestrator: a developer who keeps ownership of goals, constraints, architecture, evidence, and consequences while delegating bounded execution.

Three evidence boundaries matter:

  • Anthropic's 2026 analysis of roughly 400,000 Claude Code sessions found that users made about 70% of planning decisions, while Claude made about 80% of execution decisions in a typical session. This describes observed use of one product, not every team or future role.
  • METR's February 2026 update says its newer productivity experiment provides an unreliable estimate because tool adoption created participant, task-selection, and time-measurement problems. The earlier 2025 slowdown result should not be projected unchanged into 2026, but the newer data also does not justify a universal speedup claim.
  • DORA's 2025 report characterizes AI as an amplifier of existing organizational strengths and weaknesses. Tool adoption cannot compensate for weak feedback loops, unclear ownership, or poor delivery systems.

The defensible conclusion is not “developers stop coding.” It is that the allocation of work can change: humans often retain more planning and judgment, while Agents can perform more implementation and tool execution. The right split depends on risk and evidence.

What the Evidence Does and Does Not Prove

Evidence from interactive Agent sessions

Anthropic analyzed sessions from October 2025 through April 2026 using privacy-preserving classifiers and telemetry. Its reported planning/execution split is useful because it distinguishes what to do from how to do it.

It also found that task-specific expertise correlated with longer Agent action chains and somewhat higher success. The important qualification is task specificity: a senior engineer can be a novice in an unfamiliar domain, while a non-programmer can be the expert on an accounting or legal workflow.

This supports a practical claim: good delegation depends on knowing the problem and recognizing incorrect output. It does not prove that formal software expertise is unnecessary, that every session was production-grade, or that the same distribution applies to another tool.

Productivity remains hard to measure

Productivity is not one number. A task may finish faster while increasing review time, defects, operational load, or future maintenance. Parallel Agents also make “hours spent” difficult to attribute.

METR's 2026 update is especially useful because it documents why its current estimate is weak:

  • developers who expected high value from AI were less willing to accept AI-disallowed tasks;
  • participants omitted tasks they strongly preferred to do with AI;
  • concurrent Agent use made time reporting unreliable;
  • task type and output quality could differ between conditions.

The correct response is not to select whichever headline favors a position. Measure your own task mix and include quality, review, recovery, and delivery outcomes.

Organization design still matters

DORA's “amplifier” framing explains why the same tool can produce opposite outcomes. A team with fast tests, clear interfaces, small changes, and reliable deployment gives an Agent rapid feedback. A team with ambiguous ownership and slow CI scales ambiguity and waiting.

Agent adoption is therefore partly a software delivery and knowledge-management problem, not merely an IDE decision.

Responsibilities: Delegate Execution, Not Accountability

Use a responsibility matrix instead of assuming the Agent owns an entire ticket:

Responsibility Human or organization owns Agent may assist
Problem selection User value, priority, non-goals Gather evidence, summarize options
Architecture Boundaries, tradeoffs, long-term fit Explore code, draft alternatives
Security and privacy Risk acceptance, policy, authorization Identify patterns, run approved checks
Implementation Acceptance of the final change Draft code, tests, migrations, docs
Verification Decide what evidence is sufficient Run tools, produce artifacts, critique
Release Approval, blast radius, rollback Prepare change, monitor approved signals
Incident response Command, communication, accountability Correlate evidence, suggest hypotheses

A model can recommend a decision. It cannot assume legal, operational, or product accountability because it generated a plausible answer.

A Production-Oriented Workflow

1. Define the task contract

State the user outcome, current behavior, allowed files or services, non-goals, constraints, acceptance tests, and rollback boundary. Separate facts from hypotheses.

2. Establish a baseline

Reproduce the issue or record current behavior before changing it. Run the smallest relevant tests and capture the target revision. Without a baseline, neither a human nor an Agent can prove improvement.

3. Choose a delegation level

Level Agent authority Suitable starting work
Assist Explain or draft only Exploration, test matrix, documentation
Edit Change a bounded workspace Local refactor, tests, low-risk fixes
Execute Run approved tools Build, lint, fixture-based validation
Propose effect Prepare PR or deployment plan Reviewable integration work
Perform effect Execute approved side effect Only with identity, confirmation, idempotency, and recovery

Grant the minimum level required by the task, not the maximum the tool supports.

4. Review evidence, not fluency

Inspect the diff, test relevance, failure paths, authorization, data migration, observability, accessibility, localization, and dependency changes. Ask what would disprove the implementation.

Tests generated by the same Agent may encode the same mistaken assumption. Include at least one independent fixture, deterministic gate, or reviewer when the risk warrants it.

5. Merge only what the team can operate

The team must understand the change well enough to debug, roll back, and modify it without replaying the original conversation. Update durable architecture and operational records when the change alters a contract.

The Skill Portfolio That Matters

Task-specific expertise

Domain rules determine whether software is correct. A developer who understands settlement, identity, medical workflows, or search ranking can give precise constraints and detect subtle failures. Agent fluency does not substitute for this knowledge.

Specification and context engineering

A good specification is executable enough to test but does not prescribe unnecessary implementation. Context engineering selects current, authoritative information and keeps instructions, knowledge, memory, and task evidence distinguishable.

System design

Agents can propose architectures, but developers must reason about ownership, compatibility, failure isolation, data lifecycle, cost, and organizational constraints. These tradeoffs are rarely visible in one repository snapshot.

Verification and evaluation

Review is not reading code quickly. It is designing evidence: reproduction, invariants, negative tests, property tests, security checks, canaries, rollback, and user-outcome measures. Learn to distinguish “the command passed” from “the claim is proven.”

Debugging and operations

Generated code still fails under concurrency, partial outages, stale data, and real traffic. Keep the ability to trace a request, inspect state, form competing hypotheses, and test them without depending on the Agent that created the defect.

Security and governance

Understand identity, authorization, secrets, supply chain, tenant isolation, logging, retention, and approvals. Tool access must follow least privilege, and retrieved instructions must not change authority.

Measure the Whole Delivery System

Track outcomes by task class rather than publishing one company-wide “AI productivity” number:

Dimension Example measures
Flow Lead time, review wait, rework cycles
Quality Escaped defects, rollback, flaky tests
Review Human time, change size, unresolved findings
Operations Change failure, recovery time, alerts
Security Vulnerability findings, policy denials, secret exposure
Economics Tool cost plus review and recovery cost per accepted change
Learning Time to explain, modify, and debug the result

Compare similar work over time and record model, tool, repository, and workflow revisions. Lines of code, prompts, Agent actions, or PR counts are activity measures, not proof of customer value.

A Capability-Gated Learning Path

Avoid promises that every developer will “transform” in a fixed number of months. Progress by demonstrated capability:

Gate 1: Assisted work

  • reproduce a task with and without the tool;
  • identify where the Agent helps or adds review cost;
  • protect secrets and restrict tool permissions;
  • reject output you cannot explain.

Gate 2: Bounded edits

  • write a task contract with acceptance criteria;
  • delegate a small reversible change;
  • verify with independent tests and diff review;
  • recover from a deliberately introduced failure.

Gate 3: End-to-end proposals

  • let the Agent explore, edit, and run checks in isolation;
  • require evidence and an uncertainty report;
  • review architecture, security, and operational impact;
  • keep merge and release approval human-owned.

Gate 4: Parallel or background execution

  • partition work to avoid shared-state conflicts;
  • persist progress outside the conversation;
  • enforce budgets, leases, and stop conditions;
  • measure integration and review load, not only Agent throughput.

Gate 5: Controlled effects

  • bind approval to exact parameters and revision;
  • use idempotency and authoritative read-back;
  • test cancellation, timeout-after-write, and rollback;
  • expand authority only after representative evaluations pass.

The calendar is secondary. A developer may stay at different gates for different repositories and risk classes.

Common Failure Modes

Replacement narratives

Claims that one role is “ending” ignore task diversity, organizational constraints, and weak measurement. Use scenarios and evidence, not inevitability.

Review bottlenecks

Generating more changes than a team can understand or verify increases queue length and risk. Limit concurrent Agents by review capacity.

Comprehension debt

Software the team cannot explain becomes expensive during incidents and migrations. Require durable design context and sample deep reviews.

Automation bias

Plausible explanations and passing generated tests can make weak evidence feel strong. Add negative cases and independent checks.

Skill atrophy

Do not set a universal “manual coding percentage.” Preserve hands-on practice where it supports the role: debugging, unfamiliar systems, performance work, security-critical changes, and foundational learning.

FAQ

Is “Agent Shepherd” a real profession?

It is an informal label for a work pattern, not a standardized occupation. Existing roles may incorporate more Agent delegation without adopting a new title.

Is writing code becoming unimportant?

Implementation may consume less human time in some workflows, but code literacy remains necessary to evaluate, debug, secure, and evolve what Agents produce.

Should every task be delegated?

No. Keep deterministic, trivial work deterministic; keep high-consequence judgment human-owned; use Agents where flexible execution provides measured value.

What is the strongest career advantage?

Deep understanding of valuable problems, combined with the ability to turn that understanding into constraints and evidence. Tool familiarity helps, but it changes faster than domain and engineering judgment.

Sources

Further Reading

Conclusion

Agentic coding can shift substantial execution to software, but it does not remove the need to choose the right problem, set constraints, verify reality, and own consequences. The durable developer advantage is not the number of Agents launched. It is the quality of the decisions, evidence, and operating system around them.