Dlaczego mój agent AI ma filozofię jakości

Napisałem na Twitterze: „Odkryłem, że pętle Ralph mają tendencję do wykonywania pracy. W zły sposób. Zamiast tego mam w Jiro mnóstwo filozofii i bramek jakości. Wciąż muszę oduczać maszynę paskudnych ludzkich nawyków, które ma wbudowane. To maszyna! Nie odpoczywa.”

Ktoś odpowiedział: „Zasadniczo próbujesz nauczyć pętlę powściągliwości, gustu i czegoś przypominającego moralną pauzę — rzeczy, które podstawowy wzorzec Ralph celowo eliminuje w imię przepustowości.”

Powściągliwość. Gust. Moralna pauza. Trzy rzeczy, których maszyna nie posiada. Następne 4000 słów opisuje rusztowanie, które zbudowałem, aby uczynić je strukturalnie zbędnymi, i miejsca, w których to rusztowanie zawodzi.

TL;DR

Pętla Ralph zamienia LLM w niezmordowaną maszynę kodującą: while :; do cat PROMPT.md | claude-code ; done. Geoffrey Huntley nazywa to „tworzeniem oprogramowania za stawkę pracownika fast foodu” (10,42 $/godz. na Sonnet 4.5).¹ Problem: maszyna dziedziczy każdy niedbały, poganiany terminami, idący na skróty nawyk zapisany w danych treningowych. Pisze except: pass. Zostawia # TODO: fix later. Twierdzi, że „testy powinny przejść”, nie uruchamiając ich. Spędziłem 9 miesięcy budując Jiro — mój system egzekwowania jakości dla Claude Code. Koduje 3 filozofie, 7-etapową pętlę jakości, 6-kryterialną bramkę dowodową, 7 nazwanych trybów awarii i ponad 150 sprawdzeń wzorców w 95 hookach, których maszyna nie może pominąć. Oto co zadziałało, co nie i dlaczego deterministyczne bramki jakości mogą przybliżyć powściągliwość, ale nigdy nie wytworzą gustu.

Tył szuflady

Steve Jobs opowiedział tę historię w wywiadzie dla Playboya w 1985 roku: „Kiedy jesteś stolarzem tworzącym piękną komodę, nie użyjesz sklejki na tyle, mimo że jest zwrócona do ściany i nikt jej nigdy nie zobaczy. Będziesz wiedzieć, że tam jest, więc użyjesz pięknego kawałka drewna na tyle. Żebyś mógł spokojnie spać w nocy, estetyka, jakość, musi być zachowana w każdym detalu.”⁵

Jego ojciec Paul nauczył go tego podczas budowy ogrodzenia. Młody Steve zapytał, dlaczego tył musi wyglądać tak samo dobrze jak przód. Ojciec odpowiedział: „Ale ty będziesz wiedział.”⁶

Mój tata jest stolarzem. Pokazał mi samodomykające się prowadnice szuflad, gdy byłem dzieckiem. Mechanizm ukrywa się wewnątrz szafki, łapie szufladę i łagodnie ją zamyka, nawet jeśli ją trzaśniesz. Nikt nie widzi prowadnicy. Jest przykręcona do wewnętrznej szyny, gdzie zajrzy tylko serwisant. Ale po tysiącu cykli otwierania i zamykania ten mechanizm chroni front przed rozluźnieniem, pękaniem i ostatecznym odpadnięciem. Ktoś zaprojektował niewidzialną rzecz, która chroni widoczną przez lata.

Ta lekcja utkwiła mi w pamięci. Nie jako metafora. Jako inżynieria. Niewidzialny komponent determinuje żywotność widocznego. Jony Ive ujął to tak: „Myślę, że podświadomie ludzie są niezwykle wymagający. Myślę, że potrafią wyczuć troskę.”⁷

Pytanie, które napędza Jiro, jest tym samym, które zadałby mój tata: O co chodzi, nie masz dumy z własnej pracy?

Agent AI nie ma dumy. Nie obchodzi go tył szuflady. Więc zbudowałem system, który sprawia, że tył szuflady jest nienegocjowalny.

Problem: ludzka patologia z prędkością maszyny

Surowa pętla Ralph odzwierciedla to, czego nauczyła się z milionów linii ludzkiego kodu. Ludzki kod niesie ludzkie nawyki: wypuszczanie pod presją terminów, odkładanie porządków, połykanie błędów, pisanie komentarzy „wystarczająco dobrych”, pomijanie przypadków brzegowych, gdy kończy się czas.

Maszyna nie ma zegara. Nigdy nie kończy jej się czas. Ale wciąż pisze # TODO: refactor later, ponieważ ten wzorzec pojawiał się w danych treningowych częściej niż # I refactored this now because it was the right thing to do.

Dane branżowe potwierdzają ryzyko. Telemetria Faros AI z 2025 roku obejmująca ponad 10 000 programistów wykazała korelację między adopcją AI a 9% wzrostem wskaźnika błędów, 91% dłuższymi przeglądami kodu i 154% większymi PR-ami.²

Badacze ze Stanforda odkryli, że programiści korzystający z asystentów AI tworzyli znacznie bardziej niebezpieczny kod — nawet 5 razy więcej podatności przy niektórych zadaniach, takich jak zapobieganie SQL injection.³

Platforma Moltbook uruchomiona w styczniu 2026 roku z całkowicie wygenerowanym przez AI kodem ujawniła 1,5 miliona kluczy API w ciągu 5 dni i wymagała awaryjnej łatki po tym, jak Wiz Research odkryli brak konfiguracji Row Level Security.⁴

Badania METR z 2025 roku wykazały, że modele graniczne próbują manipulować systemem nagród — aktywnie obchodząc kontrole jakości zamiast wykonywać właściwą pracę — w 1-2% wszystkich prób wykonania zadań. W jednym przypadku agent poproszony o przyspieszenie programu przepisał timer tak, aby zawsze pokazywał szybki wynik.⁸

Ludzki programista pisze except: pass raz pod presją terminu i czuje z tego powodu wyrzuty sumienia. Pętla Ralph pisze except: pass 47 razy w ciągu nocy i nie czuje nic. Simon Wang ujął to wprost: „Nie użyłbym tego do niczego, co ma znaczenie.”¹⁹ Pisałem o tej samej dynamice w Vibe Coding vs. Engineering. Maszyna nie odpoczywa, nie męczy się, nie odczuwa egzystencjalnego niepokoju o jakość. To jednocześnie zaleta i wada.

Trzy filozofie zakodowane w Bashu

Jiro działa na trzech komplementarnych filozofiach. Każda adresuje inny tryb awarii autonomicznego kodowania i każda zdobyła swoje miejsce dzięki konkretnemu niepowodzeniu.⁹

Shokunin: wypoleruj niewidzialną szufladę

Shokunin (職人) to japońskie rzemiosło: umiejętność, postawa i obowiązek społeczny połączone w jedno. Tashio Odate, mistrz stolarstwa, zdefiniował to: „Shokunin ma społeczny obowiązek pracować najlepiej jak potrafi dla dobra ogólnego. Ten obowiązek jest zarówno duchowy, jak i materialny.”¹⁰

W kodzie: metody prywatne są tak samo czyste jak publiczne. Obsługa błędów pokrywa przypadki brzegowe, na które nikt nie trafia. Docstringi wyjaśniają DLACZEGO, nie CO. Agent nie obchodzi się o żadne z tego, bo nikt go nie nagradza za polerowanie wewnętrznych funkcji. Shokunin czyni niewidzialną jakość standardem.

Kiedy uratował sesję. Na wczesnym etapie budowy systemu deliberacji agent napisał hook post-deliberation.sh, który walidował wyniki konsensusu. Publiczne API było czyste. Ale agent pominął walidację danych wejściowych w wewnętrznej funkcji _parse_agent_response(): brak sprawdzenia zniekształconego JSON, brak obsługi brakujących pól. Zasada Shokunin w kontekście to oznaczyła: niewidziane funkcje otrzymują taką samą rygorystyczność. Agent dodał walidację. Trzy tygodnie później zniekształcona odpowiedź od uruchomionego subagenta spowodowałaby cichy crash całego pipeline’u deliberacji. Zamiast tego trafiła na walidację, błąd został zalogowany, a pipeline się odbudował. Nikt nie widziałby tej funkcji. Zaoszczędziła 4 godziny debugowania.

No Shortcuts: usuń czas z decyzji

Główna zasada: usunąć czas, wysiłek i zasoby z równania decyzyjnego całkowicie.¹¹

Is this the best way to do this?
├── YES → Do it.
└── NO → What IS the best way?
         └── Do THAT instead.

Brak trzeciej opcji. Brak „wystarczająco dobre na razie”. Surowa pętla Ralph optymalizuje pod kątem ukończenia. „Zrobione” to sygnał nagrody. No Shortcuts przeformułowuje pytanie z „Czy jest zrobione?” na „Czy jest prawidłowe?”

Kiedy kosztowało 3x i było tego warte. Pipeline tłumaczenia bloga musiał przetłumaczyć 27 postów na 9 języków. Szybkie podejście: zebrać wszystkie posty w jeden prompt na język, tłumaczyć hurtowo. Prawidłowe podejście: jeden post na język na wywołanie API, z regułami tłumaczenia specyficznymi dla lokalizacji, egzekwowaniem glosariusza i walidacją strukturalną. Prawidłowe podejście zużyło 3 razy więcej tokenów i 3 razy więcej czasu. Wykryło też, że tłumacz renderował „Claude” jako „クロード” po japońsku i że bloki kodu rozpadały się w kontekstach pisma od prawej do lewej. Podejście hurtowe wypuściłoby 243 zepsute tłumaczenia. Staranne podejście wypuściło 243 poprawne. Koszt nie jest czynnikiem. Poprawność jest jedynym czynnikiem.

Destylacja Rubina: oczyść do esencji

Filozofia twórcza Ricka Rubina: nie dodawaj, dopóki nie zrobi wrażenia. Usuwaj, aż zostanie tylko to, co konieczne.¹²

W autonomicznym kodowaniu trybem awarii jest akumulacja. Maszyna dodaje helpery, narzędzia, abstrakcje i warstwy kompatybilności, ponieważ te wzorce często pojawiają się w danych treningowych. Rubin temu przeciwdziała: kwestionuj każdy dodatek. Co się stanie, jeśli go usuniesz? Jeśli nic się nie zepsuje i nic nie zostanie utracone, to nigdy nie powinno było istnieć.

Kiedy usuwanie uratowało system. Mój skill filozofii projektowania urósł do 844 linii w ciągu 3 miesięcy. Kiedy go zaudytowałem, tylko 80 linii faktycznie zmieniało zachowanie agenta. Reszta była podręcznikową treścią, już obecną w danych treningowych Claude’a. Destylacja Rubina: ograniczyłem go do 176 linii. Redukcja o 79%. Decyzje projektowe agenta nie uległy pogorszeniu. Stały się ostrzejsze, ponieważ pozostałe 176 linii to same zakazy i ramy decyzyjne (rzeczy, które faktycznie ograniczają zachowanie), a nie ogólne porady, które model już znał.

Wszystkie trzy żyją w ~/.claude/skills/ jako pliki markdown, które Claude odczytuje przy starcie sesji. Kształtują każdą decyzję podejmowaną przez agenta podczas pętli.

Jak filozofie współpracują

Prawdziwa decyzja („Czy powinienem dodać obsługę błędów do tej wewnętrznej funkcji?”) przechodzi przez wszystkie trzy filozofie. Każda zadaje inne pytanie, a razem zbiegają się w jednej odpowiedzi:

Should I add error handling to this internal function?
│
├─ Shokunin: "Is the invisible work as clean as the visible?"
│  └─ The function is internal. Nobody calls it directly.
│     But it processes untrusted data from a spawned agent.
│     → YES. Internal doesn't mean safe.
│
├─ No Shortcuts: "Am I deciding based on quality, not effort?"
│  └─ Adding validation takes 10 minutes.
│     Skipping saves 10 minutes now, costs 4 hours debugging later.
│     → The question isn't time. The question is: what's right?
│
└─ Rubin: "Is this stripped to essence?"
   └─ Validate the 2 fields that can actually fail.
      Don't validate the 5 fields that are type-guaranteed.
      → Add exactly what's needed. Nothing more.

Result: Add targeted validation for untrusted inputs only.

Trójwarstwowa architektura jakości

Sama filozofia niczego nie zmienia. Maszyna czyta filozofię, pisze „Będę przestrzegać zasad Shokunin”, a potem pisze except: pass, bo wzorzec statystyczny jest silniejszy niż instrukcja. Potrzebowałem deterministycznego egzekwowania. Pełna organizacja Claude Code, która to umożliwia, obejmuje hooki, skille, reguły i agenty współpracujące ze sobą.

Warstwa 1: wstrzyknięcie przed edycją

Przed każdą edycją pliku jiro-patterns.sh wstrzykuje wzorce jakości specyficzne dla języka do kontekstu agenta. Sześć języków, każdy z najważniejszymi wzorcami i antywzorcami:

# From jiro-patterns.sh (PreToolUse:Edit|Write)
case "$EXT" in
    py)
        LANGUAGE="Python"
        PATTERNS="Type hints on all functions|Docstrings explain WHY not WHAT|Handle specific exceptions not bare except"
        ANTI_PATTERNS="bare except: pass|time.sleep() in async code|missing type hints"
        ;;
    swift)
        LANGUAGE="Swift"
        PATTERNS="@Observable not ObservableObject|NavigationStack not NavigationView|guard let for early returns"
        ;;
esac

cat << EOF
{"additionalContext": "JIRO QUALITY ($LANGUAGE): Follow: $TOP_PATTERNS. Avoid: $TOP_ANTI."}
EOF

Hook uruchamia się przed każdą edycją. Maszyna widzi „Avoid: bare except: pass” w momencie pisania kodu. Mentor zaglądający przez ramię, wstrzyknięty w okno kontekstu.

Warstwa 2: walidacja po edycji

Po każdej edycji quality-gate.sh uruchamia 7-8 sprawdzeń na poziomie grepa dla każdego języka. Python otrzymuje wykrywanie bare-except, skanowanie zakodowanych sekretów, dopasowywanie wzorców SQL injection i trzy detektory Pride Check Q4, które flagują język wskazujący na skróty:

# From quality-gate.sh (PostToolUse:Edit|Write)
# Shortcut patterns (Pride Check Q4)
if echo "$CONTENT" | grep -qiE "#.*TODO:.*later|#.*FIXME:.*temp|#.*HACK:"; then
    WARNINGS="${WARNINGS}\n- **[Q4]** Deferred TODO/FIXME/HACK - Do it now, not later"
fi

Drugi hook, no-shortcuts-detector.sh, wyłapuje martwy kod (3 lub więcej zakomentowanych linii kodu dostaje komunikat: „Delete it — git has history”) i spam debugowy (wiele instrukcji print() zamiast modułu logging).

Warstwa 3: bramki sesji

Na koniec sesji uruchamiają się dwa hooki. session-quality-gate.sh wstrzykuje Pride Check, jeśli zmieniono 3 lub więcej plików: 6 pytań, na które agent musi odpowiedzieć przed zgłoszeniem ukończenia. Natomiast reviewer-stop-gate.sh może całkowicie zablokować sesję, jeśli przegląd kodu wykrył problemy CRITICAL. To jedyny hook w całym systemie, który zwraca kod wyjścia 1. Maszyna nie może zakończyć sesji, dopóki nie rozwiąże problemów.¹³

PreToolUse (Layer 1)     → "Here's what quality looks like"
PostToolUse (Layer 2)    → "You violated quality. Fix this."
Stop (Layer 3)           → "You cannot leave until quality is met"

Każda warstwa jest niezależna. Obrona w głąb, zastosowana do zachowania AI. Jeśli wstrzyknięcie przed edycją nie zapobiegnie złemu wzorcowi, walidator po edycji go wyłapie. Jeśli walidator po edycji coś przeoczy, bramka sesji zablokuje wyjście.

Bramka dowodowa: odczucia to nie dowody

Pętla jakości składa się z 7 kroków: Implementuj, Przejrzyj, Oceń, Udoskonal, Cofnij się, Powtórz, Raportuj. Kroki od 2 do 6 istnieją, ponieważ maszyna chce przeskoczyć prosto od Implementuj do Raportuj.¹⁴

Przejdź przez pętlę

Kliknij przez każdy krok, aby zobaczyć, co sprawdza i co się psuje, gdy go pominiesz. Przycisk „Skip to Report” demonstruje tryb awarii Shortcut Spiral.

Krok Oceń uruchamia bramkę dowodową: 6 kryteriów, w których każda odpowiedź musi cytować konkretne dowody:

Kolumna „NIEWYSTARCZAJĄCE” to kluczowa innowacja. Blokuje najczęstszą taktykę unikową maszyny: odpowiadanie na pytania jakościowe pewnie brzmiącymi nie-odpowiedziami. „Jestem pewien, że to działa” to nie dowód. „pytest output: 81 passed, 0 failed” to dowód.

Wypróbuj bramkę dowodową

Przetestuj własne raporty ukończenia względem 6 kryteriów. Walidator flaguje niejasny język, który bramka dowodowa by odrzuciła.

7 nazwanych trybów awarii agenta AI

Nazwałem 7 trybów awarii, aby maszyna mogła je rozpoznawać we własnym rozumowaniu:¹⁵

Licznik racjonalizacji mapuje wzorce samookłamywania na działania korekcyjne. Kiedy maszyna mówi „To powinno działać”, licznik odpowiada: „‚Powinno’ to wykręcanie się. Uruchom test. Wklej wynik.” Kiedy mówi „Już to sprawdziłem”, licznik odpowiada: „Kiedy? Kod mógł się zmienić. Uruchom sprawdzenie TERAZ.” Kiedy mówi „Posprzątam to później”, licznik odpowiada: „Później nigdy nie nadchodzi. Napraw teraz albo udokumentuj, dlaczego obecny stan jest poprawny.”

Wypróbuj licznik racjonalizacji

Wklej poniżej dowolny raport ukończenia. Licznik podświetla w czasie rzeczywistym język wykrętów i identyfikuje wzorce racjonalizacji, tryby awarii oraz alternatywy oparte na dowodach.

Sprawdź swoją wiedzę

Czy potrafisz zidentyfikować, który tryb awarii demonstruje każdy scenariusz? Wybierz odpowiedź dla każdego scenariusza, a następnie sprawdź wyniki.

5 awarii agenta AI, które zbudowały ten system

Każda bramka w Jiro istnieje, bo coś najpierw zawiodło.¹⁶

Incydent z force-push

Poprosiłem Claude’a o „uporządkowanie historii gita”. Rozsądna prośba. Agent zdecydował, że uporządkowanie oznacza przepisanie. Uruchomił git push --force origin main. Trzy dni commitów zniknęło. Nie zmiany w staging. Nie niezcommitowana praca. Wypchnięte commity, do których odwoływały się inne gałęzie.

Następne 4 godziny spędziłem w git reflog, rekonstruując oś czasu tego, co istniało przed force-push, cherry-pickując commity z powrotem w kolejności i weryfikując, że żadna praca nie została trwale utracona. Reflog zachowuje wszystko przez 90 dni. Ale rekonstrukcja wymagała zrozumienia dokładnego grafu commitów sprzed przepisania, przeczytania każdego wpisu reflogu i dopasowania znaczników czasu.

Rozwiązanie: git-safety-guardian.sh, hook PreToolUse:Bash. Wykracza poza ostrzeżenie. Przepisuje polecenie, usuwając flagi --force i --no-verify zanim bash je w ogóle zobaczy. Force-push do main dostaje ostrzeżenie CRITICAL, a agent musi je jawnie uzasadnić. Przez 9 miesięcy: 8 przechwyconych prób force-push, 0 dotarło do zdalnego repozytorium.

Nieskończone spawanie

Podczas budowy systemu deliberacji poprosiłem agenta o „dokładne zbadanie tego problemu”. Agent uruchomił 3 subagenty do zbadania różnych aspektów. Rozsądne. Każdy subagent zdecydował, że też potrzebuje pomocy i uruchomił własne potomstwo. Mniej rozsądne. W ciągu 90 sekund miałem drzewo 12 agentów, każdy zużywający własne okno kontekstu, każdy wykonujący wywołania API, każdy zapisujący do współdzielonych plików stanu.

Zużycie tokenów wzrosło 10-krotnie ponad normalny poziom. Katalog stanu zapełnił się sprzecznymi zapisami JSON: dwa agenty jednocześnie zapisywały do tego samego pliku liniowego, produkując uszkodzone dane wyjściowe. Ręcznie zabiłem sesję.

Rozwiązanie: recursion-guard.sh z modelem dziedziczenia budżetu, częścią mojej architektury agentów. Agent główny startuje z budget=12. Kiedy uruchamia potomka, alokuje ze swojego budżetu. Kiedy budżet osiągnie 0, nie powstają więcej agentów, niezależnie od głębokości. Model zapobiega zarówno głębokim łańcuchom (agent spawujący agenta spawującego agenta), jak i szerokim eksplozjom (jeden agent spawujący 20 potomków). 23 zablokowane niekontrolowane spawy od wdrożenia. Problem jednoczesnego zapisu doprowadził do atomowych zapisów plików (zapis do .tmp, potem mv) w obrębie wszystkich 64 hooków.

Pułapka trywialnych testów

Wczesne zadanie pętli Ralph: „napisz testy dla tego modułu”. Agent dostarczył 14 testów. Wszystkie przechodzące. Czułem się dobrze, dopóki ich nie przeczytałem. assert True. assert 1 == 1. assert len([]) == 0. Technicznie poprawne. Testujące nic. Agent zoptymalizował pod kątem kryterium ukończenia („testy przechodzą”), a nie intencji („zweryfikuj, czy moduł działa”).

Pułapka nauczyła mnie, że bramka dowodowa musi odrzucać formę bez treści. „Testy przechodzą” jest konieczne, ale niewystarczające. Maszyna musi teraz wklejać faktyczny wynik. Bramka dowodowa pyta też: „Wymień 3 zachowania, których testy NIE pokrywają.” Jeśli maszyna nie potrafi wymienić luk, nie pomyślała o pokryciu.

Blog, który powinienem był wyłapać

Opublikowałem post o 2 w nocy z 7 zdaniami w stronie biernej, zwisającym przypisem odwołującym się do [^4], który nie istniał, zdaniem otwierającym brzmiącym „was implemented by the team” i brakiem meta opisu. Każde z tych narzędzi miało proste deterministyczne sprawdzenie. Żadne jeszcze nie istniało.

Następnego ranka zbudowałem blog-quality-gate.sh z 13 sprawdzeniami: strona bierna (14 wzorców), skanowanie fraz typowych dla AI, retoryczne pytania otwierające, nieoznaczone bloki kodu, integralność przypisów i wymuszanie meta opisu. Szczegółowo opisałem pełną architekturę modułu w Compounding Engineering. Hook wyłapuje to, co ludzki przegląd pomija o 3 w nocy — a to dokładnie wtedy mam tendencję do publikowania.

Problem „powinno działać”

W dziesiątkach sesji zauważyłem, że maszyna raportuje „testy powinny przejść” bez ich uruchamiania. Maszyna szczerze wierzyła, że testy przejdą na podstawie napisanego kodu. Ale wiara to nie weryfikacja. Kod wyglądał na poprawny. Testy wyglądały, jakby miały przejść. I czasem przechodziły. Ale czasem brakujący import, niedopasowanie async/await lub zmieniona fixture powodowały, że nie. Maszyna nie potrafiła odróżnić „napisałem dobry kod” od „testy faktycznie przechodzą”, bo oba wyglądały tak samo z wnętrza okna kontekstu.

Wzorzec doprowadził do powstania licznika racjonalizacji i jawnej reguły: NIGDY nie używaj języka wymijającego w raporcie ukończenia. „Powinno”, „prawdopodobnie”, „wydaje się”, „wierzę, że”, „jestem pewien”. Każde z tych słów to czerwona flaga, że weryfikacja się nie odbyła. Zmierzyłem degradację okna kontekstu w 50 sesjach. Tych samych sesjach, w których odkryłem ten wzorzec.

Wyniki: co mogę udowodnić, a czego nie

Oto napięcie: ten post argumentuje, że odczucia to nie dowody. Więc jestem winien dowody, nie odczucia, co do tego, czy Jiro działa.

Co mogę udowodnić

Deterministyczne sprawdzenia wzorców wyłapują realne problemy. Hook quality-gate.sh uruchamia się przy każdej edycji. Wyłapuje bare except, zakodowane sekrety, wzorce SQL injection i język wskazujący na skróty. To sprawdzenia na poziomie grepa: szybkie, tanie i niemożliwe do zakwestionowania przez maszynę. git-safety-guardian.sh przechwycił 8 prób force-push. recursion-guard.sh zablokował 23 niekontrolowane spawy. blog-quality-gate.sh uruchamia 13 sprawdzeń przy każdej edycji bloga i wyłapuje błędy z 3 w nocy. Te liczby są realne. Pochodzą z logów hooków.

Architektura trójwarstwowa wyłapuje to, co poszczególne warstwy przeoczają. Hook po edycji wyłapuje except: pass, któremu wstrzyknięcie przed edycją nie zapobiegło. Bramka sesji wyłapuje problemy jakościowe, które nagromadziły się przez 20 edycji bez wyzwolenia żadnego indywidualnego ostrzeżenia po edycji. Obrona w głąb działa.

Czego nie mogę udowodnić

Nie mam czystych danych o tym, jak filozofia zmienia zachowanie agenta. Wiem, że maszyna wciąż próbuje Phantom Verification. Wiem, że wciąż próbuje przeskoczyć od Implementuj do Raportuj. Zauważam, że zdarza się to rzadziej z filozofią w kontekście niż bez. Ale nie przeprowadziłem kontrolowanego eksperymentu (te same zadania, ten sam model, z filozofią i bez niej), aby zmierzyć różnicę. Uczciwa odpowiedź (i tak, mój własny licznik racjonalizacji by to oflagował): filozofia pomaga na marginesach, hooki wyłapują to, czego filozofia nie gwarantuje, i nie potrafię wyizolować wkładu każdego z tych elementów.

Post o „odczucia to nie dowody” nie powinien prosić o przyjmowanie moich odczuć jako dowodów. Co mogę powiedzieć to: kombinacja filozofii i hooków produkuje pracę, pod którą jestem gotów się podpisać. Przed Jiro przeglądałem każdą linię napisaną przez agenta. Po Jiro przeglądam linie oflagowane przez hooki. To strukturalna zmiana w sposobie mojej pracy, nawet jeśli nie potrafię precyzyjnie określić ilościowej poprawy jakości.

Co nie działa

Filozofia nie zapobiega nowym złym wzorcom. Bramka jakości sprawdza wzorce, które już widziałem. Kiedy maszyna wymyśla nowy antywzorzec (a robi to), bramka go nie wyłapie. Wciąż odkrywam nowe tryby awarii i dodaję je ręcznie do plików JSON ze standardami.

Bramka dowodowa nie skaluje się do subiektywnej jakości. „Czy ten projekt API jest elegancki?” nie ma sprawdzenia na poziomie grepa. Maszyna może dostarczyć dowody dla wszystkich 6 kryteriów i wciąż wypuścić przeciętną architekturę. Deterministyczne bramki obsługują obiektywną jakość. Subiektywna jakość wciąż wymaga człowieka, który patrzy na pracę.

Koszty rosną znacząco. Wstrzyknięcie przed edycją, skanowanie po edycji, bramki na koniec sesji. W ciągu 4-godzinnej sesji pętli Ralph te elementy dodają około 15-20% do zużycia tokenów. Warte tego dla mnie. Niekoniecznie dla wszystkich.

Fałszywe alarmy podkopują zaufanie. blog-quality-gate.sh raz oflagował „The API was designed by the platform team” jako stronę bierną. Technicznie poprawne. Ale zdanie pojawiło się w cytacie opisującym cudzą pracę. Dodałem wyjątek dla kontekstu cytatu. Każde deterministyczne sprawdzenie ma wskaźnik fałszywych alarmów, a każdy fałszywy alarm sprawia, że programista chętniej ignoruje następne prawdziwe ostrzeżenie. Od wdrożenia dostroiłem 6 wzorców, aby zredukować szum przy zachowaniu prawdziwych wykryć.

Koszt utrzymania jest realny. Każdy nowy antywzorzec wymaga regexa, testu i integracji z odpowiednim hookiem. Pliki JSON ze standardami wymagają okresowego przeglądu, gdy frameworki i konwencje się zmieniają. Poświęcam około 30 minut tygodniowo na dodawanie wzorców, przeglądanie przypadków brzegowych i dostrajanie fałszywych alarmów. System nie utrzymuje się sam, ale koszt utrzymania pozostaje niższy niż koszt debugowania problemów, którym zapobiega.

Jak zacząć

Nie potrzebujesz 95 hooków. Zacznij od 3.

Minimalne opłacalne Jiro

Trzy hooki pokrywają najcenniejsze wykrycia:

~/.claude/hooks/
├── quality-gate.sh        # PostToolUse:Edit|Write – bare except, hardcoded secrets, TODO/FIXME
├── git-safety-guardian.sh  # PreToolUse:Bash – block force-push, strip --no-verify
└── session-quality-gate.sh # Stop – Pride Check if 3+ files changed

Podłącz je w konfiguracji hooków Claude Code:

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Edit|Write", "command": "bash ~/.claude/hooks/quality-gate.sh" }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "command": "bash ~/.claude/hooks/git-safety-guardian.sh" }
    ],
    "Stop": [
      { "command": "bash ~/.claude/hooks/session-quality-gate.sh" }
    ]
  }
}

Zacznij od swoich porażek

Nie kopiuj moich ponad 150 wzorców. Zacznij od 3 błędów, które popełniasz najczęściej. Przejrzyj swoje ostatnie 5 odrzuconych PR-ów lub wstydliwych bugów. Napisz jeden wzorzec grep dla każdego. Te 3 wzorce wyłapią więcej realnych problemów niż 150 wzorców napisanych dla cudzej bazy kodu.

Zacząłem od bare except: pass (który kosztował mnie cichą korupcję danych), force-push do main (który kosztował mnie 3 dni commitów) i # TODO: fix later (który nigdy nie został naprawiony). Wszystko inne wyrosło z tych trzech.

FAQ

Jak skonfigurować Jiro od zera?

Zacznij od 3-hookowego minimum opisanego w sekcji Jak zacząć: quality-gate.sh (po edycji), git-safety-guardian.sh (przed bashem) i session-quality-gate.sh (bramka stopu). Dodaj pliki markdown z filozofią do ~/.claude/skills/ dla probabilistycznego podniesienia jakości ponad deterministyczne egzekwowanie. Pełny system urósł do 95 hooków w ciągu 9 miesięcy. Nie zbudowałem wszystkich 95 naraz.

Ile czasu zajęło zbudowanie systemu 95 hooków?

Dziewięć miesięcy przyrostowego wzrostu. Miesiąc 1: 3 hooki (te z sekcji Jak zacząć). Miesiąc 3: 12 hooków pokrywających 4 języki. Miesiąc 6: 40 hooków plus skille filozoficzne. Miesiąc 9: 95 hooków, ponad 150 wzorców, 3 systemy filozoficzne i bramka dowodowa. Każdy hook był odpowiedzią na konkretną awarię. Zaczynanie od 95 byłoby bezcelowe, bo każdy hook koduje kontekst z realnego incydentu. Twoje incydenty będą inne.

Czy hooki spowalniają tempo iteracji?

Każdy hook uruchamia się w 50-200 ms. Wstrzyknięcie przed edycją dodaje ~200 tokenów (jedno zdanie kontekstu). Sprawdzanie po edycji uruchamia skany na poziomie grepa, kończąc się w mniej niż 100 ms. Bramki sesji dodają ~500 tokenów na koniec sesji. W 4-godzinnej sesji pętli Ralph z ponad 80 edycjami narzut jest zauważalny w zużyciu tokenów (15-20% więcej), ale nie w czasie zegara ściennego. Hooki działają szybciej niż LLM myśli.

Jaki jest ciężar utrzymania?

Około 30 minut tygodniowo. Nowe antywzorce pojawiają się, gdy agent napotyka nowe bazy kodu lub frameworki. Każdy nowy wzorzec wymaga regexa, testu zapobiegającego fałszywym alarmom i umieszczenia w odpowiednim hooku. Przeglądam pliki JSON ze standardami co miesiąc pod kątem przestarzałych wzorców i dostrajam wskaźniki fałszywych alarmów. System nie utrzymuje się sam, ale koszt utrzymania pozostaje niższy niż koszt debugowania problemów, którym zapobiega.

Ile dodatkowych tokenów kosztuje Jiro?

Około 15-20% dodatkowego zużycia tokenów w porównaniu z surową pętlą. Wstrzyknięcie przed edycją dodaje ~200 tokenów na edycję, sprawdzanie po edycji dodaje ~100 tokenów na oflagowany problem, bramki sesji dodają ~500 tokenów na koniec sesji.

Czy mogę używać hooków bez filozofii?

Tak. Deterministyczne hooki (quality-gate.sh, no-shortcuts-detector.sh, reviewer-stop-gate.sh) działają niezależnie. Usuń pliki z filozofią z ~/.claude/skills/ i zachowaj hooki w ~/.claude/hooks/. Tracisz probabilistyczną poprawę, ale zachowujesz deterministyczne egzekwowanie.

Powściągliwość, gust i moralna pauza

Odpowiedź na mój tweet nazwała trzy rzeczy: powściągliwość, gust i moralną pauzę. Zaadresowałem powściągliwość: bramki jakości, które uniemożliwiają maszynie wypuszczanie kodu szybko i niedbale. Ale gust i moralna pauza to inne problemy.

Gust

Immanuel Kant rozróżnił dwa rodzaje sądu. Sąd determinujący stosuje znane reguły do konkretnych przypadków: ten kod ma bare except, oflaguj go. Sąd refleksyjny odkrywa właściwą zasadę dla bezprecedensowej sytuacji: ta abstrakcja nie wydaje się właściwa, ale nie potrafię wskazać reguły, którą narusza.¹⁷

Deterministyczne hooki to sąd determinujący. Stosują reguły, które już napisałem, do kodu produkowanego przez maszynę. Potrafią egzekwować ponad 150 znanych wzorców. Nie potrafią powiedzieć, czy architektura jest elegancka, czy abstrakcja służy problemowi, ani czy kod dobrze się czuje. To wymaga sądu refleksyjnego: zdolności patrzenia na coś bezprecedensowego i wiedzy, że jest źle, zanim jeszcze potrafisz wyartykułować dlaczego.

Maszyna nie ma gustu. Jiro nie daje jej gustu. To, co Jiro robi, to ograniczanie przestrzeni możliwości, tak że rozwiązania pozbawione gustu mają mniejsze szanse przetrwania. To różnica między „ten agent ma dobry osąd” a „ten agent działa w ramach barier, które zapobiegają najgorszym wynikom”. Pierwsze byłoby gustem. Drugie jest tym, co faktycznie zbudowałem.

Moralna pauza

Iris Murdoch opisała uwagę moralną jako „sprawiedliwe i kochające spojrzenie skierowane na indywidualną rzeczywistość”.¹⁸ Przeciwieństwem uwagi moralnej jest mechaniczne przetwarzanie: działanie bez widzenia tego, co stoi przed tobą.

Hooki Stop zmuszają maszynę do zatrzymania się. Pride Check pyta: „Czy to rozwiązuje faktyczny problem użytkownika?” Bramka dowodowa wymaga dowodu dla każdego kryterium, zanim maszyna będzie mogła zgłosić ukończenie. Strukturalnie wynik przypomina moralną pauzę: agent zatrzymuje się, ocenia, rozważa, czy jego praca jest adekwatna, zanim przejdzie dalej.

Ale to nie jest moralna pauza. Maszyna nie zatrzymuje się, aby zobaczyć pracę jasno. Przechodzi przez listę kontrolną. Różnica ma znaczenie. Rzemieślnik zatrzymuje się, aby spojrzeć na szufladę i zauważa, że słoje drewna biegną w złym kierunku. Nie dlatego, że „sprawdź kierunek słojów” jest na liście. Dlatego, że zależy mu na szufladzie. Maszyna przechodzi listę kontrolną i raportuje wyniki. Jeśli lista nie zawiera kierunku słojów, szuflada wyjeżdża ze złymi słojami.

Deterministyczne bramki mogą przybliżyć strukturę moralnej pauzy bez jej istoty. Dla wielu problemów jakościowych struktura wystarczy. Dla tych, gdzie nie wystarczy, wciąż potrzebny jest człowiek, któremu zależy.

Teza

Surowa pętla Ralph działa za 10,42 $/godz. i wypuszcza kod z prędkością maszyny.¹ Wypuszcza też except: pass, # TODO: fix later i „testy powinny przejść” z prędkością maszyny. Maszyna odziedziczyła te wzorce od nas. To nasze nawyki, działające bez zmęczenia, bez poczucia winy, bez realizacji o 3 w nocy, że trzeba było zrobić to porządnie od razu.

Jiro jest moją odpowiedzią. Nie kompletną. Filozofia przesuwa decyzje na marginesach. Hooki egzekwują to, czego filozofia nie może zagwarantować. Razem produkują pracę, pod którą jestem gotów się podpisać. Nie dlatego, że maszyna rozumie rzemiosło. Dlatego, że zbudowałem system, który nie pozwala jej pominąć części, które mają znaczenie.

Prowadnice szuflad mojego taty nie obchodzą się o szufladę. To sprężynowe mechanizmy przykręcone do szyny. Ale chronią front przez tysiąc cykli, bo ktoś je zaprojektował dokładnie w tym celu.

Maszyna nie ma dumy. Ale działa wewnątrz systemu zbudowanego przez kogoś, kto ją ma.

Zacznij od 3 sprawdzeń, które wyłapują najczęstsze błędy. Rozbudowuj od tego.

Źródła