ADLC: Why Judgment Must Move Upstream
In early automobile assembly, the most skilled workers were fitters, who hand-finished each part so it would fit with its neighbor. The role disappeared when precision gauging made interchangeable parts possible. However, their expertise was not lost; it moved upstream into the jigs, fixtures, and inspection gauges used before assembly.
Agentic coding has a similar effect on software development. We saw this in one of our engineering teams, where three new systems were built over 18 months. The first took seven months from design document to announcement, the second took four months. The third system took five weeks from first discussion to public launch and was built by two engineers, rather than twelve engineers in one year.
Same stages, different actors
The agentic development life cycle (ADLC) mirrors the stages of a conventional software development life cycle (SDLC), from requirements and design to coding, testing, deployment and operations.
The key change is which actor executes each stage. Engineers specify intent and own the approval gates. Agents produce plans, write and review code, and run tests. In some advanced implementations, agents merge pull requests without human review.
The life cycle does not end at merge.
Agents deploy changes, monitor production signals, triage failures, and propose fixes. These re-enter the same review and test gates. Production issues are tracked, and when one exposes a gap, it produces a durable artifact upstream. This might be a new contract clause, a regression test, or an update to the shared project context. Without that feedback path, the same class of defect gets rediscovered through the loop.
Agents accelerate implementation, but specifying the work and evaluating the results still requires deep domain expertise from a human.
Code is now free. How will you use it?
When the cost of implementation drops, the risk shifts from building something poorly to building the wrong thing. The ADLC adds an experimentation stage ahead of requirements: prototypes designed to test a hypothesis against a measurable KPI.
Each experiment should define its success metric and kill criteria before the prototype is built. Because prototypes are inexpensive, it is practical to build competing approaches in parallel and compare them on the same metric. The requirements document is written based on measured results rather than assumptions.
Prototype code should be treated as disposable. A working prototype creates pressure to ship as-is, which bypasses the contracts, review, migration, and testing that the rest of the lifecycle depends on. The design that survives experimentation is re-implemented.
Review moves from the diff to the design
When agents generate most of the code, human review capacity becomes the bottleneck. Rounds of automated AI review and revisions happen before a pull request reaches a human reviewer.
Repository rules and coding standards are codified, so reviewers no longer need to enforce standards or catch nits. Line-by-line review of agent-generated diffs does not scale and catches design problems too late.
The control point moves to the design review, the last stage where a person shapes the outcome before agents execute. Requirements and design documents must be precise enough to serve as contracts against which implementation is measured. In practice, design reviews become longer and more demanding.
Raising the quality bar with invariant contracts
When agents write the code, testing becomes more important, not less.
Beyond verifying correctness, a test suite confines the agent to a scope. It defines what ‘done’ means and fails when a change extends beyond the intended area. Agents guided this way produce consistent results across runs.
Higher throughput is only safe if verification becomes more rigorous. Changes can be checked against contracts that specify what each component guarantees and explicitly what it does not. The non-guarantees keep anyone from relying on behavior that may hold today, but was never promised.
Context across stage handoffs
Moving judgment upstream only helps if it reaches the agents executing downstream stages.
When each stage receives only the previous stage’s output, every agent reconstructs the reasoning behind its input from scratch. We call this a cold start.
In our testing, warm handoffs that carry relevant prior context cost 37-45% less than cold starts and avoid a non-deterministic rebuild of the team’s rationale. The right context matters more than more context: output quality peaks and then falls as relevant material gets diluted.
A shared context layer can instead retrieve only the information relevant to the task, rather than feeding agents everything. Handing the next agent a full transcript doesn’t work because it can’t distinguish a decision from an abandoned dead end. To solve the agent handoff problem, pass only the decisions, constraints, and open questions, with an explicit rule for what crosses into shared context.
Beyond engineering
As engineering throughput increases, related teams become the next constraint. A five-week build cycle has no room for a prolonged launch, so sales, marketing, IT, and legal now use AI to accelerate their processes.
Context sharing is also useful here. When the requirements, design documents, and release notes are made available as shared context, other teams start from what engineering knows, rather than reconstructing it through meetings and handoff documents. A sales enablement brief, a launch announcement, or a contract review can begin from the same source material.
Recommendations
As agentic development accelerates, engineering teams must shift their focus from writing code to defining outcomes, goals and clear expectations. This means establishing measurable KPIs before prototyping, tracking token usage to optimize costs, and strengthening contracts that guide agent execution. Teams should also use production issues to improve the development life cycle and extend shared context beyond engineering, helping other business functions keep pace with faster development cycles.
SD TIMES Q&A
What is the agentic development life cycle (ADLC)?
The agentic development life cycle (ADLC) maps the same stages as a conventional SDLC — requirements, design, coding, testing, deployment, and operations — but reassigns who executes each stage. Engineers define intent and own approval gates, while AI agents produce plans, write and review code, run tests, and in some implementations merge pull requests and monitor production. The life cycle also adds an experimentation stage before requirements to test hypotheses against measurable KPIs.
How does ADLC change code review for engineering teams?
In ADLC, line-by-line review of agent-generated diffs does not scale and catches design problems too late. The practical control point shifts upstream to design review, where engineers shape outcomes before agents execute. Repository rules and coding standards are codified so automated checks enforce them, freeing human reviewers to focus on design correctness rather than style or nit-picking.
How do you handle context handoffs between agents in an agentic pipeline?
Passing a full conversation transcript between agents is ineffective because agents cannot distinguish a final decision from an abandoned dead end. The recommended approach is a shared context layer that retrieves only decisions, constraints, and open questions relevant to the next stage. According to the article, warm handoffs carrying targeted prior context cost 37–45% less than cold starts where each agent reconstructs reasoning from scratch.
Should prototype code in an ADLC workflow be shipped to production?
No. Prototype code in ADLC is explicitly treated as disposable. Shipping a working prototype as-is bypasses the contracts, review, migration, and testing that the rest of the life cycle depends on. The design that survives experimentation is re-implemented from scratch using the full development process.
How do invariant contracts and test suites constrain AI coding agents?
In ADLC, a test suite serves two purposes: it verifies correctness and defines the scope boundary for the agent. Tests fail when a change extends beyond the intended area, keeping agent output consistent across runs. Invariant contracts specify what each component guarantees — and explicitly what it does not — preventing downstream teams from relying on behavior that was never promised.
The post ADLC: Why Judgment Must Move Upstream appeared first on SD Times.
Tech Developers
No comments