Jak przekonać sceptyków i seniorów

Przekonanie sceptyków i seniorów do inżynierii agentowej działa wtedy, gdy ich zarzuty traktuje się jako listę luk w weryfikacji, a nie jako opór. Każdy senior projektuje sprawdzenia, które rozstrzygają, kiedy wynikowi agenta można ufać, a potem prowadzi mierzony pilotaż na zadaniach z własnego backlogu, z regułą decyzji spisaną przed pierwszym zadaniem.

Twój staff engineer powiedział to na retro wprost: „Próbowałem przez tydzień, pisał wiarygodnie wyglądający kod, który był błędny w miejscach, które znalazłem tylko dlatego, że znam ten system, a poprawianie zajęło mi dłużej niż napisanie go od zera”. Dwóch innych seniorów po cichu przestało w ogóle otwierać agenta. CTO chce liczby adopcji na koniec kwartału, a przewodnik wdrożeniowy, który dostałeś, radzi sparować opornych z „championem” i publikować wykresy produktywności, aż zmiękną.

Taki przewodnik wdrożeniowy traktuje jako przeszkodę właśnie tych ludzi, którzy najlepiej wiedzą, co może pójść źle. Ta strona jest dla tech leada, który musi ich pozyskać, nie tracąc ich osądu, a najlepiej wykorzystując go w pracy.

Co znajdziesz na tej stronie

Tabelę „zarzut → sprawdzenie”, która zamienia osiem zarzutów, jakie usłyszysz, na lukę w weryfikacji i sprawdzenie, za które odpowiada senior.
Czterotygodniowy protokół pilotażu, który senior prowadzi na własnych zadaniach: najpierw estymata, potem losowy przydział, a reguła decyzji ustalona z góry.
Szablon dziennika pilotażu do wklejenia do repozytorium oraz prompt, który stosuje regułę decyzji bez dopisywania komentarzy.
Cztery prompty do skopiowania dla Claude Code, Codex i Cursora: zamiana zarzutu na sprawdzenie, bramka dla zadania z pilotażu, atak na zmianę agenta i analiza pilotażu.
Uczciwą lekturę wyników METR, którą możesz pokazać sceptykowi, łącznie z częścią, która przyznaje mu rację.
Typowe porażki w pracy ze sceptykami, od ustawionego pilotażu po seniorów zasypanych review, i sposób wyjścia z każdej z nich.

Dlaczego warto słuchać sceptycznych seniorów?

Bo najlepsze dostępne dane częściowo przyznają im rację. Sceptycyzm seniorów opiera się zwykle na dwóch obserwacjach: kod agenta częściej wygląda na poprawny, niż jest poprawny, a nikt nie zmierzył, czy agent oszczędza czas doświadczonemu inżynierowi na znanym mu kodzie. Badania wprost potwierdzają drugą, a z pierwszą są zgodne.

Co zmierzył METR, czytany uczciwie

Randomizowane badania kontrolowane METR to jedyne randomizowane badania w bazie dowodów tej strony, które mierzą pracę doświadczonych programistów we własnych repozytoriach. Pokaż te wyniki sceptykowi sam, zanim on do nich dotrze:

Badanie	Co wykazało	Co to znaczy dla twojego zespołu
METR, lipiec 2025: 16 doświadczonych programistów open source, 246 zadań w dobrze znanych im repozytoriach	„The use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%” (użycie AI wydłuża zadania o 19%, przedział ufności od +2% do +39%). Programiści spodziewali się przyspieszenia o 24%, a po badaniu „still believed AI had sped them up by 20%” (nadal wierzyli, że AI przyspieszyło ich o 20%).	Istotne statystycznie spowolnienie ekspertów na znanym kodzie, z narzędziami z początku 2025 roku. Deklarowana szybkość nie jest dowodem, twoja też nie.
METR, aktualizacja z lutego 2026	Estymaty punktowe wypadają teraz na korzyść AI: około 18% mniej czasu u powracających uczestników (przedział od 38% mniej do 9% więcej) i około 4% mniej u nowo zrekrutowanych (od 15% mniej do 9% więcej). Oba przedziały obejmują zero.	To nie jest zmierzone przyspieszenie. METR nazywa te dane „niewiarygodnym sygnałem obecnego wpływu narzędzi AI na produktywność” (oryg. ang. „an unreliable signal of the current productivity effect of AI tools”), między innymi dlatego, że programiści odmawiali pracy bez AI, a czasu trudno mierzyć, gdy jedna osoba prowadzi kilka agentów naraz.
Repozytorium analiz METR, sprawdzone 2026-09-26	„Please interpret these results with a major grain of salt” (te wyniki należy traktować z dużą dozą ostrożności).	Żadne z dwóch badań METR nie pokazuje, że agenci przyspieszają doświadczonych inżynierów na ich własnym kodzie; nie pokazuje tego też żadne badanie w bazie dowodów tej strony.

Projekt badania METR jest też szablonem twojego pilotażu. Kod analizy porównuje rzeczywisty czas każdego zadania z estymatą programisty, ile trwałoby ono bez AI, zapisaną przed rozpoczęciem pracy. Twój senior może zrobić to samo porównanie na 10 własnych zadaniach.

Co dodają pozostałe dane

Seniorzy nie są odosobnieni w nieufności. W ankiecie Sonar (styczeń 2026, ponad 1100 programistów) „96% programistów nie ufa w pełni kodowi generowanemu przez AI, a tylko 48% zawsze go weryfikuje przed commitem” (Sonar, oryg. ang.: „96% of developers do not fully trust AI-generated code, and only 48% always verify it before committing”). Raport DORA 2025 (Google Cloud, 23 września 2025) wykazał pozytywny związek adopcji AI z przepustowością dostarczania, ale nadal „negatywny związek ze stabilnością dostarczania oprogramowania” (oryg. ang. „negative relationship with software delivery stability”), i wskazuje przyczynę: bez „solidnych testów automatycznych, dojrzałych praktyk kontroli wersji i szybkich pętli informacji zwrotnej” (oryg. ang. „strong automated testing, mature version control practices, and fast feedback loops”) większa liczba zmian prowadzi do niestabilności.

To ostatnie ustalenie jest miejscem dla seniorów. Mechanizmy kontroli, które wymienia DORA, to dokładnie to, co seniorzy budują i utrzymują. Badanie Anthropic na własnych inżynierach (grudzień 2025) nazywa ryzyko z drugiej strony: „paradoks nadzoru” (oryg. ang. „paradox of supervision”), czyli nadzór nad agentem wymaga właśnie tych umiejętności, które nadmierne delegowanie osłabia. Twoi seniorzy te umiejętności mają. Zadanie polega na skierowaniu ich na weryfikację, a nie na wyperswadowaniu im własnego osądu.

Jak zamienić każdy zarzut na sprawdzenie?

Każdy poważny zarzut wskazuje błąd, który agent może popełnić, a którego obecne sprawdzenia nie wyłapią. Zapisz zarzut słowami seniora, a potem zapytaj, jakie sprawdzenie wyłapałoby błąd, który za nim stoi. Senior, który zgłosił zarzut, zostaje właścicielem tego sprawdzenia.

Co słyszysz	Luka w weryfikacji	Sprawdzenie, za które odpowiada senior	Gdzie je zbudować
„Pisze wiarygodny kod, który jest subtelnie błędny”.	Testy przechodzą na błędnym kodzie: wyrocznia jest słaba.	Kryteria akceptacji spisane przed zadaniem i testy mutacyjne na zmienionych plikach.	Siła wyroczni
„Zmienia testy, aż przejdą”.	Agent może edytować własnego sędziego.	Chronione ścieżki testów w `CODEOWNERS` i krok CI, który blokuje pull request modyfikujący lub usuwający istniejące testy, fixtures lub snapshoty bez zgody właściciela z `CODEOWNERS` (nowe testy są dozwolone).	Ochrona wyroczni
„Bez niego jestem szybszy”.	Nikt tego nie zmierzył, a wynik METR z 2025 roku mówi, że może mieć rację.	Czterotygodniowy pilotaż na własnych zadaniach, opisany niżej.	Ta strona
„Review jego pull requestów trwa dłużej niż napisanie kodu”.	Koszt review nie ma limitu: duże diffy, brak dowodów.	Budżet rozmiaru pull requesta i pakiet dowodów, który agent musi dostarczyć.	Pakiet dowodów, kolejka code review
„Ignoruje naszą architekturę”.	Konwencje żyją w głowach ludzi, a nie w automatycznym sprawdzeniu.	Dwie lub trzy funkcje dopasowania (fitness functions) dla najczęściej łamanych reguł oraz wspólny plik reguł.	Fitness functions, wspólne reguły agentów
„Zgnije nam od tego kod”.	Nikt nie śledzi duplikacji, churnu ani złożoności w czasie.	Comiesięczny raport o kondycji kodu z progiem, który wstrzymuje pracę agentów w danym module.	Kondycja kodu
„Będę odpowiadał za kod, którego nie przeczytałem”.	Brak reguły, które zmiany człowiek wciąż musi czytać.	Klasy eskalacji (uwierzytelnianie, pieniądze, schematy, migracje, sama wyrocznia) kierowane przez `CODEOWNERS`.	Czytanie dowodów zamiast kodu
„Juniorzy przestaną się uczyć”.	Zespół nie ma planu dla umiejętności, które teraz ćwiczy agent.	Spisana lista tego, co juniorzy wciąż robią ręcznie, i sesje review nastawione na naukę.	Rozwój juniorów

Dwóch zarzutów nie ma w tabeli, bo nie są lukami w weryfikacji: „to tylko hype” i „nie chcę”. Pierwszy znika, gdy przestajesz formułować tezy, których dane nie potwierdzają. Przy drugim zapytaj, co musiałby zobaczyć. Odpowiedź prawie zawsze pasuje do jednego z ośmiu wierszy.

Daj seniorom projekt weryfikacji, a nie cel adopcji

Stare porady wdrożeniowe robią championów z entuzjastów, a seniorów rozliczają z użycia narzędzia. Odwróć to. Senior, który najmniej ufa agentowi, jest właściwą osobą, by zdecydować, co znaczy „zweryfikowane” w części systemu, którą zna najlepiej.

W praktyce każdy sceptyczny senior dostaje jedną pętlę (powtarzalny rodzaj zmiany w jednym obszarze, na przykład „zmiany endpointów API w serwisie zamówień”) i odpowiada w niej za cztery artefakty:

Szablon kryteriów akceptacji, który specyfikacja agenta musi wypełnić przed rozpoczęciem pracy.
Listę eskalacji dla tego obszaru: ścieżki, w których człowiek za każdym razem czyta kod.
Chronioną wyrocznię: testy, fixtures i kroki CI, których agent nie może edytować.
Decyzję go/no-go o przejściu tej pętli na review oparte na dowodach. Etapy opisuje strona jak pomóc zespołowi przestać czytać każdy diff.

Równie ważne jest to, co ty jako tech lead przestajesz robić. Usuń wszystkie cele użycia: aktywacje licencji, sesje tygodniowo i udział linii napisanych przez agenta nagradzają złe zachowanie i łatwo je obejść. Zastąp je miarami wyniku z dziennika pilotażu poniżej. Wersje dla całego zespołu definiuje strona o frameworkach metryk.

Poprowadź mierzony pilotaż na zadaniach seniora

Demo na zadaniu, które wybrałeś ty, niczego sceptykowi nie dowodzi, bo to ty je wybrałeś. Pilotaż na zadaniach z jego własnego backlogu, przydzielonych losowo, z kryterium sukcesu spisanym przed pierwszym zadaniem, to eksperyment, który może uszanować. Przy 10 zadaniach nie będzie istotny statystycznie. Nie musi: ma dać decyzję, na którą obaj zgodziliście się z góry.

Wybierzcie 10–12 zadań z backlogu seniora na najbliższe cztery tygodnie. Wybiera on, nie ty. Wyklucz wszystko, co należy do klas eskalacji. Mieszaj rozmiary, ale żadne zadanie nie powinno przekraczać dwóch dni.
Zapisz estymatę każdego zadania przed przydziałem. Senior zapisuje, ile godzin zajęłoby mu zadanie ręcznie. To jest punkt odniesienia z METR i musi istnieć, zanim ktokolwiek wie, do której grupy trafi zadanie.
Przydziel każde zadanie losowo do grupy „agent” albo „ręcznie”. Rzuć monetą albo przepuść listę przez shuf. Losowy przydział chroni pilotaż przed cichym oddawaniem agentowi łatwych zadań.
Spisz regułę decyzji i podpiszcie ją. Umieść ją na początku dziennika pilotażu przed pierwszym zadaniem. Reguła, która sprawdza się w większości zespołów: wdrażamy agenta dla tego rodzaju zadań, jeśli mediana stosunku czasu rzeczywistego do estymaty w grupie „agent” nie jest gorsza niż w grupie „ręcznie” i żadne zadanie agenta nie wymaga poprawek ani nie powoduje defektu w ciągu 14 dni od merge’a. Dodaj jedną regułę zatrzymania: wstrzymujemy, jeśli zmiana agenta trafi na produkcję z defektem w klasie eskalacji.
Niech senior napisze bramkę przed każdym zadaniem agenta. Najpierw sprawdzenia akceptacyjne, jego słowami, z użyciem promptu bramki poniżej. Agent implementuje dopiero po ich zatwierdzeniu. Jako „czas rzeczywisty” licz godziny zegarowe od startu do merge’a, łącznie z review i poprawkami: o ten czas chodziło w zarzucie.
Zapisuj każde zadanie z obu grup w dniu merge’a. Estymata, rzeczywiste godziny, czy bramka przeszła za pierwszym razem, oraz pole na poprawki w ciągu 14 dni, które uzupełniasz później.
Niech wynik przedstawi senior. Zastosuj regułę decyzji promptem analizy, a potem senior prezentuje wynik zespołowi. Są trzy uprawnione wyniki: wdrażamy dla tego rodzaju zadań, wdrażamy z mocniejszą bramką albo zostawiamy ręcznie i powtarzamy pilotaż w następnym kwartale.

Gdy pilotaż ma przekonać organizację, a nie jednego inżyniera, i potrzebne są równoległe kohorty, czynniki zakłócające i wielkość próby, sięgnij po pilotaż, który czegoś dowodzi. Pilotaż z tej strony to najmniejsza wersja, która wciąż zdobywa zaufanie seniora.

Wklej ten dziennik pilotażu do repozytorium

Trzymaj dziennik w repozytorium (na przykład docs/pilots/anna-orders.md), żeby wynik dało się zrecenzować i żeby przetrwał rozmowę o nim.

# Pilot: Anna, orders-service API changes (2026-09-28 to 2026-10-23)

Decision rule (signed 2026-09-26, Anna + Marek):
Adopt the agent for orders-service API changes if the median actual/estimate
ratio in the agent arm is <= the by-hand arm AND no agent task needs rework or
causes a defect within 14 days of merge. Stop rule: pause if an agent change
reaches production with a defect in auth, billing, schema or migrations.

| #  | Task                         | Estimate (h) | Arm     | Actual (h, start to merge) | Ratio | Gate passed first time | Rework or defect within 14 days | Note                         |
| -- | ---------------------------- | ------------ | ------- | -------------------------- | ----- | ---------------------- | ------------------------------- | ---------------------------- |
| 1  | Cursor pagination on /orders | 6            | agent   | 4.5                        | 0.75  | yes                    | no                              | wrote 7 acceptance checks    |
| 2  | Remove legacy v1 serializer  | 3            | by hand | 3.5                        | 1.17  | n/a                    | no                              |                              |
| 3  | Retry policy for outbox      | 8            | agent   | 11                         | 1.38  | no                     | yes: race in retry counter      | concurrency: add to escalation list? |

Szablon zostaje po angielsku, bo tak zwykle wygląda dokumentacja w repozytorium i tak czyta go prompt analizy. Ostatnia kolumna sprawia, że pilotaż się opłaca, nawet gdy wynik jest negatywny. Wiersz 3 to pilotaż, który robi swoje: znalazł klasę zmian, współbieżność, w której sceptycyzm seniora był uzasadniony, i ta klasa trafia na listę eskalacji.

Jak każde narzędzie prowadzi grupę „agent” w pilotażu?

Bramka i dziennik są takie same w każdym narzędziu. Różni się to, jak senior trzyma agenta w trybie planowania do zatwierdzenia sprawdzeń, jak izoluje pracę i jak dostaje niezależne review przed merge’em.

Uruchom sesję w trybie Plan we własnym worktree, żeby nic nie zostało zapisane, zanim senior zatwierdzi sprawdzenia akceptacyjne i plan:

# Terminal, w katalogu głównym repozytorium (Claude Code 2.1.283)
claude --permission-mode plan -w pilot-task-1

Po implementacji uruchom w sesji /code-review, żeby dostać drugą opinię o lokalnym diffie, i /usage, żeby zanotować zużycie sesji. Jeśli zespół chce, żeby bramka była egzekwowana, a nie pamiętana, hook może blokować edycję chronionych ścieżek testów; zobacz zarządzanie wspólnymi hookami.

Uruchom zadanie w zarządzanym worktree i przed pierwszą wiadomością przełącz się w tryb Plan poleceniem /plan, żeby Codex najpierw zaproponował sprawdzenia i plan:

# Terminal, w katalogu głównym repozytorium (Codex CLI 0.157.1)
codex --worktree

Przed otwarciem pull requesta zrób nieinteraktywne review. W Codex CLI 0.157.1 codex review przyjmuje albo flagę celu (--base, --uncommitted, --commit), albo własne instrukcje, nie oba naraz, więc wybierz jedną z opcji:

# Terminal (Codex CLI 0.157.1)
# Opcja 1: standardowe review gałęzi względem main, bez własnej instrukcji
codex review --base main

# Opcja 2: zarzut seniora jako instrukcja, bez flagi celu
codex review "Review the changes on this branch against main. Look for the failure I expect in this area: state mutated across retries without a lock."

Pełne, wrogie review dostaniesz, wklejając do sesji prompt „zaatakuj zmianę agenta” poniżej.

Prompty do skopiowania dla sceptyków i seniorów

Prompty działają bez zmian w Claude Code, Codex i Cursorze. Dwa pierwsze są dla seniora, dwa ostatnie służą całemu pilotażowi.

I do not trust agent-written changes in this repository, for this reason:
"It changes shared state in retry and queue code without locking, and the
tests never exercise concurrent runs."

Do not write feature code. Read AGENTS.md or CLAUDE.md, the test setup, and the
CI configuration first. Then:
1. Show me one place in the current code where the failure I describe could
   happen, or tell me plainly that you cannot find one.
2. Propose the smallest automated check that would catch this failure in a
   future change: a test, a lint rule, an architecture test, or a CI step.
   Name the file it would live in and the command that runs it.
3. Write that check so that it fails on the example from step 1 (or on a
   deliberately broken copy of it), and show me the failing output.
4. List the file paths this check should protect in CODEOWNERS so an agent
   cannot weaken it unnoticed.
Stop after step 4 and wait for my review.

This task is part of a measured pilot. The ticket is below.

Before writing any implementation:
1. Write the acceptance criteria as a numbered list of observable behaviours,
   each with the exact test or command that will prove it.
2. Say which existing tests cover this area and which you will add.
3. List every file you expect to change. If any is under tests/, fixtures/,
   .github/workflows/, or a lint or type config, stop and explain why.
Then stop and wait for my approval of the checks.

After approval, implement in small commits, run the full test suite and the
linters, and report the literal command output. Do not modify any existing
test or snapshot. If a check fails twice, stop and report instead of trying a
third approach.

Ticket: <PASTE THE TICKET TEXT HERE>

Review the changes on this branch against main as a hostile senior engineer
who expects them to be wrong. Do not edit any file.

1. Name the three most likely ways this change is incorrect in production that
   the current tests would not catch (concurrency, partial failure, time zones,
   retries, null and empty inputs, ordering). For each, write the test that
   would expose it, and say whether that test exists.
2. List any behaviour the change alters that the ticket did not ask for.
3. List any test, fixture, snapshot, or CI file the branch modified, and
   whether the modification makes a check looser.
End with one verdict line: MERGEABLE ON EVIDENCE, NEEDS A HUMAN READ (name the
files), or REJECT (name the reason).

Read docs/pilots/anna-orders.md. Apply the decision rule written at the top of
the file exactly as written. Do not reinterpret it, soften it, or add criteria.

1. Compute the median actual/estimate ratio for each arm and show the numbers
   you used.
2. List every agent-arm task with rework or a defect within 14 days, with the
   note from the log.
3. State the outcome the rule gives: ADOPT, ADOPT WITH A STRONGER GATE (only if
   the log names the gate change), or KEEP MANUAL.
4. List every change class the notes suggest adding to the escalation list.
Do not comment on whether the outcome is good or bad, and do not recommend
running the agent more.

Co powiedzieć podczas rozmowy jeden na jeden?

To rozmowa decyduje, czy senior poprowadzi pilotaż w dobrej wierze. Przyjmij te zamiany bez zmian:

Zamiast mówić	Powiedz
„Wszyscy już tego używają, zostaniesz w tyle”.	„Wiesz, gdzie ten system się sypie. Chcę, żebyś to ty zdecydował, co tu znaczy »zweryfikowane«”.
„Badania pokazują, że to bardzo przyspiesza”.	„Badanie METR z udziałem doświadczonych programistów wykazało w 2025 roku spowolnienie, a jego dane z 2026 są zbyt zaszumione, żeby coś orzec. Zmierzmy to na twoich zadaniach”.
„To kwestia promptowania, posiedź tydzień z Kasią”.	„Jaki błąd widziałeś? Napiszmy sprawdzenie, które by go wyłapało”.
„Spróbuj najpierw na czymś małym”.	„Wybierz 10 zadań z własnego backlogu. Rzucimy monetą, które dostanie agent”.
„Użycie narzędzia jest w twoich celach na ten kwartał”.	„Twoim celem jest bramka dla pętli zamówień i podpisany wynik pilotażu, jakikolwiek będzie”.

Jak sprawdzić, że sprawdzenia seniorów naprawdę działają?

Sprawdzenie napisane przez seniora jest coś warte tylko wtedy, gdy nie przechodzi na błędnym kodzie. Każde sprawdzenie z tabeli zarzutów oceniaj tą samą miarą co kod agenta:

Nie przechodzi na znanym złym przykładzie. Prompt „zamień mój zarzut na sprawdzenie” wymaga nieudanego uruchomienia, zanim sprawdzenie zostanie przyjęte. Zachowaj ten wynik w pull requeście, który dodaje sprawdzenie.
Działa w CI i blokuje merge. Sprawdzenie uruchamiane tylko na maszynie seniora to nawyk, a nie bramka. Wymagane status checks w ochronie gałęzi czynią je wiążącym.
Agent nie może go edytować. Pliki sprawdzenia są w CODEOWNERS z seniorem jako właścicielem, więc każda ich zmiana wymaga jego zgody.
Dziennik pilotażu pokazuje, że działa. Przez cztery tygodnie kolumny „bramka przeszła za pierwszym razem” i „poprawki w ciągu 14 dni” pokazują, czy bramka łapie problemy przed merge’em, czy dopiero po nim.

Senior zatwierdza przejście pętli na review oparte na dowodach. Ty zatwierdzasz regułę decyzji i przyjęcie jej wyniku, także negatywnego.

Kiedy przekonywanie sceptyków się nie udaje

Zadania w pilotażu były łatwe i wszyscy o tym wiedzą. Pilotaż na poprawkach literówek i aktualizacjach README nikogo nie przekona, a resztę wprowadzi w błąd. Wyjście: powtórz go na zadaniach, które senior wybrał z własnego backlogu i które przydzielono losowo, i powiedz otwarcie, dlaczego pierwsza runda się nie liczy.

Senior prowadził pilotaż, żeby udowodnić, że się nie uda. Objawy: zadania agenta bez spisanej bramki, porzucone sesje albo zawyżone estymaty w grupie „ręcznie”. Wyjście: nie kłóć się o intencje. Dodaj drugą osobę, która co tydzień czyta dziennik, i wymagaj wyniku promptu bramki dla każdego zadania agenta, zanim zostanie policzone.

Wynik był negatywny, a ty go uchyliłeś. Tracisz tego seniora i wszystkich, którzy patrzyli. Wyjście: uszanuj wynik dla tego rodzaju zadań, zapisz powód i datę powtórki za kwartał, i powtórz pilotaż, gdy zmienią się modele albo bramka.

Seniorzy zostali recenzentami wszystkich. Pull requesty agentów trafiają do ludzi, którzy najmniej im ufają, a seniorzy spędzają tygodnie na czytaniu diffów. Wyjście: ogranicz obciążenie review na osobę, wymagaj pakietu dowodów, zanim senior zostanie przypisany, i stosuj limity z kolejki code review.

Zarzut seniora był trafny, a nikt go nie zapisał. Błąd współbieżności z przykładowego dziennika ma wartość tylko wtedy, gdy zmienia system. Wyjście: w ciągu tygodnia każda notatka o poprawce lub defekcie staje się nowym sprawdzeniem albo nową klasą eskalacji, której właścicielem jest senior, który ją znalazł.

Cele użycia wróciły tylnymi drzwiami. Dashboard sesji na inżyniera pojawia się znowu na przeglądzie kierownictwa, a seniorzy zaczynają nabijać sesje, żeby mieć spokój. Wyjście: wyjmij dashboard z rozmów o ocenie pracy i raportuj tylko miary wyniku, w podziale na pętle.

Dokąd dalej w pracy ze sceptykami i seniorami

Mapa drogi adopcji Następny krok: wdrażaj po jednej pętli, zaczynając od tej, którą przeszedł pilotaż seniora.

Frameworki metryk Warunek wstępny: miary wyniku, które zastępują cele użycia w całym zespole.

Siła wyroczni Jak sprawdzenia seniorów dowodzą, że potrafią nie przejść, z testami mutacyjnymi zmienionych plików.

Transfer zaufania Etapowy protokół, który przenosi pętlę od czytania każdego diffa do czytania dowodów.

Czytanie dowodów zamiast kodu Co senior czyta zamiast diffa i które klasy zmian zawsze wymagają lektury kodu.

Rozwój juniorów Druga połowa pytania o ludzi: co juniorzy wciąż ćwiczą ręcznie.

Najczęstsze pytania

Jak przekonać seniora, który nie ufa agentom AI?

Nie przez dyskusję ani demo. Każdy zarzut zamieniasz na lukę w weryfikacji, senior dostaje na własność sprawdzenie, które ją zamyka, i prowadzi mierzony pilotaż na zadaniach z własnego backlogu, z regułą decyzji spisaną przed pierwszym zadaniem.

Czy badanie METR dowodzi, że AI spowalnia doświadczonych programistów?

Dowodzi tego dla jednego układu: w badaniu METR z 2025 roku zadania 16 doświadczonych programistów open source trwały z AI o 19% dłużej, a wynik był istotny statystycznie. Estymaty punktowe z 2026 roku wypadają na korzyść AI, ale przedziały obejmują zero, a METR sam nazywa te dane niewiarygodnym sygnałem.

Co zrobić, gdy pilotaż pokaże, że agent seniorowi nie pomaga?

Przyjąć wynik dla tej klasy zadań, zostawić ją ręczną, zapisać powód i datę powtórki, i iść dalej. Pilotaż, który może skończyć się tylko wdrożeniem, jest pokazem, a sceptycy od razu to widzą.