Self-assessment · 26 questions · about ten minutes

AI engineering readiness checklist

Answer yes or no for your engineering organization as it works today, not as it is planned. Each yes should be something you could show a colleague.

A self-assessment, not an audit or a certification. A readiness assessment answers the same questions with evidence from your own repositories. Your answers stay in this page; nothing is saved or sent to us.

01Direction and ownership

A named executive owns AI-assisted engineering, with a budget and a written goal.Without an owner, every team runs its own experiment and nobody can stop one.
Engineers know which AI tools are approved, for what work, and who decides.Unapproved tools are where code and data leave your control.
You know what you spend each month on AI tools and model usage, by team.Usage-based pricing grows with adoption; licences alone no longer show the cost.
The goal is stated in delivery outcomes, not in adoption or licence counts.Usage measures activity. The board will ask about lead time, failures and cost.

02Baseline and measurement

You recorded a delivery baseline before AI tools spread: lead time, deployment frequency, change failure rate and time to restore.Without a starting point, any improvement is an anecdote.
You can see how many AI-assisted changes wait for review, and for how long.When agents write more than people can review, the queue is the new constraint.
You track rework on AI-assisted changes: reverted, reopened or rewritten.A fast first draft that is rewritten twice is not faster.
Someone reports these measures to leadership on a fixed schedule.A programme earns its next budget with evidence, not enthusiasm.

03Workflows in your own tools

AI-assisted work runs in your existing repositories, CI and ticketing, where everyone can see it.Work done in side tools leaves no trail and no shared picture.
Agents start from your architecture decisions, coding standards and the areas they must not touch.Two agents can both pass tests and still pull the design in different directions.
Each piece of agent work has a defined start and end: a ticket in, a reviewable change out.Open-ended agent sessions are hard to review, cost and stop.
Agent retries and run time have limits, and a failure goes to a named person.An unbounded retry loop is a cost and a risk, not persistence.

04Review and quality

AI-written changes reach production only through the same review and CI as any other change, or stricter.A second path to production is a second set of rules nobody wrote down.
Test results come from your CI, not from the agent's own report.“The agent said the tests passed” is a claim, not evidence.
Changes in high-risk areas, such as security, payments, personal data and infrastructure, need a person's approval that cannot be skipped.Autonomy should depend on what is at stake, not on who opened the change.
Reviewers have been trained to review AI-written code.Plausible code fails differently from careless code, and reviewing it is a skill.
Changes to prompts, agent instructions or models are tested against a fixed set of cases before they roll out.A new model or prompt can quietly change results across every team at once.

05Access, policy and cost controls

A written AI usage policy covers source code, customer data and confidential information.People follow the rule they can find. Prompts are not a policy.
Each agent has its own identity and only the access it needs, never a person's personal token.When an agent acts as a person, you cannot tell afterwards who did what.
Secrets and production credentials never appear in prompts or agent context.Anything in context can end up in a log, a transcript or a provider's systems.
Spending limits are set per team or workflow, with an alert before a limit is reached.A budget found after the invoice is not a control.
For any change, you can show what wrote it, who approved it, and which checks ran.Six months later, this is what an auditor, a customer or an incident review will ask.

06People and practice

Engineers have had hands-on training on your own codebase, not only vendor demos.Habits form on real work. Demos show the tool, not your system.
Engineering managers know how to plan and review work done by people and agents together.The first agent is a tool. The fiftieth is an organization-design question.
Each team has someone who collects what works and shares it with the others.Without it, every team repeats every other team's mistakes.
Playbooks and standards for AI-assisted work are written down and kept current.Tools and models change monthly. Unwritten practice drifts with them.

Your score

0 of 26

0–9 yes · you are here
Start with direction and a baseline
Most controls are missing or informal. Agree an owner, a goal and a baseline before rolling out further.
Usually starts with: Readiness assessment
10–18 yes
Connect the pieces
Several controls exist, but not as one operating model. Prove it with a few teams on real work before scaling.
Usually starts with: AI Engineering Transformation
19–26 yes
Scale what works
The basics are in place. The work now is extending them to more teams and keeping them current.
Usually starts with: Scale and operate

Talk about a readiness assessment Request an executive briefing