Why the Agentic SDLC Should Probably Be Governed by Gates, Not Sprints

For the better part of two decades, software engineering has been held hostage by an arbitrary unit of time: the two-week sprint.

When I started writing x86 assembly over thirty years ago, the bottleneck in software was the sheer cognitive, and mechanical effort, required to translate human intent into working instructions (two weeks of 0x90 isn't productive, IYKYK). Every register allocation, memory jump, and interrupt handler had to be reasoned through line by line. Later, as higher-level languages abstracted the silicon away and teams grew into sprawling departments, Agile, and specifically Scrum, emerged as a managerial coping mechanism for human unpredictability. Because human engineers get fatigued, suffer from context loss at every handoff, misinterpret prose requirements, and struggle to estimate complex work, management wrapped a fourteen-day calendar block around the chaos and called it "velocity".

We invented story points, an entirely fictional currency designed to mask the inability to predict effort, and celebrated when a burndown chart hit zero on a Friday afternoon. It rarely mattered whether the underlying architecture was coherent, or held together by feature flags, duct tape, and deferred technical debt; what mattered was that the tickets moved across the board before the clock ran out.

In the era of the Agentic Software Development Life Cycle (ASDLC), the two-week sprint isn't just obsolete; it is in my humble opinion, actively dangerous.

When autonomous agents and synthesis engines can materialise thousands of lines of boilerplate logic, database migration scripts, dependency injection bindings, and container manifests in forty-five seconds, managing engineering velocity with a calendar is like trying to clock a microprocessor with a sundial. If you keep feeding an agentic pipeline using traditional time-boxed sprints, you do not get faster delivery. You get high-velocity slop. You get architectural drift, security regressions, and unmaintainable state mutations at machine scale.

It is time to kill the calendar-driven sprint. In a mature ASDLC, velocity is not managed by the passage of time; it should be managed by gates. Nothing moves forward until the agents, and the humans, inside a given operational cycle reach explicit, verifiable, and cryptographically attested consensus.

Here's what it could look like, and perhaps it should...

The Illusion of Temporal Velocity and the Linear Assembly Line

Traditional software delivery treats engineering as a linear assembly line: requirements pass to specification, specifications to code, code to testing, and testing to production deployment. At each sequential handoff, human context degrades, business intent becomes distorted, and runtime realities remain completely isolated from initial design decisions.

When you superimpose a two-week timer onto this (often not) linear pipeline, the pressure to "close the sprint" overrides engineering rigour. Corner-cutting becomes institutionalised:

• Ambiguous intake: Loose, poorly bounded user stories are pushed into active development because the team needs to "fill the sprint capacity," operating on the delusion that edge cases will be discovered while writing the code.
• Premature merging: Pull requests are waved through with superficial reviews, and partial test coverage, because the sprint review demo is at 14:00 on Friday.
• Observability as an afterthought: Structured logging, distributed tracing, and operational alerting are relegated to tech-debt tickets that never survive the next sprint's backlog grooming.

When you introduce AI coding agents into this time-boxed model without fundamentally changing the governance structure, the failure modes multiply exponentially. An LLM-backed agent given a vague Jira ticket will not pause to question flawed domain boundaries. It will eagerly hallucinate a plausible-sounding implementation, generate unit tests that tautologically validate its own broken assumptions, and open a pull request in three minutes.

Meanwhile, human engineers, drowning in a flood of machine-generated pull requests, suffer from severe review fatigue. Confronted with a 2,000-line diff twenty minutes before standup, a human reviewer stops auditing the systemic architecture, and defaults to checking whether the linter passed. If your metric of success is how many tickets move from left to right within a fortnight, your throughput metrics will look glorious right up until your production estate collapses under the weight of unverified machine assumptions.

True velocity in the ASDLC is state-based, not time-based. Work does not progress because Tuesday arrived; work progresses because a strict operational gate has been satisfied.

Enter the Gate-Driven ASDLC

Think of an electronic circuit, or a modular synthesiser patch: a trigger or gate signal does not open a voltage-controlled amplifier because a predetermined wall-clock schedule says it feels like it; the gate opens when the voltage crosses an exact, physical threshold.

Software engineering in the agentic era requires the same deterministic discipline. Instead of an assembly line pushed forward by a Scrum Master's stopwatch, the lifecycle is organised into five discrete, interconnected operational cycles, what I formalise as the five nodes of the Pentagram Graph: Intent, Specification, Synthesis, Verification, and Telemetry.

Between every cycle sits a hard gate. Inside each cycle, human engineers and specialised agents operate in a tight, bidirectional loop. The gate only opens when both the machine assertions, and the human orchestrators agree that the artefact is complete, valid, and signed.

Gate 1: The Intent Gate (Alignment Before Architecture)

The foundational law of a gated ASDLC is simple: no engineering work shall begin without an explicit, machine-searchable statement of intent detailing business objectives, user requirements, architectural constraints, and quantifiable success criteria. Vague one-liners on a Kanban board are rejected at the door.

The Artefact

Instead of a prose ticket, the output of the Intent cycle is an executable intent manifest (intent.json). This manifest defines the functional boundaries, expected latency and throughput budgets, security postures, measurable acceptance criteria, and, crucially for agentic workflows, the explicit TokenOps and compute execution budgets allocated to solve the problem.

The Agent's Role in the Cycle

Context-ingestion agents scan historical repositories, existing domain models, and past incident post-mortems. They analyse the proposed intent against active system invariants, surface prior design decisions that might conflict with the new objective, and flag hidden dependencies or contradictory business goals before a single schema is touched.

The Human's Role in the Cycle

Engineering leaders, product owners, and domain experts collaborate to refine the objective, evaluate commercial trade-offs, and establish strict priority boundaries. The human decides what is worth building and why, stripping away gold-plating, and organisational noise.

The Gate Consensus Criteria

• Machine Attestation: The intent validator confirms that intent.json conforms to the schema, contains zero unresolvable conflicts with existing system intents, links directly to automated executive acceptance suites, and specifies a valid compute/token budget ceiling.
• Human Attestation: The Product Owner, and Engineering Lead, cryptographically sign the manifest, confirming that the stated business outcome and resource constraints are accurate.
• Gate Enforcement: Until both cryptographic signatures are present on the intent manifest, downstream specification compilers, and synthesis agents, are completely locked out.

Gate 2: The Specification Gate (Executable Contracts as Ground Truth)

In an agentic workflow, informal prose user stories are a complete liability. Agents do not need empathetic narratives about what a user "wants to feel"; agents require unambiguous, mathematically rigorous boundaries. The Specification cycle translates validated human intent into machine-readable contracts.

The Artefact

The deliverables of this cycle are strongly typed, executable contracts: OpenAPI specifications, TypeSpec or GraphQL definitions, strict relational database schemas, event payload structures, and Policy-as-Code governance modules (declaring data residency, encryption mandates, and RBAC rules).

The Agent's Role in the Cycle

Automated contract compilers and specification agents ingest the intent.json manifest and draft the necessary interface bindings, and schema migrations. They immediately verify backwards compatibility against the entire service estate, flag breaking changes across downstream consumers, and, via a direct pathway to the Verification node, automatically generate property-based test stubs, fuzzing inputs, and contract validation suites before any application code exists.

The Human's Role in the Cycle

System architects and senior developers focus 100% of their cognitive energy here. Instead of wasting hours reviewing thousands of lines of AI-generated implementation syntax later, senior engineers review the laws that the implementation must obey. They scrutinise state transitions, domain boundaries, data structures, nullability constraints, and concurrency bounds.

The Gate Consensus Criteria

• Machine Attestation: The contract compiler proves that all schemas compile cleanly, backwards-compatibility assertions pass across all dependent repositories, policy-as-code rules are syntactically sound, and red (failing) test suites have been generated and staged in the Verification node.
• Human Attestation: The System Architect or Senior Lead signs off on the schema and interface boundaries, confirming that the domain model is clean and extensible.
• Gate Enforcement: No implementation code can be merged, or even synthesised for production, without referencing an active, signed specification contract.

Gate 3: The Synthesis Gate (Ephemeral Implementation)

Once Gate 2 opens, we enter the Synthesis cycle. Here, a radical mindset shift is required: source code, infrastructure manifests, and configuration files are ephemeral artefacts of underlying specifications. When specifications are airtight, code synthesis is no longer a multi-week creative writing exercise; it can be a deterministic compilation step.

The Artefact

Application source code, SQL migration scripts, dependency injection wiring, container manifests, and embedded OpenTelemetry instrumentation hooks.

The Agent's Role in the Cycle

To maintain context integrity, minimise compute latency, and eliminate hallucinations, synthesis agents operate under strict Context Window Trimming protocols. They do not receive the messy conversational history or raw brainstorming from Gate 1; they receive only the compiled, strongly typed contracts from Gate 2 and the failing test stubs from Verification. The synthesis engines write the boilerplate logic, implement the interface contracts, wire the database queries, and embed structured telemetry sensors directly into the binary. If the synthesis loop exceeds the TokenOps budget defined in Gate 1, execution pauses automatically rather than burning compute in an infinite retry loop.

The Human's Role in the Cycle

Software engineers do not babysit syntax; they architect novel algorithms, solve subtle domain edge cases where probabilistic synthesis struggles, guide agentic orchestration harnesses, and inspect the structural ergonomics of the generated output.

Crucially, if a human engineer spots a flaw in how data is flowing, they do not manually hack a quick workaround into the generated code to "get it done." If the synthesised output is structurally wrong, it means the contract in Gate 2 was underspecified. The human rejects the synthesis, closes Gate 3, and loops back to Gate 2 to tighten the specification.

The Gate Consensus Criteria

• Machine Attestation: The compiler, static analysis engines, and linter pass with zero warnings; all contract interfaces are fully implemented; and the TokenOps ledger confirms synthesis remained within financial guardrails.
• Human Attestation: The lead engineer signs off on algorithmic integrity, readability, and architectural cleanliness.
• Gate Enforcement: Code cannot pass to full verification and deployment staging unless its cryptographic provenance header links it directly to the exact specification commit that authorised its generation.

Gate 4: The Verification Gate (Continuous Proof, Zero Exemptions)

In time-boxed Scrum, Quality Assurance is the whipping boy of the calendar. When synthesis drags on until Thursday afternoon of week two, QA is given six hours on Friday morning to rubber-stamp a release. In a gate-driven ASDLC, the Verification gate is an immovable wall.

The Artefact

Comprehensive test execution matrices, formal verification proofs, Static Application Security Testing (SAST) reports, property-based fuzzing logs, load-simulation profiles, and cryptographic compliance certificates.

The Agent's Role in the Cycle

Verification agents execute the test suites that were automatically derived from the Gate 2 specifications alongside the executive acceptance criteria derived from Gate 1. They run property-based tests (throwing thousands of randomised, boundary-pushing payloads at the interfaces), execute SAST and dependency vulnerability scans, simulate high-concurrency database load, and evaluate Policy-as-Code assertions to ensure no data residency, or security boundaries, have been breached.

The Human's Role in the Cycle

QA specialists, security researchers, and system architects are freed from writing repetitive regression scripts. Instead, they design adversarial threat models, perform exploratory chaos testing, and validate subtle, multi-system edge scenarios that require lateral human intuition.

The Gate Consensus Criteria

• Machine Attestation: 100% of unit, integration, property-based, and policy-as-code assertions pass. Zero skipped tests, zero muted security flags, and zero performance regressions against the latency budgets defined in Gate 1.
• Human Attestation: QA and Security Leads sign the verification certificate, confirming that exploratory threat audits revealed no unhandled failure modes.
• Gate Enforcement: There is no "merge with known defects and fix in Sprint 42". If a single property test or security policy assertion fails, Gate 4 locks shut and triggers an automated loopback to Synthesis, or Specification.

Gate 5: The Telemetry & Loopback Gate (Closing the Circuit in Production)

Deployment is not the finish line; in a self-balancing engineering topology, production runtime is the sensor array that feeds the entire system. A feature is not "Done" when it ships; it is only complete when its runtime behaviour is actively observed, and verified, against its original intent.

The Artefact

Live monitoring dashboards, structured log aggregations, distributed trace graphs, runtime contract-enforcement alerts, and automated loopback triggers.

The Agent's Role in the Cycle

Observability agents ingest high-volume production event streams, and correlate runtime behaviour directly against the boundaries defined in Gate 2 (Specification) and Gate 1 (Intent). Telemetry agents monitor compilation speeds, and runtime model token consumption, feeding performance metrics directly back to Synthesis agents to potentially auto-tune build configurations.

The Human's Role in the Cycle

Site Reliability Engineers (SREs) and developers analyse systemic health, evaluate long-term capacity planning, and validate that the deployed capability actually moves the commercial needle expected in Gate 1.

The Gate Consensus & The Loopback Protocol

Consider what happens when an anomaly occurs in production... say, an unexpected latency spike under peak concurrency, or a downstream service receiving an unpredicted null payload.

In a sprint-driven team, someone panics, writes a dirty two-line defensive if (x != null) patch directly in the code, bypasses architectural review, and hotfixes production. Huge praise, huge technical debt that compounds relentlessly over time until those that created it have long left.

In a Gate-Driven ASDLC, unverified hotfixes are strictly forbidden. Instead, the Telemetry Gate triggers a deterministic Loopback Protocol:

1. Contain & Capture (Node 5): Blast radius is isolated immediately via feature flags, rate limiting, or traffic shedding. Raw traces, and failing payloads are captured without touching the code.
2. Contract Update (Loopback to Gate 2): The failing runtime payload is fed directly back into the Specification cycle. Why did the system fail? Because our contract failed to forbid that state. The schema or interface contract is updated to explicitly handle or reject the condition.
3. Codify Failure (Loopback to Gate 4): From the updated specification, a regression or property test is generated in the Verification cycle. The test suite must run, reproduce the exact production failure, and fail predictably (Red verification) before proceeding.
4. Synthesise Resolution (Loopback to Gate 3): Only now do synthesis agents, and engineers, modify the application code against the updated contract until the failing test suite turns completely green.
5. Attest & Deploy: The fix passes back through the gates with full cryptographic lineage, and deploys to production. Every outage permanently hardens the specifications of the system.

Why Both Human and Agent Must Agree

The structural genius of a gate-governed architecture lies in bilateral veto power. Neither the human nor the machine has the authority to force an artefact through a gate unilaterally; both hold an absolute veto over the progression of work.

Consider the failure mode of commercial panic. A stakeholder demands a rushed feature, or a cowboy hotfix before a release deadline, tempting a developer to skip updating OpenAPI schemas or property tests just to get the change live. In a gated architecture, the agent holds the veto. The automated gate runner inspects the cryptographic provenance chain, detects a mismatch between the Synthesis diff, and the Gate 2 Specification signature, and refuses to open the merge gate. Machine discipline overrides human political pressure, ensuring that short-term panic cannot corrupt the long-term integrity of the estate.

Conversely, consider the failure mode of algorithmic hallucination and context blindness. An agentic swarm might satisfy 100% of the type contracts, and pass every property test in the suite, yet achieve that result by introducing a convoluted, high-latency polling loop or an unmaintainable abstraction layer. Here, the human holds the veto. The senior architect inspects the design ergonomics at Gate 2 or Gate 3, recognises the operational fragility that automated assertions cannot perceive, and withholds human cryptographic sign-off. Human wisdom, domain intuition, and architectural taste override machine syntactic compliance.

Finally, there is the operational hazard of runaway token burn, where a synthesis or verification agent gets trapped in a recursive self-correction loop trying to satisfy a contradictory constraint. In this scenario, the gate harness itself, governed by TokenOps guardrails, exercises the veto. The orchestrator hits the compute budget ceiling embedded within the Gate 1 intent.json manifest, freezes the agentic execution loop immediately, and asks the human lead to resolve the underlying specification contradiction before financial resources are squandered.

Provenance Without Bureaucracy

Whenever I describe hard gates to peers, their immediate reflex is to cry "Waterfall!" They imagine heavyweight change-advisory boards, weeks of bureaucratic sign-off meetings, and spreadsheets filled with manual checkboxes.

They are confusing governance with ceremony.

In the ASDLC, gates are not meetings; gates are cryptographic assertions enforced by local CLI tooling.

1. Cryptographic Provenance Headers: Every artefact generated across every cycle, whether an intent.json file, a TypeSpec contract, a synthesised PHP or C++ module, or a SAST verification proof, carries an immutable cryptographic signature and provenance header. Compliance auditors and engineering leads can trace any single line of production code straight back to the exact specification commit, intent manifest, prompt lineage, and automated test proof that authorised its existence.
2. Local CLI Gate Runners: Engineers do not leave their terminal to update ticket statuses in a bloated web UI. A local CLI utility inspects the workspace against graph invariants in milliseconds, verifying whether contracts compile, whether test suites cover new schema boundaries, whether telemetry tags match, and whether both agent and human cryptographic signatures are present in the repository tree.
3. Fast-Track Spikes Without Breaking the Law: What if an engineer wants to run a rapid exploratory spike to test technical feasibility? They use an explicit Intent-to-Synthesis inner-star pathway, letting raw intent drive rapid prototyping in an isolated sandbox. However, because that prototype lacks a Gate 2 Specification signature and a Gate 4 Verification proof, the gate runner physically blocks it from ever merging into the main trunk until the lessons learned from the spike are codified into formal contracts.

Engineering Sanity

When you dismantle the two-week sprint and install a gate-driven ASDLC, the cultural transformation across an R&D organisation could be profound:

• Performative agile ceremony evaporates. You eliminate two-hour sprint planning poker sessions arguing over whether a task is a "3" or a "5", and no you cannot be serious with a "21". You eliminate artificial Friday afternoon panic merges. A cycle takes exactly as long as it takes for the humans, and the agents, to satisfy the gate, whether that is four minutes for a well-bounded schema update, or four days for a complex distributed consensus algorithm.
• Velocity becomes honest. You stop measuring how busy the team looked over a fortnight and start measuring Full Graph Passes, features that have cleanly traversed Intent, Specification, Synthesis, Verification, and Telemetry with zero accumulated debt.
• Psychological safety is built into the architecture. Platform teams doing 24/7 cover no longer carry the anxiety of wondering if a rushed deployment will have them up at 03:00 on Sunday. When Gate 4 and Gate 5 open, both the human team, and the verification swarm have mathematically, and operationally, proved that the system holds.
• Engineers step into their true role as Orchestrators. Developers stop acting as exhausted human compilers racing an arbitrary calendar clock. They become systems architects, designing rigorous specifications, governing autonomous agentic harnesses, and holding the line at every gate in a way that no code review ever could.

The two-week sprint was a crutch built for an era when writing code was slow, manual, and expensive. In a world where code synthesis is almost instantaneous and virtually free, knowing that the system is right is the only metric that matters now.

It's never been as clear, the gates should be the new guards.

If any of this resonates, then you know what to do.