Kod piszą teraz agenty. Oto, czym stał się zawód dewelopera.

To pytanie wraca przy każdym rodzinnym stole, przy którym siedzi ktoś od programowania: skoro kod pisze maszyna, to co zostaje?

Uczciwa odpowiedź brzmi tak: pytanie celuje w niewłaściwą część tej roboty. Pisanie kodu nigdy nie było całą robotą. Było jej częścią widoczną, tą, która wyglądała na pracę dla każdego, kto przechodził za plecami. Było też, w większości tygodni, częścią najmniejszą.

To, co zostało zautomatyzowane, nigdy nie było całą robotą

Wszystko, co trafia na produkcję, przechodzi przez sześć ogniw:

1. Ktoś czegoś chce i mówi to źle.
2. Ktoś rozstrzyga, że warto to zrobić, i kiedy.
3. Ktoś zamienia to w opis na tyle precyzyjny, żeby dało się według niego działać.
4. Ktoś to buduje.
5. Ktoś sprawdza, czy nie zepsuło to czegoś innego.
6. Ktoś to wydaje i mówi o tym osobie, która prosiła.

Agenty wzięły ogniwo czwarte. Wzięły je przekonująco i będą w tym coraz lepsze. Prawie nikt nie mówi na głos, co to robi z pozostałymi pięcioma: robią się cięższe, a nie lżejsze.

Powodem jest przepustowość. Kiedy budowanie zajmowało dwa tygodnie, pięć otaczających je ogniw miało dwa tygodnie na przebiegnięcie. Były wolne, bo wolny był środek, i nikt nie zauważał, że są wolne. Kiedy budowanie zajmuje jedno popołudnie, cała reszta staje się wąskim gardłem, naraz.

Jedno ogniwo się zapadło. Pozostałe pięć niesie teraz ciężar, który to ogniwo zasłaniało.

To cała historia, a reszta tego artykułu opisuje, jak każde z tych pięciu wygląda, kiedy trzeba się nim naprawdę zajmować codziennie.

Ogniwo 1: usłyszeć, co budować, i nie zgubić po drodze połowy

Nowy tryb awarii jest konkretny i kosztowny: możesz zbudować wszystko, więc szybciej budujesz nie to, co trzeba.

Prośby przychodzą zewsząd. Wiadomość w wątku supportu. Zdanie na koniec rozmowy. Narzekanie w mediach społecznościowych. Zgłoszenie błędu, które w rzeczywistości jest przebraną prośbą o funkcję. Historycznie nie miało to wielkiego znaczenia, bo i tak mogłeś zbudować jedną rzecz na dwa tygodnie, a ta oczywista zwykle była tą właściwą. Teraz, kiedy możesz zbudować pięć rzeczy tygodniowo, różnica między właściwą piątką a niewłaściwą to większość twojego roku.

Muszą się wydarzyć dwie rzeczy i są to dwie różne rzeczy.

Po pierwsze, zgłoszenie musi być tanie dla osoby, która prosi. Jeśli użytkownik musi założyć konto, znaleźć formularz i opisać problem dwa razy, większość sobie odpuści, a ci, którzy sobie nie odpuszczą, nie są próbką reprezentatywną. Publiczna tablica feedbacku, na której każdy może zgłosić prośbę, dołączyć zrzut ekranu i śledzić, co się z nią dalej dzieje, usuwa to tarcie. Ludzie, którzy używają produktu, sami piszą prośby, własnymi słowami, z dołączonym kontekstem.

Po drugie, porządkowanie musi być automatyczne, bo surowy feedback nie zostaje użyteczny na długo. Dwadzieścia wiadomości mówiących mniej więcej to samo wygląda na dwadzieścia problemów, dopóki ktoś nie przeczyta całej dwudziestki i nie zauważy, że to jeden. To dokładnie ta robota, na którą nikt nie ma czasu. Idea Radar jest naszą odpowiedzią: surowe sygnały lądują nietknięte, same grupują się w tematy, duplikaty zostają skojarzone, zanim staną się dwoma osobnymi zadaniami do zbudowania, a każdy pomysł niesie liczbę różnych osób, które o niego poprosiły. Oryginalne sformułowanie nigdy nie jest przepisywane, bo dokładne słowa, których ktoś użył, to właśnie są dane.

Wynikiem tego ogniwa nie jest backlog. Jest nim korpus, który da się przeczytać.

Ogniwo 2: rozstrzyganie, czyli zasób, który zrobił się rzadki

Tablica pomysłów to nie plan. Zamiana jednego w drugie to ta ocena sytuacji, która kiedyś rozkładała się cienką warstwą na cały kwartał, a teraz musi się wydarzać co tydzień.

Liczą się tu dwa ruchy.

Promocja jest świadoma. Pomysł staje się zgłoszeniem w backlogu wtedy, gdy ktoś rozstrzyga, że warto go zbudować, a nie wtedy, gdy zostaje wysłany. Cała reszta zostaje widoczna na radarze wraz z licznikiem proszących, i to jest uczciwy stan rzeczy: usłyszane, nie zaplanowane. Backlog, w którym osiemdziesiąt procent linijek nigdy nie powstanie, nie jest planem, tylko archiwum o mylącym układzie.

Doprecyzowanie zakresu dzieje się przed budowaniem, a nie w jego trakcie. Mglisty feedback zamienia się w zwalidowaną makietę, na którą osoba prosząca może spojrzeć i ją potwierdzić. Pięć minut na potwierdzenie bije popołudnie spędzone na budowaniu niewłaściwego ekranu, a ten rachunek zrobił się dramatycznie korzystniejszy w dniu, w którym popołudnie budowania stało się popołudniem czasu agenta, które mogłeś wydać na coś innego.

Ogniwo 3: brief, czyli rzemiosło, które zastąpiło pisanie na klawiaturze

To tutaj przeniosło się prawdziwe rzemiosło.

Agent nie zakwestionuje niejednoznacznego polecenia tak, jak zrobiłby to kolega. Nie powie: „chwila, o który z dwóch procesów płatności ci chodzi”. Wypełnia lukę prawdopodobnym domysłem i wręcza ci coś spójnego i błędnego. Kosztem niejednoznaczności była kiedyś rozmowa. Teraz jest nim diff.

Tym, co dzieli ludzi osiągających dobre wyniki od ludzi walczących z własnymi agentami przez cały dzień, nie jest spryt w promptach. Jest nim kontekst wielokrotnego użytku. Cztery rodzaje, w kolejności malejącego zwrotu.

Kontekst, który agenty czytają, zanim zaczną eksplorować. Pliki konwencji trzymane w repozytorium (CLAUDE.md, AGENTS.md) oraz pamięć projektu, w której siedzą decyzje architektoniczne, dawne pułapki i powód, dla którego rzeczy są takie, jakie są. Napisane raz, czytane przez każdego agenta na każdej maszynie, bezterminowo. To dziś pisanie o najwyższej dźwigni, jakie wykonuje deweloper, i prawie nikt nie rezerwuje na nie czasu.

Procedury, zapisane jako procedury. Kiedy dziesiąty raz tłumaczysz swoją listę kontrolną wydania, nie robisz briefu, tylko przepisujesz. Biblioteka skilli zamienia powtarzalną procedurę w coś, co agent ładuje wtedy, gdy zadanie pasuje, a biblioteka promptów robi to samo dla samych briefów.

Pokazywać zamiast opisywać. Akapit opisujący źle wyrównany przycisk jest gorszy niż obrazek źle wyrównanego przycisku. Wyślij fragment ekranu wprost albo narysuj po nim, żeby wskazać, o co ci chodzi. Przy stronie internetowej podanie agentowi żywego DOM bije jej opisywanie, za każdym razem.

Mówić zamiast pisać. Trzyzdaniowy brief powiedziany na głos niesie więcej niuansu niż to jedno zdanie, które chciałoby ci się napisać. Dyktowanie głosowe do szybkiego polecenia, tryb głosowy wtedy, gdy chcesz wymiany zdań bez dotykania klawiatury. Brzmi jak funkcja dla wygody. W praktyce to funkcja przepustowości: ludzie mówią więcej, niż piszą, a agenty są ograniczone tym, co im powiesz.

Za pierwsze trzy płaci się przy każdym zadaniu. Za czwarty płaci się raz i zbiera bezterminowo.

Ogniwo 4: prowadzenie roboty, na właściwej maszynie

Jeden agent to narzędzie. Kilka agentów to system, a system potrzebuje operatora.

Praktyczne pytania nie są efektowne i to właśnie one są tą robotą. Co może działać równolegle bez tego, żeby dwa agenty edytowały ten sam moduł? Które zadanie zasługuje na twoją uwagę w trakcie działania, a które nie? Co ma się dziać, kiedy śpisz?

To ostatnie pytanie rozstrzyga, gdzie robota się wykonuje. Wszystko, co możesz chcieć przerwać, poprawić albo skierować gdzie indziej w trakcie, zostaje na maszynie przed tobą. Robota długa, dobrze opisana, bez szarych stref idzie gdzie indziej: na inny komputer, który masz albo na serwer po SSH, tak żeby dwugodzinne zadanie nie trzymało twojego laptopa jako zakładnika. Robota powtarzalna idzie na harmonogram. Pytaniem rozstrzygającym nigdy nie jest surowa moc, tylko prawdopodobieństwo, że będziesz musiał interweniować.

Kiedy zadanie ma etapy naprawdę różniące się od siebie, pojedynczy agent jest dla niego złym kształtem. Budowa, którą trzeba potem przetestować, a następnie przejrzeć, to trzy fachy o trzech różnych zestawach kompetencji, a zespoły agentów pozwalają narysować to przekazanie pałeczki wprost, zamiast tłumaczyć kontekst od nowa na każdym kroku.

A skoro nic z tego nie wymaga, żebyś tam siedział, sterowanie tym z telefonu przestaje być ciekawostką. Przeczytanie pytania agenta i odpowiedzenie na nie w dwadzieścia sekund z pociągu to różnica między zadaniem skończonym a zadaniem, które czekało na ciebie cztery godziny.

Ogniwo 5: przegląd, czyli miejsce, w którym mieszka odpowiedzialność

To ogniwo, którego nie da się oddelegować, i powód nie jest techniczny.

Agenty zastąpiły już większość czytania linia po linii. Czego nie mogą wziąć, to podpis. Odpowiedzialność nie przechodzi na model. Kiedy migracja kasuje kolumnę na produkcji, „napisał to agent” nie jest zdaniem, które ktokolwiek przyjmuje, i bardzo dobrze.

Zmienia się kształt przeglądu, a nie jego istnienie. Czytanie każdej linijki nie przeżywa zderzenia z pięcioma agentami działającymi równolegle, a człowiek przelatujący wzrokiem diff na dziewięćset linii o osiemnastej produkuje podpis bez produkowania wiedzy. Zasada, która się broni, to przegląd proporcjonalny do promienia eksplozji: teksty i style przelatuje się wzrokiem, a autoryzację, płatności, uprawnienia, dane osobowe i migracje czyta się linia po linii, za każdym razem, i robi to ktoś, kto umiałby je napisać.

Dwie rzeczy czynią to wykonalnym. Możliwość zobaczenia diffa w rozbiciu na agenty, a nie jednej scalonej kupy, mówi ci, kto co zmienił, kiedy trzy z nich pracowały w tym samym repozytorium. A dopięcie rozmowy do commita odpowiada na pytanie, które naprawdę kosztuje czas pół roku później, a nim nigdy nie jest „co się zmieniło”, tylko „dlaczego”.

Przy wszystkim, co ma interfejs, sprawdzanie nie kończy się na diffie. Agent sterujący prawdziwą przeglądarką może przejść przez ścieżkę, którą właśnie zbudował, i zdać relację z tego, co zobaczył, a to wyłapuje tę klasę błędów, która w kodzie źródłowym czyta się doskonale.

Poświęciliśmy cały artykuł temu, gdzie tę uwagę wydawać: czy powinieneś nadal przeglądać kod swojego agenta AI.

Ogniwo 6: wydanie i domknięcie pętli

Wydanie to łatwiejsza połowa tego ogniwa. Ta połowa, którą się pomija, to powiadomienie osoby, która prosiła.

To także połowa o najwyższym zwrocie. Użytkownik, który coś zgłasza i później dowiaduje się, że to weszło, zgłosi następną rzecz. Użytkownik, który zgłasza w ciszę, przestaje zgłaszać, a ty tracisz materiał zasilający ogniwo pierwsze. Kiedy zgłoszenie powstałe z publicznej prośby zostaje zamknięte, jego autor powinien się o tym dowiedzieć bez tego, żeby ktokolwiek musiał pamiętać o wysłaniu maila.

Wcześniej zwykle jest ktoś, kto musi zobaczyć, że to działa, i nie ma twojego środowiska deweloperskiego: klient, projektant, kolega na innym kontynencie. Publiczny adres HTTPS wskazujący na twoją lokalną maszynę zamienia to z wdrożenia w link do wysłania, a feedback, który wraca, idzie prosto do ogniwa pierwszego.

Łańcuch się domyka. To właśnie czyni z tego zawód, a nie kolejkę.

Co naprawdę się skurczyło, a co naprawdę urosło

Przeczytaj tę tabelę uczciwie, a lęk zmieni kształt. Części, które się skurczyły, to te, na które najłatwiej było zatrudnić. Części, które urosły, to te, które wymagają kogoś rozumiejącego system, użytkowników i konsekwencje. To zawód trudniejszy, a nie mniejszy, i znacznie mniej samotny niż ta wersja, w której pisało się na klawiaturze cały dzień.

Gdzie w tym wszystkim jest AgentsRoom

Budujemy narzędzie, które trzyma cały łańcuch, bo alternatywą jest sześć narzędzi, które nic o sobie nie wiedzą.

Konkretnie: prośby lądują na tablicy, same układają się w pomysły, awansują do zgłoszeń, zostają doprecyzowane do czegoś, czego agent nie może źle odczytać, są wykonywane przez jednego agenta albo cały ich zespół, na twojej maszynie albo na zdalnej, są przeglądane w rozbiciu na agenty z dopiętą rozmową i zostają zamknięte wraz z powiadomieniem osoby, która prosiła. Jedno okno, jedno miejsce, w którym stan roboty jest prawdziwy.

Pojedyncze klocki istnieją gdzie indziej. To połączeń między nimi nikt nie wydawał, a to właśnie w połączeniach robota wycieka.

Pytania, które ludzie naprawdę zadają

Czy AI zastąpi programistów?

Zastąpiło pisanie na klawiaturze, a nie zawód. Pisanie kodu to jedno ogniwo łańcucha, w którym są też: usłyszenie, czego potrzebują użytkownicy, rozstrzygnięcie, co warto zbudować, precyzyjne opisanie tego, prowadzenie roboty, sprawdzenie jej i wydanie. Agenty ścięły koszt jednego ogniwa, przez co wąskim gardłem stało się pozostałe pięć. Mniej ludzi będzie dostawać pieniądze za produkowanie linijek. Więcej ludzi dostaje je za rozstrzyganie, które linijki powinny istnieć, i za odpowiadanie za nie, kiedy już działają.

Co konkretnie robi deweloper, kiedy kod piszą agenty?

Sześć rzeczy, z których tylko jedna była widoczna na ekranie pełnym kodu. Zbierasz to, o co ludzie proszą, rozstrzygasz, co budować i w jakiej kolejności, opisujesz robotę na tyle precyzyjnie, żeby agent nie mógł jej źle odczytać, prowadzisz kilka zadań naraz, nie tracąc wątku, przeglądasz proporcjonalnie do tego, co dana zmiana może zepsuć, i wydajesz, powiadamiając osobę, która prosiła. Rzemiosło przesunęło się z wytwarzania zmiany na jej opisanie i wzięcie za nią odpowiedzialności.

Czy nadal trzeba umieć programować?

Tak, a do czytania nawet bardziej niż wcześniej. Nie musisz już pamiętać składni języka, którego dotykasz dwa razy w roku, bo pisze ją agent. Musisz umieć otworzyć diff i w kilka sekund wiedzieć, czy migracja jest odwracalna, czy przesunęło się sprawdzenie autoryzacji, czy zapytanie wytrzyma dziesięciokrotnie większy ruch. Kto nie umie czytać kodu, nie przejrzy agenta, a kto nie przejrzy agenta, ten nim nie steruje, tylko ma nadzieję.

Co psuje się najpierw, kiedy oddajesz kodowanie agentom?

Priorytetyzacja. Kiedy budowanie zajmuje popołudnie zamiast dwóch tygodni, koszt zbudowania niewłaściwej rzeczy znika z pola widzenia, więc ta rzecz powstaje. Zespoły mają na koniec więcej wydanych funkcji i ani jednego rozwiązanego problemu więcej. Drugą rzeczą, która się psuje, jest pętla zwrotna: prośby użytkowników przychodzą szybciej, niż ktokolwiek zdąży je uporządkować, więc odkładają się w wątkach czatu i giną, a ta sama prośba zostaje zbudowana dwa razy, bo nikt nie zauważył, że to ta sama.

Jaka umiejętność jest najtrudniejsza w tym nowym trybie pracy?

Napisanie briefu, którego agent nie może źle odczytać. Agent nie zakwestionuje niejednoznacznego polecenia tak, jak zrobiłby to kolega: wypełnia luki prawdopodobnym domysłem i wydaje ci coś spójnego i błędnego. Ludzie osiągający dobre wyniki nie są tymi ze sprytnymi promptami, tylko tymi, którzy utrzymują na miejscu kontekst wielokrotnego użytku: pliki konwencji trzymane w repozytorium, zapisaną procedurę na każde powtarzalne zadanie, pamięć projektu, którą agenty czytają, zanim zaczną eksplorować, oraz zrzuty ekranu albo szkice zamiast akapitów opisujących ekran.

Czy agenty kodujące mają działać na twojej maszynie, czy na zdalnej?

Na obu, wybieranych zadanie po zadaniu. Wszystko, czemu chcesz się przyglądać, co chcesz przerywać albo poprawiać w trakcie, zostaje na maszynie przed tobą. Robota długa, dobrze opisana, bez szarych stref idzie na inny komputer, który masz, albo na serwer po SSH, tak żeby dwugodzinne zadanie nie trzymało twojego laptopa jako zakładnika. Pytaniem rozstrzygającym nie jest moc, tylko prawdopodobieństwo, że będziesz musiał interweniować.

Wersja skrócona

Zawód nie zniknął. Wyprowadził się z edytora do łańcucha, który go otacza.

Jeśli w tym miesiącu masz zmienić jedną rzecz, wybierz ogniwo pierwsze. Wszystko, co jest za nim, to zmarnowany wysiłek, kiedy celuje w niewłaściwy problem, a to jedyne ogniwo, w którym godzina twojej uwagi wciąż bije godzinę czasu agenta w stosunku, którego nikt nie umie zmierzyć.