PART 2 OF 3 · THE AI-NATIVE SDLC 

The agent proposes. You approve. The methodology scales. 

Executive summary 

Coding agents have made code cheap to produce, but not to verify. HTEC’s three-part AI-Native SDLC series follows that problem across three interdependent layers: fixing intent before the build begins, governing how agents turn that intent into software, and verifying the result against production-shaped data. Each layer is only as dependable as the one beneath it.  

In Part 1, Code Got Cheap. Verification Did Not, we followed the AI dividend upstream into discovery and outlined how HTEC’s FDE harness fixes intent with evidence, freezes it at Gate G0, and ends at G2 with a decision that the sponsor makes: fund, stop, or defer.  

This second article begins when the sponsor approves the funding. It shows how HTEC delivery teams turn fixed intent into production software through AI-SDLC: a structured, adaptive, tool-agnostic methodology in which agents propose requirements, designs, implementation plans, and code, while people retain approval at every critical gate. The objective is not simply to generate code faster, but to make AI-assisted delivery reproducible, auditable, and scalable without surrendering human judgment.  

To close the series, Part 3 will show how HTEC’s AI-Native SDLC integrates Databricks Consort and Lakebase to provide deterministic controls and production-shaped test environments. Together, they make a passing test evidence of a real run, rather than a claim made by the agent. 

Part 2 Context: After the Sponsor Approves Funding 

As agents take on more of the work, the role of delivery changes. When almost anything can be built quickly, a team can fail faster just as easily as it can deliver faster. The challenge is to give agents enough autonomy to create velocity without letting the intent drift or controls become a bottleneck. 

As development progresses, most teams discover that AI coding tools are powerful but unstructured. We see the same pattern everywhere we look: 

• The assistant jumps straight to code generation, with no requirements gathering and no design phase. 

• The team loses context between sessions, and decisions live in a chat window that nobody will read again. 

• Outputs vary widely between prompts and models, so the team cannot reproduce what the AI decided or why. 

• Nobody keeps an audit trail. 

The result is technical debt from the first commit, expensive rework when direction changes, and vibe coding that produces demos rather than production software. AI-SDLC is how we fix that. 

A Methodology, Not a Tool 

AI-SDLC is an adaptive software development workflow that brings structure, reproducibility, and human oversight to AI-assisted engineering. We built it on five principles: 

• No duplication: one source of truth. The workflow derives every artifact from that source and never duplicates it. 

• Methodology first: process over platform. You install nothing; you copy the rule files and start. 

• Reproducible: explicit guidance, so that different models produce consistent outcomes. 

• Agnostic: any IDE, agent, or model, with no lock-in. 

• Human in the loop: the agent proposes, and a human approves at every gate. 

The same workflow runs in Claude Code through CLAUDE.md, in Cursor through .mdc rules, and in Amazon Q, Kiro, and GitHub Copilot through their own rule and steering files. Different people on one team can use different tools and still produce the same artifacts, and a team can switch tools mid-project without losing context. AI-SDLC is the workflow; your platform is the runtime. 

One Workflow, Three Phases 

Every engagement runs the same three phases. Inception determines what the team builds and why. Construction determines how the team builds it, and repeats for each unit of work. Operations covers deployment, monitoring, and maintenance, and is the next part of the methodology on our roadmap.

Not every request needs the full process, and that is easy to underestimate. AI-SDLC first examines the project, assesses the complexity of the work, and adjusts the level of rigor accordingly. When a team is working with an existing codebase, it first builds an understanding of how that system works before asking what should change. 

The Agent Proposes. You Approve. 

AI-SDLC never proceeds without explicit human approval at the critical checkpoints, and each gate has a named owner. The AI cannot approve its own work.

Code generation itself runs in two parts. In the planning part, the AI writes a plan with open questions and checkboxes and waits. In the generation part, it executes only the plan that a human approved, step by step, and marks its progress as it goes. When the human reviewer rejects the plan, the AI revises it. The AI writes no code until a human approves the plan. 

Every question and decision lands in versioned Markdown files under aidlc-docs/, not in chat. The team commits specifications, designs, plans, and build and test instructions and reviews them in pull requests like any other code. Raw prompts and working Q&A stay out of version control. The workflow loads rule details at the stage that needs them rather than all upfront, which keeps the agent’s context lean and the token bill proportional to the work. In Part 1, we called governance the 2027 token budget; this is what that looks like day to day.

Where the Hours Go 

Velocity in AI-SDLC does not come from typing faster. It comes from moving engineering time to the work that needs judgment. Our sprint model keeps a two-week sprint at 80 hours and changes how the team spends them. Agents take over the production work: boilerplate and scaffolding drop from about 20 hours to about 3 (all figures stated in this model are approximate), first-draft tests from 10 to 2, and core logic from 24 to 18, with an engineer directing the agent. Planning and estimation drop from about 16 hours to 10. The hours that those changes free go to review and verification, which grow from 6 hours to about 20, to architecture and design, which barely appears in a traditional sprint and takes about 18, and to 9 hours of work that the team could not fit before. The velocity gain is in what the sprint delivers, not in how long it takes: in our model, the same 80 hours complete approximately 8 story points instead of 5, a 60% increase. We treat that figure as a hypothesis until a team’s own metrics confirm it. 

For larger work, one engineer acts as orchestrator: they decompose the task, direct specialized agents for implementation, tests, security, documentation, and first-pass review in parallel, and review what comes back. Parallel agents need guardrails, and we make ours explicit: 

• Checkpoint commits: the orchestrator commits every 30 minutes. 

• Scope boundaries: each agent has access to its own files only. 

• Human review gate: a human reviews any change that exceeds 500 lines. 

• Full audit trail: the harness logs every tool call. 

Review Without a Bottleneck 

The fastest way to lose the AI dividend is to let agent output pile up in front of one tired reviewer. Opsera’s research earlier this year found that AI-generated pull requests wait 4.6 times longer for review than human-written ones. Our answer is three layers of review, so that human attention goes only where it matters. 

Measure Adoption Before You Claim Velocity 

We measure every AI-SDLC rollout on four layers, and each layer depends on the one before it: adoption enables productivity, productivity enables quality, and quality enables business impact. 

The rule is to measure L1 first. You cannot prove a productivity gain until you have confirmed adoption, and activity without impact is a vanity metric. Compare cohorts fairly: control for ticket complexity and team experience, and never compare story points across different teams. 

Teams move through the rollout in four stages, Foundation, Acceleration, Optimization, and Agentic, over roughly 180 days. Each stage has measurable exit criteria: at least 80% tool activation before Acceleration, at least 30% AI-assisted pull requests before Optimization, and a measurable cycle-time reduction before the team turns on autonomous, multi-agent workflows. Teams advance when they are ready, not on a fixed calendar. 

From Methodology to Purpose-Built Mechanisms 

AI-SDLC is deliberately tool-agnostic. It defines the phases, the gates, the artifacts, and the measurements, and lets each client run it on the stack that they already have. Some parts of the loop, though, benefit from mechanisms that engineers built for the job: a state machine that will not skip a gate, tests that the implementing agent cannot touch, and a database that branches like code, so that a team can trust a passing test. 

Part 3 of this series, Testing Against the Real Thing, will show how Databricks Consort and Lakebase put that methodology into practice through deterministic controls and production-shaped testing, making a passing test evidence of a real run rather than a claim made by the agent. 

If you would rather see AI-SDLC running on your own codebase than read about it, that is what HTEC’s delivery and Forward Deployed Engineering teams do.

Sources and References 

• HTEC Group, AI-SDLC: AI-Native Software Delivery, playbook covering methodology, delivery practice, toolchain, governance, and measurement, 2026. 

• HTEC Group, AI-SDLC: Structured, Adaptive, Human-Controlled AI Development, v1.0, 2026. 

• HTEC, AI Native Software Development Lifecycle Framework: Guide for Teams and Organizations, 2026. 

• AWS Labs, aidlc-workflows. github.com/awslabs/aidlc-workflows 

• Milan Stokić, Quality First Wins: The AI-Native SDLC from Why to How (Code Got Cheap. Correctness Did Not.), HTEC, 2026 (Part 1 of this series).