Zespoły inżynierskie oceniające agentów programistycznych zazwyczaj zaczynają od niewłaściwego pytania. Chcą wiedzieć, jak dużą autonomię może uzyskać agent. Jak dużą część potoku (pipeline) może przejąć? Czy potrafi napisać specyfikację, edytować repozytorium i wdrożyć zmiany na produkcję, nie zawracając nikomu głowy? Demostracje ułatwiają uleganie tej obsesji. Widzisz płynny proces, w którym pojedynczy prompt wywołuje kaskadę edycji i wdrożeń, a instynkt podpowiada, by dążyć do tej samej możliwości wewnątrz własnej organizacji. Ale blask i efektowność to fatalne zasady projektowe. Lepsze pytania są znacznie mniej ekscytujące: kto nadał temu narzędziu uprawnienia, jakich systemów może ono faktycznie dotknąć i co się stanie, gdy nieuchronnie popełni błąd?

Pułapka autonomii

Ekscytująca autonomia to pułapka. Uczy nas ona świętowania botów, które generują specyfikacje, modyfikują repozytoria i wdrażają kod, spokojnie twierdząc, że zadanie zostało wykonane. To nie jest inżynieria. To „trust fall” z dostępem do powłoki (shell). Sama praca staje się niemal zbyt łatwa do wykonania. Każdy model może w kilka sekund wygenerować kod, dokumentację czy plany architektury. Jednak prawdziwym kosztem w wytwarzaniu oprogramowania nigdy nie była prędkość pisania. Zawsze była nim walidacja, przegląd i ostrożna decyzja o stwierdzeniu: tak, to jest poprawne i bezpieczne do wdrożenia. Wygenerowana praca jest tania. Zatwierdzenie jest drogie. Firmy, które dowiedzą się, jak zarządzać procesem zatwierdzania w sposób przejrzysty i spójny, będą tymi, które faktycznie dostarczają niezawodne systemy.

Dlaczego samokontrola zawodzi

Ryzyka objawiają się w przewidywalnych wzorcach. Model tworzy plan, a następnie ocenia, czy ten plan jest dobry. Agent edytuje kod źródłowy i wyjaśnia, dlaczego jego zmiany są bezpieczne. Narzędzie wykonuje polecenie i prosi o wybaczenie zamiast o pozwolenie. Każdy z tych przypadków reprezentuje tę samą fundamentalną wadę. Jeśli agent tworzy specyfikację, coś spoza tego agenta musi ją zatwierdzić, zanim zostanie uznana za wiążącą. Jeśli agent modyfikuje kod, oddzielny proces musi sprawdzić różnice (diff). Pozwalanie generatorowi na pełnienie roli własnego walidatora nie jest drogą na skróty. To błąd strukturalny przebrany za wygodę.

Prompty to nie systemy uprawnień

Nie zabezpieczysz agenta sprytnym sformułowaniem. Powiedzenie modelowi, aby był ostrożny lub aby pytał przed usunięciem czegoś, nie tworzy bariery. Prompty to nie systemy uprawnień. Zanim pozwolisz agentowi zbliżyć się do produkcji, potrzebujesz rzetelnego zestawienia jego możliwości. Czy potrafi przeczytać całe repozytorium? Czy potrafi wykonywać polecenia powłoki? Czy potrafi otworzyć przeglądarkę? Czy potrafi pobrać dane klientów do swojego okna kontekstowego? Większość zespołów nie zna pełnych odpowiedzi. Zakładają, że narzędzie jest ograniczone do piaskownicy (sandbox), podczas gdy w rzeczywistości posiada uprawnienia do zapisu w krytycznych ścieżkach. Najpierw zmapuj powierzchnię ataku. Potem zbuduj mury.

Zbuduj wielopoziomowy system kontroli

Gdy już zrozumiesz, co agent potrafi, zaprojektuj system kontroli, który dopasowuje ryzyko do poziomu oporu. Działania niskiego ryzyka, takie jak aktualizacja wewnętrznej dokumentacji czy formatowanie kodu, mogą odbywać się automatycznie. Działania średniego ryzyka, jak refaktoryzacja modułu czy dodanie nowej zależności, powinny trafiać do punktu kontrolnego, w którym człowiek lub zweryfikowany zestaw testów potwierdza zmianę. Działania wysokiego ryzyka – wdrażanie na produkcję, modyfikacja infrastruktury czy dostęp do wrażliwych danych – wymagają oddzielnego zatwierdzającego, który nie brał udziału w procesie generowania. Każda pojedyncza akcja musi pozostawiać ślad audytowy. Powinieneś mieć możliwość odtworzenia dokładnie tego, które pliki zostały odczytane, jakie narzędzia wywołano i jakie decyzje podjęto. Rozwój oparty na agentach nie jest licencją na pomijanie przeglądów. Nudne utrudnienia to funkcja. Odpowiednia brama zatwierdzająca działa jak bezpiecznik, gdy proces zaczyna zbaczać z kursu.

Dopasuj granice do ryzyka

Skalibruj swoje granice do rzeczywistego zagrożenia. Przekształcanie każdej drobnej zmiany formatowania Markdown w ceremonię zgodności (compliance) zatrzyma Twój zespół. Jednak traktowanie działań o wysokiej stawce jako nieszkodliwych tylko dlatego, że agent wydaje się pewny siebie, jest równie głupie. Celem jest proporcjonalna kontrola, a nie teatralne ograniczanie.

Dbaj o to, by artefakty były małe i obserwowalne

The most useful agent systems do not try to wow you with massive autonomous runs. They produce small, reviewable artifacts. A tight plan. A focused diff. A readable log. Giant autonomous executions are nightmares to debug. When something breaks after a fifty-file agent session, you have to untangle intent, execution, and side effects all at once. Keep the blast radius small. Insist on knowing which files the agent read and which tools it called. Observable systems are maintainable systems. Black-box autonomy is just technical debt with better marketing.

Six Questions Before You Grant Access

Before you hand an agent any real responsibility, pressure-test your setup with six hard questions.

  • What capabilities does the system actually have?
  • Which actions are denied by default, blocked at the infrastructure level rather than discouraged by a polite sentence in the system prompt?
  • Which actions require explicit approval?
  • Which artifacts get frozen before the agent consumes them, so it cannot silently manipulate its own inputs?
  • Which validator, entirely separate from the generator, judges the final output?
  • Which log proves, without ambiguity, what actually happened?

This is basic engineering hygiene. Separate the generator from the validator. Keep human authority at the boundary.

The Real Test

There