Engineering leadership · Self-assessment

How AI-first is your software engineering organization?

A 5-minute self-assessment for engineering leaders

Assess how your organization uses AI in software delivery: how widely people use it, what they delegate, how they verify the work, and what value they can demonstrate.

Answer for the last 30 days. Describe normal practice across the scope you select, rather than your strongest pilot or your future ambition.

Choose the highest statement that is consistently true. If you cannot verify an answer, select “I don't know.”

AI-first delivery means considering AI execution at the start of suitable tasks, then defining the work, providing context, supervising execution, and reviewing results. Engineers remain accountable for what is delivered.

How this assessment works

This is a directional, self-reported diagnostic. Its thresholds are product design choices, not an independently validated industry benchmark.

Ten equally weighted questions produce a maximum score of 30. “I don't know” counts toward completion but does not receive points. An overall score and profile require all ten answers to be known; a dimension is shown only when all its answers are known.

Score bands: 0–7 AI exploration; 8–15 Local acceleration; 16–23 Managed agentic delivery; 24–30 AI-native delivery.

Managed agentic delivery also requires at least the third statement for adoption (Q1), delegation (Q2), verification (Q5), ownership (Q7), and controls (Q8). AI-native delivery requires at least the third statement on every question and the fourth statement on adoption (Q1), delegation (Q2), and workflow (Q3). The score band and these minimum practices must both be met.

Version 2.0 uses a 0–30 scale. Scores are not comparable with the previous 10–40 assessment.

Which engineering organization are you assessing?

The whole software engineering organization An engineering department or business unit One engineering teamScope name (optional)

Keep this scope consistent throughout. A result for one team describes that team, not the whole organization.

0 of 10 questions answered

1 / 10How widely is AI used in day-to-day engineering work?

Consider a typical working week, rather than license ownership or a demonstration. For a single team, assess how broadly the practice is shared within that team.

AI is not used in normal engineering work within this scope.AI use is occasional, or regular use is limited to isolated individuals.AI is used routinely within some teams or parts of this scope, but is not yet the usual practice across it.AI is a routine part of delivery work for most engineers across this scope.I don't know / I cannot verify this for the selected scope.

2 / 10What do engineers actually delegate to AI?

Examples include implementing a small change, investigating a defect, or preparing a tested refactor. Completing a task does not mean merging or deploying without human approval.

We do not use AI, or use it mainly for explanations and suggestions while engineers perform the work.AI produces individual edits, tests, or drafts; engineers coordinate and carry out the remaining steps.AI completes bounded tasks and checks its work, with engineers intervening when it needs guidance.AI routinely plans and executes multiple steps, checks results, investigates failures, and iterates within agreed boundaries before presenting work for review.I don't know / I cannot verify this for the selected scope.

3 / 10When a suitable delivery task starts, what is the usual working pattern?

“Suitable” means appropriate to the task's risk, available tools, and permitted access. Engineers still use their judgment about when to work manually.

Engineers start and carry out the task manually; AI is rarely considered.Engineers start manually and ask AI for help along the way.Engineers consider delegation to AI upfront for selected types of task, with repeatable ways to supervise and review the work.Across this scope, the normal approach for suitable tasks is to define the objective and acceptance criteria, provide context, delegate execution, and review the result.I don't know / I cannot verify this for the selected scope.

4 / 10How is the context needed by AI maintained and made available?

Context includes requirements, repository conventions, architecture constraints, and reliable instructions for building and checking the software.

There is no established way to provide relevant project context; it is absent or assembled from scratch.Individuals copy useful instructions, files, or snippets into their own sessions.Teams maintain reusable project instructions, build and test commands, and relevant documentation that AI can access within defined boundaries.This context is versioned, maintained by identified owners, and connected to repeatable workflows; outdated or missing context is corrected as part of delivery work.I don't know / I cannot verify this for the selected scope.

5 / 10What evidence is required before AI-produced changes are accepted?

Depending on the change, this can include integration, security, performance, regression, or replay checks. A convincing explanation from the generating agent is not sufficient evidence by itself.

Acceptance depends mainly on ad hoc inspection, with little repeatable verification.Some automated checks run, but important gaps or unreliable results often require case-by-case judgment.Changes are assessed against explicit acceptance criteria, reliable automated checks appropriate to the task, and human review before integration.Verification also targets failure modes that ordinary checks can miss, uses evidence beyond the generating agent's own assessment, and blocks acceptance when required checks fail.I don't know / I cannot verify this for the selected scope.

6 / 10What changes after an AI workflow produces a poor result?

Assess your established response to failures. If no failure occurred in the last 30 days, use a documented example that still reflects current practice; do not assume the strongest answer because nothing went wrong.

The immediate output is corrected or discarded, with no repeatable follow-up.Individuals adjust their prompts or working habits, but the lesson usually stays local.Teams update shared instructions, context, or checks so the same lesson benefits later tasks.Teams examine recurring failures, improve task boundaries and recovery steps, and check that the changes reduce recurrence across relevant workflows.I don't know / I cannot verify this for the selected scope.

7 / 10Who is accountable for improving human–AI delivery workflows?

This can be an existing leader or team responsibility. Assess whether ownership works in practice, not whether a formal committee exists.

No one is explicitly accountable.Interested engineers improve their own practices when time permits.A named engineering leader or team owner has allocated time to improve shared workflows and reviews progress.Ownership is part of normal engineering management, with sustained time, access to suitable tools, and accountability for adoption, quality, and results.I don't know / I cannot verify this for the selected scope.

8 / 10How clearly are the agent's permissions and human approval points defined?

Consider source code, credentials, external services, merge rights, and deployment rights where relevant. Greater autonomy is appropriate only when the task and controls support it.

Permissions, approval points, and responsibility for agent actions are unclear.Individuals apply their own precautions, with few shared rules.Recurring workflows have defined access boundaries, human approval points, and a clear way to stop or recover from unwanted actions.These controls are applied consistently, adjusted to task risk, and checked in practice; actions can be traced and exceptions have an accountable owner.I don't know / I cannot verify this for the selected scope.

9 / 10How do engineers learn and share effective AI working practices?

Practical learning includes defining tasks, supplying context, supervising agents, evaluating results, and knowing when to intervene.

There is no organized support; engineers are left to figure it out themselves.Some engineers share tips or attend occasional demonstrations, but practices remain largely individual.Engineers have practical coaching, reusable examples, and shared guidance for common delivery tasks.Hands-on learning and review of working practices are recurring activities; proven approaches are maintained, reused, and included in onboarding.I don't know / I cannot verify this for the selected scope.

10 / 10What can you demonstrate about the value of AI in delivery?

Useful measures include lead time, review effort, rework, defects, and cost per accepted change. Token volume, generated code, and license counts alone do not demonstrate value.

We do not have evidence of delivery improvements.We have examples of useful output or perceived time savings, but no consistent comparison with earlier performance.We compare recurring workflows with an explicit baseline using delivery time and quality, including human review and rework.We use these comparisons, including total delivery cost and AI spend, to decide what to scale, change, or stop, and have demonstrated improvements that hold up beyond a single example.I don't know / I cannot verify this for the selected scope.

Your next step

Optional. These answers do not affect your score or profile.

What is the most useful improvement you want to achieve in the next 90 days?Choose a priority (optional)Establish a first repeatable AI workflowMove from suggestions to delegating complete tasksImprove verification and trust in resultsImprove permissions, approvals, and recoveryDevelop engineers' practical skills and shared practicesScale working practices across the organizationDemonstrate delivery value and economicsAnother priorityWhat concrete workflow would you use to make progress?

Describe the task, who would own it, and what success would look like. Avoid confidential project details.

Your answers stay in this page. No account or contact information is required.