Jak przeprowadzić ludzi przez zmianę

Przeprowadzenie ludzi przez zmianę w stronę inżynierii agentowej to trzy ruchy w stałej kolejności: opublikowanie jasnego stanowiska wobec AI, uczciwa odpowiedź na pytanie o zastąpienie ludzi i rozszerzanie użycia agentów tylko tak szybko, jak nadąża weryfikacja. DORA wymienia jasne, zakomunikowane stanowisko wobec AI jako pierwszą z siedmiu zdolności AI Capabilities Model i jedyną, którą zapewnić może wyłącznie kierownictwo.

Ta strona jest dla członka zarządu, który sponsoruje zmianę, dla CTO, który za nią odpowiada, i dla tech leada, który w poniedziałek musi to powiedzieć na głos. Sytuacja wyjściowa: licencje rozdane, menedżer jednego z dostawców powiedział w podcaście, że tytuł „software engineer” zniknie, a twoja najlepsza seniorka zapytała na all-handsie, czy zespół jest właśnie zastępowany. Połowa inżynierów po cichu używa agentów i nikomu o tym nie mówi, druga połowa odmawia, a nikt już nie wie, jak wygląda „dobra robota”.

Co możesz wdrożyć z tego przewodnika po zmianie

Szablon jednostronicowego stanowiska wobec AI do opublikowania w tym tygodniu, z ośmioma punktami, o które pytają inżynierowie
Tabelę decyzyjną: co możesz uczciwie obiecać w sprawie etatów i jakimi słowami to powiedzieć
Tabelę komunikatów dla inżynierii, produktu, finansów, HR i klientów
Sekwencję sześciu kroków, która utrzymuje wskaźnik nieudanych zmian i czas review na poziomie wyjściowym, gdy adopcja rośnie
Ustawienia, dzięki którym stanowisko jest widoczne w Claude Code, Codex i Cursorze
Cztery definicje metryk i ankietę pulsową, które pokazują, czy zmiana się przyjmuje
Prompt do skopiowania, który tworzy szkic stanowiska z polityk, które już masz

Dlaczego to ludzie decydują, czy jakość się utrzyma

Agenci zmieniają koszt wytworzenia zmiany, a nie koszt jej weryfikacji. Raport DORA 2025 (Google Cloud, 23 września 2025) stwierdził „a positive relationship between AI adoption on both software delivery throughput and product performance”, a w tej samej publikacji: „However, AI adoption does continue to have a negative relationship with software delivery stability.” Główna teza raportu wyjaśnia dlaczego: „AI doesn’t fix a team; it amplifies what’s already there.”

To ludzie decydują, w którą stronę działa ten wzmacniacz. W czasie wdrożenia jakość psują trzy zachowania i każde z nich jest porażką przywództwa, zanim stanie się problemem narzędzi:

Ukryte użycie. Bez stanowiska inżynierowie, którzy używają agentów, nie mówią o tym, więc recenzenci nie wiedzą, jak uważnie czytać zmianę.
Zaufanie bez weryfikacji. Ankieta Sonar wśród ponad 1100 programistów (8 stycznia 2026) wykazała: „96% of developers do not fully trust AI-generated code, and only 48% always verify it before committing.” Brak zaufania bez nawyku weryfikacji to najgorsze możliwe połączenie.
Produkcja napędzana strachem. Inżynierowie, którzy wierzą, że porównuje się ich z agentem, optymalizują widoczny wolumen. A wolumenu review nie jest w stanie wchłonąć.

Zmienia się też sama praca. Wewnętrzne badanie Anthropic wśród 132 inżynierów i badaczy (2 grudnia 2025, deklaracje samych badanych) pokazało, że inżynierowie opisują siebie jako „manager[s] of AI agents”, a część mówi, że ich praca przesunęła się „70%+ to being a code reviewer/reviser rather than a net-new code writer”. Inżynierowie czują tę zmianę, zanim nazwie ją kierownictwo. Stanowisko ma przede wszystkim nazwać ją, zanim zrobią to sami inżynierowie. Szczegółowo opisuje to strona co zostaje człowiekowi w inżynierii agentowej.

Dlaczego stanowisko wobec AI jest pierwsze

AI Capabilities Model DORA (Google Cloud, 23 września 2025), zbudowany na 78 pogłębionych wywiadach i ankiecie, która „reached almost 5,000 respondents”, wymienia siedem zdolności wzmacniających korzyści z AI. Pierwsza to jasne i zakomunikowane stanowisko wobec AI (clear and communicated AI stance). Uzasadnienie samego DORA (Nathen Harvey i Allison Park, 10 grudnia 2025): „Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively.”

Pozostałe sześć (zdrowy ekosystem danych, dane wewnętrzne dostępne dla AI, solidne praktyki kontroli wersji, praca w małych partiach, skupienie na użytkowniku i wysokiej jakości platformy wewnętrzne) to praca inżynierska. Stanowisko jest jedyną zdolnością, którą może dostarczyć tylko kierownictwo, i kosztuje jedną stronę. Samoocena według modelu DORA punktuje wszystkie siedem.

Stanowisko to nie polityka użytkowania. Polityka użytkowania to egzekwowalny regulamin dotyczący narzędzi, danych i licencji. Stanowisko to krótka, publiczna odpowiedź na pytanie „czego chce kierownictwo i co będzie ze mną?”, napisana tak, żeby inżynier przeczytał ją w trzy minuty. Podlinkuj z niego politykę, ale jej nie wklejaj.

NASZE STANOWISKO WOBEC AGENTÓW AI W INŻYNIERII    Wersja 1 · Właściciel: CTO · Przegląd: co kwartał

1. Czego chcemy. Oczekujemy, że każdy inżynier używa agentów kodujących tam,
   gdzie pomagają, i mówi, kiedy ich użył. Użycia agenta nigdy się nie ukrywa.
2. Co mogą agenci. Agenci mogą pisać kod, testy, dokumentację i pull requesty
   w zatwierdzonych narzędziach (lista w polityce użytkowania). Działają
   z uprawnieniami skonfigurowanymi przez zespół platformowy, nie z prywatnymi
   tokenami.
3. Co zostaje po stronie ludzi. Za każdą scaloną zmianę odpowiada wskazana
   z imienia i nazwiska osoba. Agenci dostają pracę do wykonania; nigdy nie są
   jej właścicielem.
4. Jak oceniamy jakość. Zmianę oceniamy po dowodach (kryteria akceptacji,
   testy, których agent nie może edytować, CI, review), a nie po tym, kto ją
   napisał. Zmiana bez dowodów nie zostaje scalona, niezależnie od autora.
5. Czego nie mierzymy. Nie oceniamy ludzi po użyciu agentów, liczbie promptów,
   wygenerowanych liniach ani „% kodu z AI”. Te liczby nigdy nie trafiają do
   oceny okresowej.
6. Etaty i zatrudnienie. [Wybierz jedno zdanie z tabeli decyzyjnej.]
7. Umiejętności. Każdy inżynier dostaje [N] godzin miesięcznie chronionego
   czasu na naukę, a rekrutacja juniorów trwa dalej.
8. Jak się nie zgodzić. Zgłoś zastrzeżenia swojemu tech leadowi lub na kanale
   #ai-stance. Na każdym przeglądzie kwartalnym publikujemy, co zmieniliśmy
   w odpowiedzi na nie.

Linki: polityka użytkowania · poziomy nadzoru i autonomii · ścieżka kariery

Zanim opublikujesz, zastąp [N] prawdziwą liczbą, a punkt 6 wypełnij na podstawie następnej sekcji. Każdy punkt to obietnica, którą ktoś sprawdzi, więc pomiń te, których nie jesteś w stanie dotrzymać.

Co mówić inżynierom, którzy boją się, że zostaną zastąpieni

Inżynierowie czytają te same media co ty. The San Francisco Standard (19 lutego 2026, relacja z podcastu Y Combinator, a więc źródło z drugiej ręki) przytoczył słowa Borisa Cherny’ego z Anthropic: „We’re going to start to see the title of software engineer go away.” Udawanie, że zespół tego nie słyszał, kosztuje cię zaufanie całej sali.

Uczciwa odpowiedź ma trzy części: co wiesz, czego nie wiesz i co zdecyduje o wyniku. Wybierz wiersz, który naprawdę opisuje twoją sytuację.

Twoja faktyczna sytuacja	Co możesz powiedzieć	Czego nie wolno ci mówić
Zarząd zobowiązał się na piśmie, że przez określony czas nie będzie redukcji z powodu AI	„Do [data] żaden etat nie zostanie zlikwidowany z powodu agentów. Potem o zatrudnieniu decyduje proces opisany w stanowisku, przeglądany co kwartał.”	„Nikt nigdy nie straci pracy.” Zobowiązuj się tylko na okres, który jest zapisany.
Takiego zobowiązania nie ma, a o zatrudnieniu decydują zmierzone ograniczenia	„Nie mogę obiecać liczby etatów. Mogę obiecać, jak zapada decyzja: na podstawie ośmiu tygodni danych o review, jakości i backlogu, najpierw przez rekrutację i naturalną rotację, na kwartalnym przeglądzie, którego wyniki zobaczysz.”	„Nie przejmuj się.” Uspokajanie bez mechanizmu brzmi jak ostrzeżenie.
Redukcje są już zaplanowane z powodów biznesowych	Najpierw poinformuj osoby, których to dotyczy, przez HR, przed jakimkolwiek ogłoszeniem o AI. Nie przedstawiaj cięć jako sukcesu agentów.	Wiązanie zwolnień z wdrożeniem, które ludzie wciąż mają prowadzić. To obraca każdego pozostałego inżyniera przeciwko narzędziu.

Strona jak zmieniają się zespoły, role i zatrudnienie zawiera tabelę zmierzonych ograniczeń stojącą za drugim wierszem: który sygnał oznacza, że wąskim gardłem jest review, który, że intencja, i kiedy przepustowość naprawdę się uwalnia.

Potem odpowiedz na pytania, które padają zaraz po pierwszym. Pojawiają się na każdym all-handsie:

Pytanie inżynierów	Uczciwa odpowiedź do dostosowania
„Na czym teraz polega moja praca?”	Na decydowaniu, co zbudować, opisaniu tego tak, żeby agent nie mógł tego źle zrozumieć, projektowaniu kontroli, które dowodzą, że działa, i odpowiadaniu za wynik. Przesunęło się pisanie, nie odpowiedzialność.
„Czy będę porównywany z agentem?”	Nie. Punkt 5: użycie i wolumen nigdy nie trafiają do oceny. Oceniamy wyniki i jakość dowodów stojących za twoimi zmianami.
„A co z juniorami?”	Dalej zatrudniamy osoby na początku kariery i zmieniliśmy sposób, w jaki się uczą. Zobacz plan dla juniorów.
„A jeśli uważam, że to pogarsza sprawę?”	To pomóż nam to zmierzyć. Sceptycy projektują kontrole dla swojego obszaru i prowadzą pilotaż na własnych zadaniach.
„Kto odpowiada, gdy agent się myli?”	Wskazany człowiek, który scalił zmianę, i dlatego nic nie jest scalane bez dowodów. Linear ujął tę zasadę wprost: „an agent cannot be held accountable” (1 sierpnia 2025).

Szczegóły są na dwóch sąsiednich stronach: rozwój juniorów, gdy kod piszą agenci w sprawie ścieżki talentów oraz jak przekonać sceptyków i seniorów w sprawie rozmowy jeden na jeden.

Co mówić reszcie firmy

Każdy dział słyszy tę samą zmianę jako inne ryzyko. Powiedz tę część, która dotyczy jego, razem z metryką, którą będzie oglądał.

Odbiorca	Jego pytanie	Komunikat	Metryka, którą zobaczy
Produkt	„Czy inżynieria będzie teraz dostarczać wszystko szybciej?”	Czas budowania spada; wąskim gardłem staje się decyzja, co budować, i pisanie kryteriów akceptacji. Produkt odpowiada za intencję bardziej bezpośrednio niż dotąd.	Lead time od zaakceptowanej specyfikacji do produkcji
Finanse	„Gdzie są oszczędności?”	Zaoszczędzony czas to nie zaoszczędzona gotówka. Raportujemy koszt zaakceptowanej zmiany, łącznie z review i poprawkami.	Koszt zaakceptowanej zmiany, kwartalnie
HR i ludzie	„Które role i ścieżki kariery się zmieniają?”	Role przesuwają się w stronę specyfikowania i weryfikacji; ścieżka kariery nagradza jakość dowodów i osąd, nie wolumen.	Odejścia, których żałujemy; wykorzystane godziny nauki
Bezpieczeństwo i dział prawny	„Co wychodzi poza firmę?”	Agenci działają w zatwierdzonych narzędziach z zarządzaną polityką i tożsamościami usługowymi; dane reguluje polityka użytkowania.	Naruszenia polityki; sekrety ujawnione w sesjach
Klienci	„Czy nasze oprogramowanie pisze AI?”	Każda zmiana jest weryfikowana według tego samego standardu dowodów, niezależnie od autora. Ujawniaj użycie agentów tam, gdzie wymagają tego umowy.	Wskaźnik nieudanych zmian; trend incydentów

Perspektywę produktu opisuje strona zarządzanie produktem, gdy budowanie trwa godziny, a finansów — ekonomia oprogramowania budowanego przez agentów.

Ułóż zmianę tak, żeby jakość nie spadła

Kolejność jest ważniejsza niż tempo. Każdy krok poniżej ma warunek wyjścia, a następny zaczyna się dopiero wtedy, gdy ten warunek jest spełniony.

Opublikuj stanowisko (tydzień 1). CTO publikuje jednostronicowe stanowisko, sponsor z zarządu popiera je na piśmie, a każdy tech lead omawia je ze swoim zespołem na spotkaniu, nie tylko mailem. Warunek wyjścia: każdy zespół je przedyskutował, a pytania są zapisane.
Słuchaj i zmierz punkt wyjścia (tygodnie 1–3). Przeprowadź ankietę pulsową z dalszej części strony i zapisz dla każdego zespołu wskaźnik nieudanych zmian, medianę czasu review i rozmiar pull requestów. Warunek wyjścia: punkt odniesienia dla każdego zespołu, zapisany, zanim cokolwiek innego się zmieni.
Oddaj kontrole w ręce sceptyków (tygodnie 2–6). Poproś najbardziej sceptycznego seniora w każdym obszarze, żeby zdefiniował, co tam znaczy „zweryfikowane”, i przeprowadził zmierzony pilotaż na własnych zadaniach według projektu pilotażu. Warunek wyjścia: w każdym obszarze co najmniej jedna kontrola, która nie przechodzi na znanym złym przykładzie i blokuje scalenie w CI.
Zbuduj weryfikację przed autonomią (tygodnie 4–12). Zabezpiecz testy przed edycją przez agenta, wymagaj pakietu dowodów przy każdym pull requeście i ustal limity rozmiaru pull requestów, żeby review nadążało. Warunek wyjścia: czas review i wskaźnik nieudanych zmian na poziomie wyjściowym lub lepszym przez cztery tygodnie.
Rozszerzaj pętla po pętli, nie dekretem (od 3. miesiąca). Przesuwaj jedną pętlę dostarczania naraz w górę drabiny autonomii, przez protokół przekazywania zaufania. Warunek wyjścia dla każdej pętli: dowody dla jej bramki podpisane przez wskazaną osobę.
Zmień ścieżki kariery i oceny (do 6. miesiąca). Zaktualizuj ścieżki kariery i kryteria ocen tak, żeby nagradzały specyfikowanie, weryfikację i osąd, i usuń każdą miarę wolumenu. Warunek wyjścia: następny cykl ocen odbywa się według nowych kryteriów.

Zespół, u którego pojawi się sygnał stopu, wraca do poprzedniego kroku. Sygnały stopu to: wskaźnik nieudanych zmian powyżej punktu odniesienia przez dwa tygodnie, mediana czasu review rosnąca przez cztery tygodnie albo defekt, który uciekł na produkcję i wynika z niezweryfikowanej zmiany agenta. Ogłaszaj wycofanie w tym samym kanale co postępy, żeby cofnięcie się było odbierane jako proces, który działa. Mapa transformacji dla organizacji prowadzi te same bramki w skali całej firmy przez 12 miesięcy.

Pokaż stanowisko w każdym narzędziu

Stanowisko przeczytane raz jest zapomniane przed następnym sprintem. Umieść części dotyczące każdej sesji tam, gdzie sesja się zaczyna, a części, których agent musi przestrzegać, w jego instrukcjach. Mechanizmy różnią się między narzędziami; stanowisko nie.

Ustawienia zarządzane (plik managed-settings.json, MDM albo ustawienia zarządzane z serwera z konsoli claude.ai (plany Team i Enterprise)) nadpisują wszystkie ustawienia użytkownika i projektu. companyAnnouncements pokazuje komunikaty organizacji przy starcie; przy kilku wpisach Claude Code losuje jeden na każdą sesję, a przy pierwszym uruchomieniu u danej osoby pokazuje pierwszy.

{
  "companyAnnouncements": [
    "Our AI stance: use agents and say so in the PR. Nothing merges without evidence. https://wiki.example.com/ai-stance"
  ],
  "availableModels": ["opus", "sonnet"],
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Punkty skierowane do agenta (ujawnij w opisie pull requesta, że zmianę napisał agent; nigdy nie edytuj chronionych testów) umieść w pliku CLAUDE.md repozytorium. Klucze ustawień sprawdzone w dokumentacji ustawień Claude Code 26 września 2026 (v2.1.283).

Codex oddziela wartości domyślne, które użytkownik może zmienić (config.toml), od ograniczeń ustawianych przez administratora (requirements.toml), których użytkownik nie nadpisze. Ograniczenia sprawiają, że punkt 2 stanowiska („agenci działają z uprawnieniami skonfigurowanymi przez zespół platformowy”) jest prawdziwy dzięki mechanizmowi, a nie deklaracji:

# requirements.toml — egzekwowane przez administratora
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approval_policies = ["untrusted", "on-request"]
allow_managed_hooks_only = true

allowed_sandbox_modes ogranicza starszą oś sandboksa. Nowszym mechanizmem są profile uprawnień (beta), a requirements.toml może zamiast tego przypiąć permission_profile; wybierz jeden system, bo według OpenAI profile i starszy sandbox „do not compose”.

Codex czyta AGENTS.md przed rozpoczęciem pracy, więc tam umieść punkty skierowane do agenta: w opisie pull requesta podaj, że zmianę napisał agent i jakie kontrole zostały uruchomione, i nigdy nie modyfikuj plików w chronionych ścieżkach testów. Nazwy kluczy sprawdzone w źródłach openai/codex 26 września 2026 (CLI 0.157.1).

Wspólne mechanizmy kontroli w Cursorze to Rules, Hooks i Plugins; plugin pakuje reguły, skille, agentów, komendy, serwery MCP i hooki w jedną paczkę do dystrybucji (sprawdzone w dokumentacji Cursora 28 sierpnia 2026). Punkty stanowiska skierowane do agenta umieść w regule projektu zacommitowanej do repozytorium. Ścieżki testów chroń poza narzędziem, przez CODEOWNERS i wymagane kontrole CI, tak żeby ochrona działała niezależnie od tego, który agent otworzył pull request.

Ustawień administracyjnych Cursora na poziomie organizacji nie dało się zweryfikować ze środowiska, w którym powstawała ta strona (26 września 2026). Zanim opiszesz je w stanowisku, sprawdź w konsoli administracyjnej Cursora, które ustawienia egzekwuje twój plan.

Pełne porównanie warstwy kontroli wszystkich trzech narzędzi znajdziesz na stronie jedna polityka dla wszystkich agentów kodujących.

Przygotuj szkic stanowiska z tego, co już masz

Większość organizacji ma już politykę akceptowalnego użytkowania, standard bezpieczeństwa i ścieżkę kariery. Stanowisko musi być spójne ze wszystkimi trzema. Ten prompt działa w Claude Code, Codex i agencie Cursora, uruchomiony w katalogu z tymi dokumentami.

Read every document in this folder: our acceptable-use policy, security standard,
career ladder and any existing AI tool guidance.

Draft a one-page "stance on AI agents in engineering" with exactly these eight
clauses: what we want, what agents may do, what stays human, how quality is judged,
what we will not measure, jobs and headcount, skills, how to disagree.

Rules:
- Every clause must be consistent with the source documents. Where a clause would
  contradict one, write the contradiction as an open question instead of a clause.
- Clause 5 must exclude usage counts, lines generated and "% of code by AI" from
  performance reviews. If the career ladder rewards output volume, flag it.
- Leave clause 6 as "[LEADERSHIP DECISION REQUIRED]". Do not invent a commitment.
- Maximum 400 words. Plain sentences, no marketing language.
- Write the draft in Polish.

Then list every open question, each with the source document and section that
caused it. Do not edit any source file.

Jak sprawdzić, że zmiana się przyjmuje, a jakość nie spada

Nikt nie czyta każdego diffa, żeby ocenić wdrożenie. Oceniaj je na podstawie czterech miar z repozytorium, CI, systemu incydentów i krótkiej ankiety. Każdy wzrost adopcji, któremu towarzyszy spadek jakości, traktuj jako porażkę.

Miara	Definicja	Cel w trakcie zmiany	Właściciel
Wskaźnik nieudanych zmian	Wdrożenia, które wymagały wycofania, hotfixa lub spowodowały incydent ÷ wszystkie wdrożenia, dla każdego zespołu	Na poziomie punktu odniesienia z kroku 2 lub niżej	Tech lead
Mediana czasu review	Od otwarcia pull requesta do zatwierdzenia, dla każdego zespołu	Nie rośnie przez cztery kolejne tygodnie	Engineering manager
Jasność stanowiska	Odsetek odpowiedzi „zgadzam się” lub „zdecydowanie się zgadzam” na P1 i P2 ankiety pulsowej	Rośnie co kwartał	CTO
Ukryte użycie	Odsetek odpowiedzi „zgadzam się” lub „zdecydowanie się zgadzam” na P4	Spada w stronę zera	CTO

Kanoniczne definicje wskaźnika nieudanych zmian i czasu review są na stronie ramy metryk; używaj ich zamiast lokalnych wariantów.

Odpowiedz na każde pytanie w skali 1–5: zdecydowanie się nie zgadzam … zdecydowanie się zgadzam.

P1. Wiem, co wolno mi robić z agentami kodującymi w pracy.
P2. Wiem, jak oceniana jest jakość zmiany napisanej przez agenta.
P3. Wierzę, że decyzje o zatrudnieniu zapadają tu tak, jak opisuje stanowisko.
P4. Używam agentów w sposób, o którym mój zespół nie wie.
P5. Mam czas, którego potrzebuję, żeby nauczyć się tak pracować.
P6. Kiedy zmiana agenta jest błędna, potrafię to zauważyć przed scaleniem.

Pytanie otwarte: Co warto zmienić w naszym stanowisku wobec AI?

Wyniki pokazuj per zespół tylko tam, gdzie odpowiedziało co najmniej pięć osób, tak żeby żadnej odpowiedzi nie dało się przypisać. P3 i P6 to wskaźniki wyprzedzające: niskie zaufanie do procesu zapowiada odejścia, a niska pewność w wychwytywaniu błędów zapowiada incydenty.

Kto odpowiada za którą część zmiany

Decyzja	Sponsor z zarządu	CTO	Tech lead	HR
Stanowisko i jego punkt o zatrudnieniu	Odpowiada (A)	Wykonuje (R)	Konsultowany	Konsultowany
Co każdy zespół uznaje za „zweryfikowane”	Informowany	Odpowiada (A)	Wykonuje (R)	—
Sygnały stopu i wycofania w zespołach	Informowany	Odpowiada (A)	Wykonuje (R)	—
Ścieżka kariery i kryteria ocen	Informowany	Odpowiada (A)	Konsultowany	Wykonuje (R)
Odpowiadanie na pytania o zastąpienie ludzi	Wykonuje (R)	Wykonuje (R)	Wykonuje (R)	Konsultowany

Ostatni wiersz jest celowy: każdy lider odpowiada na to pytanie tymi samymi słowami, z tej samej tabeli decyzyjnej.

Co idzie nie tak, gdy liderzy ogłaszają zmianę?

Ogłoszenie obiecuje szybkość. Objaw: inżynierowie słyszą „oczekujemy, że będziecie szybsi”, wolumen rośnie, a czas review się wydłuża. Naprawa: powtórz, że jakość ocenia się po dowodach i że żadna miara wolumenu nie trafia do oceny, a potem egzekwuj limity rozmiaru pull requestów.

Kierownictwo za bardzo uspokaja. Objaw: pada „nikt nie straci pracy” bez pisemnego zobowiązania, a zaufanie upada przy pierwszej niezwiązanej redukcji. Naprawa: sprostuj to publicznie i zastąp zdaniem o procesie z tabeli decyzyjnej. Poprawiona obietnica kosztuje mniej niż złamana.

Pojawia się ranking użycia. Objaw: dashboard szereguje ludzi lub zespoły według liczby sesji z agentem albo linii napisanych przez AI. Naprawa: zdejmij go tego samego dnia. Łamie punkt 5 i nagradza wolumen, którego review nie wchłonie.

Adopcja jest nakazana, zanim istnieje weryfikacja. Objaw: wskaźnik nieudanych zmian rośnie w ciągu kilku tygodni od odgórnego wdrożenia. Naprawa: cofnij dotknięte zespoły do kroku 4 i otwarcie ogłoś wycofanie.

Sceptyków się omija, zamiast ich zaangażować. Objaw: seniorzy publicznie się podporządkowują, a po cichu przestają uważnie recenzować zmiany agentów. Naprawa: przekaż im odpowiedzialność za kontrole w ich obszarze, jak w kroku 3.

Juniorzy znikają z planu. Objaw: rekrutacje juniorów są po cichu zamykane. Naprawa: przywróć punkt 7 i realizuj plan dla juniorów. Wewnętrzne badanie Anthropic nazywa to ryzyko „paradox of supervision”: nadzór wymaga umiejętności, które nadmierne delegowanie osłabia.

Dokąd dalej w przewodzeniu zmianie

Jak zmieniają się zespoły, role i zatrudnienie Tabela zmierzonych ograniczeń stojąca za każdą odpowiedzią o etatach.

Jak przekonać sceptyków i seniorów Rozmowa jeden na jeden i pilotaż na własnych zadaniach seniora.

Mapa transformacji dla organizacji Te same bramki w skali całej firmy przez 12 miesięcy.

Model DORA AI Capabilities Oceń pozostałe sześć zdolności po stanowisku.

Rozwój juniorów Utrzymaj ścieżkę talentów, gdy kod piszą agenci.

Raportowanie inżynierii AI zarządowi Raportuj zmianę z miarami jakości i ludzi obok siebie.

Najczęstsze pytania

Od czego zacząć wdrażanie agentów kodujących w organizacji?

Od opublikowania jednostronicowego stanowiska wobec AI: co agenci mogą robić, co zostaje po stronie ludzi, jak oceniamy jakość i jak zapadają decyzje o zatrudnieniu. DORA wymienia jasne i zakomunikowane stanowisko wobec AI jako pierwszą z siedmiu zdolności w swoim AI Capabilities Model.

Czy CTO powinien obiecać inżynierom, że nikt nie straci pracy przez AI?

Tylko jeśli zarząd zobowiązał się do tego na piśmie i z datą. W przeciwnym razie powiedz, co naprawdę decyduje o zatrudnieniu, kiedy jest to przeglądane i jakie wsparcie dostają ludzie. Nigdy nie obiecuj więcej, niż kontrolujesz.

Jak nie dopuścić do spadku jakości, gdy zespoły wdrażają agentów?

Zbuduj weryfikację przed autonomią: chronione testy, dowody przy każdym pull requeście i sygnały stopu dla każdej pętli. Rozszerzaj użycie agentów dopiero wtedy, gdy wskaźnik nieudanych zmian i czas review trzymają się punktu odniesienia.