Adopcja w zespole — przekroczenie 70% odblokowuje compounding

CTO Scorecard P1 — Adopcja i wydatki

“Jaki procent Twojego zespołu inżynierskiego aktywnie używa narzędzi AI do kodowania (>3×/tydzień)?”

Odpowiedź na maksymalny wynik: “>70% z monitorowaniem osób nieadoptujących i widocznym ROI.”

Poniżej 30% adopcji płacisz overhead bez dźwigni. Powyżej 70% zaczynają się pojawiać efekty compoundingu — wspólne prompty, wspólne konfiguracje MCP, wewnętrzni championi, wspólny język i prędkość per inżynier, która wreszcie uzasadnia koszt licencji. Środkowy pas to najdroższe miejsce do zamieszkania: pełna cena, częściowy benefit, brak pętli uczenia się na poziomie organizacji.

Ta strona to długa wersja pierwszego pytania CTO Scorecard. Wyjaśnia, jak mierzyć aktywne użycie, jak wyglądają benchmarki w 2026, dlaczego <30% łamie matematykę ROI, jak rzeczywiście wygląda compounding powyżej 70% i podaje konkretny plan, jak przesunąć swoją liczbę.

Dlaczego to ważne w 2026

Era “czy pozwolić inżynierom używać narzędzi AI” skończyła się gdzieś w 2024. Pytanie 2026 nie dotyczy już zgody — dotyczy aktywnej stawki. Według aktualnych branżowych badań 73% zespołów inżynierskich używa dziś codziennie narzędzi AI do kodowania, wobec 18% w 2024, a około 85% deweloperów używa ich regularnie w kodowaniu, debugowaniu i review. Rynek poszedł dalej, z adopcji-jako-polityki w adopcję-jako-egzekucję.

Zmieniła się ekonomika. Cena per licencja dla Cursora, Claude Code, GitHub Copilota i podobnych narzędzi jest na tyle wysoka, że niewykorzystane miejsce to mierzalna pozycja w budżecie. Zespół 50 inżynierów wydający 20–40 USD per licencja miesięcznie traci 12 000–24 000 USD rocznie za każde 10% nieaktywnych miejsc. To marnotrawstwo nakłada się na koszt onboardingu, dryf konfiguracji i koszt alternatywny inżynierów, którzy mogli zostać doprowadzeni do biegłości, ale nie zostali.

Co ważniejsze, różnica produktywności między nieadoptującymi a biegłymi użytkownikami się pogłębiła. Deweloperzy używający asystentów AI w 2026 produkują o około 12–15% więcej kodu i raportują około 21% wzrostu produktywności. Ponad 46% nowo pisanego kodu jest AI-assisted, prognoza do końca 2026 to 60%. Zespół, w którym jedna połowa dowozi w tempie 1.0x, a druga w tempie 1.21x ma problem koordynacyjny na wierzchu problemu wydajnościowego — kolejki review, dyskusje projektowe i obsługa incydentów zaczynają działać na różnych skalach czasowych.

Pytanie CTO w 2026 nie brzmi “czy adoptujemy?”, tylko “czy adoptujemy wystarczająco głęboko, żeby zebrać compounding?”.

Jak naprawdę wygląda maksymalny wynik

Maksymalny wynik na tym pytaniu ma trzy części, a brak którejkolwiek z nich zrzuca cię o poziom niżej:

1. >70% inżynierów używających narzędzi AI więcej niż 3 razy w tygodniu, mierzone z telemetrii narzędzia (nie z ankiety).
2. Monitorowanie nieadoptujących ze ścieżką coachingową, nie mandatem — wiesz, kto jest poniżej progu i wiesz dlaczego.
3. Widoczny ROI — leadership potrafi wskazać dwa-trzy konkretne wskaźniki wyjścia (przepustowość PR, cycle time, częstotliwość deploymentów, czas od ticketa do fixa), których krzywa się poruszyła od kiedy adopcja przekroczyła 50%.

Zespoły, które trafiają w trzy z trzech, wyglądają inaczej od środka. Ich .cursor/rules, CLAUDE.md i wspólne rejestry MCP są commitowane do repo, reviewowane w PR-ach i traktowane jak kod produkcyjny. Inżynierowie parują nad promptami tak, jak kiedyś parowali nad trudnymi regexami. Nowi pracownicy nadrabiają tempo, czytając prompty zespołu na równi z kodem zespołu. Decyzje narzędziowe — który model, które IDE, które MCP — są dyskutowane w design docach, nie na Slacku.

Przeciwny wzorzec — duża liczba licencji, niskie aktywne użycie, brak widoczności — jest dużo częstszy i dużo droższy. Tam utknęła większość organizacji inżynierskich.

Aktualny krajobraz (zweryfikowany przez web search)

Jak mierzyć aktywne użycie (Cursor Admin API, Anthropic Console seat usage)

Ankieta jest niewiarygodna. Inżynierowie konsekwentnie zawyżają deklarowane użycie, bo społeczny koszt przyznania się do nieużywania wydaje się większy niż jest. Mierz po stronie narzędzia.

Cursor udostępnia telemetrię administracyjną przez Cursor Admin API w planach Team i Business. Można wyciągnąć dane per użytkownik: liczbę wysłanych zapytań, zaakceptowanych linii, dni aktywnych w ostatnim tygodniu. Właściwa metryka dla tego pytania scorecardu to dni aktywne w ostatnich 7 dniach z co najmniej jedną zaakceptowaną sugestią lub sesją czatu. Trzy lub więcej takich dni kwalifikuje jako aktywny.

Claude Code seat usage jest widoczny w Anthropic Console w sekcji organizacji. Widać tam wydatek tokenów per workspace, a z eksportem usage na poziomie organizacji — aktywność per użytkownik. Obowiązuje ten sam próg: trzy lub więcej dni w tygodniu z prawdziwą sesją Claude Code.

GitHub Copilot dostarcza Copilot Metrics API i dashboard Copilot Usage, które pokazują aktywność per użytkownik, akceptację sugestii i użycie czatu. Traktuj dni z akceptacją sugestii jako sygnał aktywności.

OpenAI Codex CLI nie ma na ten moment dedykowanego dashboardu — śledź użycie przez stronę usage platformy i przez audyt logów w historii powłoki lub rozwiązaniu nagrywającym terminal, jeśli takie masz.

Wybierz jedno kanoniczne narzędzie per inżynier (większość zespołów konwerguje na jedno narzędzie z IDE plus jedno terminalowe) i pobieraj tygodniowo. Postaw mały dashboard — wystarczy Google Sheet odświeżany skryptem — z listą każdego inżyniera, jego dni aktywnych i flagą “poniżej progu w tym tygodniu”.

Benchmarki branżowe 2026 (stawki adopcji wg wielkości firmy)

Punkty danych z ankiet branżowych 2026 dają przybliżony obraz, gdzie znajdują się zespoły:

• Codzienne aktywne użycie we wszystkich zespołach inżynierskich: ~73% na początku 2026, wobec 18% w 2024.
• Jakiekolwiek użycie (tygodniowe lub częstsze): ~85% deweloperów.
• Organizacje aktywnie zachęcające do adopcji: tylko 30–40%. Kolejne 29–49% pozwala, ale nie promuje. Ta dziura to dokładnie miejsce, w którym żyje to pytanie scorecardu.
• Udział kodu AI w dojrzałych workflowach: 30–70% commitowanego kodu w organizacjach o wysokiej adopcji; 46% w szerszym rynku.

Cięcia po wielkości firmy mają znaczenie. Startupy poniżej 50 inżynierów są zazwyczaj albo bardzo wysoko (>80%), albo bardzo nisko (<30%) — rozkład jest bimodalny, bo dominuje kultura, a małe zespoły idą albo all-in, albo wcale. Średnie firmy (50–500 inżynierów) skupiają się wokół 50–60% — szeroka adopcja, ale nierówna głębokość, często blokowana przez procurement, review bezpieczeństwa lub jednego sceptycznego staff engineera. Korporacje powyżej 500 inżynierów najmocniej się różnią: oficjalnie nisko, nieoficjalnie znacznie wyżej, ze znaczącym shadow IT w postaci kont prywatnych.

Jeśli jesteś CTO benchmarkującym wobec rynku, uczciwe porównanie jest do zespołów podobnej wielkości i podobnej charakterystyki kodu. Zespół 200-osobowy na monolicie z 40% adopcji to coś innego niż zespół 200-osobowy na mikroserwisach z 40% adopcji — koszt bezczynności jest wyższy tam, gdzie każdy serwis jest na tyle mały, że da się go wygenerować przez AI od początku do końca.

Dlaczego <30% zabija matematykę ROI

ROI z narzędzi AI do kodowania opiera się na trzech pętlach:

1. Czas oszczędzony per inżynier — bezpośrednia produktywność, zbierana przez aktywnego użytkownika.
2. Dzielenie wiedzy na poziomie zespołu — prompty, pliki rules, konfiguracje MCP, wewnętrzne szablony, które się rozprzestrzeniają.
3. Przeprojektowanie workflow — code review, on-call, obsługa incydentów i onboarding zmieniają się tak, by zakładać AI w pętli.

Pierwsza pętla spłaca się przy pojedynczym użytkowniku. Druga i trzecia spłacają się dopiero wtedy, kiedy adopcja przekracza próg na tyle wysoki, że inżynierowie mogą założyć, że ich koledzy też używają narzędzi.

Poniżej 30% adopcji dostajesz tylko pętlę jeden. Płacisz pełną cenę licencji za wszystkich (włącznie z nieużywającymi), dostajesz marginalne zyski wydajnościowe od aktywnej mniejszości i nigdy nie widzisz zmian na poziomie workflow, bo większość zespołu tak nie pracuje. PR-y od AI-heavy inżynierów wyglądają nie-w-rytmie z PR-ami od nieużywających. Pair programming staje się trudniejszy, nie łatwiejszy. Kolejki review się przekrzywiają. Dokumentacja onboardingu zostaje w pre-AI świecie, bo piszą ją pre-AI użytkownicy.

Matematyka: przy 30% aktywnej stawce wydajesz 100% kosztu licencji, żeby dostać 30% benefitu per inżynier i 0% benefitów sieciowych. Efektywny ROI to mniej więcej 30% tego, ile mógłby być. Przy typowej cenie 25 USD/licencja/miesiąc i typowej różnicy produktywności wartej około 1 500 USD/inżynier/miesiąc w pełnokosztowym wynagrodzeniu, zespół 50-osobowy zostawia 52 500 USD/miesiąc na stole w porównaniu z zespołem na poziomie 70%+.

To podłoga. Sufit jest gorszy: niska adopcja zazwyczaj oznacza, że inżynierowie, którzy poprowadziliby zmianę workflow, odchodzą do organizacji, które już zmieniły. Koszt rekrutacji seniorów komfortowych z AI-native workflowami jest dziś widocznie wyższy niż dla seniorów, którzy nie są, i ta różnica się powiększa.

Compounding powyżej 70% (wspólne umiejętności, wspólne MCP, efekty sieciowe)

Powyżej 70% aktywnej stawki coś się jakościowo zmienia. Zespół zaczyna zachowywać się tak, jakby narzędzia AI były częścią środowiska deweloperskiego, a nie osobistym life hackiem produktywnościowym. Pojawiają się trzy efekty compounding:

Wspólna baza umiejętności. Inżynierowie pytają się nawzajem o prompty tak, jak kiedyś pytali o workflow debuggera albo sztuczki gitowe. Wewnętrzne kanały slackowe gromadzą snippety, które są reużywane. Zbiorowy słownik promptów zespołu rośnie szybciej niż słownik dowolnej osoby, a nowi pracownicy wchłaniają go w dni, a nie odkrywają od nowa przez miesiące.

Wspólne rejestry MCP i rules. Kiedy większość zespołu mocno używa Claude Code albo Cursora, opłaca się zainwestować we wspólne serwery MCP (wewnętrzne dane, ticketing, deployment, runbooki), wspólne pliki .cursor/rules i CLAUDE.md commitowane do repo i wspólne biblioteki promptów. Każde nowe MCP lub plik rules podnosi każdego w zespole — jednorazowa inwestycja ze zwrotem proporcjonalnym do wielkości zespołu. Poniżej 70% ta sama inwestycja spłaca się tylko aktywnym użytkownikom, więc praca po prostu się nie dzieje.

Efekty sieciowe na workflow. Code review ewoluuje: reviewerzy mogą poprosić AI o wyjaśnienie diffu, uruchomienie targetowanych testów albo spot-check edge case’ów. On-call ewoluuje: boty od incydentów potrafią streścić alerty i zaproponować pierwszą wersję remediation. Onboarding ewoluuje: pierwszy PR nowego pracownika może być scaffoldowany przez AI pierwszego dnia, z reviewem seniora na końcu. Nic z tego nie dzieje się w zespole, w którym większość ludzi nie używa narzędzi — założenia workflow nie trzymają się.

Zyski wydajnościowe w tym reżimie to nie 21% per inżynier; to 21% plus zmiany na poziomie zespołu. Zespoły, które dokonały przekroczenia, konsekwentnie raportują redukcję cycle time PR-ów o 30–50%, bez degradacji rzetelności code review.

Wdrożenie krok po kroku

1. Mierz uczciwie przez dwa tygodnie. Pobierz telemetrię ze strony narzędzia z Cursor Admin API, Anthropic Console, Copilot Metrics API albo tego, na co masz licencje. Zbuduj per-inżynier tygodniowy widok dni aktywnych. Powstrzymaj się od publicznego udostępniania na razie — pierwsze czytanie jest dla ciebie i twoich engineering leadów. Większość CTO jest zaskoczona różnicą między percepcją a rzeczywistością.

2. Ustaw próg i nadaj mu nazwę. Trzy sesje na tydzień, na danych ze strony narzędzia, w ostatnich siedmiu dniach. To staje się operacyjną definicją “aktywnego”. Zapisz to w engineering wiki. Nie ruszaj jej co najmniej przez kwartał.

3. Znajdź championów i dziury. Wśród inżynierów powyżej progu zidentyfikuj dwóch-trzech, którzy używają narzędzi głęboko — nie tylko otwierają je, ale commitują AI-assisted kod, piszą pliki promptów, budują MCP. Wśród inżynierów poniżej progu posegmentuj na: nigdy nie próbował, próbował i odbił się, próbował i jest sceptyczny po cichu, twardy ideologiczny “nie”.

4. Zorganizuj cotygodniowe office hours. 30-minutowa sesja Zoom lub na żywo prowadzona przez jednego z championów. Temat rotuje: “prompty, których użyłem w tym tygodniu”, “MCP, które właśnie podłączyłem”, “rzecz, którą zepsułem używając Claude Code”. Obecność opcjonalna, ale widoczna. Chodzi o normalizację rozmowy, nie o szkolenie.

5. Commituj wspólne rules i konfiguracje MCP do głównych repo. .cursor/rules, CLAUDE.md, .mcp.json. Traktuj jak kod: review PR, ownership, changelog. To pojedynczy ruch z największą dźwignią — obniża koszt rozpoczęcia dla grupy “próbował i odbił się” z “ogarnij wszystko sam” do “git pull”.

6. Coachuj segmenty inaczej. “Nigdy nie próbował” → sparuj z championem na popołudnie przy prawdziwym ticketcie. “Próbował i odbił się” → debug odbicia; zazwyczaj to problem konfiguracyjny albo jedno złe pierwsze wrażenie. “Sceptyk po cichu” → zaproś go na krytyczną rozmowę; ich zastrzeżenia często ujawniają realne problemy z workflow warte naprawy. “Twardy ideologiczny nie” → uznaj stanowisko, udokumentuj wyjątek, idź dalej.

7. Zrób stawkę adopcji widoczną metryką. Publikuj per-zespół liczbę adopcji co miesiąc. Nie per-inżynier (to staje się inwigilacją). Per-zespół, z managerem inżynieryjnym jako właścicielem. Sparuj to z jedną metryką wyjścia — przepustowość PR, cycle time albo częstotliwość deploymentów — żeby rozmowa zostawała o dźwigni, a nie o zgodności.

8. Wybierz historię produktywności, którą chcesz opowiedzieć. Zanim świętujesz przekroczenie 70%, zdecyduj, która metryka wyjścia jest twoim dowodem ROI. Przepustowość PR per inżynier-tydzień jest najprostsza. Cycle time (PR otwarty do mergea) jest najmocniej do obrony. Stabilność wskaźnika defektów obok przepustowości jest najmocniejsza. Cokolwiek wybierzesz, zrób baseline teraz, zanim adopcja wzrośnie, żebyś miał krzywą przed-po.

9. Trzymaj linię na ścieżce wyjątku. Niektórzy inżynierowie nie zaadoptują. To jest w porządku, jeśli masz wprost określone alternatywne oczekiwania output i inżynier dowozi. Nie jest w porządku, jeśli “po prostu nie używam tych narzędzi” staje się sposobem na dowiezienie 30% mniej niż peers bez bycia oznakowanym. Zrób wyjątki wprost, z terminem i przeglądem.

10. Wróć przy 70%. Kiedy przekroczysz, nie ogłaszaj zwycięstwa. Efekty compounding potrzebują jeszcze kwartału lub dwóch, żeby się pojawić — wspólne MCP, zewoluowane code review, szybszy onboarding. Zaplanuj wprost push przeprojektowania workflow (jeden kwartał, nazwany właściciel), żeby je zebrać, zamiast oczekiwać, że pojawią się same.

Częste pułapki

Mandaty bez coachingu. “Od przyszłego tygodnia każdy musi używać Cursora” produkuje jednotygodniowy skok adopcji, po którym następuje cichy powrót do baseline’u, plus mierzalny ubytek zaufania. Adopcja to problem coachingowy, nie problem polityki. CTO, którzy dochodzą do 70%, spędzają więcej czasu na parowaniu championów z maruderami niż na pisaniu memo.

Brak pomiaru, tylko wibracje. Bez telemetrii ze strony narzędzia rozmowa schodzi do “myślę, że większość zespołu tego używa” — co jest błędne za każdym razem, kiedy ktoś faktycznie sprawdzi. Wyciągnij dane. Niechęć do ich wyciągnięcia zazwyczaj sygnalizuje, że już wiesz, że liczba jest niższa niż historia.

Inwigilacja per-inżynier zamiast accountability per-zespół. Publikowanie leaderboardu, kto użył Cursora ile godzin w tym tygodniu, to szybki sposób, żeby zatruć studnię. Per-zespół rollupy, z managerem inżynieryjnym jako właścicielem, niosą tę samą informację bez dynamiki panoptykonu.

Brak ścieżki wyjątku. Część seniorów ma legalny, wydajny workflow, który nie obejmuje narzędzi AI. Jeśli twoja kultura traktuje to jako powód do zwolnienia, stracisz ludzi, których nie chcesz stracić. Zbuduj wprost ścieżkę wyjątku, która wymaga od inżyniera utrzymania parytetu wyjścia i zaangażowania w pracę zespołową nad promptami i MCP.

Mylenie liczby licencji z adopcją. Kupienie wszystkim licencji Cursora i nazwanie tego 100% adopcji to najczęstszy błąd raportowania. Aktywna stawka z telemetrii, nie liczba licencji z procurementu.

Pominięcie inwestycji we wspólne rules. Zespoły, które dochodzą do 70% indywidualną siłą woli bez commitowania wspólnych rules, konfiguracji MCP i bibliotek promptów do repo, tracą połowę benefitu compounding. Cały sens przekraczania 70% to odblokowanie pracy na poziomie zespołu — zrób tę pracę wprost.

Traktowanie liczby jako metryki próżności. Adopcja jest środkiem, nie celem. Jeśli osiągnąłeś 70%, a przepustowość PR się nie ruszyła, coś jest nie tak z tym, jak narzędzia są używane (albo z tym, jak mierzysz przepustowość). Sparuj stawkę adopcji z jedną metryką wyjścia od dnia pierwszego.

Jak sprawdzić, czy już tam jesteś

Zespół trafia w max na to pytanie, kiedy wszystkie poniższe są prawdziwe:

• Aktywna stawka (≥3 sesje tygodniowo, telemetria ze strony narzędzia) jest powyżej 70% w ostatnich czterech tygodniach.
• Potrafisz nazwać każdego inżyniera obecnie poniżej progu i wskazać jego plan coachingu — albo to, że ma wprost wyjątek z udokumentowanymi oczekiwaniami output.
• Co najmniej dwa z: .cursor/rules, CLAUDE.md, .mcp.json, wewnętrzna biblioteka promptów, wewnętrzny serwer MCP są commitowane do twoich głównych repo i mają wpisy w changelogu w ostatnim kwartale.
• Leadership potrafi zacytować jedną metrykę wyjścia (przepustowość PR, cycle time, częstotliwość deploymentów), która mierzalnie się poruszyła od kiedy adopcja przekroczyła 50%.
• Liczba adopcji jest publikowana co miesiąc, per zespół, z managerami inżynieryjnymi jako właścicielami, obok metryki wyjścia.
• Masz spisaną politykę wyjątków dla nieadoptujących i co najmniej jeden wyjątek został zreviewowany w ostatnim kwartale.

Jeśli któreś z tych brakuje, nie trafiłeś w max-score niezależnie od surowej liczby adopcji. Wynikiem jest system, a nie procent.

Dalsza lektura

P2 — Polityka narzędziowa i standaryzacja Wybór i trzymanie się stacku: Cursor vs Claude Code vs Copilot, kiedy standaryzować, a kiedy pozwolić zespołom wybierać.

P3 — Billing zespołu i zarządzanie licencjami Pula vs per-licencja, kto płaci, jak odzyskiwać nieużywane licencje i playbook procurementu dla narzędzi AI.

P19 — Czas onboardingu developera Jak AI-native onboarding kompresuje time-to-first-PR i co mierzyć.

CTO Scorecard Pełny scorecard 20 pytań dla organizacji inżynierskich używających narzędzi AI do kodowania w 2026.