An engineering leader's guide to building an AI-native SDLC

Most teams have “adopted AI” the same way: someone expensed a coding assistant, a few people loved it, a policy doc showed up six months later. That isn’t an AI-native SDLC. It’s individuals with better autocomplete.

An AI-native SDLC is a lifecycle you designed with agents as participants: they get work, produce artifacts, pass through gates, and get measured. Think “some devs write tests” versus “we have CI.”

The maturity stages

Five stages. Not a scorecard, just a way to be honest about where you are so you pick the right next step.

1. 0. Ad hocPersonal chat and IDE use. No config, no policy. Owner: nobody.
2. ↓→
3. 1. SanctionedApproved tools, data policy, central licences. Owner: IT / security.
4. ↓→
5. 2. ConventionsAGENTS.md, shared prompts, review rules. Owner: eng leadership.
6. ↓→
7. 3. IntegratedAgents invoked from tickets, review, CI, incidents. Humans own gates. Owner: platform / DevEx.
8. ↓→
9. 4. AI-nativeWork decomposed for agents, gated end to end, metrics drive automation. Owner: leadership + platform.

📊 How AI-native is your SDLC?

1. 1. We have one or two approved AI coding tools and a written data policy.

   Not at all12345Completely

2. 2. Our active repos carry agent context files (AGENTS.md or equivalent) with an owner.

   Not at all12345Completely

3. 3. We have agreed review rules for agent-authored code, including PR size limits.

   Not at all12345Completely

4. 4. Agents are triggered from the workflow itself (tickets, CI, review), not only from someone's editor.

   Not at all12345Completely

5. 5. We've written down which types of work agents may do alone and which need a human gate.

   Not at all12345Completely

6. 6. We took a baseline and track flow and quality metrics for agent-involved work.

   Not at all12345Completely

Answer every question to see your result

The decisions only you can make

Enthusiasts will happily pick tools and write prompts. The trade-offs below belong to leadership, not to them.

1. Tooling standard

Pick a small, deliberate set. Model quality changes every quarter; your integration surface doesn’t. Revisit the choice every six months, not every week.

2. Autonomy levels: where agents act alone and where humans gate

The most important decision in this guide. Define autonomy per type of work, not per tool.

Level	Agent can…	Human…	Good fit
A. Suggest	Propose code in the editor	Accepts or rejects each change	Everything, by default
B. Draft	Open a branch or draft PR	Reviews and owns the merge	Features, bug fixes, refactors
C. Act with gate	Run end to end, incl. tests and PR	Approves at a defined gate	Dependency bumps, lint fixes, test backfill, docs
D. Act and report	Execute and notify	Audits after the fact	Triage labels, changelog drafts, stale-branch cleanup

🎮 Autonomous or human-gated?

1 / 9 · Score: 0

Where would you put each agent action, following the autonomy table above?

Agent acts, human audits laterHuman gate required

Next →

/ 9

↺ Try again

3. Context and repo conventions

Agents are only as good as their context. Making every repo self-describing is the highest-leverage, lowest-cost move here.

🃏 What a self-describing repo has

Tap a card to flip it

AGENTS.md at the rootHow to build, test and run; the architecture in a few paragraphs; conventions; what never to touch.Nested instruction filesFor subfolders with their own rules: a legacy module, a generated-code folder.Deterministic commandsOne to install, one to test, one to lint. If a new human can't find them in five minutes, an agent will guess wrong.Shared, versioned promptsIn the repo, reviewed like code, not in someone's personal notes.

Treat these files as code: reviewed, updated when the build changes, and a stale one is a bug. I’ve seen agents follow build instructions two migrations out of date because nobody owned the file.

4. Review and quality gates

Same bar for AI-generated code. What changes is how you hold it.

5. Security and data policy

Write this down before you scale, not after the first incident. Most of these are design mistakes, not model mistakes.

✅ Security and data policy

0 / 6 completed

• Data classification: what code and data may go to which tool (production customer data: no, unless covered contractually and technically)
• Secrets kept out of repos, .env files, logs and fixtures, with scanning
• Shell-capable agents run with an allowlist, in a sandbox, without production credentials
• Agent-suggested dependencies go through your normal review and scanning
• Agents reading untrusted input (issues, comments, web pages) run at low privilege, with no write access to what they read about
• Vendor retention, training use and data residency reviewed; Quebec teams check Law 25 obligations with their privacy owner

↺ Reset

6. Measurement

Without numbers, it becomes “feels faster” versus “feels riskier,” and the loudest person wins. Measure the system, not individuals.

Dimension	What to track
Flow	Lead time ticket to production, PR cycle time, review wait time
Quality	Change failure rate, escaped defects, reverts, incidents tied to recent changes
Adoption	Share of PRs with agent involvement, by repo and work type
Cost	Tool spend per engineer and per merged change
Experience	Short quarterly survey on friction and trust

Take a baseline before the pilot and compare against a similar team. Two numbers I refuse to use as productivity metrics: lines of code generated and acceptance rate. Both reward volume, which agents already overproduce.

A phased rollout: 90 days

One pilot team of four to eight engineers, and one owner with at least a day a week of protected time.

1. 1

   Days 0–30

   Foundations and a pilot (reach stage 2)

   Pick a team with good tests and a willing lead. Baseline it and a comparison team. Decide tools, publish the data policy. Have an agent draft AGENTS.md, then the team fixes it. Conservative autonomy table (mostly A and B). Half-day hands-on on real tickets. 30-minute weekly retro.

2. 2

   Days 31–60

   Integrate into the workflow (stage 3 for a few flows)

   Wire two or three workflows (ticket to draft PR, first-pass review, test backfill) into CI or ticketing with least privilege and a sandboxed runner. Add provenance labels and PR size guidance. Promote one low-risk work type to level C. Start a shared prompt library. Review metrics at day 45: if quality slips, stop expanding.

3. 3

   Days 61–90

   Expand and institutionalize

   Write up the pilot honestly, failures included. Package conventions, autonomy table, review rules, CI jobs and onboarding. Roll out to two or three teams with a pilot buddy each. Hand ownership to platform or DevEx. Schedule a quarterly review.

Common failure modes

All of these are avoidable. Flip each card for the fix.

🃏 Failure mode → fix

Tap a card to flip it

Tool-first, workflow-neverLicences bought, nothing else changed, usage stuck with a few enthusiasts. The fix is conventions and integration, not a better tool.Review collapseMore PRs, overwhelmed reviewers, LGTM on green CI. Watch review time per PR and PR size; a sharp drop in review time per line is a red flag.Context rotAGENTS.md written once, never updated. Give each file an owner and add "did this affect agent instructions?" to the PR checklist.Autonomy creepA level B workflow quietly gets merge rights. If approvals feel like rubber-stamping, promote the work type explicitly or fix your reviews.Skill atrophy in juniorsAnyone must be able to walk through their PR without the agent open. Keep some work deliberately agent-light for learning.Security as an afterthoughtBroad repo tokens reading public issues; shell agents with production credentials. Design mistakes, owned by humans.Measuring vanitySuggestions-accepted dashboards while lead time and change failure rate go untracked. You'll prove adoption and nothing else.Mandate by decree"50% of code must be AI" breeds gaming and resentment. Make the paved road better; hold teams to outcomes, not usage.

The checklist

Run this as a leadership review at the end of each phase. Progress is saved in your browser.

✅ Phase-end leadership review

0 / 6 completed

• Tooling: primary and alternative chosen with written criteria; licences central; rule for unapproved tools published
• Autonomy: A–D table per work type; high-risk areas capped at A or B; no agent can author and approve
• Context: AGENTS.md with an owner in every active repo; one-command install, test, lint; shared prompts versioned
• Quality: review guidance incl. size limits; agent reviews never required approvals; test changes scrutinized; provenance label
• Security: data classification; secrets scanning; sandboxed least-privilege CI agents; minimal permissions on untrusted input; vendor and privacy terms reviewed
• Measurement: baseline captured; flow, quality, adoption, cost and experience tracked; quarterly review with a named owner

↺ Reset

🧠 Quick check

Score: 0 / 4

1. 1. What's the best sign you're really at stage 3?

   Most developers use an assistant dailyRemoving the tools would break a processYou bought licences for everyone

   If only people get slower, you're at stage 1 or 2.

2. 2. How should autonomy be defined?

   Per toolPer developer seniorityPer type of work

3. 3. Can an agent's approval count toward required PR approvals?

   Yes, if tests passNo, it's a filter, not a gateOnly for level C work

4. 4. Which metric should you avoid as a productivity measure?

   Change failure ratePR cycle timeLines of code generated

   It rewards volume, which agents already overproduce.

↺ Try again

What to do this week

✅ This week

0 / 5 completed

• Place your team on the maturity scale: ask "would any process break?" at the next leadership meeting
• Draft a one-page autonomy table (work types down, levels A–D across) and circulate it for argument
• Pick one repo, let an agent draft its AGENTS.md, spend an hour with the team correcting it
• Capture a baseline: lead time, PR cycle time, change failure rate for the pilot team
• Name one owner with protected time; without that, everything above stays a document

↺ Reset