# AI-native engineering maturity assessment

> 29 questions across 5 areas, a score out of 100, and the list of what nobody on the team knew.

- **Source:** https://ainativesoftware.engineering/assessment
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

A free 29-question maturity assessment for engineering teams adopting AI. It scores out of 100 across 5 areas, names your blind spots, and gives you a question-by-question report to review with your team. About 10 minutes, no email.

- **Questions:** 29
- **Areas:** 5
- **Time:** about 10 minutes
- **Cost:** Free, no email, answers stay in your browser
- **Take it:** https://ainativesoftware.engineering/assessment

The full set of questions is below, so you can run this as a discussion with your team instead of clicking through it alone. The scoring is on the page.

## How it scores

- Every question is worth 0 to 4 points.
- Behavioural questions use one ladder: absent (0), ad hoc (1), present but not enforced (2), enforced (4). The jump from 2 to 4 is deliberate — an unenforced practice is not a practice.
- Inventory questions ask you to tick everything that is true. Each item carries a weight and the total is capped at 4, so you do not need every item to score full marks.
- "I don't know" scores 0 and comes back at the end as a list of things to go and find out.
- The overall score is the average of the 5 area percentages, so every area counts for exactly a fifth whatever it holds.

### Score bands

- **0–25: Licenses, not practices** — You bought the tools. Not much else has changed yet.
- **26–50: Ad hoc** — It works when the right person is in the room.
- **51–75: Standardising** — The practices exist. They are not all enforced yet.
- **76–100: AI-native** — The harness does the work, and it gets better every week.

### Area bands

- **0–25%:** Absent
- **26–50%:** Ad hoc
- **51–75%:** Established
- **76–100%:** Systematic

## The areas

### 01 · Context and specs

What the agent knows about this repo before it writes its first line.

- **Questions:** 6
- **Max points:** 24
- **Book chapters:** 3 (Context Engineering Fundamentals), 5 (Spec-Driven Development), 6 (The SDD Workflow)

### 02 · Verification and review

What has to go green, and who reads the diff, before anything merges.

- **Questions:** 6
- **Max points:** 24
- **Book chapters:** 6 (The SDD Workflow), 8 (Verification and Quality Gates)

### 03 · Goal and guardrails

What you are chasing, what it costs, and what is not allowed to get worse.

- **Questions:** 6
- **Max points:** 24
- **Book chapters:** 3 (Context Engineering Fundamentals), 9 (Agent Orchestration Patterns), 10 (Scaling AI-Native Engineering in Teams)

### 04 · Delegation and autonomy

Which work an agent starts, how far it goes alone, and what it can reach.

- **Questions:** 5
- **Max points:** 20
- **Book chapters:** 4 (Model Context Protocol), 9 (Agent Orchestration Patterns), 11 (AI-Native in Practice)

### 05 · Production and feedback

Once it is live: how you limit the damage, how you see it, what you learn.

- **Questions:** 6
- **Max points:** 24
- **Book chapters:** 8 (Verification and Quality Gates), 10 (Scaling AI-Native Engineering in Teams)

## The questions

### Context and specs

#### 1.1 — Which of these are checked into your repo right now?

In version control. Not on one laptop, not in a Notion page from March.

**Tick everything that is true**

- An AGENTS.md, CLAUDE.md or equivalent _(1)_
- Layered rules files: base, language, framework _(0.75)_
- A specs/ directory with recent entries _(0.75)_
- Custom skills or slash commands for your recurring workflows _(0.75)_
- CLI scripts or MCP servers that reach the tools engineers use _(0.5)_
- A spec template _(0.5)_
- Architecture decision records _(0.5)_
- Code examples the agent is pointed at by name _(0.25)_

**How to find out:** Run: ls; then ls scripts specs .claude .cursor 2>/dev/null. Tick what is really there.

**Book chapters:** 3, 6

#### 1.2 — How is your AGENTS.md structured?

Structure, not length. What an agent finds when it opens the file, and in what order.

**Pick one**

1. We do not have one. _(0 points)_
2. One long file. It was generated once and nobody has opened it since. _(1 points)_
3. Sections for the stack, the commands to run, and where things live. _(2 points)_
4. Sectioned, with the reason behind each rule, and it gets edited when the repo changes. _(4 points)_

**How to find out:** Open it. Count the sections, then the lines that name something only this repo has.

**Further reading:** [How to write a great AGENTS.md: lessons from over 2,500 repositories](https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/)

**Book chapters:** 3

#### 1.3 — Do you use Spec-Driven Development?

A spec is the intent written down before the prompt. A ticket title is not a spec.

**Pick one**

1. No. We prompt and go. _(0 points)_
2. Partially. Somebody writes a high-level spec, then prompts from it. _(1 points)_
3. We write a proper spec for the work that needs one. _(2 points)_
4. We run an SDD framework, and every phase produces the artifact the next one reads. _(4 points)_

**How to find out:** Ask for the last spec somebody wrote. Then ask whether the next task will get one.

**Book chapters:** 5, 7

#### 1.4 — Read your last acceptance criteria. Could a machine tell whether they were met?

**Pick one**

1. We do not write acceptance criteria. _(0 points)_
2. We write them, but as prose. Along the lines of 'it should work properly'. _(1 points)_
3. They are specific enough to turn straight into tests, and they cover the happy path. _(2 points)_
4. Specific enough to test, and they also say what happens when a step fails, when two run at once, how you see it in production, and how to undo it. _(4 points)_

**How to find out:** Open the newest ticket that shipped and try to turn its criteria into test names.

**Book chapters:** 6

#### 1.5 — Two engineers run the same agent on the same repo. Do they get the same behavior?

**Pick one**

1. Everyone brings their own tool, set up their own way. _(0 points)_
2. Mostly the same tool, but everyone has configured it their own way. _(1 points)_
3. The same tool, and its configuration is checked into the repo. _(2 points)_
4. Shared configuration in the repo, plus an agreed way to try something new and report back on it. _(4 points)_

**How to find out:** Compare two teammates' agent config side by side. Count the differences.

**Book chapters:** 10

#### 1.6 — What happens when an agent session runs long?

Compaction is a summary of a summary. The question is whether the state that matters survives on disk.

**Pick one**

1. It runs until it drifts, and we argue with it. _(0 points)_
2. We start a fresh chat and re-explain everything from memory. _(1 points)_
3. The agent writes a handoff file, when somebody remembers to ask for one. _(2 points)_
4. Fresh session per task by default, and the state lives in files the next session reads first. _(4 points)_

**How to find out:** Take your last long task and find the file a fresh session could resume from. Is there one?

**Book chapters:** 3, 9

### Verification and review

#### 2.1 — Which of these run on every pull request, without anyone asking?

Tick it if it runs on its own, whether or not it blocks the merge.

**Tick everything that is true**

- Linter _(0.75)_
- A type check, or a strict compile _(0.75)_
- Unit tests _(0.75)_
- A formatter check _(0.5)_
- Integration or end-to-end tests _(0.5)_
- Secrets scanning _(0.5)_
- Dependency scanning for known vulnerabilities _(0.5)_
- A check on how big the pull request is _(0.5)_
- Any other check that runs on its own, every time _(0.5)_

**How to find out:** Open the checks tab on your newest pull request and read the list.

**Book chapters:** 8

#### 2.2 — Which of your automated checks can actually stop a merge?

**Pick one**

1. None of them. They are advisory. _(0 points)_
2. Some do, and anyone can click straight past them. _(1 points)_
3. The important ones block a merge. People do override them, but rarely. _(2 points)_
4. The important ones block with no way to override, and any new serious finding fails the build. _(4 points)_

**How to find out:** Open your branch protection settings and see which checks are marked required.

**Book chapters:** 6, 8

#### 2.3 — Do you use an LLM to review your own changes, told to go looking for problems?

Told to find what is wrong, not to summarise. Locally or on the pull request, both count.

**Pick one**

1. No. _(0 points)_
2. Sometimes, when somebody remembers to. _(1 points)_
3. Yes, every time. Either locally before we push, or on the pull request. _(2 points)_
4. Yes, and several reviewers each go looking for a different kind of problem. _(4 points)_

**How to find out:** Read the last five review comments an LLM left you. Were any of them worth reading?

**Book chapters:** 8

#### 2.4 — An agent just opened a 900-line pull request. Who reads it?

**Pick one**

1. Whoever opened it. Approving your own work is technically a review. _(0 points)_
2. Whichever teammate has ten free minutes. _(1 points)_
3. Whoever owns that part of the code. _(2 points)_
4. It goes automatically to someone who has actually worked in that code before. _(4 points)_

**How to find out:** Look at who approved your last ten AI-assisted merges, and whether they own that code.

**Book chapters:** 8

#### 2.5 — Which changes can never reach production without a human reading them?

Enforced by a rule, not by good intentions.

**Tick everything that is true**

- Payments, or anything touching money _(0.75)_
- Authentication and authorization _(0.75)_
- Database migrations _(0.75)_
- Anything reading or exporting customer data _(0.75)_
- Infrastructure, or the CI configuration itself _(0.75)_
- Changes to a public API or an event schema _(0.5)_

**How to find out:** Try to merge a one-line change to your riskiest path on a test branch. See what stops you.

**Book chapters:** 8

#### 2.6 — Your tests are green. What proves they actually test anything?

An agent can write tests that walk every line and assert none of it. Coverage cannot tell the difference.

**Pick one**

1. Nothing. Green is green. _(0 points)_
2. The coverage number, and we treat it as a quality score. _(1 points)_
3. Reviewers read the tests, not just the code, and push back on empty assertions. _(2 points)_
4. Mutation testing or similar runs on the paths that matter, so a test that asserts nothing fails the build. _(4 points)_

**How to find out:** Break one line of core logic on a branch and run the suite. Count how many tests notice.

**Book chapters:** 8

### Goal and guardrails

#### 3.1 — What is AI actually supposed to make better in your project, and who signed up to that?

**Pick one**

1. We bought the licenses. That was the plan. _(0 points)_
2. Everyone has their own reason for it, and none of them are written down. _(1 points)_
3. We agreed out loud on what we want out of it, but nobody wrote it down. _(2 points)_
4. We named the outcome, put dates on it at 30, 60 and 90 days, and wrote down what is not allowed to get worse. _(4 points)_

**How to find out:** Ask three teammates separately, in a DM, and compare the three answers you get.

**Book chapters:** 10

#### 3.2 — You made coding faster. Do you know whether coding was the slow part?

**Pick one**

1. We have never looked at where the time actually goes. _(0 points)_
2. We assumed coding was the slow part, so coding is the part we sped up. _(1 points)_
3. We measured one stage of it, usually how long review takes. _(2 points)_
4. We measured the whole path from idea to production, so we know which step the work really waits in. _(4 points)_

**How to find out:** Take last month's ten biggest changes and write down the date at each stage.

**Book chapters:** 10

#### 3.3 — Which of these would an agent find in the repo, without anyone telling it?

In the repo. Not in a wiki, not in a Slack thread, not in the head of whoever is on holiday.

**Tick everything that is true**

- Compliance or regulatory rules _(0.75)_
- Security requirements _(0.75)_
- Uptime, latency or SLO targets _(0.75)_
- Data residency or privacy rules _(0.75)_
- Backward compatibility promises to consumers _(0.75)_
- Cost and budget limits _(0.5)_
- Any other business-related constraints that have an impact on the application _(0.5)_

**How to find out:** Grep the repo for the words compliance, latency, PII and deprecated. See what comes back.

**Book chapters:** 3

#### 3.4 — What stops somebody pasting production data into a chat window this afternoon?

**Pick one**

1. Nothing, and nobody has raised it. _(0 points)_
2. An informal understanding that everyone interprets generously. _(1 points)_
3. There is a written policy. _(2 points)_
4. There is a written policy, and tooling that keeps people inside it. _(4 points)_

**How to find out:** Ask where the rule is written. If three people name three places, there is no rule.

**Book chapters:** 10

#### 3.5 — Could you say what your team's AI tooling cost last month, to the nearest hundred?

**Pick one**

1. No idea. Genuinely. _(0 points)_
2. A bill lands somewhere and somebody glances at it. _(1 points)_
3. We track it, broken down by team. _(2 points)_
4. We track it, there are spending caps, and one person owns the number. _(4 points)_

**How to find out:** Open the billing page. If you cannot find who has access to it, that is the finding.

**Book chapters:** 9

#### 3.6 — Who is in the room when a spec gets written?

The most common spec failure is a constraint one role knew about and another did not, until too late.

**Pick one**

1. Specs, when they exist, are one engineer typing alone. _(0 points)_
2. Engineering writes them. Product finds out at the demo. _(1 points)_
3. Product and engineering write them together. Design and security get a review pass. _(2 points)_
4. Product, design and engineering answer the agent's questions together, and whoever owns the risk reads it before work starts. _(4 points)_

**How to find out:** Open the last spec and count the authors. Then ask design whether they ever saw it.

**Book chapters:** 5, 10

### Delegation and autonomy

#### 4.1 — Which of these does your team hand to an agent on a normal Tuesday?

Routinely. Not the one time it worked and somebody screenshotted it for Slack.

**Tick everything that is true**

- A first pass at a task that is already well specified _(0.75)_
- Writing tests for new code _(0.75)_
- Adding tests to old code that never had any _(0.5)_
- Refactoring _(0.5)_
- Upgrading dependencies _(0.5)_
- Framework or data migrations _(0.5)_
- Reproducing and triaging bugs _(0.5)_
- Reviewing code _(0.5)_

**How to find out:** Scroll your merged pull requests from the last two weeks and tally what an agent started.

**Book chapters:** 9, 11

#### 4.2 — What happened to the last prototype an agent threw together in an afternoon?

**Pick one**

1. We do not really separate prototype code from production code. _(0 points)_
2. We called it a prototype, shipped it anyway, and now everything leans on it. _(1 points)_
3. It stayed on its own branch, and we deleted it when we were done. _(2 points)_
4. We gave it a time limit and a written question to answer, then deleted it and wrote the spec. _(4 points)_

**How to find out:** Search your repo for the branch, then check whether any of it is running in production.

**Book chapters:** 6

#### 4.3 — Is anything working while nobody is watching, overnight or in the background?

**Pick one**

1. No. Somebody watches every run, coffee in hand. _(0 points)_
2. Sometimes, and there are no real limits on what it can do. _(1 points)_
3. Yes, and it opens pull requests rather than merging them. _(2 points)_
4. Yes, on narrow permissions, with no production credentials, a spending cap, and a full log of what it did. _(4 points)_

**How to find out:** Check your CI and agent platform for scheduled runs, and see which token they hold.

**Book chapters:** 10

#### 4.4 — The agent hits two valid approaches and no way to choose. What does it do?

**Pick one**

1. Keeps going. Confidently. _(0 points)_
2. We sometimes remember to tell it to ask us first, in the prompt. _(1 points)_
3. The cases where it has to stop are written into AGENTS.md or the spec template. _(2 points)_
4. They are written down, they name who to go to, and the agent really does stop when it hits one. _(4 points)_

**How to find out:** Grep your AGENTS.md and spec template for the word stop, or ask, or escalate.

**Book chapters:** 6

#### 4.5 — Assume one prompt injection lands tonight. Which of these are already in place?

Every one of them shrinks what a compromised agent can reach, or tells you afterwards.

**Tick everything that is true**

- Every agent tool holds the narrowest token that still works _(0.75)_
- A human approves any tool call that writes something _(0.75)_
- No production credentials anywhere an agent runs _(0.75)_
- Secrets scanning before anything leaves the machine _(0.5)_
- A log of every tool call an agent made _(0.5)_
- Agents run sandboxed, or inside a container _(0.5)_
- A list of which MCP servers and tools are approved _(0.5)_

**How to find out:** List every token your agent can reach, then check what each one is scoped to.

**Book chapters:** 4

### Production and feedback

#### 5.1 — The change was wrong and it is already in production. Which of these limits the damage?

**Tick everything that is true**

- Feature flags that default to off _(0.75)_
- Releasing to a small percentage of users first _(0.75)_
- An automatic rollback when errors start climbing _(0.75)_
- Schema changes done in expand and contract steps _(0.75)_
- Jobs and event consumers that are safe to run twice _(0.75)_
- A written rollback plan for risky changes _(0.5)_

**How to find out:** Ask how the last bad change got undone, and how many minutes it took.

**Book chapters:** 8

#### 5.2 — Once the change is live, can you see what it is doing? Can the agent?

Observability is what you can find out without shipping another deploy to add a log line.

**Pick one**

1. No. We find out when somebody tells us. _(0 points)_
2. Logs, and that is all. _(1 points)_
3. Logs, traces and metrics, with alarms that fire when something is wrong. _(2 points)_
4. All of that, and the agent can query it, so it debugs from real data instead of guessing. _(4 points)_

**How to find out:** Take your last incident and ask how long it took to see where it was going wrong.

**Book chapters:** 6, 8

#### 5.3 — Which of these numbers could you find in less than ten minutes?

Tracked means somebody looks at it and it changes a decision.

**Tick everything that is true**

- Pull request cycle time _(0.75)_
- Change failure rate _(0.75)_
- Escape rate, meaning the bugs that reach production _(0.75)_
- How often you have to revert _(0.75)_
- How often you deploy _(0.5)_
- Human minutes spent on each pull request _(0.75)_

**How to find out:** Try it. Open your dashboard and time how long each number takes to find.

**Book chapters:** 8, 10

#### 5.4 — Your CEO asks how the AI rollout is going. What do you show them?

**Pick one**

1. The share of code written by AI, or how often its suggestions get accepted. _(0 points)_
2. How many seats we bought, and how many of them are active. _(1 points)_
3. A sense of how much faster it all feels. _(2 points)_
4. Cycle time and change failure rate, read side by side. _(4 points)_

**How to find out:** Find the last slide or email anyone sent upward about AI, and read the number on it.

**Book chapters:** 10

#### 5.5 — Something an agent wrote took production down. What exists now that did not exist before?

**Pick one**

1. A fix, and a shared sense of unease. _(0 points)_
2. A postmortem document, and nothing else. _(1 points)_
3. A postmortem, and a regression test that covers exactly that bug. _(2 points)_
4. A postmortem, a regression test, and a rule or a check so nothing of that kind can come back. _(4 points)_

**How to find out:** Pick your last incident and go looking for the test or check it left behind.

**Book chapters:** 8

#### 5.6 — Someone finds a prompt, rule or skill that clearly works. What happens to it?

Chapter 10 calls this trapped knowledge: every engineer relearning the same lessons alone.

**Pick one**

1. It dies in their chat history. _(0 points)_
2. It gets pasted into Slack, then scrolls away. _(1 points)_
3. It usually becomes a shared rule or skill, when someone finds the time. _(2 points)_
4. Promoting it into the shared harness is a habit with an owner, and the whole team gets it next session. _(4 points)_

**How to find out:** Ask when the shared rules or skills last changed, and who changed them. git log answers this.

**Book chapters:** 10

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._