AI Resistance Map
A working template for a team. It helps turn AI-resistance diagnostic results into a draft AI Working Agreement.
The map does not ask you to collect quotes or label people. The entry point is different: the diagnostic highlights gaps in the work system, and the map helps you understand how those gaps show up in work and which agreement the team needs to make explicit.
Where to start
First, take the AI Resistance Diagnostic →. Twelve questions, five minutes. The questionnaire shows where gaps have appeared in the work system.
Then check the AI Adoption Checklist →. It helps you understand which adoption stage is weak and which action to choose first.
Once the red zones are clear, transfer 1–3 of them into the map. For each zone, describe how it appears in work, the risk it creates, and the next team agreement.
Working template
Main field
| What the diagnostic highlighted | How it shows up in work | Who is affected | Risk | Next agreement |
|---|---|---|---|---|
How to fill the map
- Take 1–3 red zones from the diagnostic.
- For each zone, describe the observable work pattern: expectations, workarounds, review conflicts, weak quality, or unclear responsibility.
- Name who is affected: the team, reviewers, leads, platform, security, business, or adjacent teams.
- Write the risk to delivery, quality, responsibility, or people development.
- Formulate one agreement the team can test in the next sprint.
Individual remarks from the team can be used as clues if they help recognize the source of the problem. The map itself does not need to be filled with quotes.
Reference: six sources of resistance
| # | Source | What is broken | How it may sound |
|---|---|---|---|
| 1 | Purpose and metrics | It is unclear which work problem AI is supposed to solve. Activity grows while delivery metrics stay flat. | “We are being forced to use AI, but nobody can explain why.” |
| 2 | Role and growth anxiety | People worry about their role, autonomy, expertise, and learning path. | “If AI writes the code, how will juniors learn to think?” |
| 3 | Capability and tool quality | There is not enough practice on real tasks, or the tool is weak, slow, or blind to context. | “We tried it. It still writes garbage.” |
| 4 | Environment and rules | The official path is inconvenient: missing access, missing context, unclear data rules, and unclear escalation. | “It is easier to open a personal account than go through the official process.” |
| 5 | Responsibility | It is unclear who owns the AI-generated result and answers for the consequences. | “I will not be responsible for code written by an agent.” |
| 6 | Flow | AI accelerated a local step, and the queue moved to review, QA, release, or business validation. | “Developers became faster, but releases still wait for approvals.” |
Reference: five positions
| Position | In short |
|---|---|
| Supporter | Experiments and helps others |
| Productive skeptic | Raises real risks: quality, responsibility, safety |
| Avoider | Quietly returns to the old process |
| Ritual adopter | Formally uses AI for reporting |
| Active blocker or saboteur | Breaks agreements, hides information, blocks experiments |
Important distinction: a productive skeptic protects the work system — they need criteria and experiments. A saboteur breaks agreements in bad faith — they need explicit expectations and a boundary.
How to choose the action
The source of resistance tells you which part of the system to fix. The person’s position tells you how to hold the conversation and what role to give them.
| If this zone is burning | What to do first | What should exist afterward |
|---|---|---|
| Purpose and metrics | Formulate the working goal of the pilot: delivery, quality, support, or speed of hypothesis validation. | An effect metric before launch and an agreement that activity metrics are only early signals. |
| Role and growth anxiety | Name how the role changes and where professional judgment remains. | A learning path: which tasks a person does manually first, where AI enters, and who checks judgment quality. |
| Capability and tool quality | Separate the skill gap from tool weakness; run practice on real tasks. | Role-based scenarios, tool-quality criteria, and a team-owned blocker list. |
| Environment and rules | Build a safe official path: approved tools, access, context, data rules, escalation. | Short rules for AI work: what is allowed, what is forbidden, what requires approval. |
| Responsibility | Introduce result ownership: whoever gives the task to AI is responsible for the outcome. | Team agreements on review, final validation, and high-risk actions. |
| Flow | Draw the task path with AI and find where the queue moved. | WIP limits, review capacity, definition of done, and end-to-end delivery metrics. |
| If you are dealing with | How to work | Output to create |
|---|---|---|
| Supporter | Give them the role of champion and keeper of good practices. | Demos on real tasks, an example of a safe use case, contribution to team rules. |
| Productive skeptic | Turn objections into quality criteria and testable experiments. | Review checklist, failure modes, red-team scenarios, or acceptance criteria. |
| Avoider | Give them a small safe scenario with a mentor nearby. | First real experience without public pressure and permission to say where the tool did not help. |
| Ritual adopter | Shift the conversation from the fact of AI use to the work result and quality checks. | Clarity on which part of the task actually changed and what result it produced. |
| Active blocker or saboteur | Set expectations, boundaries, and consequences. | A management decision instead of endless training and terminology debates. |
Example intersection: if responsibility is burning, it can help to ask a productive skeptic to build a risk checklist, ask a supporter to document an example of a good PR with AI context, and give an avoider a first AI-assisted task next to a mentor. Sabotage in the same zone requires a clear ownership rule and a management boundary.
Template: AI Working Agreement
AI Working Agreement — team _______________
Date: _______________
What we delegate to AI:
Where a human must remain in the loop:
How review of AI-generated output works:
- The pull request includes: ________________________________
- The reviewer checks: ________________________________
- The person responsible for the result: ________________________________
Who owns the result and is responsible for the consequences:
Which data and contexts are allowed:
Which data and contexts are forbidden:
Required checks before production:
AI effect metrics, separate from usage frequency:
First agreement for the next sprint:
How we will know it works:
The template and the AI Working Agreement are living documents. The team returns to them at the next retrospective, in a month, and whenever the tool changes.
AI Adoption Checklist → — a step-by-step framework for what to do at each stage so these gaps do not appear.