Diagnostic: how your team works with AI

Twelve questions, six pairs. In each pair, the first question describes a real situation. The second checks the same zone from another angle.

For primary questions, Often or This is our norm is a red signal. For control questions, Not us or a weak maturity answer is usually the red signal.

If the primary question is “often” and the control question is “not us,” the problem is probably there. The team may not see it yet or may not be ready to admit it.

For each situation, choose:

• Not us — this does not happen here
• Sometimes — it appears occasionally, but it is not systematic
• Often — a recognizable pattern
• This is our norm — constant pain for everyone

1. Purpose and metrics

1a. When someone asks why we are adopting AI, the team gives three different answers. The AI adoption dashboard looks good, but Lead Time, quality, and working practices have not changed.

• Not us
• Sometimes
• Often
• This is our norm

1b. Beyond “how many people use AI,” we track effect metrics: whether Lead Time, review time, the number of post-release bugs, or other delivery outcomes have changed.

• Not us (we do not have those metrics)
• Sometimes (we measured somewhere, but not systematically)
• Often (we track them, but not across all teams)
• This is our norm (effect metrics are part of regular monitoring)

2. Role and growth anxiety

2a. The developer who knows a module best started taking longer to review AI-generated code and more often asks people to rewrite it “properly.” A senior engineer forbids juniors to use AI: “How will they learn otherwise?”

• Not us
• Sometimes
• Often
• This is our norm

2b. We have discussed with the team how their roles are changing, what they stop doing manually, what they start validating, and what growth looks like now.

• Not us (we have not discussed it)
• Sometimes (we talked about it once)
• Often (we discuss it regularly)
• This is our norm (roles are revised in writing, and people know their new boundaries)

3. Capability and tool quality

3a. People tried AI once or twice, got a strange result, said “it hallucinates,” and stopped. They did not test it on their own work or rewrite prompts. Or the opposite: the tool is objectively weak — it takes an hour to explain the task, and it is easier to write the result yourself.

• Not us
• Sometimes
• Often
• This is our norm

3b. We have concrete AI use cases tested on the team’s real tasks: writing tests, review, refactoring, documentation generation. Not “use it however you want,” but “it works for these tasks.”

• Not us (we have no use cases)
• Sometimes (someone developed their own approach)
• Often (we have shared use cases, but not everyone uses them)
• This is our norm (use cases are documented, tested, and regularly updated)

4. Environment and rules

4a. The corporate assistant cannot see the repository code and does not know the architecture. To get help, people copy files manually. Or: someone uploads production configs into a public service because it is “faster,” while someone else is afraid to send anything because “they said we cannot, but it is unclear what exactly is forbidden.”

• Not us
• Sometimes
• Often
• This is our norm

4b. We have written AI-use rules: which data can be sent, which data cannot, which services are approved, and who makes the decision in unclear cases.

• Not us (we have no rules)
• Sometimes (we have a verbal agreement)
• Often (rules exist, but not everyone knows them)
• This is our norm (rules are written down, known, and followed)

5. Responsibility

5a. In review, people say: “AI wrote this; I only checked it.” A bug becomes “not my bug, AI did it.” Nobody knows who is responsible for the result generated by an assistant.

• Not us
• Sometimes
• Often
• This is our norm

5b. We have an explicit agreement: the person who assigned the task to the assistant owns the result. Pull requests include context: what was asked, what constraints were given, and which files the agent saw.

• Not us (we have no agreement)
• Sometimes (some people do this, but it is not a rule)
• Often (the rule exists, but is not always followed)
• This is our norm (the rule works, and review does not turn into a defense)

6. Flow

6a. There are noticeably more PRs from agents. Reviewers cannot keep up with the volume. Review quality has dropped, and time from commit to release has increased. Acceleration at the coding stage did not shorten the overall flow.

• Not us
• Sometimes
• Often
• This is our norm

6b. We have measured end-to-end Lead Time after adopting AI — from idea to production, not only the development stage — and know whether it changed.

• Not us (we have not measured it)
• Sometimes (we looked once)
• Often (we measure it, but not regularly)
• This is our norm (end-to-end Lead Time is a regular metric, and we see the trend)

What to do next

Look at the pairs. Where the primary question is in “often” or “this is our norm” and the control question shows weak maturity — usually “not us” or “sometimes” — the zone is really burning.

Where the primary answer is “often” and the control answer is “not us,” the zone is burning. The team is not acknowledging it yet. Start the conversation there.

Next step:

• AI Adoption Checklist → — a step-by-step framework for what to do at each stage
• AI Resistance Map → — a working template: transfer red zones into team agreements

Facilitator table: