Osiem miesięcy prowadzenia produktu w pojedynkę z agentami AI jako współinżynierami

TL;DR: Od ponad ośmiu miesięcy prowadzę produkcyjny serwis z ofertami pracy jako projekt poboczny, całkowicie sam, obok głównej pracy inżynierskiej. Agenci kodujący AI pracują przy nim jako współinżynierowie, a nie jako podpowiadanie kodu. W domu podstawowym narzędziem jest Claude Code, w korporacyjnej pracy na etacie Kiro CLI, a Cursor służy mi za IDE od 2023 roku. To nie jest relacja z tygodniowego eksperymentu. To tryb pracy, który wreszcie przeprowadził projekt poboczny przez coś, co nazywam ścianą 60%: moment, w którym moje samodzielne produkty umierały pod ciężarem backendu, devopsu i przypadków brzegowych. Agenci tę ścianę usunęli. Nie usunęli potrzeby oceny produktowej, wyczucia UX ani weryfikacji. W tym artykule opisuję, gdzie agenci naprawdę przyspieszają, a gdzie nie, jak układam kontekst, uprawnienia i weryfikację, żeby mogli pracować samodzielnie i niczego nie zepsuć, oraz ile to uczciwie kosztuje: stały abonament za $200 miesięcznie.

Ściana 60%

Mam dziewięć lat komercyjnej pracy full-stack i frontendowej w zespołach. Pod spodem ciągnie się długa lista projektów pobocznych, które umierały w tym samym miejscu. Nigdy na etapie pomysłu i nigdy na etapie prototypu. Stawały mniej więcej na 60%: interfejs istniał, główna ścieżka działała, podstawowy model danych był gotowy. Zabijało je wszystko, co przychodziło potem. Zadania w tle i ponowienia. Narzędzia administracyjne. Migracje. Monitoring. Jedenasty przypadek brzegowy w formularzu. Te mało efektowne 40%, które oddziela demo od produktu.

Schemat powtarzał się bezlitośnie: po ośmiu godzinach pracy energia kończyła się dokładnie tam, gdzie zaczynała się mozolna robota. To nie był problem umiejętności, tylko przepustowości. Jedna osoba z dwiema wieczornymi godzinami nie przemieli infrastruktury, przypadków brzegowych i utrzymania prawdziwego produktu, a matematyki nie obchodzi, jak bardzo ktoś jest zmotywowany.

Dziś ten projekt, dokładnie taki, jakie kiedyś stawały w pół drogi, działa na produkcji, ma prawdziwych użytkowników i rośnie. Prowadzę go w całości sam: backend, frontend, pipeline do scrapowania i przetwarzania danych, dopasowywanie przez AI, treści i utrzymanie. Różnica nie polega na tym, że zrobiłem się bardziej zdyscyplinowany. Różnica to nowa generacja narzędzi, a konkretniej to, jak postanowiłem z niej korzystać. Więcej o tej historii na stronie o mnie.

Jakie opcje naprawdę rozważałem

Kiedy postanowiłem znowu podejść do poważnego produktu, rozpisałem realne opcje, zamiast sięgać po to, co akurat było modne.

Opcja pierwsza: bez AI. Pełna kontrola, zero kosztów, a każda linijka przechodzi przez moją głowę, więc rozumiem system w całości. Wada jest zabójcza: właśnie ten tryb trzy razy z rzędu doprowadził mnie do ściany 60%. Powtarzanie tego samego eksperymentu po raz czwarty w nadziei na inny wynik nie było planem.

Opcja druga: autouzupełnianie w IDE. Z Cursora korzystałem od 2023 roku, na tyle wcześnie, że AI w IDE oznaczało głównie podpowiadanie kodu plus czat w panelu bocznym. Zalety są realne: szybsze pisanie, niskie ryzyko, bez zmiany sposobu pracy. Tyle że autouzupełnianie działa na poziomie naciśnięć klawiszy, a ściana stoi na poziomie zadań. Podpowiedzi nigdy nie uruchomiły za mnie migracji, nie postawiły zestawu testów ani nie wyśledziły błędu w całym kodzie o 22:00. Przyjemne 60% robiłem dzięki nim o jakieś 20% szybciej, a dla ważnych 40% nie zmieniały nic.

Opcja trzecia: asystenci czatowi. Wklejasz kod do okna czatu i dostajesz rozumowanie. Naprawdę przydatne, gdy trzeba przegadać architekturę albo wejść na nieznany teren. Wada: to ja byłem schowkiem. Cały kontekst żył w mojej głowie, każdą odpowiedź trzeba było ręcznie wprowadzić i ręcznie sprawdzić jeszcze raz, a wszystko, co obejmowało więcej niż kilka plików, się rozsypywało. Świetny konsultant, fatalny współpracownik.

Opcja czwarta: autonomiczni agenci z zabezpieczeniami. Agent, który mieszka w repozytorium, czyta kod, edytuje pliki, uruchamia polecenia i testy, i iteruje, aż zadanie jest skończone od początku do końca. Zalety pasują dokładnie do kształtu mojego problemu: działa na poziomie zadań, nie męczy się i może przemielić mało efektowne 40%, kiedy śpię albo siedzę na spotkaniach. Wady są równie realne: agent z dostępem do powłoki może usunąć nie to, co trzeba, uruchomić destrukcyjną migrację albo wypchnąć bzdury, a w każdym z tych przypadków z pełnym przekonaniem zgłosi sukces. Autonomia bez struktury to obciążenie, a nie dźwignia.

Wybrałem opcję czwartą z jednym zastrzeżeniem, które okazało się sednem całej gry: autonomię zdobywa się strukturą, nie dostaje się jej domyślnie. Najciekawsza część tego artykułu to właśnie ta struktura.

Gdzie agenci naprawdę przyspieszają

Uczciwy wniosek po ponad ośmiu miesiącach: agenci są najmocniejsi dokładnie tam, gdzie projekty prowadzone w pojedynkę umierają.

Żmudna praca od początku do końca. Pipeline do scrapowania i przetwarzania danych za moim serwisem z ofertami powstał we współpracy z agentem: pobieranie, parsowanie, deduplikacja, klasyfikacja, zapis, ponowienia, alerty. Nic z tego nie jest trudne intelektualnie, wszystko to jest kwestią ilości. To samo dotyczy paneli administracyjnych, okablowania i18n, audytów zależności i długiego ogona stanów formularzy. To są te 40% za ścianą, a agent przerabia je w tempie, którego jeden zmęczony człowiek nigdy by nie osiągnął.

Migracje i refaktory. Zmiana nazwy pojęcia w sześćdziesięciu plikach, przeniesienie modułu, przerobienie wzorca wszędzie, gdzie występuje, a potem build i testy, które potwierdzają, że nic się nie zepsuło. Mechaniczne, sprawdzalne, wyczerpujące ręcznie i niemal darmowe z agentem.

Szkielety testów. Agenci świetnie radzą sobie z tą częścią testowania, którą inżynierowie odkładają na później: konfiguracją środowiska testowego, fixture'ami, pierwszymi dwudziestoma przypadkami wokół błędu. Nadal to ja decyduję, co zasługuje na test. Agent usuwa próg wejścia.

Czarna robota przy dochodzeniu. Odtwórz ten błąd, przeczytaj te logi, znajdź każde miejsce, w którym ustawiana jest ta wartość, powiedz mi, która z tych pięciu hipotez przetrwa konfrontację z dowodami. Agent przeczesuje kod w kilka minut i wraca z wnioskiem, który mogę sprawdzić. Ja w tym czasie nie tracę wieczoru na grepową archeologię.

Przy większych funkcjach ten tryb się skaluje. Planuję w jednej skupionej sesji, dzielę funkcję na kilka równoległych podzadań o małym ryzyku konfliktów, z kontraktami między nimi uzgodnionymi z góry, każde podzadanie uruchamiam w odizolowanej kopii roboczej, a potem świadomie integruję wszystko w ostatniej sesji z weryfikacją end-to-end. Trzech czy czterech agentów budujących równolegle, podczas gdy ja robię przegląd, to przepustowość, której wcześniej nie miałem, budując sam po wieczorach.

Gdzie agenci nie pomagają

To równie ważne, bo właśnie tu przehajpowana wersja tego artykułu by Cię okłamała.

Decyzje produktowe. Którą funkcję budować, jaki segment obsługiwać, co wyciąć. Agent z równym przekonaniem obroni każde stanowisko. Jakość decyzji bierze się z rozmów z użytkownikami i obserwowania ich prawdziwego zachowania, a tego żaden model za mnie nie zrobi.

Wyczucie UX. Agenci tworzą interfejsy, które wyglądają wiarygodnie, a wiarygodnie nie znaczy dobrze. Każdy ekran, który użytkownicy faktycznie chwalą, przeszedł kilka rund mojej własnej oceny: odstępy, hierarchia, co usunąć. Agent iteruje szybko, kiedy potrafię powiedzieć, co jest nie tak, ale sam tego nie wie.

Decyzje w niejasnych sytuacjach. Ceny, ton tekstów, to, czy ryzykowna migracja jest warta zachodu w tym tygodniu, czy funkcja jest na tyle gotowa, żeby ją wypuścić. Tu potrzebny jest ktoś, kto odpowiada za konsekwencje.

Jest też jedno metaograniczenie, które kształtuje całą resztę: gdy agent zgłasza "gotowe", to jest twierdzenie, a nie fakt. Traktowanie wyniku agenta jako skończonej pracy bez weryfikacji to prosta droga do wypuszczania pewnych siebie bzdur. I tu dochodzę do struktury.

Struktura, dzięki której autonomia jest bezpieczna

Trzy filary: kontekst, uprawnienia, weryfikacja. Opiszę wzorce, a nie moją dokładną konfigurację, bo wzorce da się przenieść, a konfiguracji nie.

Kontekst. Agent jest tak dobry, jak jego wiedza o projekcie, a okno kontekstu przepełnione po brzegi traci jakość. Moje zasady: mały zestaw globalnych instrukcji obowiązujących w każdym projekcie (standardy kodu, konwencje gita, domyślne ustawienia bezpieczeństwa), pliki instrukcji w każdym projekcie, które działają jak router do głębszej dokumentacji, i wyspecjalizowane instrukcje ładowane tylko w projektach, które ich potrzebują. Jeden czat to jedno skupione zadanie. Gdy zadanie się zmienia, zaczynam od nowa. Wszystko, co warto zapamiętać, trafia do dokumentacji projektu w tej samej sesji, w której się tego nauczyłem, więc nowa sesja może podjąć pracę z plików, a nie z rozdętej historii rozmowy. Trwała wiedza żyje w repozytorium, nie w czacie.

Uprawnienia. Cel to agent, który doprowadza pracę do końca, nie pytając o każdy odwracalny krok, a jednocześnie fizycznie nie jest w stanie wykonać kroków nieodwracalnych. Buduję to warstwami: tryb uprawnień, który pozwala na normalną pracę, ale przy ryzykownych akcjach uruchamia kontrolę bezpieczeństwa; twarde reguły zakazu dla kategorii, które nie mogą się wydarzyć w żadnym trybie, takich jak force push, usuwanie gałęzi lub repozytoriów i dotykanie sekretów; oraz sprawdzenie przed wykonaniem, które łapie destrukcyjne polecenia nawet wtedy, gdy przychodzą opakowane albo zamaskowane. Przy pracy równoległej najwięcej robi izolacja: każdy agent dostaje własną kopię roboczą z wyłączonym pushem i bez produkcyjnych danych dostępowych, więc w najgorszym razie powstaje zła gałąź, której nigdy nie scalę. Nad tym wszystkim stoją bramki dla człowieka, których automatyzacja nigdy nie przekracza: migracje schematu, merge do głównej linii i wdrożenia na produkcję należą do mnie. Testuję też same zabezpieczenia, bo warstwa bezpieczeństwa, której nikt nigdy nie próbował złamać, to nadzieja, a nie kontrola.

Weryfikacja. Każde twierdzenie agenta sprawdzam na tym poziomie, na którym zostało postawione. Twierdzenia o kodzie: zbuduj go, uruchom testy. Twierdzenia wizualne: otwórz stronę i popatrz, bo markup, który dobrze się czyta, potrafi wyrenderować się źle. Poprawki błędów: najpierw test, który pada, potem poprawka, inaczej nie wiadomo, czy cokolwiek zostało naprawione. Twierdzenia o braku czegoś ("tej funkcji jeszcze nie ma") sprawdzam podwójnie, bo pojedyncze nieudane wyszukiwanie już raz skończyło się u mnie planowaniem pracy, która była zrobiona. Właściwie żadna z tych rad nie dotyczy wyłącznie agentów. Tak robi każdy dobry recenzent z pracą dowolnego współpracownika. Agent po prostu sprawia, że rola recenzenta staje się moim głównym zajęciem.

Ile to kosztuje, uczciwie

Pieniądze: stały abonament na najwyższy plan Claude (Max 20x, $200 miesięcznie), bez żadnych dodatkowych opłat za zużycie. Przy produkcie, który inaczej wymagałby godzin kontraktora albo po prostu by nie istniał, to kwota bez znaczenia. Model abonamentowy zmienił też pożytecznie moje zachowanie: kiedy koszt krańcowy zadania spada praktycznie do zera, przestajesz racjonować dobry model i zaczynasz optymalizować szybkość i jakość.

Czas: uczciwie liczony narzut to utrzymanie samego systemu. Pliki z instrukcjami się rozjeżdżają, zabezpieczenia wymagają od czasu do czasu audytu, a każde usprawnienie workflow to godzina, w której nie buduję funkcji. Powiedzmy kilka godzin miesięcznie. Zwraca się, ale udawanie, że narzut wynosi zero, byłoby właśnie tym hajpem, którego obiecałem unikać.

Skupienie: typową porażką całego tego układu jest samozadowolenie. Tygodnie, w których agenci marnowali mój czas, to były tygodnie, w których pomijałem weryfikację, bo poprzednie dziesięć zadań poszło dobrze. Ceną jest stała czujność na etapie przeglądu i nie podlega ona negocjacjom.

Wnioski po ośmiu miesiącach

• Ścianą była przepustowość, nie talent. Projekty prowadzone w pojedynkę umierały na 60%, bo jedna zmęczona osoba nie przemieli po wieczorach infrastruktury i przypadków brzegowych. Agenci atakują dokładnie ten odcinek i dlatego zmienili wynik, a nie tylko tempo.
• Autonomię się zdobywa, a nie dostaje. Pliki kontekstu, warstwowe uprawnienia, izolacja pracy równoległej i bramki dla człowieka przy nieodwracalnych akcjach to rzeczy, dzięki którym można bezpiecznie pozwolić agentom pracować do końca. Bez tej struktury opcja czwarta degraduje się do opcji trzeciej z dodatkowym ryzykiem.
• Agenci przenoszą wąskie gardło z pisania na decydowanie. Moim deficytowym zasobem jest teraz ocena: co budować, co jest wystarczająco dobre, co jest faktycznie prawdą. To lepsze wąskie gardło, ale nadal wąskie gardło.
• Trwała wiedza należy do plików, nie do czatów. Zapisywanie decyzji i wniosków w dokumentacji projektu w chwili, gdy się pojawiają, sprawia, że świeże, skupione sesje są tanie, a w skupionych sesjach agenci pracują najlepiej.
• "Gotowe" to twierdzenie, dopóki go nie sprawdzisz. Zbuduj, przetestuj, obejrzyj na własne oczy. Przegląd to teraz główna praca. Pominięcie go to droga do wypuszczania pewnych siebie bzdur.
• $200 miesięcznie to najtańszy współinżynier, jakiego kiedykolwiek zatrudnisz. Prawdziwą ceną jest dyscyplina w takim układaniu pracy, żeby bardzo szybki, niezmordowany i czasem mylący się współpracownik czynił Cię szybszym, a nie bardziej niechlujnym.