Technologia

Kiedy AI pisze i dostarcza kod, doświadczeni programiści pracują 19% wolniej

Susan Hill

Agenci programowi tacy jak Devin, Claude Code i GitHub Copilot Workspace przyjmują teraz opis zadania, odczytują bazę kodu, piszą kod, który go realizuje, uruchamiają testy, aż te przejdą pomyślnie, i otwierają pull request – bez konieczności pisania ani jednej linii kodu przez programistę. Devin, stworzony przez Cognition AI, robi to w izolowanych środowiskach chmurowych. Wśród swojej bazy użytkowników produkcyjnych 67% pull requestów, które otwiera autonomicznie, zostaje scalonych. Claude Code odczytuje całe repozytorium, planuje zmiany w wielu plikach, uruchamia zestaw testów i iteruje bez instrukcji między poszczególnymi krokami. Narzędzia te są używane w produkcji, a nie w fazie badawczych podglądów.

Tym, co odróżnia je od wcześniejszych narzędzi do generowania kodu, jest pętla sprzężenia zwrotnego. Silnik sugestii generuje tekst i zatrzymuje się; autonomiczny agent generuje kod, uruchamia go, odczytuje to, co zwrócono, i próbuje ponownie. Podstawowy szkielet jest taki sam we wszystkich narzędziach: duży model językowy odczytuje kontekst – bazę kodu, opis problemu, dziennik błędów – generuje plan, wykonuje go za pomocą narzędzi takich jak polecenia powłoki, edycje plików i operacje git, odczytuje wynik i koryguje. Pętla trwa, dopóki agent nie osiągnie sukcesu lub nie wyczerpie swojego budżetu zasobów.

Pętla, która zastąpiła edytor

Zakres autonomii dostępnych narzędzi obejmuje trzy poziomy. Na poziomie asystowanym GitHub Copilot sugeruje kilka następnych linii, gdy programista pisze. Jeden poziom wyżej, edytory wieloplikowe, takie jak Cursor, przepisują kod w całej bazie kodu na polecenie programisty, wprowadzając zmiany, które programista określi. Na poziomie autonomicznym Devin i podobne systemy działają niezależnie przez dłuższy czas, podejmując sekwencyjne decyzje o tym, co czytać, co zmienić i co testować, ujawniając się tylko w przypadku zatwierdzeń, których system nie jest w stanie samodzielnie obsłużyć.

Ramą ewaluacyjną mierzącą postępy tych narzędzi jest SWE-bench, stworzony przez naukowców z Princeton i Stanford. Testuje agentów na rzeczywistych zgłoszeniach błędów z otwartoźródłowych repozytoriów Pythona – Django, Flask, scikit-learn – i mierzy, jaki procent agent jest w stanie poprawnie zamknąć. Obecnie najwyższy opublikowany wynik w starannie wyselekcjonowanym podzbiorze Verified, wynoszący 96%, należy do Claude Opus 5. Ta liczba reprezentuje rzeczywistą zdolność: umiejętność zdiagnozowania prawdziwego błędu w oprogramowaniu, napisania poprawki i zweryfikowania, że przechodzi ona własne testy projektu.

Co kryje benchmark

Wynik 96% opatrzony jest ważną gwiazdką. SWE-bench Verified czerpie z 500 starannie wybranych zadań. Gdy badacze zastosowali wariant odporny na kontaminację – SWE-bench Pro, zaprojektowany z użyciem problemów, które nie mogły pojawić się w danych treningowych żadnego modelu – wcześniejszy model, który uzyskał ponad 80% w Verified, spadł poniżej 50% w Pro. Część wydajności benchmarku odzwierciedla znajomość zestawu ewaluacyjnego, a nie uogólnioną zdolność rozwiązywania problemów. Ta luka to znane wyzwanie badawcze, a nie krytyka żadnego konkretnego narzędzia.

Osobne badanie wykazało coś trudniejszego do wytłumaczenia. METR, organizacja badawcza zajmująca się bezpieczeństwem AI, przeprowadziła randomizowane badanie kontrolowane z doświadczonymi programistami open source pracującymi nad własnymi repozytoriami. Programiści korzystający z obecnych narzędzi AI do kodowania byli o 19% wolniejsi niż ci pracujący bez nich – mimo że niezależnie oszacowali, że są o 20% szybsi. Przyczyny były konkretne: czas spędzony na ponownym promptowaniu, gdy agent wyprodukował nieprawidłowe wyniki, czas spędzony na weryfikacji wyjść przed scaleniem oraz obciążenie poznawcze związane z przełączaniem się między kierowaniem agentem a śledzeniem tego, co agent zrobił. Benchmark testuje, czy agent jest w stanie zamknąć dobrze określony błąd w izolacji. Randomizowane badanie testuje, czy programista pracuje szybciej w ciągu rzeczywistego dnia. Mierzą one różne rzeczy.

Dlaczego 93% adopcji przyniosło jedynie 10% wzrost przepustowości

Autonomiczność kodu sprawdza się najlepiej w przypadku ograniczonych, dobrze określonych zadań: powtarzalnego błędu z jasnymi wejściami i wyjściami, funkcji z precyzyjną specyfikacją, zestawu testów dla modułu o zdefiniowanym zachowaniu. W miarę rozszerzania zakresu na zadania wymagające ukrytej wiedzy architektonicznej, nieudokumentowanych konwencji zespołu czy decyzji dotyczących kierunku produktu, niezawodność spada – nie dlatego, że modelom brakuje możliwości, ale dlatego, że kontekst potrzebny do tych decyzji nie mieści się w systemie i nie można go wywnioskować wyłącznie z plików repozytorium.

Praktyczna zmiana polega na tym, czego wymaga praca. Programiści pracujący z autonomicznymi agentami spędzają więcej czasu na pisaniu specyfikacji wystarczająco precyzyjnych, aby agent mógł je wykonać: szczegółowych opisów problemów, jasnych kontraktów testowych, wyraźnych kryteriów akceptacji. Spędzają więcej czasu na przeglądaniu kodu, którego nie napisali, co wymaga innego rodzaju uwagi niż pisanie kodu – szukania błędów logicznych, luk bezpieczeństwa i dryfu architektonicznego, których agent sam nie zgłosi. Ankieta z 2026 roku przeprowadzona wśród 121 000 programistów wykazała, że 93% regularnie korzysta z narzędzi AI do kodowania; przepustowość pull requestów wzrosła mniej więcej o 10% w tej samej grupie. Wąskie gardło przesunęło się z pisania kodu na jego przeglądanie.

Kolejnym etapem będącym w trakcie aktywnego rozwoju są agenci, którzy zarządzają własnymi kolejkami zadań: otrzymują specyfikację projektu, dzielą ją na podzadania, delegują między wyspecjalizowane modele i ujawniają tylko te decyzje, które wymagają ludzkiego osądu. W 2026 roku wydano kilka otwartoźródłowych frameworków do orkiestracji kodowania wieloagentowego. Przyjęcie w środowiskach produkcyjnych w przedsiębiorstwach pozostaje ograniczone. Gartner prognozuje, że znaczna część projektów oprogramowania agentowego rozpoczętych w tym roku zostanie zaniechana przed 2028 rokiem, gdy zespoły odkryją dystans między tym, co pokazuje kontrolowane demo, a tym, czego wymaga niezawodne wdrożenie na dużą skalę.

Tagi: , , , ,

Dyskusja

Jest 0 komentarzy.