AI adoption checklist for organizations

AI is already in the team. The question is where you are now and what to do next. This checklist is based on real adoption work: mistakes that repeat from company to company and practices that consistently work.

Before using the checklist, take the diagnostic →. It will show which zones are burning red in your own team.

Four phases

Phase 1. Sense-making

Before anyone gets access to an AI tool.

What to check

• The goal is framed through work. “Reduce Lead Time by 20%,” “increase automated test coverage,” “free seniors from routine tasks.” The goal is tied to work, not to the fact of using AI.
• The team shares the goal. If three people give three different answers to “why,” the “Purpose and metrics” zone is burning. Go back and agree.
• Metrics are layered, not reduced to one number. Four metric layers, from intermediate to final:
  • AI work habit — how many people actually work with the tools (MAU, W50: the share of people using AI on 50%+ of workdays)
  • Delivery — whether delivery metrics changed: Lead Time, Throughput, review time, number of bugs after release
  • Guardrails — whether you are breaking things on the way: Defect Rate, incidents involving AI, data security
  • ROI — business effect: shorter feature delivery time, lower development cost, people reallocated to more complex work
• AI work habit is an intermediate signal. The result is delivery change. Chats are tourism: people entered, looked around, and left. No artifacts appear in the work. Rising activity without delivery change is adoption theater.
• A starting use case is selected. Choose one or two specific use cases: writing tests, code review, documentation generation, legacy refactoring.

What does not work

• Email campaigns and webinars — knowledge does not transfer, expertise does not grow
• Tool catalogs — nobody opens them on their own
• “You must use it” — resistance and status quo
• AI work habit as the only success metric

Red flags

• Different teams name different goals, and nobody notices the difference
• 80% of people work with AI, but Lead Time does not move — adoption theater
• “Leadership told us to adopt it” with no further specifics
• There are no effect metrics, only user counts

What to do

Bring the team together and answer three questions in writing:

1. Which work metric do we want to change?
2. How will we know AI produced a result, not merely that it was “used”?
3. What will we stop doing when AI takes over part of the work?

Phase 2. Preparation

You have a goal. Now make sure the tool becomes a habit, not a workaround.

What to check

• The tool sees the work context. The assistant is connected to the repository, knows the architecture, and is integrated into the IDE and CI. If an engineer copies files into a chat manually, the environment is not ready.
• Fast setup. People leave before the first result not because AI is complex. The reason is simpler: the tool is impossible to install. One terminal command — and it works.
• Rules of use are written down. What can be sent to an AI service, what cannot, and what is under compliance. Use a concrete list instead of generic warnings: production configs — no; anonymized logs — yes; personal data — no.
• Use cases are tested on the team’s real tasks. Test on the team’s own work. If a demo uses somebody else’s example and nobody tries their own, people will say “we are different” and leave.

Red flags

• Shadow tools: part of the team already uses personal AI services outside the official path
• Production configs go into a public service because it is “faster”
• “They said no, but it is unclear what exactly is forbidden” means people either fear everything or ignore the ban
• The tool exists, but nobody uses it because it is too inconvenient

What to do

1. Run a DevEx audit: walk through one real scenario as an engineer and measure how many unnecessary steps it takes.
2. Write one page of rules: what is allowed, what is forbidden, what is unclear, and who decides.
3. Choose one pilot team. Not two, not three — one.

Phase 3. Launch

The pilot is working. Now make sure AI use does not create new problems.

What to check

• Responsibility is marked. The person who assigns work to the assistant owns the result. A pull request includes short context: what was asked, what constraints were given, which files the agent saw. In review, “AI wrote it” is not an excuse.
• Roles are revised explicitly. Who now reviews AI-generated code? Who checks output for security? Who decides “this use case can be delegated, this one cannot”? Write it down.
• Anxiety about role and growth is discussed. A senior who forbids juniors to use AI out of concern for their growth is a symptom. The team needs a conversation: what does growth look like now, if an agent generates part of the code?
• The people side is handled systematically. Many transformations fail because they do not work with people. A systematic change approach raises the odds of success. ADKAR gives a simple map for working with people at each stage of change.

What works in practice

• Workshops on the team’s real tasks. A real ticket from the tracker. Small groups: one expert for two or three people. The participant drives; the expert navigates. In practice, participants who learn this way keep using the tool months later.
• Managers are a precondition for transformation. Team leaders must be able to work with AI themselves. Their involvement multiplies AI use in the team. Without them, systematic change does not start.
• The first experience on your own task is critical. People who try agents on a real work task keep using them. People who try them on someone else’s example drop off.

Red flags

• “AI wrote it” appears in review as an excuse
• Nobody knows who is responsible for the AI-generated result
• Seniors sabotage AI use by juniors
• The team uses AI, but roles have not changed

What to do

1. AI Working Agreement (template in the AI Resistance Map): one document per team.
2. A conversation about roles: “what do we stop doing manually, and what do we start validating?”
3. A workshop on real tasks.
4. A pilot retrospective before scaling.

Phase 4. Scaling

The pilot worked. Now make sure acceleration at the input does not create a bottleneck at the output.

What to check

• The whole flow is measured. AI accelerated coding. What happened to review, QA, release, and support? If there are many more PRs and the same number of reviewers, there is no acceleration. The bottleneck moved.
• All roles participate in agentization. If developers actively use AI but testers, DevOps, and analysts do not, Lead Time will not move. System speed equals the speed of the slowest element.
• Agentization of roles. Each specialty automates its own part of the work. QA teaches agents to write test cases and traceability matrices. Analysts generate specifications. DevOps configures pipelines.
• The first team’s experience is packaged. The second team receives a ready package: working prompts, an AI Working Agreement template, review checks, and examples from real tasks. It launches a pilot in weeks instead of months.
• The adoption format matches the team’s context.

Three problems of AI-first teams (prevention checklist)

• Cognitive load — end-to-end responsibility for the whole SDLC lands on one person. Solution: digitize the domain — guardrails and context are available so the agent can fetch what it needs at the right moment.
• Validation — agents generate faster than humans can verify. Solution: route only the most important parts to humans and train the agent to check its own result.
• Bottleneck — the business expert is needed everywhere at once. Solution: the expert becomes the steward of the domain.

The core shift: the specialist no longer just does the work — the specialist holds the standard. People are quality gatekeepers at their stages. AI provides additional hands.

Red flags

• There are more PRs, but time to release did not shrink or grew
• Review quality dropped because reviewers miss errors under volume pressure
• Each new team “reinvents AI” from scratch
• AI activity grows while delivery metrics stay flat
• Only developers accelerated; other specialties are not in the loop

What to do

1. Value stream mapping with AI: draw the flow, mark where AI accelerated it, and where the bottleneck appeared.
2. Package for the next team: working prompts, AI Working Agreement template, checklist of review checks, task examples.
3. Limit WIP in review if the volume of AI-generated code grows.
4. Start role agentization with the specialty that is falling furthest behind.

How to use the checklist

1. Take the diagnostic — 12 questions, 5 minutes.
2. See which zones are burning red.
3. Find your phase in the checklist and go through the control points.
4. Move 1–3 red zones into the AI Resistance Map and draft an AI Working Agreement.

This checklist is a living document. If something worked for you that is not here, write to me. I will add it.