Scaling Agentic SDLC: Designing an Adaptive Auto Mode for Autonomous Coding

In Part 1, I explained why moving from AI-first prompt engineering (VS Code + GitHub Copilot / OpenCode) to autonomous agentic coding (VS Code + Claude Code) breaks traditional software delivery, and why I built a strict Dual-PR Spec-First workflow for autonomous agents. By separating intent agreement from implementation execution, the architectural results were solid: zero contract drift, no test gaming, and strict boundary containment.

Then I ran into the human reality of software engineering: developer pushback.

When a developer needed to update a comment, tweak a test fixture, or adjust an internal helper function, the tool still demanded a full Spec PR, human approval on main, a locked SHA, and a second Implementation PR. Developers found it excessive, and rightly so.

Around the same time, Anthropic’s Claude Code team published a blog post: “How the Claude Code team does code review”. It explained how they handle code reviews when 90% of their codebase is written by agents.

Their core insight helped me redesign agentic-sdlc with an Adaptive Risk-Tiered Governance engine (auto mode). Here is how it works, the design choices I made, and how to roll it out safely.

🎯 BLUF (Bottom Line Up Front)

• The Problem: Forcing Dual-PR on every task creates too much red tape for everyday fixes. But dropping back to an ungoverned single PR brings back boundary bugs and “Player == Referee” test bias.
• Anthropic’s Lesson: When agents write most of your code, asking “Did a human read every line?” stops working. Anthropic uses a multi-layer setup: automated pre-PR checks, risk-tiered approvals, a 3-round review cap to stop endless debates, and clear human ownership (“You land it, you own it”).
• My Design: An auto mode (asdlc config set workflow_mode auto) using four risk tiers (L0 to L3):
  • L0 / L1 (Routine tasks): Use a Single PR with automated checks or independent AI review, eligible for auto-merge under a Bounded Positive Safety Envelope ($\le 5$ files, no public API exports, no god-nodes).
  • L2 / L3 (APIs, schemas, auth): Strictly enforce the Dual-PR Spec-First flow with human Tech Lead sign-off.
• The Multi-Stack Reality: Directory-name regexes alone failed across multi-stack benchmarks (97 under-classifications across 120 enterprise cases in Java, Python, Go, Node, .NET). agentic-sdlc replaced brittle paths with a <50ms lightweight 3-layer static fingerprint engine + Graphify 1-hop AST topology.
• Humane In-Place Escalation: If an L1 task expands to touch an API during implementation, keep the PR in-place and route to a human, instead of forcing a branch restart.
• Anti-Gaming Hash Chain: Every tier transition is sealed in an append-only SHA-256 hash-chained risk-history.jsonl, preventing agents from self-downgrading L2 -> L1.

1. When Strict Process Meets Developer Reality

After building the Dual-PR model in Part 1, the technical logic was sound. But in daily use, developers quickly ran into friction:

Developer: "I just need to fix a typo in the README and update one test fixture."
Tool:      "Please open a Spec PR, wait for Tech Lead merge on main, 
            lock specSha, branch to impl, and open an Implementation PR."
Developer: "I'm just going to turn this tool off."

This is a classic governance trap. If your safety rules treat a typo fix with the same friction as a database migration or an auth rewrite, developers will simply bypass the rules.

I needed a middle ground: fast-track routine changes without giving up safety on high-impact code.

2. What I Learned from Anthropic’s Review Post

In October 2026, the Claude Code team at Anthropic shared how they manage reviews internally. Across their repository, daily merged changes jumped from 2,500 in May to over 30,000 in September.

With that volume, reading every line of code is simply impossible. A few key ideas stood out to me:

1. Review has two separate jobs: catching bugs before deployment, and sharing system context across the team.
2. One size does not fit all: Low-risk changes (docs, small bug fixes) should merge quickly once automated tests pass. High-risk changes (auth, billing, core libraries) must require human eyes.
3. Set a round cap on AI reviews: An AI reviewer will endlessly argue about style or small preferences if you let it. Anthropic set a 3-round limit. If the author and reviewer agents don’t agree by round 3, stop the loop and bring in a human.
4. “You land it, you own it”: A green bot check does not excuse human responsibility. The engineer who prompted the agent owns the change in production.

3. The Architecture: L0–L3 Adaptive Governance

To balance speed and safety, I introduced the Adaptive Dual-Track Engine (asdlc config set workflow_mode auto).

When a change starts, the engine evaluates three vectors:

1. Vector 1 (Task Intent): Pre-code intent from the prompt, structured spec contract blocks, and host agent declarations.
2. Vector 2 (Security & Data Boundaries): Detection of database DDL statements (CREATE TABLE, ALTER TABLE), authentication engines, and credential patterns.
3. Vector 3 (AST Topology & Architecture via Graphify): Quantitative fan-in analysis—how many dependent files rely on the functions or classes being modified.

  flowchart TD
    REQ["Natural Language Prompt / Diff"] --> ASSESS{"Neuro-Symbolic Risk Engine<br/>(Static Fingerprints + AST Invariants)"}

    ASSESS -->|"L0: Docs, Typo, Test Fixture"| T_L0["<b>Level L0 · Trivial</b><br/>Docs, pure test fixtures"]
    ASSESS -->|"L1: Bounded Local Logic (<= 5 files)"| T_L1["<b>Level L1 · Routine</b><br/>Internal utils, local helpers"]
    ASSESS -->|"L2: Public API, DB DDL, Shared Hub"| T_L2["<b>Level L2 · Structural</b><br/>FastAPI, Spring, Schemas, God-Nodes"]
    ASSESS -->|"L3: Auth Engine, DROP TABLE, Governance"| T_L3["<b>Level L3 · Critical</b><br/>Security, Auth, .sdlc/policy"]

    subgraph FAST_TRACK ["Fast-Track: Single-PR Flow"]
        T_L0 --> SP1["Direct Implementation<br/>(Spec & Code in 1 PR)"]
        T_L1 --> SP1
        SP1 --> V_AUTO["Local asdlc verify<br/>(12 Quality Gates)"]
        V_AUTO --> PR_AUTO["Single PR to main<br/>(Eligible for Auto-Merge)"]
    end

    subgraph SPEC_FIRST ["Spec-First Track: Dual-PR Flow"]
        T_L2 --> DP1["Spec PR to main"]
        T_L3 --> DP1
        DP1 --> G_SPEC["Spec Review & Tech Lead Approval"]
        G_SPEC --> S_LOCK["specSha Lock on main"]
        S_LOCK --> DP2["Implementation Unlocked"]
        DP2 --> DP3["Task-level TDD Loop"]
        DP3 --> PR_IMPL["Implementation PR<br/>(Human Tech Lead Sign-off)"]
    end

    SP1 -.->|"In-Place Escalation<br/>(Touches API/DDL during coding)"| ESCALATE["Keep Single PR in-place<br/>Revoke auto-merge & route to Lead"]
    ESCALATE -.-> PR_IMPL

The Governance Tier Matrix

4. Key Engineering Discoveries & Trade-offs in Auto-Mode

Building an adaptive mode brought up several deep engineering challenges. Here are the core technical decisions:

1. The Multi-Stack Reality: Why Path Regexes Failed (97/120 Under-Classifications)

An early prototype used simple path regular expressions (e.g., matching /api/ or /migrations/).

When I stress-tested this against a benchmark of 120 real-world enterprise test cases across Java (Spring Boot, Quarkus), Python (FastAPI, Django), Go, Node.js, Kotlin, and .NET, simple path regexes suffered 97 under-classifications:

• A Flyway database migration at src/main/resources/db/mysql/2026/V12__alter.sql was missed because the path lacked a literal /migration/ segment.
• A Go server in cmd/server/main.go exporting public routes via echo.New() or gin.Default() was missed because it wasn’t placed under /api/.

To fix this without embedding heavy, slow compilers into the CLI, I engineered a <50ms lightweight 3-layer static fingerprint engine:

1. Framework Import & Decorator Signatures: Detecting @RestController, APIRouter, echo.New(), gin.Default(), @Controller.
2. Schema & DDL Content Headers: Scanning for CREATE TABLE, ALTER TABLE, foreign keys, and migration annotations.
3. Build Manifests & Dependencies: Inspecting structural changes in package.json, pom.xml, or go.mod.

Combined with Graphify 1-hop in-degree, this accurately surfaces structural changes across languages in milliseconds.

2. The L0 + L1 Bounded Positive Safety Envelope

Why not simply classify every non-documentation change as L2?

• Forcing L2 on every single internal code change would destroy the L1 fast track, bringing back the exact friction developers complained about.
• Decision: Establish a strict Bounded Positive Safety Envelope for L1:
  • Total changed files must be $\le 5$.
  • Must not touch root package exports (index.js, mod.rs, public interfaces).
  • Must not modify an AST hub with in-degree $\ge 20$.
  • Must contain zero API/DDL/auth static fingerprints.

If a change fits inside this envelope, it moves quickly through the Single-PR pipeline.

3. Humane In-Place Escalation vs. Branch Restarts

Suppose an engineer prompts an agent: “Refactor the order discount helper.” This gets classified as L1 (Single PR).

Halfway through coding, the agent realizes it needs to add a new column to a database table or alter a public API route.

In a strict gate system, CI would block the PR and say: [ERROR] Database schema touched on a Single-PR branch. Please stash your code, open a Spec PR, get it merged, and rebase. That makes developers hate the tool.

Instead, I implemented Humane In-Place Escalation (Invariant #8):

• The single PR stays in-place. No stashing, no branch recreating.
• asdlc verify detects the boundary expansion via the risk-escape check.
• It automatically revokes auto-merge and adds the label asdlc:escalated-to-lead.
• The PR routes to a human Tech Lead for review and approval.

Safety is preserved, and the developer’s work is not thrown away.

4. Anti-Gaming Hash Chain (risk-history.jsonl)

An early prototype let the authoring agent write a local file declaring its own risk level. An agent will almost always declare itself “L1 Low Risk” because it wants to complete the task without waiting for human approval.

To prevent this:

• Every level transition is sealed in an append-only, SHA-256 hash-chained log (risk-history.jsonl).
• Manual or agent downgrades (L2 -> L1) break the hash chain and are instantly blocked by level-integrity.
• The static fingerprint engine acts as an immutable invariant guard. If the diff contains DROP TABLE or touches .sdlc/policy.yaml, it is unconditionally forced to L3.

5. 3-Round Review Cap to Stop Infinite Loops

Adopting Anthropic’s rule, independent review sessions (asdlc-impl-review) are capped at 3 rounds.

If the implementation agent and review agent cannot agree on a clean diff after 3 rounds, the loop stops. Instead of wasting tokens on minor formatting arguments, the PR gets labeled asdlc:needs-human-arbitration for a human to make the call.

5. How to Roll This Out: A Two-Stage Playbook

If an engineering team wants to adopt this, I recommend doing it in two phases:

PHASE 1: Team Onboarding                  PHASE 2: Steady-State Delivery
┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│ workflow_mode: spec-first       │  ──▶  │ workflow_mode: auto             │
│ (Dual-PR for all changes)       │       │ (Adaptive L0–L3 Dual-Track)     │
└─────────────────────────────────┘       └─────────────────────────────────┘
 • Builds team spec discipline             • Zero friction for L0/L1 tasks
 • Teaches writing clear BDD scenarios     • Strong safety on L2/L3 code
 • Calibrates AI reviewer baseline         • Maximum team development speed

1. Phase 1: Start with spec-first (asdlc config set workflow_mode spec-first): Run mandatory Spec-First for 3 to 4 weeks. This gets both human engineers and AI agents used to writing clear BDD specs and thinking about architecture before writing code.
2. Phase 2: Switch to auto (asdlc config set workflow_mode auto): Once the team is comfortable with the spec format, switch to auto. Routine fixes move through the fast track, while critical contracts stay protected.

6. What’s Next: Taking Agents Off Developer Laptops

With auto mode working, I solved the balance between safety and speed. But one big limitation remained:

Developers still had to run everything locally in their IDE.

You still have to keep your laptop open, watch test suites run, and handle prompts in your local terminal.

Can this entire agent workflow move off developer machines into an isolated, hardened container running headlessly in the background—handling all human interaction asynchronously through Git and GitHub PR comments? Taking agents off developer laptops is the next logical step in autonomous software engineering.

🔗 Links & References

• Part 1: From AI-First + SDD to Agentic SDLC: Building a Dual-PR Governance Engine for Autonomous Coding
• Anthropic Engineering Blog: How the Claude Code team does code review (Oct 2026)
• agentic-sdlc Repository: https://github.com/akjamie/agentic-sdlc

× Jamie's Blog

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →