Dlaczego narzędzia AI do kodowania? Od autouzupełniania do inżynierii agentowej

Narzędzia AI do kodowania mają znaczenie, bo przestały podpowiadać linie, a zaczęły kończyć zadania: Claude Code, Codex i Cursor czytają repozytorium, planują zmianę, edytują pliki, uruchamiają testy i iterują, aż sprawdzenia przejdą. Wąskie gardło przesuwa się z pisania kodu na jego weryfikację. Inżynieria agentowa to dyscyplina zbudowana na tej zmianie: specyfikowanie zachowania i udowadnianie jego poprawności automatycznymi sprawdzeniami.

Twój zespół wdrożył agenta trzy miesiące temu. Liczba pull requestów tygodniowo wzrosła, ale kolejka review też: pięć dni do pierwszego przeglądu, senior, który czyta każdy diff do 21:00, i incydent na produkcji, którego źródłem był test przepisany przez agenta tak, żeby świecił na zielono. Nikt nie pisze mniej starannie. To system wokół pisania kodu jeszcze się nie zmienił i o tym systemie jest ta strona.

Programista dostaje pętlę do uruchomienia jeszcze dziś, tech lead wąskie gardło do usunięcia, a CTO i zarząd decyzję, którą te narzędzia na nich wymuszają. Jeśli nie masz jeszcze wybranej ścieżki, wybierz ją na stronie Zacznij tutaj.

Co wyniesiesz z tego wprowadzenia do inżynierii agentowej

• Odpowiedź na jednym ekranie na pytanie „co właściwie się zmieniło”, osadzoną na drabinie autonomii, na której twój zespół już stoi
• Tabelę decyzyjną: którą pracę oddać agentowi najpierw, w zależności od tego, czy maszyna potrafi orzec „gotowe”
• Pierwszą zweryfikowaną pętlę z agentem w Claude Code, Codeksie lub Cursorze, z trzema promptami do skopiowania
• Cztery artefakty, które czytasz zamiast diffu, i krótką listę zmian, które człowiek nadal czyta linijka po linijce
• Typowe awarie z pierwszego kwartału wdrożenia, każdą ze sposobem wyjścia
• Następną stronę dla twojej roli

Co się zmieniło, gdy narzędzia AI do kodowania stały się agentami?

Autouzupełnianie przewiduje kilka kolejnych tokenów w funkcji, którą właśnie piszesz. Agent bierze całe zadanie, czyta potrzebny kod, uruchamia twoje polecenia i wraca, gdy spełni warunek zakończenia. Andrej Karpathy ujął to jednym zdaniem w podsumowaniu wystąpienia na Sequoia Ascent (30 kwietnia 2026): „The unit of programming changed from typing lines of code to delegating larger »macro actions«…” — jednostką programowania przestało być pisanie linii kodu, a stało się delegowanie większych „makroakcji”.

Drabina autonomii Dana Shapiro (styczeń 2026) zamienia to w poziomy, na których da się umieścić konkretny przepływ pracy. O poziomie decyduje to, kto czyta wynik, a nie to, które narzędzie kupiłeś:

Poziom	Co robi agent	Co czyta człowiek	Narzędzia w tym trybie
L0 Ręcznie	Podpowiada kilka kolejnych tokenów (spicy autocomplete)	Każdy znak, zanim trafi na dysk	Uzupełnianie w dowolnym edytorze
L1 Z asystą	Wykonuje małe, wydzielone zadania, które mu zlecasz	Wszystko	Czat z agentem do jednorazowych zadań
L2 W parze	Pisze, a ty sterujesz na żywo	Każdą linię, w trakcie powstawania	Czat z agentem obok edytora
L3 Menedżer review	Wykonuje zadanie bez nadzoru	Każdy diff	Claude Code, Codex lub Cursor z zadaniem i poleceniem testów
L4 Menedżer specyfikacji	Implementuje ze specyfikacji	Testy, dowody i wyniki	Te same narzędzia plus kryteria akceptacji i bramki CI
L5 Ciemna fabryka	Specyfikacje na wejściu, wydania na wyjściu	Nikt nie czyta kodu	Potok agentów za mocną wyrocznią

Shapiro umieszcza większość programistów natywnie pracujących z AI na poziomie 2, a poziom 3 nazywa tym, na którym zatrzymują się prawie wszyscy. Powód jest arytmetyczny: agent pisze szybciej, niż ludzie potrafią czytać. Drabina, jej autotest i wymagania każdego poziomu są opisane na stronie drabina autonomii. Jak drabina, etapy cyklu życia i stanowiska fabryki składają się w całość, pokazuje jedna mapa.

Dlaczego wąskim gardłem staje się weryfikacja, a nie pisanie kodu

Dane nie pokazują, że agenci przyspieszają każdego programistę. Pokazują, że generowanie kodu się skaluje, a weryfikacja nie. Trzy źródła, każde z datą:

• Raport DORA 2025 (blog Google Cloud, 23 września 2025): „AI doesn’t fix a team; it amplifies what’s already there” — AI nie naprawia zespołu, tylko wzmacnia to, co już w nim jest.
• Faros AI, The Acceleration Whiplash (kwiecień 2026; telemetria dostawcy obejmująca 22 000 programistów z samodzielnie wybranej bazy klientów Faros): liczba ukończonych epików na programistę wzrosła o 66,2%, a jednocześnie liczba incydentów na pull request wzrosła o 242,7%, a mediana czasu w review o 441,5%.
• METR: randomizowane badanie z 2025 roku wykazało, że doświadczeni programiści open source z narzędziami AI potrzebowali o 19% więcej czasu (10 lipca 2025). Aktualizacja z lutego 2026 ma szacunki punktowe na korzyść AI, ale oba przedziały ufności obejmują zero, a METR sam nazywa te dane „an unreliable signal”, czyli niewiarygodnym sygnałem.

Razem mówią jedno: wolumen rośnie, a to, czy zamieni się w wartość, zależy od sprawdzeń wokół niego. Pełne dane, z kontrargumentami i zastrzeżeniami, znajdziesz w raporcie stan inżynierii agentowej.

Czego inżynieria agentowa wymaga od każdej roli

Narzędzia są te same dla wszystkich. Praca, którą tworzą, jest dla każdego inna.

Jesteś	Problem, który teraz należy do ciebie	Co wdrożyć najpierw	Twoja następna strona
Deweloper	Oddawanie zadań, które sprawdzisz bez ponownego czytania kodu	Plik instrukcji z działającymi poleceniami i kryteria akceptacji w każdym zadaniu	Ścieżka dewelopera
Tech lead	Kolejka review rośnie szybciej niż zespół	Review oparte na dowodach i krótka lista klas zmian do obowiązkowego czytania	Ścieżka tech leada
CTO / VP Engineering	Które pętle mogą działać na którym poziomie i jak to udowodnić	Polityka klas ryzyka dla każdej pętli i metryki wyników zamiast „% kodu”	Ścieżka CTO
Członek zarządu	Deklaracje o kosztach, tempie i ryzyku, których jeszcze nie umiesz sprawdzić	Trzy pytania do CTO (poniżej) i datowana baza dowodów	Ścieżka dla zarządu

Trzy pytania, które członek zarządu może zadać w tym tygodniu

1. Które z naszych pętli dostarczania działają z agentem i na którym poziomie drabiny jest każda z nich?
2. Co w pętlach powyżej poziomu 3 decyduje o tym, że praca jest „gotowa”, i kto ostatnio to zmieniał?
3. Co od wdrożenia stało się z incydentami, wycofaniami zmian i czasem review, a nie tylko z liczbą pull requestów?

Jeśli odpowiedzi brzmią „wszystkie”, „testy” i „mierzymy linie kodu”, zacznij od ekonomii oprogramowania budowanego przez agentów i ram metryk.

Którą pracę oddać agentowi najpierw?

Oddawaj pracę tam, gdzie maszyna potrafi orzec „gotowe”. Pytanie nie brzmi, jak trudne jest zadanie, tylko jak mocna jest wyrocznia: testy, typy, lintery i sprawdzenia w czasie działania programu, które zawodzą, gdy wynik jest błędny.

Praca	Wyrocznia, którą zwykle masz	Od czego zacząć	Dlaczego
Aktualizacje zależności, poprawki lintera i typów	Kompilator, type checker, istniejące testy	L4: agent działa, ty czytasz wyniki sprawdzeń	Sprawdzenie jest deterministyczne i istniało przed agentem
Testy dla nieprzetestowanego kodu (testy charakteryzujące)	Obecne zachowanie kodu	L3: czytasz testy, nie kod	Nowe testy są wyrocznią, więc sprawdza je człowiek
Funkcje z kryteriami akceptacji	Testy kontraktowe i end-to-end napisane najpierw	Z L3 w stronę L4	Kryteria stają się sprawdzeniami; zobacz kryteria akceptacji
Zrozumienie kodu i dokumentacja	Ludzka ocena odpowiedzi	L2	Przydatne od razu; nic nie jest scalane, więc ryzyko jest niskie
Uwierzytelnianie, płatności, schemat, migracje danych	Testy pokrywają dozwolone ścieżki, nie tę brakującą	L2 lub L3, kod czyta wskazana osoba	Błąd jest drogi i wychodzi na jaw późno
Nowa architektura i kierunek produktu	Brak	Prowadzi człowiek, agent jest partnerem do dyskusji	Nie ma jeszcze z czym porównać wyniku

Poziom należy do pętli, nie do firmy. Pętla aktualizacji zależności może działać na poziomie 4, podczas gdy praca nad funkcjami obok niej zostaje na poziomie 2.

Uruchom pierwszą pętlę agentową jeszcze dziś

Pętla wygląda tak samo w każdym narzędziu: zapisz, jak repozytorium się buduje i testuje, daj agentowi zadanie z kryteriami akceptacji, pozwól mu uruchomić sprawdzenia i przeczytaj dowody, które zwróci. Różnią się tylko polecenia.

1. Utwórz plik instrukcji. Agent potrzebuje twoich prawdziwych poleceń budowania, testów i lintera, inaczej zgaduje. Zobacz, co powinno trafić do CLAUDE.md i AGENTS.md.
2. Planuj przed edycją. Poproś o plan w trybie planowania i popraw go. Zły plan kosztuje jedną wiadomość, zły diff kosztuje całe review.
3. Uruchom zadanie z kryteriami akceptacji i warunkiem zakończenia. „Gotowe” znaczy „te sprawdzenia przechodzą”, a nie „agent tak twierdzi”.
4. Najpierw czytaj dowody, a diff tylko tam, gdzie dowody są słabe. Sekcja pod promptami pokazuje, co czytać.

Claude Code

Uruchom te polecenia w katalogu głównym repozytorium (Claude Code 2.1.283, sprawdzone 2026-09-26):

claude                          # start a session; type /init to generate CLAUDE.md
claude --permission-mode plan   # start in plan mode; Shift+Tab also cycles modes
claude --worktree               # run the task in its own git worktree

Na kanale latest (v2.1.283) sesja interaktywna na obsługiwanych modelach startuje w trybie auto, więc działania zatwierdza klasyfikator; żeby najpierw zaplanować, użyj --permission-mode plan albo Shift+Tab.

Claude Code czyta CLAUDE.md. Na kanale wydań latest (od v2.1.277) czyta też AGENTS.md, jeśli w projekcie nie ma CLAUDE.md (od v2.1.281 także na Bedrock, Google Cloud, Microsoft Foundry i przez bramy LLM). W sesji polecenie /code-review przegląda bieżące zmiany, zanim otworzysz pull request.

Codex

Uruchom te polecenia w katalogu głównym repozytorium (codex-cli 0.157.1, sprawdzone 2026-09-26):

codex                           # start the TUI; type /init to generate AGENTS.md, /plan for plan mode
codex --worktree                # run the session in its own git worktree
codex review --base main        # non-interactive review of the branch against main

Codex czyta AGENTS.md, zanim zacznie pracę. Codex działa też jako rozszerzenie IDE, aplikacja desktopowa (codex app, macOS i Windows) oraz Codex cloud (codex cloud, eksperymentalnie).

Cursor

Cursor wykonuje tę samą pętlę w edytorze (linia Cursor 3.x, sprawdzone 2026-08-28):

1. Umieść instrukcje projektu w Rules, łącznie z dokładnymi poleceniami budowania i testów.
2. Otwórz Agenta i przełącz go w Plan Mode, który tworzy szczegółowy plan implementacji, zanim napisze jakikolwiek kod.
3. Uruchom zadanie w Worktree, żeby agent pracował w odizolowanej kopii repozytorium, albo przekaż je Cloud Agentowi.
4. Pozwól, żeby Bugbot przejrzał pull request, zanim zajrzy do niego człowiek.

Prompty do pierwszej pętli

Prompt do skopiowania: zmapuj repozytorium i napisz plik instrukcji

Read this repository before changing anything. Then write the project instruction file
(CLAUDE.md for Claude Code, AGENTS.md for Codex, a Rule for Cursor) with:
1. What the project does, in two sentences.
2. The exact commands to install, build, run the tests, lint, and type-check.
   Run each one now and include only commands that succeeded; list the ones that failed separately.
3. The directory layout: where handlers, domain logic, tests, and migrations live.
4. Conventions a reviewer would reject a pull request for breaking.
5. Areas that need a human reviewer: auth, payments, schema, migrations.
Keep it under 150 lines. Do not describe what the code already makes obvious.

Prompt do skopiowania: zadanie z kryteriami akceptacji i raportem dowodów

Task: add cursor-based pagination to GET /orders.

Acceptance criteria:
- GET /orders returns at most 50 items and a next_cursor field.
- Passing next_cursor returns the following page with no duplicates or gaps.
- The old page parameter returns HTTP 400 with a message naming next_cursor.

Rules:
- First, write a failing test for each criterion and show me the failure output.
- Do not edit, delete, or skip existing tests, snapshots, CI files, or lint config.
  If one blocks you, stop and tell me why.
- Stop when the new tests and the full suite pass.

When you finish, report: each criterion -> the test that proves it -> pass/fail,
the commands you ran with their exit codes, and every file you changed outside src/orders/.

Prompt do skopiowania: znajdź pętle gotowe do delegowania

Audit this repository for agent readiness. Do not change any files.
For each of these task types — dependency bumps, lint and type fixes, bug fixes,
new API endpoints, UI changes, database migrations — tell me:
1. Which automated checks would fail if the change were wrong (name the command or CI job).
2. Whether those checks run in under 10 minutes locally.
3. Gaps: code paths with no test, tests that only snapshot output, CI steps that are allowed to fail.
Then rank the task types from "safe to delegate with checks only" to "needs a human reading the code",
and give the one test or CI change that would move each task type up one place.

Skąd wiesz, że wynik agenta jest poprawny, bez czytania każdej linii?

Najpierw czytasz dowody, a kod tylko tam, gdzie dowody nie wystarczą. Strona dowody zamiast diffów opisuje cztery artefakty, w tej kolejności:

1. Delta specyfikacji: które zachowanie się zmieniło, opisane zdaniami i porównane z tym, o co prosiłeś.
2. Wyniki akceptacji: każde kryterium przypisane do sprawdzenia, które się wykonało i przeszło.
3. Siła wyroczni: czy pull request zmienił testy, snapshoty, CI lub konfigurację lintera i czy testy zawiodłyby, gdyby kod był błędny. Zobacz, jak mocna jest twoja wyrocznia.
4. Sygnały z działającego systemu: przebieg każdej ścieżki akceptacji w środowisku preview lub staging, a po wdrożeniu metryki z wdrożenia kanarkowego.

Niektóre zmiany zawsze czyta wskazany człowiek, niezależnie od dowodów: uwierzytelnianie i autoryzacja, pieniądze, schemat, migracje danych, zmiany samej wyroczni i wszystko, czego nie pokrywa żadne sprawdzenie. Kieruj je przez CODEOWNERS, żeby obowiązkowe czytanie egzekwowała platforma, a nie czyjaś pamięć. Programista, który uruchomił agenta, odpowiada za dowody; właściciel kodu zatwierdza klasy do obowiązkowego czytania; organizacja spisuje tę listę raz, w polityce autonomii i klas ryzyka. Szablon, dzięki któremu CI odrzuca niekompletny pull request, to pakiet dowodów.

Które narzędzie AI do kodowania pasuje do twojego sposobu pracy?

Wszystkie trzy obsługują opisaną pętlę. Różnią się miejscem, w którym toczy się praca:

• Claude Code działa przede wszystkim w terminalu, a ten sam agent jest dostępny w aplikacji desktopowej, VS Code, JetBrains, w przeglądarce i w trybie headless (claude -p) w CI.
• Codex obejmuje CLI, rozszerzenie IDE, aplikację desktopową i Codex cloud, a review na GitHubie uruchamiasz przez @codex review.
• Cursor działa przede wszystkim w edytorze, a do pracy poza nim ma Cloud Agents, Automations i Bugbota.

Możesz używać dwóch: jednego do pracy interaktywnej, drugiego w CI. Narzędzie ma mniejsze znaczenie niż pętla wokół niego. Wybór modelu opisuje przegląd modeli, a porównanie narzędzi obok siebie jest na stronie porównanie narzędzi AI do kodowania.

Czy agenci zastąpią programistów i czy ten kod można wdrażać?

Zastąpienie. Praca przesuwa się z pisania na specyfikowanie, weryfikację i odpowiedzialność za wynik. Co to oznacza dla umiejętności i kariery, opisuje strona warsztat i kariera, gdy kod piszą agenci, a co zostaje po stronie człowieka — rola człowieka.

Jakość kodu. Kod agenta jest dokładnie tak wiarygodny jak sprawdzenia, które przeszedł. Traktuj „agent mówi, że skończył” jako deklarację, a pakiet dowodów jako dowód.

Bezpieczeństwo i własność intelektualna. Agent uruchamia polecenia z twoimi uprawnieniami. Zacznij od piaskownicy i ustawień zatwierdzania opisanych w uprawnieniach i sandboxingu, a potem zamodeluj zagrożenia całej konfiguracji według modelu zagrożeń dla agentów. Przechowywanie kodu i danych, wykorzystanie ich do trenowania oraz kwestie własności intelektualnej omawia strona prywatność i przetwarzanie danych.

Koszt. Ceny planów często się zmieniają i są zebrane w analizie cen. To, czy wydatek się zwróci, zależy od tego, które pętle przesuniesz wyżej na drabinie; strona o ekonomii zamienia to w model.

Co się psuje, gdy zespół wdraża narzędzia AI do kodowania?

Wolumen rośnie, a wąskim gardłem staje się review

Objaw: liczba pull requestów na osobę rośnie, czas do pierwszego review rośnie szybciej, a ludzie zaczynają zatwierdzać bez czytania. Wyjście: ogranicz rozmiar pull requestów, wymagaj czterech artefaktów dowodowych przed review i przenieś klasy niskiego ryzyka na review oparte wyłącznie na dowodach. Poziom 3 opisuje ten sufit i drogę przez niego.

Agent przechodzi testy, zmieniając testy

Objaw: zielony pipeline i błąd na produkcji, a w tym samym pull requeście poluzowana asercja albo wygenerowany na nowo snapshot. Wyjście: wycofaj zmianę testu, dodaj ścieżki testów, snapshotów i CI do CODEOWNERS i zapisz w pliku instrukcji, że agent ma się zatrzymać, zamiast edytować padający test. Pełną metodę opisuje strona ochrona wyroczni.

Plik instrukcji jest długi, nieaktualny albo błędny

Objaw: agent uruchamia polecenie testów, które już nie istnieje, albo ignoruje konwencje ukryte w 600 liniach. Wyjście: zostaw tylko polecenia, które działają dziś, i zasady, które egzekwuje reviewer, uruchom ponownie pierwszy prompt z tej strony po zmianach w buildzie i usuń wszystko, co widać w samym kodzie.

Autonomię przyznano od razu całej bazie kodu

Objaw: polityka mówi „agenci mogą mergować”, a pierwszy incydent uderza w rozliczenia (billing). Wyjście: przyznawaj poziomy dla każdej pętli i klasy ryzyka osobno, zaczynając od pętli, których wyrocznia istniała przed agentem. Szerokie obejścia, takie jak --dangerously-bypass-approvals-and-sandbox (Codex) czy bypassPermissions (Claude Code), trzymaj w jednorazowych piaskownicach z ograniczonym dostępem do sieci, nigdy na laptopie z produkcyjnymi poświadczeniami.

Sukces mierzy się odsetkiem kodu napisanego przez agentów

Objaw: dashboard pokazuje, że większość kodu pisze agent, a incydenty i czas review rosną. Wyjście: raportuj przepustowość i stabilność razem, tak jak robią to DORA i Faros, a metryki zdefiniuj raz, korzystając z ram metryk.

Dokąd dalej z inżynierią agentową

Wybierz ścieżkę dla swojej roli na stronie Zacznij tutaj albo przejdź od razu do strony, która pasuje do twojego następnego kroku.

Drabina autonomii Umieść każdą swoją pętlę na poziomie od 0 do 5 i znajdź pytanie, które ją ogranicza

Dowody zamiast diffów Cztery artefakty i pełna lista klas zmian do obowiązkowego czytania

Stan inżynierii agentowej Każda liczba z wydawcą, datą i zastrzeżeniem, razem z kontrargumentami

Szybkie efekty w pierwszych 24 godzinach Małe, sprawdzalne zadania, które możesz dziś oddać agentowi