Polityka narzędzi — standaryzowany stack + proces wyjątków

Pytanie ze scorecard: Jaka jest polityka narzędziowa (Claude Code / Cursor / Codex / inne)? Odpowiedź na maks. wynik (3 pkt): Standaryzowany stack + proces wyjątków na „chcę spróbować nowego narzędzia”.

Dlaczego to ważne w 2026

Shadow AI to dziś najszybciej rosnąca porażka governance w organizacjach inżynierskich. W Q1 2026 Microsoft wyciągnął Agent 365 z preview właśnie dlatego, że obserwował, jak klienci enterprise tracą rozeznanie, których agentów, których seatów i które modele faktycznie używają ich deweloperzy. Każdy zespół ma co najmniej jednego inżyniera, który po cichu kupił Cursor Ultra na prywatną kartę, drugiego puszczającego Claude Code przez klucz ze side projectu i trzeciego wklejającego snippety w darmową zakładkę ChatGPT. Żaden z tych ruchów nie pokazuje się w Twoich logach SSO, skanach DLP, raportach audytowych ani fakturach planów grupowych.

To dziura audytowa, wyciek billingowy i blokada dzielenia się wiedzą — wszystko w jednym. Nie wymusisz residency danych na narzędziu, o którym nie wiesz, że istnieje. Nie wynegocjujesz pricingu enterprise na seat na czyimś prywatnym Stripe. Nie podzielisz się szablonami CLAUDE.md z inżynierami używającymi narzędzia, którego Twój platform team nigdy nie otworzył.

Ale failure mode po drugiej stronie jest równie kosztowny. Kilku CTO pod koniec 2025 zareagowało na Shadow AI wybierając jedno narzędzie — zwykle „tylko Copilot, bo Legal już go odbił” — i banując wszystko inne. Sześć miesięcy później ich najlepsi inżynierowie albo odeszli, albo po cichu łamali politykę, bo Copilot to nie Claude Code, a senior, który dowiózł sto PR‑ów przez claude, nie wraca z zasady do inline‑suggestion autocomplete.

Wygraną jest środek. Krótka lista — typowo dwa albo trzy sankcjonowane narzędzia z wyraźną uzasadnieniem — plus realna, lekka ścieżka, którą inżynier może powiedzieć „chcę spróbować X przez 30 dni” i dostać tak albo nie w ciągu tygodnia. To jest 3 punkty na tym pytaniu i to jest to, co reszta tej strony operacjonalizuje.

Jak naprawdę wygląda maksymalny wynik

Maksymalna polityka ma sześć widocznych artefaktów. Brak któregokolwiek oznacza, że jeszcze tam nie jesteś.

Spisana polityka narzędzi na 1–2 strony w handbooku, podlinkowana z onboardingu, która wymienia każde zatwierdzone narzędzie AI do kodu, do których use case’ów każde jest preferowane i kto trzyma relację z dostawcą.
Preferowany stack 2–3 narzędzi, nie 1 i nie 7. Typowy kształt na 2026: Cursor jako primary w IDE dla większości IC, Claude Code jako primary terminal/agent dla pracy senior + platform, plus jedno dopuszczalne inline assistant (Copilot Business albo Codex) dla języków lub repo, gdzie pierwsze dwa są słabsze. Czasem prostsze — np. „Claude Code + Cursor, wszystko inne przez wyjątek”.
Proces wyjątków mieszczący się na jednej stronie — szablon w Notion / Linear z opisem problemu, narzędziem, którego inżynier chce, kryteriami sukcesu na 30‑dniowy pilot, klasyfikacją danych i wskazanym approverem. SLA: odpowiedź w 5 dni roboczych.
Pipeline pilotów 2–4 narzędzi aktualnie w 30‑dniowej ewaluacji, z właścicielami i datami końca, żeby inżynierowie widzieli, co już jest sprawdzane, zanim złożą nowy wniosek.
Kwartalne review, w którym lead platformy / DevEx republikuje preferowany stack, wyrzuca to, z czego zespół wyrósł, awansuje to, co wygrało swój pilot, i ponownie uzasadnia wybory wobec aktualnego rynku.
Bulk billing zgodny z polityką. Wszyscy na Claude Code są na Anthropic Teams; wszyscy na Cursor są na Cursor Teams; nikt nie rozlicza prywatnej subskrypcji. (Zobacz Q3 · Rozliczenia zespołowe.)

Prosty self‑test: zapytaj trzech losowych inżynierów „jakie narzędzia AI wolno nam używać i jak spróbować nowego?”. Jeśli dostaniesz trzy zgodne odpowiedzi w mniej niż 30 sekund każda, jesteś na 3 punktach. Jeśli wzruszają ramionami lub odpowiadają różnie, jesteś na 1 albo 2.

Aktualny krajobraz (zweryfikowany przez web search)

Koszt Shadow AI (governance, billing, dzielenie się wiedzą)

Shadow AI jest dziś traktowane jako kategoria odrębna od Shadow IT właśnie dlatego, że promień rażenia jest inny. Złe narzędzie SaaS wycieka dane, które organizacja w nie wkłada; złe narzędzie AI wycieka plus modyfikuje — ingestuje kod, sugeruje patche, a w 2026 odpala komendy i otwiera PR‑y. Trzy konkretne straty na każdy kwartał, w którym pozwalasz mu działać bez zarządzania:

Białe plamy audytowe. Twoje kontrole SOC 2, ISO 27001, EU AI Act i HIPAA są scope’owane na znane systemy. Jeśli 30% Twojego kodu dotyka narzędzi, których nie umiesz wymienić, finding od audytora staje się brzydki bardzo szybko. Część enterprise’ów w 2026 prowadzi już „AI Bill of Materials” — każdy model, dostawca, dataset i narzędzie użyte w developmencie — wprost po to, żeby zamknąć tę dziurę.
Wyciek billingowy. Seat Cursor Pro na prywatnej karcie to $20/miesiąc i 0% zwrotu z rabatu Twojego planu Anthropic / Cursor / OpenAI Team. Dziesięciu inżynierów robiących tak to $2,4K/rok znikające z linii, którą widzi Twój CFO, plus utracony wolumen, który kwalifikowałby Cię do pricingu enterprise. (Zobacz Q3 · Rozliczenia zespołowe — matematyka tam.)
Silosy wiedzy. Jeśli dwóch inżynierów ma 5× przyspieszenie z Claude Code, a reszta zespołu o tym nie wie, to najdroższy silos wiedzy w Twojej organizacji. Sankcjonowane narzędzia oznaczają wspólne CLAUDE.md, wspólne repo skills, wspólne serwery MCP, brown‑bag sessions i skrypty onboardingowe. Shadow tools oznaczają, że nic z tego się nie kumuluje.

Failure mode wymuszonego pojedynczego narzędzia

Odruchowa reakcja — „wystandaryzujemy się na Copilocie, bo Procurement już podpisał BAA” — wyprodukowała najbardziej widoczne spiki rotacji w ostatnich dwóch latach. Trzy wzorce powtarzają się konsekwentnie:

Senior odchodzi. Staff engineer, który zinternalizował claude code przez 6 miesięcy, nie wróci szczęśliwy do inline autocomplete w VS Code. Odchodzi do organizacji, gdzie narzędzie, w którym jest dobry, jest sankcjonowane. To dziś numer 1 powodów cytowanych w exit interviews dla inżynierów AI‑native pod koniec 2025 / początku 2026.
Polityka się sypie w drugim tygodniu. Jeśli Twoje jedno zatwierdzone narzędzie nie jest najlepsze do połowy realnej pracy zespołu, inżynierowie będą go omijać. Masz teraz Shadow AI i ból z egzekwowaniem. Gorzej niż brak polityki.
Przegapiasz następną falę. Krajobraz narzędzi AI do kodu ma half‑life 90 dni od 2023. Cursor był niszowy na początku 2024. Claude Code nie istniał jako agent surface do połowy 2024. Codex relaunchował jako prawdziwy produkt w 2025. Polityka jednego narzędzia gwarantuje, że jesteś 6–12 miesięcy za frontierem na tym, co Twój zespół powinien faktycznie używać.

Wzorzec „preferowane + alternatywne” (np. Cursor primary, Claude Code dla terminal‑heavy)

To, co działa w 2026 — i do czego zbiega większość polityk z maksymalnym wynikiem — to dwunarzędziowy default z czytelnym podziałem po typie pracy:

Cursor primary do pracy IDE‑centrycznej. Frontend, design‑heavy, refactor w pliku, autocomplete‑heavy. Wizualny diff, inline edits, Agent Mode dla średnich tasków. Default dla większości IC.
Claude Code primary do pracy terminal/agent‑heavy. Backend, infra, multi‑file refaktory, długie plany, workflowy oparte na MCP, agenci prowadzący git i PR‑y. Default dla pracy platform / SRE / senior IC i dla każdego, kogo flow jest w terminalu.
Codex CLI jako model second‑opinion. Niższa częstotliwość, ale wprost zatwierdzony do review diffów, ratowania utkniętych agentów, reasoningu GPT‑5 na ciężkich refaktorach. Większość zespołów trzyma jeden płatny seat OpenAI per pod właśnie po to.
Copilot Business do języków, gdzie 1–3 słabuje. Część organizacji trzyma Copilota jako inline autocomplete w Visual Studio dla .NET albo w JetBrains dla Kotlin/Java, bo inline experience tam wciąż prowadzi.

„Preferowane” nie znaczy „obowiązkowe”. Inżynier może się przerzucać — Cursor primary dziś, Claude Code jutro — pod warunkiem, że oba są na liście sankcjonowanych. To lista jest ograniczona; wybór nie.

Szablon procesu wyjątków (1 strona, 30‑dniowy pilot, kryteria sukcesu)

Dobry proces wyjątków jest dość krótki, żeby inżynierowie faktycznie z niego korzystali. Szablon, który działa w 2026:

Formularz (≤1 strona). Pola: nazwa narzędzia, dostawca, plan/tier, czego aktualne sankcjonowane narzędzie nie potrafi, hipoteza (jedno zdanie), klasyfikacja danych (czy dotyka kodu prod, danych klienta, PII?), długość pilota (default 30 dni), kryteria sukcesu (konkretne: „oszczędzam 30 minut/dzień na X” albo „PR‑y z workflow Y idą 2× szybciej”), proponowany reviewer.
Approver. Wskazana, jedna osoba (Twój DevEx lead albo AI tooling lead — zobacz Q24 · AI tooling roadmap). Nie komitet. SLA: 5 dni roboczych na tak / nie / „pogadajmy”.
Warunki pilota. Sandboxowe repo albo dane non‑prod, chyba że klasyfikacja danych dopuszcza prod. Licencja opłacana centralnie w trakcie pilota, nie prywatnie. Inżynier zobowiązuje się do 15‑minutowego writeupa na dzień 30 — co działało, co nie, czy rekomenduje dodać do listy sankcjonowanych tak/nie.
Wynik. Writeup z dnia 30 idzie do platform teamu. Albo narzędzie trafia na listę sankcjonowanych (z uzasadnieniem) przy najbliższym kwartalnym review, albo wyjątek wygasa i inżynier wraca do sankcjonowanego stacku. Każdy wynik jest OK; najgorszy scenariusz to brak decyzji.

To jest dźwignia, która zapobiega failure mode’owi „forced single tool”. Sygnał, który dajesz inżynierom: „Mamy opinie, ale mamy też ścieżkę do ich zmiany. Obie są realne”.

Wdrożenie krok po kroku

Zinwentaryzuj, co jest realnie w użyciu. Odpal anonimową ankietę: „Których narzędzi AI do kodu używałeś przy tym codebase w ostatnich 30 dniach?” z free‑text polem „inne”. Skrzyżuj z logami SSO, telemetrią IDE (jeśli masz) i raportami wydatków oznaczonymi „subskrypcja” lub „narzędzia developerskie”. Prawie na pewno masz 2–4 narzędzi więcej w użyciu, niż myślisz.
Posortuj inwentarz po wolumenie i wartości. Naszkicuj narzędzia w dwóch wymiarach: ilu inżynierów używa każdego i które workloady wygrywają. Top dwa albo trzy prawie zawsze wyłaniają się czytelnie. Wszystko w długim ogonie to kandydat albo na konsolidację z topami, albo na formalny wyjątek.
Naszkicuj preferowany stack z uzasadnieniem. Napisz 2–4 zdania na każde sankcjonowane narzędzie: do których workloadów jest preferowane, kto jest sponsorem wykonawczym, jak wygląda kontrakt / plan Team, na jaką klasyfikację danych jest odhaczone. Całość zmieść w dwóch stronach. Długich polityk się nie czyta.
Napisz formularz wyjątku, zanim opublikujesz politykę. To jest część, którą zespoły pomijają i potem żałują. Jeśli Twoja polityka mówi „wyjątki są dozwolone”, ale nie ma formularza, approvera ani SLA, inżynierowie nie będą się męczyć — po prostu cicho zainstalują narzędzie. Wrzuć formularz do Notion albo Linear, wskaż approvera, ustaw 5‑dniowe SLA i podlinkuj z polityki w minimum dwóch miejscach.
Przenieś wszystkich na sankcjonowane plany grupowe. Zmigruj prywatne subskrypcje na plany Team / Business / Enterprise dla każdego sankcjonowanego narzędzia. Anthropic Teams, Cursor Teams, ChatGPT Business, Copilot Business — co pasuje. Zjedz tarcie migracji teraz; to największa wygrana billingowa w scorecardzie (zobacz Q3 · Rozliczenia zespołowe).
Opublikuj, ogłoś i poprowadź dwie otwarte sesje Q&A. Wrzuć politykę do handbooku i na #engineering. Poprowadź 30‑minutowe Q&A w tym samym tygodniu i drugie dwa tygodnie później. Łap pytania „dlaczego nie ma narzędzia X na liście?” na żywo — większość ma dobre odpowiedzi („oceniliśmy, było 3. miejsce”), a kilka odsłoni realne luki.
Postaw kwartalne review. Zaplanuj 60 minut co 90 dni z DevEx leadem i 2–3 senior IC. Agenda: jakie piloty toczyły się w tym kwartale, co dodać / usunąć ze sankcjonowanego stacku, co przychodzi w kolejnym kwartale, jak wygląda przesunięcie budżetu. Opublikuj wynik jako deltę na oryginalnym dokumencie polityki — nie przepisuj.
Trzymaj wyniki pilotów w jednym miejscu. Spreadsheet albo projekt Linear, bez znaczenia. Kolumny: narzędzie, wnioskodawca, data startu, data końca, decyzja, uzasadnienie. To staje się Twoim broniącym się audit trailem zarówno dla Procurementu („dlaczego to kupujemy?”), jak i dla Security („jakich danych dotykało?”). Zatrzymuje też ponowną ewaluację tego samego odrzuconego narzędzia co pół roku.

Częste pułapki

Brak cyklu review. Polityka napisana raz i nigdy nieotwarta jest martwa w 90 dni. Rynek się rusza; Twoja polityka musi się ruszać z nim. Zaplanuj kwartalne review zanim opublikujesz politykę, nie po.
Brak procesu wyjątków. „Mamy sankcjonowany stack i tyle” to polityka jednego narzędzia z dodatkowymi krokami. Inżynierowie będą ją omijać. Ścieżka wyjątku to zawór bezpieczeństwa, który sprawia, że standaryzacja realnie się trzyma.
Banowanie tego, co już działa. Jeśli połowa Twoich senior inżynierów jest na Claude Code i dowozi szybciej niż kiedykolwiek, nie pisz polityki spychającej ich na Copilota, bo BAA było łatwiejsze. Załatw BAA dla Claude Code — Anthropic oferuje Teams z tymi samymi kontrolami — zamiast wybierać najgorsze narzędzie na jedyne sankcjonowane.
Wymienienie siedmiu sankcjonowanych narzędzi. Siedem to to samo co zero dla dewelopera próbującego ustalić, co zainstalować. Trzymaj dwa albo trzy. Dodawaj przez wyjątek, nigdy przez „i jeszcze sankcjonujemy…”.
Zatwierdzanie przez komitet. Pięcioro ludzi na liście approverów oznacza, że nic nie zostanie zatwierdzone w tydzień. Wskaż jedną osobę, accountable, z zastępcą na urlop. Komitet pojawia się na kwartalnym review, nie w inboxie.
Pomijanie niuansu języka / repo. Blankietowa „Cursor primary” sypie się na repo, gdzie Cursor jest realnie słabszy — duże monorepo, niektóre języki, niektóre frameworki. Wytnij to wprost: „Primary to Cursor poza naszym repo Rust kernel module, gdzie primary jest Claude Code”.
Piloty bez kryteriów sukcesu. „Próbowaliśmy, czuło się dobrze” to nie wynik pilota. Wymuś na wnioskodawcy spisanie, jak wygląda sukces, zanim pilot ruszy. Inaczej wszystko zalicza i kończysz z problemem siedmiu narzędzi.
Polityka w doku, którego nikt nie czyta. Podlinkuj z onboardingu, z headera firmowego kanału AI tooling, z formularza wydatków inżyniera i z Twoich szablonów CLAUDE.md. Postaw twardy cel: „każda nowa osoba czyta to w tygodniu 1”.

Jak sprawdzić, czy już tam jesteś

Nowy inżynier potrafi odpowiedzieć „jakie narzędzia AI do kodu wolno nam używać i jak spróbować nowego?” w mniej niż 30 sekund z handbooku.
Twoje raporty SSO / billingu / DLP pokrywają ≥95% realnego użycia narzędzi AI do kodu w organizacji. Spot‑check przez anonimową ankietę IC.
Co najmniej jeden inżynier złożył wyjątek w ostatnim kwartale i dostał tak/nie w ciągu tygodnia.
Co najmniej jedno narzędzie albo weszło, albo wyszło ze sankcjonowanego stacku w ostatnich 12 miesiącach — polityka żyje, nie jest zamrożona.
Twoje plany grupowe Team / Business / Enterprise pokrywają ≥90% seatów dla każdego sankcjonowanego narzędzia. Prywatne subskrypcje odzyskane albo grandfatherowane z jasną datą wygaśnięcia.
Kwartalne review faktycznie się odbywa. Potrafisz wyciągnąć notatki z dwóch ostatnich na zawołanie.
Twój DevEx albo AI tooling lead ma wskazaną rolę i alokację czasu na tę pracę, nie tylko „extra duty as assigned”.
Senior inżynier, który jest w zespole od dwóch lat, mówi sam z siebie, że polityka „wydaje się sensowna” i „nie przeszkadza”.

Dalsza lektura

Q1 · Wskaźnik adopcji w zespole Przekraczanie progu 70% aktywnych użytkowników — warunek wstępny, zanim polityka cokolwiek znaczy.

Q3 · Rozliczenia zespołowe Plany grupowe Team / Enterprise (Anthropic Teams, Cursor Teams, OpenAI Business) z centralnym audytem.

Q5 · Wspólne reguły agentów Gdy stack jest ustalony, warstwa wspólnych CLAUDE.md / .claude/rules zaczyna się zwracać.

CTO Scorecard 25 pytań, ocena tieru, plan 30/60/90.