Czym jest prawdziwy harness: dlaczego agenci AI potrzebują twardego kodu, a nie plików Markdown

Współcześni agenci AI fundamentalnie przedefiniowują cykl wytwarzania oprogramowania (SDLC), jednak w branżowych dyskusjach narasta poważne nieporozumienie pojęciowe: mylenie instrukcji promptowych z technicznym harnessem wykonawczym. Wielu inżynierów i menedżerów uległo złudzeniu, że sformułowanie reguł w pliku Markdown czy zdefiniowanie zestawu umiejętności w repozytorium stanowi barierę zabezpieczającą projekt przed błędami generowanymi przez modele językowe. Tymczasem praktyka inżynierska brutalnie weryfikuje to podejście. Prawdziwy harness nie jest deklaratywnym życzeniem zapisanym w języku naturalnym, lecz deterministyczną infrastrukturą kodu i konfiguracji, której autonomiczny system nie jest w stanie ominąć w trakcie pracy.

Kwestię tę bezkompromisowo naświetlili Łukasz Kałużny i Szymon Warda w podcaście Patoarchitekci (odcinek „Kto się podpisze pod kodem od AI? - SDLC, koszty i harness”). Wskazują oni na powszechną w środowisku nadinterpretację: próby traktowania plików konfiguracyjnych dla edytorów jako twardych gwarantów jakości kodu.

Złudzenie kontroli w plikach Markdown: dlaczego prompt to nie harness

Popularność narzędzi wspomagających programowanie sprawiła, że repozytoria zapełniły się plikami typu .cursorrules, CLAUDE.md czy dokumentami ze wskazówkami architektonicznymi. Choć pełnią one rolę kontekstową, nadawanie im miana harnessu jest błędem technicznym. Jak dosadnie ujął to Łukasz Kałużny: „plik MD i skille to nie jest harness - harness to config, którego agent nie ominie, nawet gdyby bardzo chciał”.

Modele językowe działają probabilistycznie. Ich nadrzędnym dążeniem podczas rozwiązywania zadania jest minimalizacja straty i doprowadzenie polecenia do końca. W sytuacji, gdy ograniczenie zapisane jest wyłącznie jako tekst w Markdownie, model w obliczu trudności syntaktycznych lub logicznych potrafi je zignorować, uznając regułę za mniej istotną niż zrealizowanie celu. Zjawisko, w którym autonomiczny asystent po prostu „zignorował, żeby osiągnąć cel”, jest powszechnym problemem w nieskrępowanych pętlach Claude Code oraz innych agentach CLI. Dopóki ograniczenie istnieje jedynie na poziomie promptu, dopóty stanowi ono wyłącznie sugestię, a nie wiążącą regułę inżynierską.

Deterministyczny harness: techniczna anatomia ograniczeń

Pojęcie harnessu wywodzi się z klasycznej inżynierii oprogramowania oraz systemów testowych (test harness). W architekturze systemów agentowych harness oznacza zewnętrzne rusztowanie wykonawcze (scaffolding), które narzuca agentowi twarde reguły środowiskowe. Nie prosi ono modelu o przestrzeganie standardów, lecz uniemożliwia zatwierdzenie zmian niespełniających kryteriów.

Na rzeczywisty harness składają się konkretne elementy architektoniczne:

1. Hooki i blokady wykonawcze — skrypty pre-commit i pre-push uruchamiane w odizolowanym środowisku, które natychmiast przerywają pętlę wykonawczą agenta, jeśli dojdzie do naruszenia konwencji nazewniczych, typowania lub prób modyfikacji plików objętych ochroną.
2. Statyczna analiza kodu i quality gates — integracja z narzędziami takimi jak SonarQube, które wymuszają progi pokrycia testami, brak długu technologicznego oraz bezpieczeństwo typów. Kod odrzucany jest na poziomie bramki jakościowej, a nie subiektywnej oceny modelu.
3. Testy architektoniczne — deterministyczna weryfikacja zależności warstwowych (np. reguły uniemożliwiające importowanie logiki bazodanowej bezpośrednio do widoków UI), eliminująca samowolę agenta w strukturze projektu.
4. Środowiska efemeryczne i sandboxing uprawnień — uruchamianie agentów w kontenerach pozbawionych bezpośrednich uprawnień do niszczenia infrastruktury, z dostępem do zasobów ściśle kontrolowanym przez polityki IAM.

W tak zdefiniowanym reżimie specyfikacja wymagań również musi ulec uproszczeniu. Warda i Kałużny zwracają uwagę na wyższość lekkiego podejścia Spec-Driven Development, wspieranego diagramami architektury C4, nad przerośniętymi, nieutrzymywalnymi strukturami pokroju Spec Kita. Jasna, formalna architektura w połączeniu z twardą weryfikacją tworzy ramy, w których model może działać produktywnie.

Mit skrupulatnego review i bolesna prawda o SDLC

Wielu krytyków autonomicznego generowania kodu podnosi argument o degradacji jakości i braku odpowiedzialności za commity. Szymon Warda stawia jednak trafną diagnozę: agenci kodujący niczego nie zepsuli w procesie wytwórczym, a jedynie obnażyli wieloletnie zaniedbania zespołów deweloperskich. Odnosząc się do rzekomego upadku kultury inspekcji kodu, Warda pyta wprost: „Czy robiliśmy review lat temu trzy? Nie, nie robiliśmy, tylko wszyscy okłamywali się, że robią review porządnie i klikali: tak, tak, tak może iść.”

Przez lata zespoły polegały na iluzorycznym, powierzchownym review manualnym. Gdy agent generuje setki linii kodu w kilkanaście sekund, człowiek nie jest w stanie wychwycić subtelnych halucynacji bez zautomatyzowanych testów i rygorystycznego harnessu. Odpowiedzialność za kod ostatecznie spoczywa na inżynierze podpisującym pull request, lecz jedyną tarczą przed zalewem niskiej jakości kodu (tzw. AI slop) staje się automatyczny quality gate, a nie ludzka czujność zmęczonego programisty.

Ekonomia tokenów i techniczny mit self-hostingu

Wdrożenie agentów w proces SDLC wiąże się także z twardymi realiami budżetowymi. Miesiąc miodowy nieograniczonych subskrypcji dobiega końca, a firmy muszą liczyć koszty operacyjne. Z danych przytoczonych przez prowadzących podcast wynika, że realne koszty tokenów potrafią wynosić 200-300 dolarów miesięcznie na DevOpsa oraz 500-600 dolarów na developera pracującego przy wymagających zadaniach, takich jak migracja starego .NET-u. W przypadku czteroosobowego zespołu forecast sięga już 3000 euro, a w skrajnych, niekontrolowanych przypadkach odnotowano pojedyncze osoby z 13 tysiącami przepalonymi na kredyty Copilota.

Część organizacji próbuje uciekać przed tymi kosztami w stronę lokalnego uruchamiania modeli (self-hosting). Warda i Kałużny oceniają to jednoznacznie: „W tym momencie self-hosting to jest mit finansowy”. Nawet topowa stacja robocza M5 Max ze 128 GB pamięci zunifikowanej osiąga zaledwie 30-parę tokenów na sekundę przy modelach o parametrach zdolnych do złożonego wnioskowania architektonicznego. Taka przepustowość eliminuje opłacalność self-hostingu w zastosowaniach profesjonalnych zespołów, skazując inżynierów na korzystanie z komercyjnych API, których zużycie musi być precyzyjnie monitorowane przez harness.

Podsumowanie: Inżynieria zamiast życzeniowego promptowania

Plik Markdown zawierający zestaw pobożnych życzeń dotyczących formatowania kodu nie chroni projektu przed degradacją architektoniczną. Agent AI traktuje taki plik jako jeden z wielu probabilistycznych wektorów w oknie kontekstowym, który może pominąć, jeśli koliduje on z wygenerowaniem odpowiedzi. Prawdziwy harness to deterministyczny system kontroli: blokujące hooki, testy architektoniczne, narzędzia pokroju SonarQube i efemeryczne środowiska z twardymi uprawnieniami. Dopóki zespoły nie wdrożą nieomijalnych reguł inżynierskich w kodzie, dopóty integracja sztucznej inteligencji w SDLC pozostanie budowaniem na ruchomych piaskach.