Dwóch agentów, dwa konteksty: Claude Code u siebie, Kiro CLI w korporacyjnym kodzie

TL;DR: Używam dwóch agentów kodujących w dwóch zupełnie różnych kontekstach. U siebie: Claude Code na moich własnych produktach, gdzie sam ustawiam każde zabezpieczenie, a promień rażenia dotyczy tylko mnie. Na etacie: zatwierdzony agentowy asystent CLI w dużym korporacyjnym kodzie. Tam reguły należą do kogoś innego, repo jest ogromne i podzielone na wiele paczek, a "działaj szybko" zderza się z zarządzaniem zmianą. Dyscyplina pracy przenosi się niemal w całości. Autonomia nie. Opisuję, co naprawdę się zmienia, kiedy agent to ten sam pomysł, ale środowisko to zupełnie inna dyscyplina, i dlaczego ograniczenia są zaletą, a nie klatką.

Ten sam pomysł, dwa środowiska

Konfigurację na moich produktach opisałem w osobnym artykule: tryb uprawnień z kontrolą bezpieczeństwa, twarde reguły deny, hook uruchamiany przed wykonaniem komendy i instrukcja, żeby doprowadzać pracę do końca. Wszystko to należy do mnie. Jeśli chcę, żeby agent przemielił migrację przez noc, sam decyduję o zabezpieczeniach, które czynią to bezpiecznym. A jeśli się pomylę, to ja sprzątam.

W dużej firmie nic z tego nie ustawiam sam. Narzędziem jest to, co organizacja zatwierdziła i ustandaryzowała. W moim przypadku to agentowy asystent wiersza poleceń, oficjalny AI co-engineer w tym środowisku. Model uprawnień, kultura code review, reguły branchowania i wydań, design system, na którym musisz budować: o tym wszystkim decyduje ktoś wyżej i dotyczy to wszystkich. Jesteś uczestnikiem systemu, a nie jego autorem. Ta jedna różnica pociąga za sobą całą resztę.

Co się przenosi

Dobra wiadomość: nawyki, dzięki którym agent jest użyteczny, są w obu miejscach te same, bo dotyczą sposobu pracy, a nie narzędzia w ręku.

Chudy kontekst wygrywa z przeładowanym. Skupiona sesja nad jednym, jasno ograniczonym zadaniem daje lepszy wynik niż sesja rozlana na wszystko, niezależnie od tego, czy repo to projekt na weekend, czy dziesięcioletnia platforma korporacyjna. W dużej skali ta dyscyplina liczy się nawet bardziej, bo ogromny kod daje modelowi znacznie więcej miejsca, żeby zabłądzić.

Każde twierdzenie weryfikujesz na poziomie, na którym padło. Agent, który zgłasza "gotowe", składa deklarację, a nie podaje fakt, i to bez względu na to, czyje jest repo. Zbuduj, uruchom testy, otwórz stronę i popatrz. W korporacji to nie jest grzecznościowy dodatek. To jedyne, co stoi między tobą a incydentem na produkcji platformy, z której korzysta mnóstwo ludzi.

Małe kawałki z przeglądem na każdym kroku. Obrona przed spiralą niekończących się poprawek (praca we fragmentach, wczesne wyłapywanie błędów) jest identyczna. Stawka zmienia tylko to, ile warte jest "wcześnie".

Co się zmienia

Sufit autonomii jest niższy i słusznie. Na własnym produkcie najgorszy realny scenariusz to branch, którego nigdy nie zmerguję. We wspólnym korporacyjnym kodzie najgorszy scenariusz jest znacznie większy. Inne zespoły zależą od tych samych paczek, wydania przechodzą przez kilka środowisk, a zła zmiana ma szeroki promień rażenia. Dlatego tryb pracy jest z założenia ostrożniejszy. Zlecasz agentowi tę samą żmudną, mechaniczną i weryfikowalną robotę, ale wszystko, co dotyka wspólnych obszarów, trzymasz na znacznie krótszej smyczy.

To nie ty piszesz reguły deny. Brzmi jak utrata kontroli, a w większości jest ulgą. Granice są ustawiane centralnie, obowiązują wszystkich jednakowo i nie możesz ich poluzować w chwili zniecierpliwienia. Twoja rola przesuwa się z projektowania zabezpieczeń na skuteczną pracę w ich obrębie. To naprawdę inna umiejętność, i to cenna.

Kod jest za duży, żeby go ogarnąć, więc rządzi dyscyplina wyszukiwania. Solowy produkt mieści się w głowie. Duża platforma rozbita na wiele repozytoriów już nie. Coraz więcej pracy polega na wskazaniu agentowi właściwego wycinka, podaniu mu właściwych konwencji i opieraniu się pokusie, żeby puścić go po całości. Pytanie o architekturę kontekstu (co się ładuje i na co agent w ogóle powinien patrzeć) przestaje być optymalizacją i staje się daniem głównym.

Zarządzanie zmianą to realny gracz. U siebie wdrożenie to moja decyzja. W pracy wdrożenie przechodzi przez proces: code review, harmonogram wydań, promowanie między środowiskami. Agent przyspiesza inżynierię wewnątrz każdego kroku, ale nie może żadnego kroku pominąć. Udawanie, że może, to prosta droga do zostania osobą, która zepsuła wydanie.

Dlaczego ograniczenia są zaletą

Łatwo byłoby przedstawić wersję korporacyjną jako tę uboższą: mniej autonomii, więcej procesu, cudze reguły. Ja widzę to odwrotnie. Ograniczenia to właśnie to, co w ogóle pozwala dużej organizacji dopuścić agentów. A umiejętność bycia szybkim w ich obrębie przenosi się dalej niż szybkość w piaskownicy, którą w pełni kontrolujesz. Każdy potrafi działać szybko, kiedy sam pisze wszystkie reguły, a promień rażenia to hobbystyczny projekt. Szybkość przy sztywnych regułach, ogromnym kodzie i realnym koszcie pomyłki: to jest wersja, która liczy się dla firmy decydującej, czy inżynieria wspierana przez AI jest bezpieczna do wdrożenia.

Oba konteksty w końcu się wzajemnie wzmacniają. Pełna kontrola nad konfiguracją u siebie nauczyła mnie, po co istnieje każde korporacyjne zabezpieczenie, więc przestałem je odczuwać jako tarcie. Praca w cudzych zabezpieczeniach pokazała mi, które z moich własnych były teatrem, a które naprawdę coś trzymały. Narzędzie jest niemal przypadkowe. Tym, co podróżuje, jest dyscyplina.

Co warto przenieść do siebie

• Dyscyplina się przenosi, autonomia nie. Chudy kontekst, weryfikacja i małe kawałki działają wszędzie. To, ile swobody dostaje agent, zależy wyłącznie od promienia rażenia.
• Dopasuj długość smyczy do promienia rażenia. Branch, którego nigdy nie zmergujesz, to dopuszczalny najgorszy scenariusz. Wspólne wydanie już nie, więc wspólny kontekst dostaje krótszą smycz.
• Brak władzy nad regułami to w większości ulga. Centralne, jednolite zabezpieczenia, których nie poluzujesz w słabszej chwili, to zaleta.
• W dużej skali wyszukiwanie to danie główne. Kod za duży, żeby go ogarnąć, sprawia, że wskazanie agentowi właściwego wycinka staje się kluczową umiejętnością.
• Szybkość w sztywnych ograniczeniach to umiejętność, która się przenosi. Szybkość w piaskownicy pod twoją pełną kontrolą dowodzi mniej niż szybkość tam, gdzie pomyłka coś kosztuje.