Badanie Anthropic: wiedza dziedzinowa bije kodowanie w pracy z agentami
Siedem miesięcy obserwacji realnej pracy z agentami przyniosło wynik, który wywraca intuicję: częściej wygrywa nie inżynier, lecz osoba, która dobrze zna problem.
Redakcja Neurise
6 min czytania
17 czerwca 2026 (aktualizacja: 9 września 2026)
Anthropic przez siedem miesięcy obserwował, jak 235 000 osób tworzy oprogramowanie z pomocą agentów AI, i policzył, komu to naprawdę wychodzi. O powodzeniu sesji częściej decydowała znajomość dziedziny niż lata spędzone przy kodzie: inżynierowie oprogramowania kończyli zweryfikowanym sukcesem 34% sesji, w których powstawał kod, a osoby z innych zawodów 29%. Zawody menedżerskie wypadły minimalnie powyżej inżynierów, a dystans między zawodami związanymi z oprogramowaniem a resztą przez cały okres obserwacji ani się nie powiększył, ani nie zmniejszył.
W skrócie
- Anthropic przeanalizował około 400 000 sesji Claude Code pochodzących od 235 000 osób, od października 2025 do kwietnia 2026.
- Inżynierowie oprogramowania: 34% sesji ze zweryfikowanym sukcesem. Pozostałe zawody: 29%. Menedżerowie nieco powyżej inżynierów.
- Dziesięć największych grup zawodowych zmieściło się w przedziale siedmiu punktów procentowych od inżynierów.
- Udział sesji poświęconych naprawianiu zepsutego kodu spadł z 33% do 19%.
- Człowiek podejmuje około 70% decyzji o tym, co zbudować, model około 80% decyzji o tym, jak to zrobić.
Co dokładnie zmierzono
To nie ankieta, tylko obserwacja realnej pracy. Anthropic opisał w publikacji „Agentic coding and persistent returns to expertise" analizę około 400 000 sesji Claude Code pochodzących od mniej więcej 235 000 osób, prowadzoną od października 2025 do kwietnia 2026. Autorzy nie pytali użytkowników, czy są zadowoleni. Sprawdzali, czy zadanie faktycznie się udało.
Miara nazywa się zweryfikowanym sukcesem i ma dwie części. Pierwszy klasyfikator szuka twardych śladów powodzenia: commitów i pull requestów pasujących do wykonywanej pracy, przechodzących testów oraz wyraźnego potwierdzenia ze strony użytkownika. Drugi liczy sygnały porażki: błędy, nieudane testy, ponawianie tej samej próby, kwestionowanie wyniku przez człowieka. Sesja liczy się jako sukces dopiero wtedy, gdy oceniono ją pozytywnie i jednocześnie znaleziono co najmniej jeden twardy ślad. To znacznie ostrzejsze kryterium niż brak narzekania po stronie użytkownika.
Menedżer ponad inżynierem
Najmocniejszy wynik dotyczy zawodów. W sesjach, w których powstawał kod, grupa zawodów związanych z oprogramowaniem i matematyką osiągnęła 34% zweryfikowanego sukcesu, a pozostałe zawody 29%. Zawody menedżerskie uplasowały się nieznacznie powyżej inżynierów oprogramowania, a wszystkie dziesięć największych grup zawodowych zmieściło się w przedziale siedmiu punktów procentowych od nich.
Brzmi to nieintuicyjnie tylko dopóty, dopóki nie spojrzymy na to, czego wymaga praca z agentem: precyzyjnego opisania problemu, rozbicia go na kroki i oceny, czy efekt jest dobry. To kompetencje bliższe prowadzeniu projektu niż pisaniu pętli. Pięć punktów różnicy między inżynierami a resztą zawodów to niewiele jak na dziedzinę, w której jeszcze niedawno bez znajomości składni nie dało się zrobić nic.
Agent nie nagradza tego, kto zna składnię. Nagradza tego, kto wie, co naprawdę trzeba zbudować.
Podział pracy między człowiekiem a modelem
Anthropic policzył też, kto podejmuje które decyzje. W typowej sesji człowiek odpowiada za około 70% decyzji planistycznych, czyli tego, co ma powstać, a model za mniej więcej 80% decyzji wykonawczych, czyli tego, jak to zrobić. Podział jest wyraźny i utrzymuje się w całym badanym okresie.
Stąd bierze się reszta wyniku. Skoro najbardziej wartościowa połowa pracy polega na decydowaniu, co zbudować, przewagę ma ten, kto najlepiej rozumie problem: księgowa znająca własny proces rozliczeń, kierownik produkcji znający wąskie gardło na hali, właściciel sklepu wiedzący, w którym kroku klienci porzucają koszyk.
Mniej gaszenia pożarów
Zmienił się także charakter pracy. Udział sesji opisanych jako naprawianie zepsutego kodu spadł w badanym okresie z 33% do 19%, czyli prawie o połowę. Równolegle rósł udział zastosowań prowadzonych od początku do końca przez agenta: uruchamiania i wdrażania kodu, analizy danych, przygotowywania dokumentów, które kodem w ogóle nie są.
Dla firmy to zmiana kosztu wejścia. Im mniejszy udział sesji poświęconych ratowaniu zepsutego kodu, tym rzadziej potrzebny jest ktoś, kto potrafi wejść w cudzy kod i go odratować, a częściej wystarcza ktoś, kto potrafi opisać cel i rzetelnie sprawdzić rezultat.
Nowicjusz kontra ktoś, kto zna temat
Podział na zawody to jedno, a poziom znajomości dziedziny to drugie, i tu różnice są dużo większe. Sesje ocenione jako prowadzone przez nowicjusza kończyły się zweryfikowanym sukcesem w 15% przypadków. Sesje z widoczną znajomością tematu, średnią lub wysoką, mieściły się w przedziale od 28 do 33%.
Najciekawsza jest reakcja na kłopoty. Gdy sesja zaczynała się sypać, nowicjusze porzucali ją w 19% przypadków, a osoby ze średnim i wysokim poziomem znajomości tematu w 5 do 7%. Znajomość dziedziny nie chroni przed błędem agenta. Pozwala go rozpoznać i skorygować kurs, zamiast zamykać okno.
Dystans, który się nie powiększa
Można się było spodziewać, że lepsze narzędzia dadzą inżynierom jeszcze większą przewagę, bo lepiej wiedzą, jak z nich korzystać. Przez siedem miesięcy nic takiego się nie stało: różnica między zawodami związanymi z oprogramowaniem a resztą pozostała mniej więcej ta sama. Nie urosła, ale też się nie zamknęła.
Dla właściciela małej firmy to praktyczny sygnał. Do prototypu, wewnętrznego narzędzia czy skryptu porządkującego dane nie zawsze potrzebny jest dział inżynierii. Czasem wystarczy osoba, która najlepiej rozumie proces i ma cierpliwość do sprawdzania wyników.
Druga strona medalu: czego to badanie nie pokazuje
Publikacja pochodzi od Anthropic i dotyczy Claude Code, czyli własnego produktu firmy, mierzonego na własnych użytkownikach. Nikt niezależny tego pomiaru nie powtórzył. Po Claude Code sięgają dziś osoby, które same się na to zdecydowały, więc próba nie jest przekrojem polskiego ani żadnego innego rynku pracy.
Autorzy sami zaznaczają ograniczenie: nie potrafią zmierzyć rezultatów w świecie rzeczywistym, czyli tego, czy kod napisany w sesji został potem użyty, czy wylądował w koszu. Zweryfikowany sukces to sygnał wewnątrz sesji, na przykład przechodzący test albo scalony pull request, a nie dowód, że powstała wartość dla firmy.
Warto zestawić ten wynik z pomiarem, który poszedł w drugą stronę. W eksperymencie z losowym przydziałem, przeprowadzonym przez METR w lipcu 2025, szesnastu doświadczonych programistów open source wykonało 246 zadań we własnych repozytoriach. Z narzędziem AI potrzebowali na nie 19% więcej czasu, choć po wszystkim byli przekonani, że AI przyspieszyła ich o 20%. Sami autorzy odradzają uogólnianie tego wyniku na całą branżę, ale jedno pokazuje dobitnie: poczucie tempa bywa mylące, a pomiar potrafi je odwrócić.
Dwa tygodnie po publikacji Anthropic badacze Microsoftu opisali na arXiv wdrożenie agentów uruchamianych z linii poleceń u dziesiątek tysięcy własnych inżynierów. Tam efekt był dodatni: osoby, które przyjęły narzędzie, scalały około 24% więcej pull requestów, a przewaga utrzymała się przez cztery miesiące obserwacji. Autorzy zastrzegają jednak, że scalony pull request mierzy produkcję, a nie wartość biznesową. Trzy pomiary, trzy różne pytania i żaden z nich nie odpowiada na to, czy Twojej firmie się to opłaci. Dlatego wyniki testów modeli warto czytać jako wskazówkę, nie jako obietnicę.
Co z tego wynika dla małej firmy
Pierwszy wniosek jest kadrowy. Jeśli w firmie działa proces, który ktoś zna na wylot, to ta osoba jest lepszym kandydatem do zbudowania pierwszej wersji narzędzia niż wykonawca poznający temat od zera. Nie dlatego, że napisze lepszy kod, tylko dlatego, że wie, co ma powstać i po czym pozna, że powstało.
Drugi dotyczy zakresu. Badanie mówi o pojedynczych sesjach, a nie o systemach utrzymywanych latami. Wewnętrzny raport, skrypt czyszczący bazę adresów, prototyp kalkulatora ofertowego to dobry początek. Rozliczenia, dane osobowe i wszystko, co widzi klient, nadal wymagają kogoś, kto weźmie za to odpowiedzialność.
Trzeci dotyczy sposobu sprawdzania. Anthropic uznaje sesję za udaną dopiero wtedy, gdy widzi twardy ślad: przechodzący test, scalony commit, wyraźne potwierdzenie. Ten sam nawyk działa w firmie. Zanim ktoś zacznie, warto zapisać jedno zdanie z kryterium odbioru, na przykład: raport ma zgadzać się z zestawieniem z systemu księgowego za marzec. Bez tego trudno odróżnić działające narzędzie od ładnie wyglądającego ekranu.
Najczęstsze pytania
Nie. Badanie pokazuje, że do wielu zadań wystarczy dobra znajomość problemu, ale złożone, krytyczne systemy nadal wymagają inżynierów. Zmienia się raczej to, kto może zbudować pierwszą wersję.
Bo praca z agentem premiuje umiejętność precyzyjnego opisania problemu, podziału go na kroki i oceny rezultatu - to kompetencje bliższe zarządzaniu niż samemu kodowaniu.
Że mniej czasu idzie na gaszenie pożarów, a więcej na budowanie nowych funkcji. Agenci coraz częściej tworzą działający kod od razu.
Że wewnętrzne narzędzia i prototypy mogą powstawać szybciej i taniej, także rękami osób spoza działu IT, które najlepiej znają dany proces.
Źródła: Anthropic, „Agentic coding and persistent returns to expertise" (16.06.2026), METR, pomiar wpływu AI na pracę doświadczonych programistów open source (10.07.2025), Murphy-Hill, Butler, Savelieva, wdrożenie agentów CLI w Microsoft (arXiv, 01.07.2026).
Powiązane artykuły
Sprawdź, czy AI poleca Twoją firmę.
Zacznij od bezpłatnego audytu SEO i GEO. Sprawdzimy, jak modele AI opisują Twoją markę, i wskażemy priorytety zwiększające szanse na cytowanie.