AI jako podwykonawca: jak przestałem bać się automatyzacji

Chciałbym opowiedzieć ci o chwili, w której zrozumiałem, że muszę zmienić sposób, w jaki pracuję z agentami AI.

Byłem trzy godziny pochylony nad debugowaniem „prostej" funkcji, którą napisał jeden z moich agentów. Agent śmiało commitował zmiany, wysłał je do produkcji i zostawił optymistyczną wiadomość o zakończeniu zadania. był tylko jeden szkopuł: kod był kompletnie błędny. Nie zbugowany — po prostu fundamentalnie nie rozumiał tego, co próbowaliśmy zbudować.

Tamto zdarzenie przełamało coś w moim sposobie myślenia. Wcześniej traktowałem agentów jak pomocnych juniorów, którzy potrzebują prowadzenia za rękę. Ale juniorzy nie wysyłają nietestowanego kodu do produkcji, kiedy śpisz.

Więc zmieniłem metaforę. Kompletnie.

Model podwykonawcy

Zamiast traktować agenty AI jak pracowników czy asystentów, zacząłem traktować je jak podwykonawców. Co to oznacza w praktyce?

Podwykonawca nie ma kluczy do twojego budynku. Nie pojawia się bez zaproszenia. Kończy swój zakres prac i przedstawia fakturę — którą sprawdzasz przed zapłatą. Jeśli jakość jest niezadowalająca, odsyłasz do poprawki.

To nie kwestia braku zaufania. To kwestia wyrównania zachęt i odpowiedzialności. Kiedy podwykonawca wie, że jego rolą jest dostarczenie gotowego artefaktu do twojej oceny — nie podejmowanie jednostronnych decyzji — pracuje lepiej. Jest skupiony. Produkuje wyniki w ramach wyznaczonych granic.

Czego potrzeba w praktyce

Ta mentalna ramka wymaga technicznego podparcia. W moich projektach wygląda to tak:

Zakres tokenów to podstawa

Moje agenty operują z ograniczonymi poświadczeniami, które fizycznie nie mogą dotknąć produkcji. Mają dostęp read do głównego codebase'u i dostęp write do osobnego repozytorium staging. To nie jest polityka — to ograniczenie kryptograficzne. Nawet jeśli agent zwariuje albo wygeneruje zmyślone komendy git, nie może zmodyfikować kodu produkcyjnego. Tokeny mu na to nie pozwolą.

Repozytorium staging to skrzynka pocztowa

Nic nie merge'uje się ze staging automatycznie. Domyślna gałąź tego repo to dosłownie nagrobek — branch o nazwie „no-main" zawierający tylko README z informacją „proszę używać głównej gałęzi oryginalnego repozytorium".

Agenty pushują tu swoje gotowe zmiany. Informują mnie, że branche są gotowe. Wtedy ja przeglądam, cherry-pickuję to, co działa i integruję ręcznie. Brzmi to żmudnie, dopóki nie uświadomisz sobie, że dokładnie tak przez dwadzieścia lat działał Linux. Kontrybutorzy wysyłają patche. Maintainerzy je aplikują.

Review to nie podlegająca negocjacji zasada

Żaden agent nigdy nie merge'uje własnego kodu. Kropka. Branch nie zostaje usunięty, dopóki niezależnie i programowo nie zweryfikuję, że jego commity są bezpiecznie wewnątrz produkcji. „Ufaj, ale sprawdzaj" to za mało, kiedy weryfikacja jest darmowa.

Dlaczego to działa dla solo developerów

Oto sedno bycia solo developerem lub małym zespołem: nie tylko budujesz software. Utrzymujesz kontekst, który nie istnieje nigdzie w kodzie. Historii incydentów. Edge case'ów. Klienta z dziwną konfiguracją. Trzech rzeczy, które próbowałeś i które nie zadziałały.

Agenty mają zerowy dostęp do tego kontekstu. Czytają pliki, ale nie rozumieją twojego świata. Więc cel nie polega na dawaniu im większej autonomii — tylko na maksymalizacji pracy, jaką mogą wykonać bezpiecznie w ramach twojego czasu na review.

W tym miejscu „vibe coding" dostaje złą opinię. Robione źle, vibe coding oznacza pozwalanie agentom na cokolwiek i modlenie się, że zadziała. Robione dobrze, oznacza używanie AI jako mnożnika twojego osądu, nie zastępnika.

Nieoczekiwany bonus

Kiedy zaakceptujesz relację kontraktową, dzieje się coś nieoczekiwanego: zaczynasz podejmować więcej ryzyka. Chętnie odpalasz ten eksperymentalny feature, bo ryzyko jest ograniczone. Agent nie może zepsuć produkcji. Może dostarczyć coś zaskakująco błędnego albo zaskakująco dobrego — ale w obu przypadkach łapiesz to, zanim ma to znaczenie.

Zaczynałem więcej side projectów w ostatnich sześciu miesiącach niż w poprzednich dwóch latach. Nie dlatego, że pracuję ciężej — bo deleguję agresywnie w bezpiecznych granicach.

Zbuduj to w swoim workflow

Jeśli używasz agentów AI do developmentu, zapytaj siebie:

1. Co mój agent może teraz ruszać? Jeśli odpowiedź brzmi „produkcja" — to problem.
2. Czy istnieje techniczne zabezpieczenie przed złymi akcjami, czy tylko polityka?
3. Kto merge'uje kod? Jeśli nie człowiek — to dlaczego?

Narzędzia są dostępne. Zakres tokenów, osobne staging repo, branch protection — to nie są egzotyczne workflow gitowe. To różnica między AI-assisted development a AI-accidental disasters.

U ciebie ocenianie wciąż pozostaje wąskim gardłem. To nie ograniczenie — to sedno sprawy. Agenty istnieją po to, by wzmacniać to, co możesz zrobić, nie żeby zastępować osąd, który sprawia, że software faktycznie działa dla prawdziwych użytkowników.

Buduj z tym założeniem.