Historie sukcesu AI w programowaniu: studia przypadków, które się bronią

Studiów przypadków AI w programowaniu, które wytrzymują weryfikację, jest niewiele i wszystkie mają daty: Minions w Stripe (ponad 1300 pull requestów od agentów scalanych tygodniowo, luty 2026), badanie Microsoftu nad wdrożeniem Claude Code i GitHub Copilot CLI (około 24% więcej scalonych pull requestów, lipiec 2026) oraz zespoły Anthropic. Każde skalowało się dzięki weryfikacji, nie samemu agentowi.

Zarząd przesłał ci prezentację, która obiecuje „10x wydajności inżynierów”, a CFO pyta, czy firma powinna w to wejść. Każdy przykład w tej prezentacji to logo, okrągła liczba i zero metodologii. Ta strona jest dla CTO i członka zarządu, który musi zdecydować, którym historiom wierzyć, czego one dowodzą i co skopiować najpierw, oraz dla tech leada, który potem prowadzi i zatwierdza pierwsze odtworzenie wzorca.

Co z tych studiów przypadków przeniesiesz do planu?

• Weryfikowalne studia przypadków w jednej tabeli, każde z wydawcą, datą, mierzoną wielkością i zastrzeżeniem, gotowe do wklejenia w notatkę planistyczną
• Kontrdowody w pełnej sile, żeby plan przetrwał pierwszego sceptyka, który czytał METR albo Faros
• Siedem pytań kontrolnych i prompt do skopiowania, którym zweryfikujesz każde studium przypadku od dostawcy
• Jeden wzorzec z tych danych (pętlę agenta z twardym limitem), który zespół odtworzy na własnym backlogu jeszcze w tym tygodniu, w Claude Code, Codeksie albo Cursorze
• Szablon opisu własnego, wewnętrznego studium przypadku, tak żeby liczył się jako dowód

Którym studiom przypadków AI w programowaniu można ufać?

Studium przypadku zasługuje na miejsce w planie, gdy mówi, co zmierzono, u kogo, kiedy i kto to opublikował. Tabela zawiera te, które spełniają ten próg na dzień 2026-09-26. Wszystkie pochodzą od dostawców albo z ich otoczenia, więc traktuj każde jako fakt o tamtej firmie, a nie prognozę dla twojej.

Przypadek	Co zmierzono	Wynik	Wydawca, data	Zastrzeżenie
Stripe Minions	Pull requesty scalane tygodniowo bez kodu napisanego przez człowieka	Ponad 1300 tygodniowo, każdy przejrzany przez człowieka	Stripe, Alistair Gray, Minions, część 2, 2026-02-19	Jedna firma; liczba pull requestów, nie dostarczonej wartości
Wdrożenie agentów CLI w Microsofcie	Scalone pull requesty użytkowników wobec scenariusza kontrfaktycznego	Około 24% więcej pull requestów, efekt utrzymany przez cztery miesiące	Murphy-Hill, Butler i Savelieva, arXiv 2607.01418, 2026-07-01	Słowami autorów: scalony PR to nie to samo, co wartość, którą dostarcza
Anthropic, scalony kod	Udział linii scalonych na produkcję, przypisanych Claude	Ponad 80% w maju 2026, wobec kilku procent przed lutym 2025	Anthropic, When AI builds itself (zdanie o ponad 80% ma datę „As of May 2026”; strona zawiera aktualizację z 2026-09-18 o sukcesie sesji ocenianym przez LLM, który nie jest miarą jakości; odczyt 2026-09-26)	Dostawca mierzy własny produkt; linie, nie praca
Anthropic, ankieta wewnętrzna	Deklarowany udział w pracy i wzrost produktywności	Claude w 60% pracy, deklarowany wzrost produktywności o 50%	Anthropic, How AI is transforming work at Anthropic, 2025-12-02	Ankieta wśród 132 inżynierów i badaczy; deklaracje, nie telemetria
Przepływy pracy zespołów Anthropic	Konkretne przepływy pracy, kilka pomiarów czasu	20 minut oszczędności podczas awarii; do 100 wariantów reklam w jednej partii	Anthropic, How Anthropic teams use Claude Code, 2025-07-24	Anegdoty; przydatne jako przepływ pracy, nie jako prognoza
Google, udział nowego kodu	Udział nowego kodu generowanego przez AI	75%	Sundar Pichai na Google Cloud Next, według relacji Fast Company, 2026-04-24	Źródło wtórne: nie dotarliśmy do transkrypcji Google; cytuj jako doniesienie prasowe

Obok nich postaw liczbę dla całej branży, czyli dane DX: w danych z ponad 400 firm z drugiego kwartału 2026 roku średnio 51,9% kodu jest autorstwa AI (DX, 2026-06-17). To deklarowany udział kodu i nie mówi nic o tym, czy ten kod był wart napisania.

Jak Stripe doprowadził agentów do ponad 1300 pull requestów tygodniowo?

Wpisy o Minions w Stripe szczegółowo opisują, jak agenci dostarczają kod produkcyjny na dużą skalę, a cały opis dotyczy weryfikacji. Dwa wpisy Alistaira Graya (2026-02-09 i 2026-02-19) wymieniają cztery składniki:

1. Wyrocznia istniała przed agentami. Pętla działa na ogromnym zestawie testów, który Stripe miał już wcześniej: ponad trzech milionach testów. Agenci odziedziczyli system weryfikacji; nie przynieśli własnego.
2. Twardy limit ponownych prób. Minion dostaje najwyżej dwie rundy CI. Jeśli testy padną po pierwszym pushu, poprawia je i pushuje jeszcze raz, a potem gałąź wraca do człowieka, który ją nadzoruje, do ręcznej kontroli.
3. Deterministyczna struktura wokół agenta. Blueprints to przepływy zdefiniowane w kodzie, które sterują przebiegiem miniona: maszyna stanów łącząca deterministyczne węzły kodu z węzłami agenta.
4. Narzędzia podłączone raz dla wszystkich. Toolshed zawiera prawie 500 narzędzi MCP dla systemów wewnętrznych i platform SaaS (część 2). Sam agent to fork agenta goose od Block.

Każdy pull request nadal przegląda człowiek. Zmieniło się to, co recenzent dostaje: gałąź, która przeszła już zestaw milionów testów, a nie surowy diff. To wzorzec, który na tej stronie nazywamy dowodami zamiast diffów.

Co zmierzyło badanie wdrożenia w Microsofcie?

Praca Microsoftu to największe badanie adopcji w tabeli: dziesiątki tysięcy inżynierów Microsoftu w trakcie wdrożenia Claude Code i GitHub Copilot CLI na początku 2026 roku. Osoby, które zaczęły używać tych narzędzi, scaliły około 24% więcej pull requestów, niż scaliłyby bez nich, a efekt utrzymał się przez całe czteromiesięczne okno badania.

Dla planu wdrożenia ważniejsze od nagłówka są dwa ustalenia. Po pierwsze, pierwsze użycie rozchodziło się głównie przez sieci kontaktów między współpracownikami: adopcję napędzali koledzy, nie odgórne polecenia, i dlatego adopcja w zespole zaczyna się od liderów zmiany. Po drugie, autorzy mierzyli scalone pull requesty jako przybliżenie efektu i otwarcie to napisali. Zachowaj w planie tę samą uczciwość: licz zaakceptowane zmiany i wyceniaj je kosztem zaakceptowanej zmiany.

Co pokazują własne zespoły Anthropic?

Anthropic publikuje o sobie dwa rodzaje dowodów i odpowiadają one na różne pytania.

Historie przepływów pracy (2025-07-24) pokazują, co ludzie faktycznie wpisywali. Gdy klastry Kubernetes przestały planować pody, zespół Data Infrastructure przekazał Claude Code zrzuty ekranu dashboardu; agent poprowadził ich przez interfejs Google Cloud aż do wyczerpania puli adresów IP podów i podał dokładne polecenia tworzące nową pulę IP, co zaoszczędziło 20 minut w trakcie awarii. Growth Marketing zbudował przepływ, który przetwarza pliki CSV z setkami reklam, wskazuje najsłabsze i generuje nowe warianty, a do tego wtyczkę do Figmy generującą do 100 wariantów reklam w jednej partii. Analitycy danych bez biegłości w TypeScripcie budowali całe aplikacje React do wizualizacji wyników modeli RL.

Liczby zbiorcze pokazują skalę i niosą własne ostrzeżenia. Wskaźnik ponad 80% scalonych linii to ostrożna miara Anthropic; ta sama strona zaznacza, że szacunek kierownictwa, 90% lub więcej, obejmuje skrypty i kod eksperymentalny. Zanim ten wskaźnik powstał, Redwood Research argumentował, że wzrost produktywności przy danym udziale kodu generowanego przez AI nie jest duży, bo AI pozwala tanio wytwarzać mnóstwo kodu o niskiej wartości (Ryan Greenblatt, 2025-10-22). Cytuj udział kodu razem z tą krytyką albo wcale.

Prompt do skopiowania: diagnoza incydentu ze zrzutu ekranu dashboardu

Dołącz zrzut ekranu i wklej ten prompt do Claude Code, Codeksa albo agenta Cursora. Odtwarza historię Data Infrastructure, a decyzję o każdym poleceniu nadal podejmuje człowiek.

Attached is a screenshot of our GKE cluster dashboard during an active
incident: new pods are stuck in Pending. List the three most likely root
causes in priority order, with the evidence in the screenshot for each.
For the top candidate, give the exact gcloud and kubectl commands that
would confirm it, and separately the commands that would remediate it.
Do not run anything. For every command, state what it reads or changes and
what output would prove or rule out the diagnosis.

Co mówią kontrdowody?

Plan oparty wyłącznie na historiach sukcesu nie przetrwa pierwszego świadomego pytania. Postaw obok nich:

• Randomizowane badanie METR z udziałem 16 doświadczonych programistów open source i 246 zadań wykazało, że z AI zadania trwały o 19% dłużej, z przedziałem ufności od +2% do +39% (METR, 2025-07-10). Kontynuacja z lutego 2026 przechyla się na korzyść AI, ale nie jest istotna statystycznie, a METR nazywa nowe dane niewiarygodnym sygnałem (METR, 2026-02-24). Oszacowania punktowe to około 18% krócej u wcześniejszych uczestników (przedział od -38% do +9%) i 4% krócej u nowych (od -15% do +9%); oba przedziały obejmują zero. (Wpis METR opisuje te liczby jako „speedup” równy -18% i -4%, ale kod analizy METR raportuje zmianę czasu wykonania zadania, więc wartość ujemna oznacza krótszy czas.)
• Telemetria Faros AI z 22 000 programistów (kwiecień 2026) pokazuje, że przepustowość i jakość zmieniają się razem: epiki na programistę +66,2%, ale błędy na programistę +54%, a incydenty na pull request +242,7% (Faros AI).
• Raport DORA 2025 wykazał pozytywny związek adopcji AI z przepustowością dostarczania i wynikami produktu, a jednocześnie negatywny związek ze stabilnością dostarczania (Google Cloud, 2025-09-23).
• DX zmierzył wzrost mediany rozmiaru pull requesta z 44 do 72 linii między lipcem 2025 a czerwcem 2026 (DX, 2026-06-17), czyli więcej do przeczytania dla każdego recenzenta.

Historie sukcesu i kontrdowody zgadzają się w jednym. DORA ujmuje to wprost: bez solidnych mechanizmów kontroli, takich jak mocne testy automatyczne, dojrzała kontrola wersji i szybkie pętle informacji zwrotnej, wzrost liczby zmian prowadzi do niestabilności. Stripe miał te mechanizmy wcześniej. Pełny obraz dowodów znajdziesz w stanie inżynierii agentowej w 2026 roku.

Co łączy wdrożenia, które się udały?

Wzorzec	Gdzie widać go w dowodach	Co skopiować
Wyrocznia była przed autonomią	Trzy miliony testów Stripe; mocne testy automatyczne jako warunek u DORA	Zmierz, jak mocne są twoje testy, zanim poszerzysz to, co agenci mogą scalać
Pętla ma twardy limit	Najwyżej dwie rundy CI w Stripe	Ogranicz liczbę prób i wydatki; oddaj zadanie człowiekowi z raportem
Człowiek zatwierdza scalenie na podstawie dowodów	Każdy pull request Minions przegląda człowiek	Dołącz pakiet dowodów do każdego pull requesta agenta
Kontekst i narzędzia podłączone raz	Toolshed Stripe z prawie 500 narzędziami MCP	Uruchom wspólne serwery MCP i pliki kontekstu dla całego zespołu
Twierdzenie nazywa swoją metrykę i zastrzeżenie	Przybliżenie przez scalone PR w Microsofcie, nazwane wprost przybliżeniem	Raportuj zaakceptowane zmiany i ich koszt, nigdy linie ani „% kodu od AI”

Zweryfikuj studium przypadku, zanim trafi do planu

Przepuść przez te siedem pytań każdą historię dostawcy, wystąpienie konferencyjne i cytat analityka. Historia, która oblewa trzy lub więcej, to marketing; nie wpuszczaj jej do business case.

1. Kto to opublikował i kiedy? Brak daty lub nazwiska autora oznacza brak cytowania.
2. Co dokładnie zmierzono? Linie, pull requesty, deklarowane godziny i dostarczone efekty to cztery różne rzeczy.
3. Względem jakiego punktu odniesienia? Wynik typu 24% więcej, niż byłoby bez narzędzia, ma scenariusz kontrfaktyczny. „3x szybciej” zwykle go nie ma.
4. Na ilu osobach i przez jak długo? Miesiąc jednego inżyniera to anegdota; dziesiątki tysięcy osób przez cztery miesiące to badanie.
5. Co weryfikowało wynik? Jeśli historia nie wspomina testów, CI ani review, strona jakościowa nie była mierzona.
6. Co działo się z jakością? Szukaj change failure rate, incydentów, revertów i błędów. Ich brak też jest wnioskiem.
7. Czy źródło podaje własne zastrzeżenie? Wiarygodne podają: Microsoft o scalonych PR, METR o danych z 2026 roku, Anthropic o szacunku 90%.

Prompt do skopiowania: weryfikacja studium przypadku dostawcy z agentem

Zapisz studium przypadku jako case-study.md (albo PDF) w pustym katalogu i wklej ten prompt do Claude Code, Codeksa albo agenta Cursora.

Read case-study.md. Act as a skeptical analyst preparing a note for our CFO.
Produce a table with one row per quantitative claim and these columns:
claim (quoted verbatim), metric actually measured (lines, PRs, hours,
outcomes, or self-report), baseline or counterfactual, population and
duration, how the output was verified (tests, CI, review; "not stated" if
absent), quality or stability data reported, and caveats the source itself
states. Then score the document against these seven questions: named
publisher and date, defined metric, baseline, sample size and duration,
verification method, quality data, stated caveats. Quote the sentence that
answers each question, or write "not answered". Do not infer numbers that
are not in the text. End with one line: usable as evidence, usable only as
an anecdote, or marketing.

Odtwórz wzorzec pętli z limitem na jednym typie zadań

Kopiuj wzorzec, nie liczbę. Wybierz z backlogu jeden powtarzalny, dobrze przetestowany typ zadań (podbicie zależności, naprawa niestabilnego testu, migracja z przestarzałego API) i odtwórz na nim kształt ze Stripe: spisane zadanie, przebieg agenta z twardym limitem, zestaw testów jako wyrocznia i przegląd dowodów przez człowieka. Przebieg zajmuje popołudnie; projekt pomiaru należy do pilotażu, który czegoś dowodzi.

Plik zadania jest taki sam w każdym narzędziu. Zapisz go jako .agent/tasks/deprecated-api.md:

Replace every call to legacyFetch() in src/ with httpClient.get(), keeping
behaviour identical. Acceptance criteria:
1. `npm test` passes.
2. No file outside src/ and test/ changes.
3. No existing test is deleted or weakened; add a test for any call site
   that had none.
Process: run `npm test` after your change. If it fails, fix and run it
once more. If it still fails after the second run, stop and write
REPORT.md with the failing tests and your best diagnosis instead of
continuing. Always finish by writing REPORT.md: files changed, tests
added, test results, and anything you were unsure about.

Claude Code

Uruchom zadanie w trybie nieinteraktywnym (-p) w terminalu, z katalogu głównego repozytorium. --max-budget-usd ogranicza wydatki (działa tylko z --print), a --permission-prompts none odrzuca wszystko, co wymagałoby zatwierdzenia, więc --allowedTools przepuszcza tylko polecenie testów.

claude -p "$(cat .agent/tasks/deprecated-api.md)" \
  --permission-mode acceptEdits \
  --permission-prompts none \
  --allowedTools "Bash(npm test *)" \
  --max-budget-usd 5 \
  --output-format json > run.json

Jak uruchamiać to samo zadanie przy każdym pull requeście, opisuje strona o skryptach w Claude Code.

Codex

Uruchom zadanie nieinteraktywnie w terminalu. Profil uprawnień :workspace, zalecany przez OpenAI, trzyma zapisy wewnątrz repozytorium, a -o zapisuje końcową wiadomość agenta dla recenzenta. Profile uprawnień są w wersji beta i wymagają Codex CLI 0.138.0 lub nowszego.

codex exec -c default_permissions=":workspace" \
  -o last-message.md \
  "$(cat .agent/tasks/deprecated-api.md)"

W starszym CLI użyj starszego mechanizmu sandboxu: zastąp opcję -c flagą --sandbox workspace-write. Używaj jednego albo drugiego, nie obu naraz: według OpenAI profile i starszy sandbox „do not compose”, czyli nie łączą się ze sobą.

Codex nie ma flagi --full-auto (sprawdzone w codex exec --help, v0.157.1). Uruchomienia według harmonogramu i w chmurze opisuje strona o automatyzacji w Codeksie.

Cursor

Otwórz repozytorium w Cursorze, przełącz agenta w Plan Mode i wklej plik zadania. Zatwierdź plan, a potem uruchom wykonanie w worktree (funkcja Worktrees w Cursorze pozwala agentowi pracować w odizolowanych kopiach repozytorium Git), żeby zmiana nie trafiła do twojej kopii roboczej. Cursor nie egzekwuje tu limitu dwóch uruchomień testów: istnieje on tylko w prompcie, co wyjaśnia sekcja o weryfikacji poniżej. Żeby uruchamiać ten typ zadań bez nadzoru, użyj Cloud Agents; zobacz automatyzację w Cursorze.

Prompt do skopiowania: przegląd przebiegu jako człowiek nadzorujący

Wklej ten prompt w nowej sesji po przebiegu, żeby recenzentem nie był agent, który napisał zmianę.

Review the uncommitted changes in this repository against
.agent/tasks/deprecated-api.md. Do not edit any file. Check each acceptance
criterion and quote the evidence: the test output, the list of changed
paths, and a diff of every test file (flag any assertion that was removed,
loosened or skipped). Then list up to five call sites where behaviour could
differ from legacyFetch() (headers, timeouts, error types, retries) and say
whether a test covers each. Finish with one verdict: merge, fix and re-run,
or reject, with the reason.

Jak zweryfikować odtworzony wzorzec bez czytania każdej linii?

Recenzent sprawdza dowody, a nie każdą linię diffu. Przy każdym przebiegu:

• Testy są wyrocznią. Przebieg się liczy tylko wtedy, gdy npm test przechodzi, a prompt recenzenta nie znajduje osłabionego testu. Jeśli zestaw testów jest cienki, ten typ zadań nie jest gotowy na wzorzec; najpierw wzmocnij testy.

• Zakres sprawdza się mechanicznie. Po przebiegu uruchom w terminalu to polecenie. Wypisuje każdy zmieniony lub nowy plik poza src/ i test/ (z wyjątkiem pliku zadania w .agent/ i plików wynikowych samego przebiegu), a każdy wypisany plik oznacza nieudany przebieg:

  { git diff --name-only HEAD; git ls-files --others --exclude-standard; } \
    | grep -vE '^(src|test)/|^\.agent/|^(REPORT\.md|run\.json|last-message\.md)$' \
    && echo 'SCOPE VIOLATION' || echo 'scope ok'

• Zatrzymania liczy się osobno. Przebieg, który doszedł do drugiej porażki, kończy się plikiem REPORT.md, a nie pull requestem. Licz takie przebiegi; to twój wskaźnik porażek. Pamiętaj, co egzekwuje regułę stopu: limit dwóch uruchomień testów istnieje tylko w prompcie, więc agent może go zignorować. Twardy limit daje dopiero opakowanie przebiegu, na przykład timeout 20m claude -p …, albo zadanie CI, które liczy uruchomienia testów i przerywa przebieg przy trzecim. Spośród poleceń na tej stronie jedynym twardym limitem wydatków jest --max-budget-usd w zakładce Claude Code; przebiegi w Codeksie i Cursorze nie mają żadnego, dopóki go nie dodasz.

• Zatwierdza konkretna osoba. Tech lead odpowiedzialny za repozytorium scala albo odrzuca zmianę i zapisuje werdykt.

• Jakość śledzi się po scaleniu. Przez 30 dni zapisuj reverty i incydenty wynikające ze zmian agentów, a potem policz koszt zaakceptowanej zmiany.

Po 10–20 przebiegach jednego typu zadań masz wewnętrzne studium przypadku z punktem odniesienia, próbą, metodą weryfikacji i miarą jakości, czyli więcej niż większość prezentacji dostawców. Opisz je według tego szkieletu i dołącz do business case:

Internal case study: <task type>, <team>, <dates>
Question: can agents complete <task type> to our merge standard?
Baseline: median hours per task before the pilot (n = ?, source)
Runs: n = ?, merged = ?, stopped by the retry cap = ?, rejected at review = ?
Verification: test suite (size, mutation score if known), scope check, reviewer
Quality after 30 days: reverts = ?, incidents = ?
Cost: agent spend + review hours, per accepted change
Caveats: what this does not show (other task types, other teams)
Decision: expand / repeat / stop, and who decided

Kiedy historie sukcesu sprowadzają wdrożenie na manowce

• Pożyczasz liczbę bez wyroczni, która za nią stała. Skala Stripe opiera się na trzech milionach testów. Co zrobić: zanim cokolwiek prognozujesz, zmierz siłę własnych testów dla danego typu zadań i planuj autonomię dla każdej pętli osobno, tak jak robi to roadmapa adopcji.
• Liczysz wytworzony kod zamiast zaakceptowanych zmian. Linie i pull requesty rosną, a błędy i incydenty rosną szybciej, co zmierzył Faros. Co zrobić: jako główną metrykę przyjmij zaakceptowane, niecofnięte zmiany i raportuj jakość obok przepustowości, według strony o frameworkach metryk.
• Deklaracje zastępują pomiar. Programiści w badaniu METR z 2025 roku wierzyli, że AI przyspieszyło ich o 20%, choć pomiar pokazał spowolnienie. Co zrobić: weź punkt odniesienia z danych o dostarczaniu przed startem pilotażu, a nie z ankiety po nim.
• Kopiujesz narzędzie, a nie środowisko pracy agenta (harness). Zakup licencji nie odtwarza blueprints, limitu prób ani narzędzi Stripe. Co zrobić: sfinansuj wspólne środowisko pracy agenta (testy, pliki kontekstu, serwery MCP, bramki review) jako osobną pozycję w business case.
• Błąd przeżywalności ukrywa porażki. Firmy publikują to, co zadziałało. Co zrobić: zachowaj zatrzymane i odrzucone przebiegi w wewnętrznym studium przypadku; to one dowodzą, że reguła stopu działa.
• Review staje się wąskim gardłem. Więcej pull requestów od agentów to więcej do przejrzenia, a DX zmierzył, że są coraz większe. Co zrobić: ustal limity rozmiaru pull requestów i kieruj je według ryzyka, jak w kolejce code review.

Dokąd dalej po studiach przypadków

Ekonomia: koszt zaakceptowanej zmiany

Zamień odtworzony wzorzec w koszt, który zaakceptuje CFO.

Wyceń zaakceptowane zmiany →

Pilotaż, który czegoś dowodzi

Punkt odniesienia, grupy porównawcze i reguła decyzji spisana przed startem pilotażu.

Zaprojektuj pilotaż →

Business case

Notatka decyzyjna oparta na twoich dowodach, nie na mnożniku dostawcy.

Napisz business case →

Raportowanie do zarządu

Kwartalny szablon na jedną stronę, łącznie z tym, czego nie deklarować.

Przygotuj raport →