Dlaczego większość programistów nadal ma niewiele korzyści z agentów do pisania kodu.

Dwa badania z 2026 roku, jedno przeprowadzone przez JetBrains, a drugie przez Anthropic, podają konkretne dane na temat tego, w jaki sposób inżynierowie faktycznie pracują z agentami programistycznymi. Ich zdaniem różnica pomiędzy czerpaniem korzyści z agenta a otrzymywaniem bezużytecznych informacji wynika z sposobu delegowania zadań, a nie z wyboru konkretnego modelu.

Głównym stwierdzeniem jest to, że programowanie przy użyciu sztucznej inteligencji nie jest już eksperymentem, a kluczową różnicą jest teraz rozróżnienie pomiędzy proszeniem modelu o napisanie kodu a rzeczywistym delegowaniem pracy inżynierskiej na niego.

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Dlaczego aplikacja do handlu to dobry test

Rozważmy aplikację do handlu dla systemu iOS stworzoną dla firmy maklerskiej. UIKit i SwiftUI współistnieją obok siebie, a na ich podstawie funkcjonują wzorce MVVM oraz Clean Architecture. W takim kodzie błędna liczba na ekranie potwierdzenia zamówienia nie staje się zgłoszeniem błędu – to zamiast tego powoduje telefon od działu ds. zgodności.

Dla zespołu w takiej sytuacji przekazywanie rzeczywistej pracy agentowi programistycznemu nie dotyczy szybkości. Najważniejsze jest to, by zauważyć moment, w którym agent potajemnie popełnia błąd, a nikt tego nie zauważa. Analiza takiego momentu uczy więcej o procesach pracy agentów niż jakikolwiek kurs, a dane z 2026 roku wyjaśniają dlaczego.

Co ujawniło badanie JetBrains

W okresie od maja do lipca 2026 roku JetBrains przeprowadziło ankietę wśród ponad 15 000 pracujących programistów. Dziewięciu na dziesięciu odpowiedziało, że używa agentów programistycznych opartych na AI w pracy przynajmniej raz w tygodniu, a 68% – codziennie.

Claude Code prowadzi z wynikiem 39% na świecie i 47% w Stanach Zjednoczonych, co stanowi mniej więcej dwukrotność wyniku GitHub Copilot na poziomie 21%, który z kolei spadł z 29% rok wcześniej. Codex wzrósł z 3% do 16%.

W towarzyszącym raporcie znajduje się bardziej interesująca liczba. Programiści szacują, że około 47% ich kodu jest obecnie pisane w całości przez asystentów, ponad połowa z nich pisze ręcznie mniej niż 20% swojego kodu, a jeden na pięciu w ogóle nie pisze bez pomocy AI.

Doswiadczenie nie hamowało wdrażania tych narzędzi, lecz przyspieszało je. Mniej więcej jeden na czterech doświadczonych programistów polega na asystentach przy tworzeniu ponad 80% swojego kodu, co stanowi większy odsetek niż wśród początkujących, którzy wolą pomoc krok po kroku. To podważa tezę, że AI czyni początkujących zbędnymi. Ci, którzy potrafią najlepiej ocenić sytuację, przekazują najwięcej zadań asystentom, i to raczej nie jest przypadek.

Co pokazują 400 000 sesji

Własne badanie Anthropic obejmowało około 400 000 interaktywnych sesji Claude Code przeprowadzonych przez około 235 000 użytkowników, zarejestrowanych od października 2025 roku do kwietnia 2026 roku. Podział tych sesji jest prostszy, niż sugeruje marketing:

• Prace związane z kodem stanowiły 56% sesji, w tym 25% to pisanie kodu, 26% naprawianie błędów, a 5% testowanie lub organizacja procesu.
• Obsługa oprogramowania zajmowała 17% sesji.
• Planowanie i eksploracja stanowiły 14% sesji.
• Analiza i pisanie tekstu stanowiły 13% sesji.

Najważniejszy wniosek dotyczy tego, kto decyduje o czym. Ludzie podejmują około 70% decyzji planistycznych, natomiast Claude podejmuje około 80% decyzji dotyczących realizacji. Ludzie decydują o *czym*, a agent o *jak*.

Nikt nie zaprojektował takiego podziału. To równowaga, do której niezależnie doszły setki tysięcy inżynierów, ponieważ działa skutecznie. Wiele skarg na agenty kodujące pochodzi od osób, które to zmieniły, przekazując im informacje o tym, co ma zostać zrobione, a potem kłócąc się z nimi co do sposobu realizacji zadania.

Eksperckość zmienia wynik

Liczby pokazują, jak błędne jest przekonanie, że „każdy może teraz coś stworzyć”. Sesje były oceniane pod kątem rzekomej ekspertyzy użytkownika w danej dziedzinie na podstawie trzech kryteriów: dokładności instrukcji, tego, co użytkownik poprosił Claude’a o sprawdzenie, oraz sposobu wprowadzania korekt. Wyniki te były następnie porównywane ze sobą.

Zacznij od pierwszych dwóch wierszy. Eksperci nie piszą więcej. Jedna instrukcja od eksperta daje wynik ponad dwukrotnie lepszy niż praca wykonywana bez nadzoru – dwanaście działań w porównaniu z pięcioma u początkującego, mimo że model, narzędzie i cena są identyczne. Komunikat eksperta zawiera wystarczająco dużo kontekstu, dzięki czemu agent nie musi się zatrzymywać i zgadywać.

Ostatni wiersz ma równie duże znaczenie. Po tym, jak sesja zboczyła z kursu, około 19% początkujących poddało się bez stworzenia żadnego kodu, w porównaniu z 5 do 7% ekspertów. Kluczową umiejętnością nie jest sformułowanie promptu, lecz przywrócenie sesji na właściwą ścieżkę.

Jedno zdanie z artykułu to podsumowuje: u początkujących Claude ma tendencję do korygowania użytkownika, natomiast u ekspertów to użytkownik koryguje Claude’a. To jest granica pomiędzy korzystaniem z agenta a byciem przez niego zarządzanym.

Pętla trzech kroków, która zawodzi

Zwykła rutyna wygląda tak:

Bad:
Prompt → AI writes code → Accept

Dwa z tych trzech kroków należą do agenta. Nie ma żadnych wymagań, kontekstu, planu ani weryfikacji. To nie jest delegowanie pracy inżynieryjnej – to autodopisywanie na większej skali z nadzieją, że wynik będzie poprawny.

Siedmioetapowy cykl, który się sprawdza

Rutyna, która przetrwała kontakt z aplikacją do handlu w produkcji, składa się z siedmiu etapów:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

Inżynier odpowiada za pierwsze trzy etapy oraz dwa ostatnie, natomiast agent zajmuje się tym, co znajduje się pomiędzy nimi. Ten podział odzwierciedla wyniki badań, w których stosunek planowania do realizacji wynosi 70/30, a stosunek wykonywania do realizacji – 80/20, przedstawiony w formie łańcucha procesowego. Każdy etap ma swoje własne koszty.

Wymaganie

Zdanie takie jak „Dodaj kartę potwierdzenia do procesu zamawiania” jest uważane za zadanie. Agent może stworzyć coś, co technicznie jest poprawne, ale funkcjonalnie błędne. Wartościowe wymaganie zawiera znacznie więcej informacji:

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

Ostatnią kwestią w tej specyfikacji jest wiedza z danej dziedziny, której nie posiada żaden model. To właśnie ona odróżnia ekran, który poprawnie funkcjonuje, od takiego, który powoduje konieczność interwencji regulacyjnej. Odzwierciedla to wskaźnik „dokładności kierunku” z badań i jest to element najłatwiejszy do poprawy.

Kontekst

Gdy UIKit i SwiftUI współistnieją w ramach Clean Architecture, agent tworzy własne wzorce, jeśli żaden nie został przedstawiony, a każdy taki wymyślony wzorzec staje się później komentarzem w recenzji. Dlatego najpierw pokazuje się agentowi rzeczywiste przykłady: aktualny protokół przypadku użycia, jedną implementację repozytorium, ViewModel pełniący najbliższą funkcję oraz plik CLAUDE.md modułu z zasadami strukturyzacji. Trzy pliki i dokument z zasadami zawsze przewyższają efektywnością trzy akapity wyjaśnień. Prawie wszyscy pomijają ten etap, mimo że przynosi on największe korzyści.

Plan

Zanim napiszesz jakikolwiek kod, poproś o plan, w którym wymienione zostaną pliki, które ulegają zmianie, który warstwa obejmuje każdą zmianę, co exponuje ViewModel oraz co otrzymuje test. Czytaj go tak, jakby był to opis PR. Odrzucenie planu zajmuje około dziewięćdziesięciu sekund. Odrzucenie implementacji trwa dwadzieścia minut i pozostawia diff, który trzeba mentalnie odrzucić.

Około jednej trzeciej planów jest modyfikowanych, niemal zawsze z powodu kwestii związanych z warstwami, np. gdy agent umieszcza obliczenie w ViewModel, które powinno znajdować się w use case. Poprawienie tego w formie tekstu jest tanie, natomiast w Swift nie jest.

Implementacja

Gdy plan zostanie uzgodniony, proszę się wycofać. To tutaj znajduje się 80% decyzji dotyczących realizacji: nazewnictwo, przepływ sterowania, sposób strukturyzowania różnic między wersjami kodu oraz wybór odpowiedniego narzędzia pomocniczego. Przerwanie pracy w celu krytykowania nazwy zmiennej sprawia, że sesja składająca się z dwunastu kroków zamienia się w taką z pięcioma. Ponadto wymaga to uwagi doświadczonego inżyniera, aby uzyskać wynik od mniej doświadczonego.

Weryfikacja

Instrukcja z najlepszymi wynikami stanowi, że praca nie jest ukończona, dopóki kod się nie skompiluje, a testy nie przejdą, przy czym agent musi wykonać obie te czynności samodzielnie. Badania opisują to jako to, o co użytkownik prosi Claude’a, aby to sprawdził, i jest to element, który najczęściej jest niedoceniany. Agent zdolny do uruchomienia xcodebuild oraz testów samodzielnie zamyka swój cykl. Ten, który nie ma takiej możliwości, zwraca tylko wersję roboczą i określa ją jako funkcjonalność.

Dla arkusza potwierdzenia zdanie testów oznacza konkretne zachowania wymienione wcześniej. Siłę nabywczą trzeba przeliczyć ponownie przy prezentacji arkusza, przycisk potwierdzenia musi pozostać wyłączony podczas tego przeliczania, a obliczenia opłat muszą być zgodne z ustaleniami już istniejącymi w repozytorium.

Przegląd

Każdy wiersz jest czytany. Nie dzieje się tak dlatego, że kod jest zazwyczaj zły, bo zwykle tak nie jest. Przegląd to moment, w którym ekspercka wiedza człowieka nadal musi wejść do systemu. Czytanie ma na celu wykrycie tego, czego nie może dostrzec zielone buildowanie: czy zmiana przestrzega granic warstw, czy reguła zaokrąglania jest tą, którą faktycznie stosuje dział finansowy, oraz czy maszyna stanowa radzi sobie z utratą połączenia w trakcie procesu potwierdzenia.

To etap stanowi również rzeczywisty limit wydajności. Agent może generować więcej pracy, niż ktokolwiek jest w stanie odpowiedzialnie przejrzeć, a pokusa szybkiego przeglądania jest prawdziwym zagrożeniem całego procesu pracy. Ryzykiem nie jest tyle halucynacja, co zmęczenie.

Kierunek rozwoju pracy

Trend z siedmiu miesięcy w ramach 400 000 sesji zasługuje na uwagę:

• Udział sesji poświęconych na debugowanie spadł, z jednej trzeciej (33%) do 19%.
• Uruchamianie oprogramowania w trakcie pracy wzrosło do 21% po poziomie 14% na początku.
• Pisanie tekstów wraz z analizą danych niemal się podwoiło, wzrastając z około jednej dziesiątej do około jednej piątej sesji.

Lepsze znajdowanie błędów zajmuje mniej czasu, natomiast obsługa i analiza działających systemów wymagają więcej czasu. W tym samym okresie szacowana wartość zadań wzrosła o około 25%, a zadania związane z budową wzrosły o około 43%. Praca nie znika – przenosi się na wyższy poziom, z dala od pisania implementacji, w kierunku ich definiowania, koordynowania i weryfikacji, co odpowiada sposobowi pracy doświadczonego inżyniera z zespołem.

Wąskim gardłem jest pętla

Dziewięciu na dziesięciu programistów używa tych narzędzi co tydzień, a jednak tylko 15 do 33% sesji kończy się potwierdzonym sukcesem. Zatem model nie był nigdy ograniczeniem. Większość ludzi po prostu stosuje trzystopniową pętlę wobec narzędzia zaprojektowanego dla siedmiu kroków.

Dopracowywanie instrukcji nie rozwiąże tego problemu. Rozwiązaniem jest określenie kryteriów w momencie, gdy problemy się pojawiają, co oznacza z góry zdefiniowanie, co jest „poprawne”, oraz potwierdzenie na końcu, że te kryteria zostały spełnione. Agent zajmuje się resztą i robi to dobrze, w zależności od tego, jak wyraźnie zostały ustalone granice.

W 2026 roku ci, którzy uzyskają największe korzyści z agentów do programowania, nie będą pisali najsprytniejszych instrukcji. Będą to nadal ci, którzy decydują, co oznacza „zrobione”.