The role of a software engineer has always shifted with the tools available. Compilers replaced assembly; version control changed how teams collaborate; cloud platforms changed where software runs. Coding agents — programs that can write, test, and iterate on code autonomously — are the next shift, and unlike some previous ones, this one changes the core loop: an agent can now implement a substantial feature across a large codebase in the time it used to take to write a ticket.
The question practitioners are working through is not whether to use agents, but how to structure the work around them so the output stays reliable, auditable, and genuinely owned. One framework gaining traction in engineering teams is the Agentic Development Life Cycle (ADLC), organized around three areas: the Harness, the Handoffs, and the Humans.
The Harness: scaffolding that makes agents reliable
The harness is everything a team sets up so an agent can operate predictably inside a real codebase. Think of it as infrastructure built once that pays off on every subsequent task.
Several practices have largely converged across teams doing this seriously:
Shared configuration, versioned like code. Agent instructions, custom skills, and external tool connections (MCP servers — small adapters that give agents access to databases, APIs, and other services) live in the repository and are reviewed like any other change. Every agent and every contributor works from the same playbook.
The repo as living memory. Rather than handing context to an agent in a single prompt, a set of markdown documents — covering project purpose, architecture, coding standards, and current state — gives the agent a continuously updated picture of where things stand. Documents reference each other so the agent can navigate progressively from high-level to detail.
Hardwired standards. Every commit triggers automated checks: type verification, linting, test coverage thresholds, security scanning. The agent cannot skip them; neither can any human contributor. The agent is also instructed to run these checks in its own loop and iterate until they pass before declaring a task done.
Self-improvement built in. After completing a task, the agent reviews its own process and updates the process documentation. Done well, the harness sharpens over time without anyone managing it explicitly — and the harness can instruct the agent to improve how it improves itself, a compounding effect worth designing for.
Harness practices are the most settled piece of this picture. Teams who have been at this for a year or more converge on roughly the same elements. The other two areas are less resolved.
The Handoff: writing requirements that agents can actually execute
How humans communicate what they want to an agent has evolved. The practice with the most traction: write a spec first.
A useful spec captures the goal, the constraints, what is explicitly out of scope, and measurable success criteria — the things a reviewer would check to confirm the task is actually finished. The agent then produces a plan, breaking the work into phases with their own criteria. From there the agent executes, with the harness enforcing standards throughout. On completion, a pull request carries evidence that success criteria were met, and automated checks gate the merge.
What this replaces is the informal prompt: a description of what is wanted, vague on constraints and vaguer on what “done” looks like. Agents can execute against that kind of brief, but the results are harder to verify and the failure modes are harder to reason about. The spec is overhead, but it is front-loaded overhead — and it makes the review step, which is where most of the real work now happens, much more tractable.
The Human: slow review, non-negotiable accountability
The trickiest question in this framework is what the human’s role actually is once agents are writing most of the code.
There is a meaningful asymmetry: generating code with agents is fast; reviewing it carefully is slow. Engineers find themselves functioning more as professional code reviewers than as writers — and the accountability that comes with that role has not changed. Someone must own every pull request. A regression introduced by an agent is still a human-owned regression.
Where the dial sits between full human oversight and near-full agent autonomy depends on the project and its stakes. A personal prototype sits at one end — spot-check results, confirm the success criteria. Payment infrastructure or medical data sits at the other — a human reads every line. Most production work falls somewhere in between, and the right level is worth agreeing on explicitly as a team before the first task begins, rather than letting it drift into place by accident.
What the practice looks like from here
The ADLC is still stabilizing. Harness practices are converging; what it means to be the human in this loop is the open question the field will be working through for a while. The most useful thing teams can do now is treat these three areas — scaffolding, spec writing, and oversight level — as deliberate team decisions rather than defaults. That deliberateness is probably what software engineering in the agent era means in practice: less about writing code, more about designing the conditions under which good code reliably gets written and owned.
Text summarized and optimized using Anthropic’s models and reviewed by a human.