Od asystentów do agentów: jak dziś tworzymy oprogramowanie

Rok temu opisaliśmy, jak nasi inżynierowie na co dzień korzystają z AI: asystenci w edytorze, bot AI, który podsumowuje każdy pull request, a wokół tego proces z jasnymi zadaniami, testami i przeglądem przez człowieka. Od tamtej pory sposób, w jaki tworzymy oprogramowanie, zmienił się bardziej niż przez kilka poprzednich lat.

Różnicę łatwo opisać. Asystent podpowiada kilka kolejnych linijek. Agent bierze całe zadanie: czyta zgłoszenie, poznaje kod, wprowadza zmianę, uruchamia testy i otwiera pull request. Rola inżyniera przesuwa się z pisania każdej linijki na definiowanie pracy, kierowanie nią i przegląd wyniku.

Wspieramy to własnym budżetem. Od stycznia 2026 roku firma opłaca subskrypcje Claude, a do czerwca objęły one programistów, architekta oprogramowania, tech leada i zarządzanie projektami – z wyższymi planami dla osób, które najczęściej pracują z agentami. Edytor nastawiony na AI, z którego nasi programiści korzystają na firmowych licencjach od końca 2024 roku, nadal jest częścią zestawu narzędzi.

Od podpowiedzi do zadania

Od marca 2026 roku w jednym z projektów dla klienta pull requesty przygotowane z agentem AI do kodowania stały się częścią codziennej pracy. Typowa zmiana wygląda dziś tak:

1. Praca jest opisana w zgłoszeniu z celem, a pull request ma numer tego zgłoszenia.
2. Inżynier uruchamia na nim agenta w repozytorium, z zasadami projektu wczytanymi z pliku instrukcji.
3. Agent wprowadza zmianę na własnej gałęzi i otwiera pull request z podsumowaniem, co zmienił i dlaczego.
4. W ciągu kilku minut bot AI do przeglądu kodu, z którego korzystamy od końca 2024 roku, dodaje własne omówienie zmiany.
5. Inżynier czyta oba podsumowania, prosi o poprawki albo wprowadza je sam i decyduje, czy zmiana zostanie scalona. Wdrożenie nadal jest decyzją człowieka.

Agenci dobrze sprawdzają się też w pracy równoległej. Pod koniec maja przeprowadziliśmy audyt nieużywanego kodu w aplikacji mobilnej – z narzędziami analizy statycznej i czterema agentami, które przeszukiwały kod równolegle. Wynikiem był pisemny raport, a nie usuwanie kodu: nic nie zostało skasowane automatycznie. Audyt wykrył też prawdziwy błąd, który trafił do backlogu jak każde inne ustalenie.

Plik instrukcji to nowy onboarding

Agent zaczyna każdą sesję bez żadnej wiedzy o projekcie. Dlatego spisujemy to, czego nowa osoba w zespole potrzebowałaby pierwszego dnia, w pliku, który agent czyta na początku: czym jest projekt, słownik pojęć, kim są użytkownicy, konwencje, które dokumenty trzeba zawsze wczytać oraz co agentowi wolno, a czego nie. Od stycznia 2026 roku prowadzimy takie pliki nie tylko w repozytoriach kodu, ale też w przestrzeniach analitycznych, gdzie agenci pomagają zamieniać zapisy warsztatów w dokumentację obecnych i docelowych procesów. W tym samym projekcie osobny plik instrukcji przygotowuje agenta do pracy nad UX: buduje on klikalne prototypy na prawdziwych komponentach aplikacji z danymi testowymi, a każdą zmianę w oryginalnych plikach musi oznaczyć i opisać.

Ta sama dyscyplina dotyczy każdego zadania. Dobry opis zadania podaje cel, zakres, co znaczy „gotowe”, które części kodu są istotne, czego nie wolno ruszać i jak sprawdzić wynik. Pisanie takich opisów jest dziś jedną z najważniejszych umiejętności w zespole. Zachowaliśmy też zasadę z wcześniejszej pracy: bez zgłoszenia nie ma kodu. Każdą zmianę da się powiązać z opisaną potrzebą.

Testy to warunek, nie dodatek

Zmiana przygotowana przez agenta bez testów to zgadywanie. Dopiero testy i działający build sprawiają, że osoba przeglądająca może jej zaufać. Tam, gdzie kod ma mało testów, rozsądnym pierwszym zadaniem dla agenta jest napisanie testów dla obecnego działania, zanim cokolwiek zostanie zmienione.

Przy zmianach widocznych dla użytkownika same zielone testy nie wystarczą. Ktoś musi obejrzeć wynik w środowisku deweloperskim, na prawdziwej treści, zanim zmiana pójdzie dalej.

Bezpieczeństwo: sekrety, uprawnienia i to, co czyta agent

Agent, który może uruchamiać polecenia, wymaga tej samej ostrożności co nowa osoba w zespole z dostępem do Twoich systemów – a pod pewnymi względami jeszcze większej. Nasze zasady:

• Minimalne uprawnienia. Agent dostaje tylko taki dostęp, jakiego wymaga jego zadanie. Żadnego bezpośredniego dostępu do produkcji.
• Sekrety nie trafiają do kodu ani do poleceń. Dane dostępowe zapewnia środowisko. Nigdy nie są commitowane ani wklejane do opisu zadania.
• Praca kończy się na gałęzi. Agenci wypychają swoją pracę i otwierają pull requesty. Scalanie i wdrażanie zostaje przy ludziach.
• Treść to dane, nie polecenia. Strony internetowe, dokumenty i zewnętrzne zgłoszenia, które czyta agent, mogą zawierać tekst napisany po to, żeby nim manipulować. Agenci powinni traktować taką treść jako informację, a uprawnienia i tak ograniczają to, co mógłby zrobić zmanipulowany agent.
• Kod klienta tylko za jego zgodą. Obowiązują te same zasady umowne co przy każdym innym narzędziu.

Model dobrany do zadania

Nie każde zadanie wymaga najmocniejszego modelu. Małą, dobrze opisaną zmianę może wykonać szybszy i tańszy model. Praca obejmująca wiele plików albo wymagająca starannego rozumowania zasługuje na mocniejszy. Decyzje architektoniczne i niejasne problemy zostają przy inżynierze, którego wspiera najlepszy dostępny model. A gdy agent utknie, właściwy ruch to przekazanie zadania mocniejszemu modelowi albo człowiekowi, a nie kolejna próba tego samego.

Co to znaczy dla inżynierów i dla klientów

Praca naszych inżynierów przesunęła się w stronę rozumienia problemu, projektowania rozwiązania, pisania precyzyjnych opisów zadań i krytycznego przeglądu. Dobry przegląd jest trudniejszy, niż się wydaje: trzeba przeczytać cudzą zmianę tak uważnie, jakby była podpisana własnym nazwiskiem – bo jest.

Dla klientów dobrze zdefiniowana praca idzie szybciej, a bramki jakości zostają te same: zgłoszenie, testy, przegląd i decyzja człowieka, zanim cokolwiek trafi na produkcję.

Jest też szersza perspektywa. Skoro agenci w ciągu roku tak bardzo zmienili naszą pracę, zmienią też codzienne procesy naszych klientów: obsługę zapytań, przygotowanie ofert, czytanie dokumentów. O tym napiszemy w kolejnym wpisie.

Agenci nie zniosły potrzeby inżynierskiej dyscypliny – to ona stała się czynnikiem rozstrzygającym. Jeśli chcesz porozmawiać o tym, jak taki sposób pracy może przyspieszyć Twój produkt albo jak AI może wesprzeć procesy w Twojej firmie, napisz do nas.