In an agentic software development lifecycle, the model works inside a harness: the surrounding tools, permissions, context and evaluation loop. Product teams should define the intended outcome and the evidence required at each consequential handoff. Faster generation only helps when the resulting change can be understood, verified and safely released.
Why harness engineering matters now
ASDLC is used here to mean agentic software development lifecycle; terminology varies, and this is not a formal industry standard. The useful shift is that agents can participate across discovery, implementation, testing and operations. The surrounding workflow becomes a product decision, because it determines what the agent can attempt and how a person knows whether the task is complete.
GitHub’s October 6, 2026 engineering post, updated October 7, describes concurrent agent workloads creating new demands on repository infrastructure. Its architectural work aims to preserve familiar branching, review and governance as activity scales. This is evidence of changing infrastructure needs, not proof that more commits produce more customer value.
Anthropic’s March 24, 2026 engineering article examines harness design for longer application-development tasks. Its examples make the surrounding development system a concrete design variable. Treat these vendor examples as material to investigate with your team, rather than as a guarantee that the same architecture will suit your environment.
Give the agent a contract it can be checked against
Consider a hypothetical agent asked to reduce failed account activations. “Improve onboarding” leaves important choices unresolved. A more useful task names the observed user problem, a bounded scope, unacceptable side effects and an outcome that can be independently checked.
For this example, the contract might require preserving existing authentication behavior, making an incomplete step recoverable and demonstrating the revised flow in a test environment. A generated implementation is an artifact. Evidence that the user can finish the intended task is the acceptance condition.
The PM does not need to prescribe every technical step. Work with engineering to separate the intent that must remain stable from the implementation choices the agent can explore. Keep a record of assumptions that still require a person’s judgment.
Put human intervention where it changes the decision
Map the workflow into preparation, proposed change, verification and release. An agent might explore a repository and prepare a patch with limited supervision, while production access or an irreversible data change requires a different permission boundary.
For each boundary, name who can authorize progress and what they need to see. A useful review packet contains the problem, the change, validation evidence, known uncertainty and recovery options. A stream of intermediate messages rarely gives a reviewer the same clarity.
Define what happens when evidence is missing, tests disagree or the assigned reviewer is unavailable. Do not let “the agent finished” silently become permission to release. Equally, avoid requiring a human to approve every low-risk action without a reason. The goal is deliberate authority, with an escalation path that actually works.
Measure the whole delivery path
Choose a small set of measures that connect the agent’s work to the delivery system: time from accepted intent to verified change, reviewer effort, rework, escaped defects and the customer behavior the change was meant to improve.
Inspect those measures together. More generated patches can coexist with a growing review queue. Faster implementation can hide weaker acceptance criteria. A sensible experiment changes one bounded workflow, compares it with a documented baseline and stops if quality or operational control deteriorates. These are proposed measurement choices, not universal targets.
Mentoring exercise: design one handoff in 20 minutes
Choose a recurring task your team might delegate to an agent. In five minutes, write the user outcome, the scope and one consequence that makes the task risky. Avoid starting with a tool name.
Spend the next five minutes drawing the path from request to release. At each handoff, write the evidence the receiving person or system needs. Mark the one step where human judgment is essential and explain why.
Use five minutes to rehearse a missing test, an unexpected permission request and an unavailable reviewer. Decide how the workflow pauses, narrows scope or hands back control.
In the final five minutes, choose one baseline measure, one quality boundary and the person accountable for the experiment. Bring that single-page contract to a mentoring discussion. A useful next step is a small trial with a clear stop condition.
Questions worth asking
Is ASDLC a replacement for the SDLC?
It is a useful label for adapting delivery workflows to agents. Existing responsibilities for product intent, testing, security and operations still need explicit owners.
Does a better harness mean more agents?
Not necessarily. Begin with the simplest workflow that can meet the acceptance contract. Add orchestration only when a specific bottleneck or evaluation result justifies it.
Sources & further reading
- GitHub — Building Git infrastructure for agent-scale development (6 October 2026; updated 7 October)
- Anthropic — Harness design for long-running application development (24 March 2026)
Primary sources were reviewed on 19 October 2026. Vendor descriptions are attributed; the product frameworks, scenarios and exercises below are editorial analysis, not reported personal experience or verified performance results.