Zasada ograniczeń

Parę tygodni temu patrzyłem, jak agent kodujący regeneruje plik, który już istniał trzy foldery dalej. Model się nie mylił. Output był czysty, dobrze ustrukturyzowany, wewnętrznie spójny. Nie miał tylko nic wspólnego z plikiem, który był faktycznie wdrożony.

Agent zoptymalizował generację. Nie zoptymalizował ciągłości. A w systemie jakiejkolwiek istotnej skali te dwie rzeczy to nie to samo — to przeciwieństwa.

Większość rozmów o orkiestracji AI skupia się na modelu. Który model. Jak duży. Jak szybki. Jak drogi. Model ma znaczenie, ale to nie tam systemy produkcyjne się sypią. Systemy produkcyjne sypią się w szwach między akcjami, w momentach, w których agent sięga po nowy output, zamiast sprawdzić, jak naprawdę wygląda świat.

To paradoks ograniczeń. Większość liderów inżynierii zakłada, że ograniczenia limitują to, co AI może dla nich zrobić. W skali jest dokładnie odwrotnie. Ograniczenia — schematy, bramki, hierarchie zaufania, sprawdzenia stanu — są tym, co czyni output AI na tyle niezawodnym, by wpuścić go w realny system. Bez nich nie dostajesz szybszego zespołu. Dostajesz zespół, który spędza popołudnia, godząc cztery lekko różne wersje tego samego komponentu, trzy z których model wymyślił w ostatnią godzinę.

Tryb awarii: równoległe rzeczywistości

Chcę nazwać ten tryb awarii wprost, bo branża nie była co do niego szczera. Generacja bez ograniczeń produkuje równoległe rzeczywistości. Agent nie odmawia działania. Agent działa pewnie, w kierunku, który nie ma nic wspólnego ze stanem prawdziwego systemu.

W produkcji przyjmuje to postaci nieefektowne i powtarzalne:

• →agent regeneruje plik, który już istnieje w innej wersji
• →agent pisze schemat konfiguracji, który zaprzecza temu już wdrożonemu
• →agent wymyśla nazwę funkcji, która prawie pasuje do realnej
• →agent odpowiada na pytanie, produkując nowy zestaw faktów, zamiast przeczytać istniejący

Nic z tego, w izolacji, nie jest błędne. Wszystko z tego jest niekompatybilne z otoczeniem. Artefakt jest dobrze sformułowany. Relacja artefaktu z projektem jest zepsuta. I nic w samym artefakcie ci tego nie powie.

Koszt tokenów to mały rachunek. Prawdziwy koszt jest poznawczy — godziny, które inżynierowie i operatorzy spędzają, krocząc przez alternatywne linie czasu, próbując ustalić, która wersja jest prawdziwa, którą agent wymyślił, a którą wymyślił na podstawie poprzedniej wersji, którą też wymyślił. Ta praca procentuje. To największy nieraportowany podatek w operacjach wspomaganych AI tu i teraz.

System optymalizował generację zamiast ciągłości. A w dużych systemach kreatywnych ciągłość jest wszystkim.

Dyscyplina korygująca jest starsza niż software. Ta sama, której używają dobrzy inżynierowie wchodzący w system, którego nie zbudowali. Najpierw sprawdzasz stan świata. Potem, i dopiero potem, go rozwijasz. Najpierw zweryfikuj, potem rozwijaj. Nigdy w drugą stronę.

Dyscyplina verify-then-extend

To zdanie jest właściwie całym esejem, ale to jego wdrożenie oddziela zespoły, które uzyskują wartość z orkiestracji AI, od tych, które po drugim incydencie po cichu z niej rezygnują. W produkcji ta dyscyplina pokazuje się jako cztery konkretne wzorce. Żaden z nich nie jest egzotyczny. Wszystkie rutynowo się pomija, bo wyglądają jak narzut wobec dopaminy z modelu produkującego świeżą, pewną odpowiedź.

1. Weryfikacja stanu

Przeczytaj filesystem, zanim do niego zapiszesz. Sprawdź schemat, zanim go zmienisz. Przeczytaj dokument statusu, zanim zaczniesz działać na założeniu. Weryfikacja stanu to najtańsza dyscyplina z tej listy i najkonsekwentniej pomijana, bo model czuje się pewny co do stanu, którego nie sprawdził.

Wzorzec w kodzie jest niemal trywialnie mały: stat() przed zapisem, SELECT przed UPDATE, listing katalogu przed utworzeniem pliku. W agent loopie pokazuje się jako wywołanie narzędzia, które harness wymusza przed każdą mutacją. Agent nie ma prawa zakładać świata; świat jest świeżo wczytywany do kontekstu pracy za każdym razem, gdy ma to znaczenie.

2. Hierarchie zaufania

Gdy źródła się nie zgadzają, agent musi wiedzieć, które źródło wygrywa. Bez hierarchii każdy konflikt staje się rzutem monetą — a modele językowe rzucają monetą bardzo pewnie. Reguła jest prosta: im bardziej konkretne źródło, tym wyższe zaufanie. Filesystem bije każdy dokument opisujący filesystem. Kanoniczny moduł statusu bije stronę dokumentacji o nim. Strona dokumentacji bije pamięć tego, że się ją czytało. Pamięć bije cokolwiek model powiedział w bieżącej rozmowie.

W naszym systemie pamięci stan filesystemu bije zbuforowane dokumenty statusu; nowsze źródło kanoniczne zawsze wygrywa. Ta reguła żyje w pliku pamięci najwyższego poziomu, który model ładuje na początku każdej sesji. To jedno zdanie. Zmienia wyniki bardziej niż jakikolwiek prompt tuning, jaki robiłem w ostatnim roku.

Kluczowy punkt: to przede wszystkim problem dokumentacji, nie problem modelu. Większość zespołów nigdy nie zapisała, które źródło wygrywa, gdy źródła się nie zgadzają, bo w przedAI-owych workflow pytanie rzadko się pojawiało — zwykle istniało tylko jedno źródło. Orkiestracja AI generuje nowe źródła nieustannie. Hierarchia musi istnieć, zanim pojawią się konflikty.

3. Bramki preflight

Każda akcja agenta zabezpieczona sprawdzeniem. Bramka może być tania — sprawdzenie istnienia pliku, klasyfikacja jednym tokenem — albo droga — pełna walidacja schematu, dry-run przeciw środowisku staging. Koszt bramki niemal zawsze jest mniejszy niż koszt akcji, której zapobiega.

Reguła operacyjna: jeśli nie potrafisz nazwać warunku wstępnego, nie możesz ufać akcji. Agent, który nie umie powiedzieć to musi być prawdą, żeby mój następny ruch był bezpieczny, to agent wykonujący ruch na wiarę. Wiara ma swoje miejsce. Nie jest strategią wdrożeniową.

4. Ograniczenia outputu

Schematy, typy, formaty, dopuszczalne wartości. Ustrukturyzowany output to nie funkcja UX — to mechanizm bezpieczeństwa. Generacja swobodna w kontekście orkiestracji to odpowiednik nietypowanej zmiennej w języku kompilowanym. Im mniej stopni swobody ma output, tym bardziej niezawodny jest następny krok.

To dyscyplina, którą dostawcy modeli najbardziej ułatwili do adopcji — structured outputs, schematy tool-callingowe, tryby JSON ze ścisłymi walidatorami — i nadal jest tą, którą widzę wdrażaną najmniej starannie. Zespoły włączają structured output, piszą schematy z ośmioma opcjonalnymi polami i polem free-textowym notes, a potem dziwią się, dlaczego następny agent w łańcuchu nadal halucynuje. Luźny schemat to to samo, co brak schematu. Ograniczenie musi gryźć.

Jak to wygląda w produkcji

Większość krajobrazu orkiestracji — LangChain, AutoGen, CrewAI, wewnętrzne odpowiedniki, które zbudowały duże organizacje — traktuje te cztery dyscypliny jako opcjonalne. Można je podpiąć. Zwykle trzeba. Domyślne ustawienia zakładają, że chcesz płynności, i to dostajesz.

Kształty awarii są przewidywalne w różnych domenach:

• ▸Multi-agentowe wsparcie klienta. Bez weryfikacji stanu drugi agent w wątku zaprzecza pierwszemu — inny zwrot zaoferowany, inna polityka cytowana, inne konto oflagowane. Klient nigdy nie widzi łańcucha, tylko sprzeczności.
• ▸Generacja kodu wspomagana AI. Bez hierarchii zaufania model przepisuje już wdrożone funkcje w lekko innych kształtach. Codebase rośnie o trzy implementacje tej samej narzędziówki, żadna nie jest miarodajna.
• ▸Agentowe workflow finansowe i operacyjne. Bez bramek preflight agent działa na nieaktualnych danych — księga, którą przeczytał na początku zadania, nie jest już tą, do której zapisuje na końcu.
• ▸Systemy designu sterowane AI. Bez ograniczeń outputu każdy wygenerowany komponent odjeżdża od specyfikacji marki w drobnych, broniących się drobiazgach. Po dwóch miesiącach system designu jest zestawem wariacji na temat, a nie systemem.

Typowy wzorzec, który widzę w pracy z klientami: przed, agentowy workflow działa z wysoką przepustowością i zespół świętuje wolumen; po pierwszym incydencie liderzy inżynierii po cichu dorzucają warstwę weryfikacji przed każdą mutacją, przepustowość spada o trzydzieści procent, a wskaźnik poprawek spada o rząd wielkości. Wynik netto to więcej dowiezionej pracy, mniej poprawek — ale dopiero po wbudowaniu dyscypliny. Świętowanie przepustowości było iluzją. Wolumen był prawdziwy; wartość nie.

Awaria nigdy nie tkwi w modelu. Awaria tkwi w brakującej dyscyplinie wokół modelu.

Lustro w systemach kreatywnych

Krótkie odbicie w bok, bo zasada nie dotyczy właściwie inżynierii — po prostu tam najlepiej widać.

W długiej formie fabularnej ciągłość jest elementem nośnym. Postaci, motywacje, geografia, zasady magii, kolor pokoju trzy rozdziały temu. Gdy ciągłość pęka, czytelnik traci zaufanie, zanim zdoła nazwać dlaczego. Nie mówi system magii zaprzeczył sobie w rozdziale dwunastym; mówi przestałem wierzyć tej książce. Zanim czytelnik nazwie awarię, awaria już zrobiła swoje.

Mechanizm jest ten sam co w orkiestracji. Generacja jest tania. Ciągłość trzeba zweryfikować wobec zewnętrznego rekordu. W fikcji rekord zewnętrzny to kanon — karty postaci, dokumenty lore, pliki linii czasu, już napisane rozdziały. W produkcyjnych systemach AI rekord zewnętrzny to filesystem, schemat, wdrożona konfiguracja, hierarchia zaufania kto co wie. Różne domeny, identyczny tryb awarii: gdy ciągłość pęka, zaczyna się fragmentacja.

Ci sami ludzie, którzy nigdy nie znieśliby błędów ciągłości w powieści, wdrażają systemy agentowe, które produkują wyłącznie błędy ciągłości. Dyscyplina jest ta sama. Po prostu jeszcze nie nazwaliśmy jej tak samo.

Ograniczenia jako dyscyplina inżynierska skali

Warto powtórzyć tę inwersję: ograniczenia nie są przeciwieństwem kreatywności. Są substratem niezawodnej kreatywności. Agent bez ograniczeń to sprinter na lodzie. Agent z ograniczeniami to sprinter na bieżni. Oba mogą biec szybko. Tylko jednego z nich można zmierzyć stoperem.

Następnej ery orkiestracji AI nie wygrają większe modele. Wygrają lepiej ograniczone. Sufit możliwości, który podniesie kolejne pokolenie frontier models, szybciej obnaży problemy z podłogą, a nie je rozwiąże. Bardziej zdolny model w systemie bez warstwy weryfikacji to bardziej zdolny system do produkowania równoległych rzeczywistości.

To jest praca, na której wciąż lądję z klientami. Pytają o pomoc w wyborze modelu, ocenie dostawcy, zaprojektowaniu topologii agentów. Prawdziwa praca niemal zawsze jest warstwę niżej: gdzie naprawdę żyje stan, które źródło wygrywa, gdy źródła się nie zgadzają, jaki warunek wstępny musi być spełniony, by ta akcja była bezpieczna, jakiego kształtu tego outputu wymaga następny krok. Model to łatwa część. Substrat to inżynieria.

Generacja jest tania. Ciągłość to aktywo.

Ograniczenia nie są wrogiem AI. To one czynią AI niezawodnym w skali. Zbuduj weryfikację, zanim zbudujesz generację — albo zbudujesz generację dwa razy i będziesz ją godzić w nieskończoność.