Docs White Papers Pricing Contact Get Started

AI SDLC self-check

A self-check for engineering leaders whose teams use AI coding tools. Answer each item yes or no, and be strict: anything you would need to investigate counts as no. It takes about 15 minutes. The unchecked items show where AI is probably costing you more than you think.

0 / 31AI is mostly running on its own

Check every item that is true for your team today.

1. Visibility 0 / 4

You know which AI coding tools each team uses, and which ones are paid for by the company.
You can tell which merged pull requests were mostly written by an agent.
You know roughly what you spend on AI tools and model usage per engineer each month.
Someone owns AI tooling decisions for engineering as part of their actual job.

2. Delivery results 0 / 4

You measured delivery (lead time, deploy frequency, change failure rate, time to restore) before the AI rollout, so you have a baseline.
You have compared those numbers since the rollout, and they improved.
Rework is tracked: code that gets rewritten or reverted within a few weeks of merging.
Your engineers would say AI makes them faster on your main, older codebase too.

3. Deciding before building 0 / 5

Tickets have a written Definition of Ready that the team actually follows.
Open questions on a task get answered before an agent or engineer starts it.
Specs and acceptance criteria are written down where an agent can read them.
When an agent makes a design decision mid-task, it gets surfaced to a person.
Your backlog is ordered by something more than whoever asked loudest.

4. Review and quality 0 / 5

Reviewers are keeping up. The queue of PRs waiting for review has not grown since the rollout.
Large PRs get the same depth of review as small ones. Whether people or agents do the reviewing, your team has decided how much change it can review well, and sticks to it.
AI-written code has to meet the same test coverage bar as human-written code.
Every AI-written change is reviewed by a person or by a different model from the one that wrote it.
Security scanning runs on every change, including the ones agents open.

5. Governance and risk 0 / 5

There is a written policy on what agents may and may not do (touch production config, change auth code, add dependencies).
Agents run with the minimum permissions they need, in isolated environments.
Secrets and customer data cannot end up in prompts or model context.
For any change, you can show who or what wrote it, who reviewed it, and what checks it passed.
If you are in a regulated industry, you know which rules apply to AI-assisted development (for example the EU AI Act, NIST AI RMF or ISO 42001) and where you stand.

6. Context and knowledge 0 / 4

Architecture decisions are recorded somewhere agents and new hires can find them.
Agents start each task with project-specific context: conventions, patterns and domain terms.
Lessons from past incidents and mistakes make it back into what agents see.
Your internal docs, tickets and wiki are searchable enough that an agent could find the answer a senior engineer would give.

7. People 0 / 4

Engineers have had real training on working with agents, beyond being handed a license.
Senior engineers spend most of their time on design and decisions. Cleaning up agent output is a small part of their week.
Junior engineers can explain the code they ship, including the parts an agent wrote.
You have a way to share what works between teams.

What this means

AI is mostly running on its own. Expect rework, review bottlenecks and risk you cannot see yet. Start with sections 2 and 4.

This fits the AI SDLC Audit. AI SDLC Audit

Email me this breakdown (optional)

Used once to send this breakdown and to reply if you ask for a call. Not stored. See the privacy page.

The autonomous AI-SDLC framework. Open source, agent-agnostic, spec-driven.

Product

Documentation
Pricing
Specification

Resources

Getting Started
Tutorials
API Reference

Company

Contact Sales
GitHub
License (Apache 2.0)

© 2026 AI-SDLC Project. Licensed under Apache 2.0.