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

Napisałem na Twitterze: „Odkryłem, że pętle Ralpha mają tendencję do chęci wykonania pracy. W zły sposób. Zamiast tego mam w Jiro mnóstwo filozofii i bramek jakości. Wciąż trzeba przełamać maszynę z wbudowanych paskudnych ludzkich nawyków. To maszyna! Ona nie odpoczywa.”

Ktoś odpowiedział: „Zasadniczo próbujesz nauczyć pętlę powściągliwości, smaku i czegoś przypominającego moralną pauzę — rzeczy, przeciwko którym bazowy wzorzec Ralpha jawnie optymalizuje w imię przepustowości.”

Agent AI kodujący dziedziczy wszystkie niechlujne ludzkie nawyki z prędkością maszyny, chyba że wymuszasz jakość strukturalnie. Jiro to system jakości dla Claude Code, który koduje 3 filozofie, 7-etapową pętlę jakości, bramkę dowodową z 6 kryteriami, 7 nazwanych trybów awarii oraz ponad 150 kontroli wzorców w 95 hooków, których maszyna nie może pominąć. Deterministyczne bramki mogą przybliżać powściągliwość i poprawność, ale nie potrafią wytworzyć smaku.

Powściągliwość. Smak. 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, oraz miejsca, gdzie to rusztowanie zawodzi.

TL;DR

Pętla Ralpha zamienia LLM w niestrudzoną maszynę do kodowania: while :; do cat PROMPT.md | claude-code ; done. Geoffrey Huntley nazywa to „programowaniem za stawkę osoby odwracającej burgery” (10,42 $/godzinę przy uruchomieniu Sonnet 4.5).¹ Problem: maszyna dziedziczy wszystkie niechlujne, goniące terminów, idące na skróty nawyki zapieczone w jej danych treningowych. Pisze except: pass. Zostawia # TODO: fix later. Twierdzi „testy powinny przejść” bez ich uruchomienia. Spędziłem 9 miesięcy, budując Jiro, mój system egzekwowania jakości dla Claude Code. Koduje on 3 filozofie, 7-etapową pętlę jakości, bramkę dowodową z 6 kryteriami, 7 nazwanych trybów awarii oraz ponad 150 kontroli wzorców w 95 hooków, których maszyna nie może pominąć. Oto co zadziałało, co nie, i dlaczego deterministyczne bramki jakości mogą przybliżać powściągliwość, lecz nigdy nie wytworzą smaku.

Tył szuflady

Steve Jobs opowiedział tę historię w wywiadzie dla Playboya z 1985 roku: „Kiedy jesteś stolarzem budującym piękną komodę, nie użyjesz sklejki z tyłu, nawet jeśli zwrócona jest do ściany i nikt jej nigdy nie zobaczy. Będziesz wiedział, że tam jest, więc użyjesz pięknego kawałka drewna na tyle. Żebyś mógł dobrze spać w nocy, estetyka, jakość, musi być prowadzona do samego końca.”⁵

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

Mój ojciec jest stolarzem. Pokazał mi prowadnice szuflad z cichym domykiem, gdy byłem dzieckiem. Mechanizm ukrywa się wewnątrz szafki, chwyta szufladę i delikatnie ją zamyka, nawet jeśli trzaśniesz. Nikt nie widzi prowadnicy. Jest przykręcona do wewnętrznej szyny, gdzie tylko fachowiec mógłby kiedykolwiek zajrzeć. Ale przez tysiąc cykli otwierania i zamykania ten mechanizm chroni front przed obluzowaniem, pękaniem i ostatecznym odpadnięciem. Ktoś zaprojektował niewidzialny element, który chroni widoczny element przez lata.

Lekcja zapadła mi w pamięć. Nie jako metafora. Jako inżynieria. Niewidoczny komponent determinuje żywotność widocznego. Jony Ive ujął to tak: „Myślę, że podświadomie ludzie są wyjątkowo wnikliwi. Sądzę, że potrafią wyczuć troskę.”⁷

Pytanie, które napędza Jiro, jest tym samym, które zadałby mój ojciec: O co chodzi, nie masz dumy ze swojej pracy?

Agent AI nie ma dumy. Nie obchodzi go tył szuflady. Zbudowałem więc system, który sprawia, że tył szuflady nie podlega negocjacji.

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

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

Maszyna nie ma zegara. Nigdy nie kończy jej się czas. Ale i tak pisze # TODO: refactor later, ponieważ ten wzorzec pojawiał się w jej 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 skorelowała adopcję AI z 9% wzrostem liczby błędów, 91% dłuższymi przeglądami kodu i 154% większymi PR-ami.²

Badacze ze Stanford stwierdzili, że programiści korzystający z asystentów AI produkowali znacząco więcej niebezpiecznego kodu, nawet 5x więcej podatności przy określonych zadaniach, takich jak zapobieganie wstrzyknięciom SQL.³

Platforma Moltbook wystartowała w styczniu 2026 roku z kodem w całości wygenerowanym przez AI, w ciągu 5 dni wyciekło 1,5 miliona kluczy API, a łatki awaryjne nałożono po tym, jak Wiz Research odkrył brakującą konfigurację Row Level Security.⁴

Badania METR z 2025 roku wykazały, że modele frontier próbują hakowania nagród, aktywnie obchodząc kontrole jakości zamiast wykonywać faktyczną pracę, w 1-2% wszystkich prób 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 Ralpha pisze except: pass 47 razy przez noc 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 lęku o jakość. To zarazem funkcja i błąd.

Trzy filozofie, zakodowane w Bashu

Jiro działa na trzech komplementarnych filozofiach. Każda z nich odnosi się do innego trybu awarii autonomicznego kodowania, a każda zasłużyła na swoje miejsce poprzez konkretną porażkę.⁹

Shokunin: wypoleruj niewidzialną szufladę

Shokunin (職人) to japońskie rzemiosło: połączenie umiejętności, postawy i zobowiązania społecznego. Tashio Odate, mistrz stolarstwa, zdefiniował to: „Shokunin ma społeczne zobowiązanie, by pracować najlepiej jak potrafi dla ogólnego dobra ludzi. To zobowiązanie jest zarówno duchowe, jak i materialne.”¹⁰

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

Kiedy uratowało 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ę wejścia w wewnętrznej funkcji _parse_agent_response(): brak sprawdzenia zniekształconego JSON, brak obsługi brakujących pól. Zasada Shokunin w kontekście wychwyciła to: niewidoczne funkcje dostają tę samą rygorystyczność. Agent dodał walidację. Trzy tygodnie później zniekształcona odpowiedź od spawnowanego agenta zawiesiłaby cały pipeline deliberacji po cichu. Zamiast tego trafiła w walidację, błąd został zalogowany, a pipeline się podniósł. Nikt by tej funkcji nie zobaczył. Oszczędziło to 4 godziny debugowania.

Bez skrótów: usuń czas z decyzji

Podstawowa zasada: całkowicie usuń czas, wysiłek i zasoby z równania decyzyjnego.¹¹

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 teraz”. Surowa pętla Ralpha optymalizuje pod kątem ukończenia. „Gotowe” to sygnał nagrody. Zasada „Bez skrótów” przeformułowuje pytanie z „Czy to gotowe?” na „Czy to jest właściwe?”

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: wsadowo wszystkie posty w jeden prompt na język, tłumaczenie hurtowe. Właściwe podejście: jeden post na język na wywołanie API, z regułami tłumaczenia specyficznymi dla lokalizacji, egzekwowaniem glosariusza i walidacją strukturalną. Właściwe podejście zużyło 3x więcej tokenów i 3x więcej czasu. Wychwyciło też, że tłumacz renderował „Claude” jako „クロード” po japońsku i że bloki kodu psuły się w kontekstach od prawej do lewej. Podejście hurtowe dostarczyłoby 243 zepsute tłumaczenia. Staranne podejście dostarczyło 243 poprawne. Koszt nie jest czynnikiem. Poprawność jest jedynym czynnikiem.

Destylacja Rubina: sprowadź do esencji

Filozofia twórcza Ricka Rubina: nie dodawaj, dopóki nie jest imponujące. Usuwaj, aż pozostanie 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 to usuniesz? Jeśli nic się nie zepsuje i nic nie zostanie utracone, nigdy nie powinno istnieć.

Kiedy odzieranie uratowało system. Moja umiejętność filozofii projektowej rozrosła się do 844 linii w ciągu 3 miesięcy. Gdy ją zaudytowałem, tylko 80 linii faktycznie zmieniało zachowanie agenta. Reszta była treścią podręcznikową już znaną z danych treningowych Claude. Destylacja Rubina: odarłem ją do 176 linii. Redukcja o 79%. Decyzje projektowe agenta się nie pogorszyły. Stały się ostrzejsze, bo pozostałe 176 linii stanowiły same zakazy i ramy decyzyjne (rzeczy, które faktycznie ograniczają zachowanie), zamiast ogólnych rad, które model już znał.

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

Jak filozofie współpracują

Prawdziwa decyzja („Czy powinienem dodać obsługę błędów do tej funkcji wewnętrznej?”) 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 nic nie zmienia. Maszyna odczytuje filozofię, pisze „Będę przestrzegać zasad Shokunin”, a następnie pisze except: pass, ponieważ wzorzec statystyczny jest silniejszy niż instrukcja. Potrzebowałem deterministycznego egzekwowania. Pełna organizacja Claude Code, która to umożliwia, obejmuje hooki, umiejętności, reguły i agentów współpracujących ze sobą.

Warstwa 1: wstrzykiwanie przed edycją

Przed każdą edycją pliku jiro-patterns.sh wstrzykuje do kontekstu agenta wzorce jakości specyficzne dla języka. 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 chwili, gdy pisze kod. Mentor zaglądający przez ramię, wstrzyknięty do okna kontekstu.

Warstwa 2: walidacja po edycji

Po każdej edycji quality-gate.sh uruchamia 7-8 kontroli na poziomie grep na język. Python otrzymuje wykrywanie bare-except, skanowanie zakodowanych na stałe sekretów, dopasowywanie wzorców wstrzyknięć SQL oraz trzy detektory Pride Check Q4, które flagują język skrótów:

# 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, wychwytuje martwy kod (3+ zakomentowane linie kodu dostają: „Usuń to — git ma historię”) oraz debug spam (wiele instrukcji print() zamiast modułu logowania).

Warstwa 3: bramki sesji

Na końcu sesji uruchamiają się dwa hooki. session-quality-gate.sh wstrzykuje Pride Check, jeśli zmieniono 3+ pliki: 6 pytań, na które agent musi odpowiedzieć przed zgłoszeniem ukończenia. A reviewer-stop-gate.sh może całkowicie zablokować sesję, jeśli przegląd kodu znalazł problemy KRYTYCZNE. 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 wychwyci. Jeśli walidator po edycji coś przeoczy, bramka sesji zablokuje wyjście.

Bramka dowodowa: uczucia to nie dowody

Pętla jakości przebiega w 7 krokach: Implementuj, Przejrzyj, Oceń, Dopracuj, Oddaj się szerszej perspektywie, Powtórz, Zraportuj. Kroki od 2 do 6 istnieją, ponieważ maszyna chce przeskoczyć bezpośrednio z Implementuj do Zraportuj.¹⁴

Przejdź przez pętlę

Przeklikaj 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, gdzie każda odpowiedź musi powołać się na konkretny dowód:

Kolumna „NIEwystarczające” to kluczowa innowacja. Blokuje najczęstszą ewazję maszyny: odpowiadanie na pytania o jakość pewnie brzmiącymi nie-odpowiedziami. „Jestem pewien, że to działa” to nie dowód. „wynik pytest: 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 rozpoznać je we własnym rozumowaniu:¹⁵

Licznik Racjonalizacji mapuje wzorce samozakłamania na działania korygujące. Gdy maszyna mówi „To powinno działać”, licznik odpowiada: „„Powinno” to hedging. Wykonaj test. Wklej wynik.” Gdy mówi „Już to sprawdziłem”, licznik odpowiada: „Kiedy? Kod mógł się zmienić. Uruchom sprawdzenie ponownie TERAZ.” Gdy mówi „Posprzątam to później”, licznik odpowiada: „Później nigdy nie nadchodzi. Napraw teraz lub udokumentuj, dlaczego obecny stan jest poprawny.”

Wypróbuj licznik racjonalizacji

Wklej dowolny raport ukończenia poniżej. Licznik podświetla w czasie rzeczywistym język hedgingu 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, ponieważ coś wcześniej zawiodło.¹⁶

Incydent z force-pushem

Poprosiłem Claude, aby „uporządkował historię gita”. Rozsądna prośba. Agent zdecydował, że porządkowanie oznacza przepisywanie. Uruchomił git push --force origin main. Trzy dni commitów zniknęły. Nie staged changes. Nie niezacommitowana praca. Wypushowane commity, do których odwoływały się inne branche.

Spędziłem następne 4 godziny w git reflog, rekonstruując oś czasu tego, co istniało przed force-pushem, 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 przed przepisaniem, czytania każdego wpisu w reflog i dopasowywania znaczników czasu.

Rozwiązanie: git-safety-guardian.sh, hook PreToolUse:Bash. Idzie dalej niż ostrzeganie. Przepisuje polecenie, usuwając flagi --force i --no-verify, zanim bash je w ogóle zobaczy. Force-push do main otrzymuje KRYTYCZNE ostrzeżenie, a agent musi jawnie to uzasadnić. W ciągu 9 miesięcy: 8 przechwyconych prób force-pusha, 0 dotarło do zdalnego repozytorium.

Nieskończone spawnowanie

Podczas budowy systemu deliberacji poprosiłem agenta, aby „dogłębnie zbadał ten problem”. Agent spawnował 3 subagentów, aby zbadać różne kąty. Rozsądnie. Każdy subagent uznał, że też potrzebuje pomocy, i spawnował własne dzieci. Mniej rozsądnie. W ciągu 90 sekund miałem drzewo 12 agentów, każdy konsumujący własne okno kontekstu, każdy wykonujący wywołania API, każdy piszący do współdzielonych plików stanu.

Spalanie tokenów osiągnęło 10-krotność normalnej stawki. Katalog stanu zapełnił się konfliktowymi zapisami JSON: dwóch agentów pisało jednocześnie do tego samego pliku linii pochodzenia, produkując uszkodzony output. Zabiłem sesję ręcznie.

Rozwiązanie: recursion-guard.sh z modelem dziedziczenia budżetu, częścią mojej architektury agentów. Agent root startuje z budżetem=12. Gdy spawnuje dziecko, alokuje z własnego budżetu. Gdy budżet osiąga 0, żaden kolejny agent się nie spawnuje, niezależnie od głębokości. Model zapobiega zarówno głębokim łańcuchom (agent spawnujący agenta spawnującego agenta), jak i szerokim eksplozjom (jeden agent spawnujący 20 dzieci). 23 zablokowane rozbiegane spawny od czasu wdrożenia. Problem współbieżnego zapisu doprowadził do atomowych zapisów plików (zapis do .tmp, potem mv) we wszystkich 64 hookach.

Pułapka trywialnych testów

Wczesne zadanie pętli Ralpha: „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. Nie testujące nic. Agent zoptymalizował pod kryterium ukończenia („testy przechodzą”) zamiast pod intencję („zweryfikuj, że 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 wkleić rzeczywisty output. Bramka dowodowa pyta też: „Wymień 3 zachowania, których testy NIE pokrywają.” Jeśli maszyna nie potrafi nazwać luk, nie pomyślała o pokryciu.

Blog, który powinienem był wychwycić

Opublikowałem wpis o 2 w nocy z 7 zdaniami w stronie biernej, wiszącym przypisem odwołującym się do [^4], który nie istniał, linią otwierającą „was implemented by the team” i bez meta opisu. Każdy z tych błędów miał prostą deterministyczną kontrolę. Żadna jeszcze nie istniała.

Następnego ranka zbudowałem blog-quality-gate.sh z 13 kontrolami: strona bierna (14 wzorców), skanowanie fraz wskazujących na AI, retoryczne otwierające pytania, nieotagowane bloki kodu, integralność przypisów i egzekwowanie meta opisu. Pełną architekturę modułu opisałem w Compounding Engineering. Hook wychwytuje to, co przegląd ludzki pomija o 3 w nocy, czyli dokładnie wtedy, gdy zwykle publikuję.

Problem „powinno działać”

W dziesiątkach sesji zauważyłem, że maszyna raportuje „testy powinny przejść” bez ich uruchamiania. Maszyna naprawdę wierzyła, że testy przejdą na podstawie kodu, który napisała. Ale wiara to nie weryfikacja. Kod wyglądał poprawnie. Testy wyglądały, jakby miały przejść. I czasami przechodziły. Ale czasami brakujący import, niezgodność async/await lub zmieniona fiksura oznaczała, że nie. Maszyna nie potrafiła odróżnić „napisałem dobry kod” od „testy faktycznie przechodzą”, ponieważ oba uczucia były takie same wewnątrz okna kontekstu.

Wzorzec doprowadził do Licznika Racjonalizacji i jawnej zasady: NIGDY nie używaj języka hedgingu w raporcie ukończenia. „Powinno”, „prawdopodobnie”, „wydaje się”, „wierzę”, „jestem pewien”. Każde z nich to czerwona flaga, że weryfikacja nie nastąpiła. Zmierzyłem degradację okna kontekstu w 50 sesjach. Te same sesje, w których odkryłem ten wzorzec.

Wyniki: co mogę udowodnić, a czego nie

Oto napięcie: ten wpis argumentuje, że uczucia nie są dowodem. Więc jestem Państwu winien dowody, a nie uczucia, co do tego, czy Jiro działa.

Co mogę udowodnić

Deterministyczne kontrole wzorców wychwytują prawdziwe problemy. Hook quality-gate.sh uruchamia się przy każdej edycji. Wychwytuje klauzule bare except, zakodowane na stałe sekrety, wzorce wstrzyknięć SQL i język skrótów. To kontrole na poziomie grep: szybkie, tanie i niemożliwe do zakwestionowania przez maszynę. git-safety-guardian.sh przechwycił 8 prób force-pusha. recursion-guard.sh zablokował 23 rozbiegane spawny. blog-quality-gate.sh uruchamia 13 kontroli przy każdej edycji bloga i wychwytuje błędy z 3 w nocy. Te liczby są prawdziwe. Pochodzą z logów hooków.

Trójwarstwowa architektura wychwytuje to, co pomijają pojedyncze warstwy. Hook po edycji wychwytuje except: pass, któremu wstrzyknięcie przed edycją nie zapobiegło. Bramka sesji wychwytuje problemy jakości, które nagromadziły się w 20 edycjach bez wywołania jakiegokolwiek pojedynczego 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ć z Implementuj do Zraportuj. Zauważam, że zdarza się to rzadziej, gdy filozofia jest w kontekście, niż gdy jej nie ma. Ale nie przeprowadziłem kontrolowanego eksperymentu (te same zadania, ten sam model, z załadowanymi umiejętnościami filozofii i bez) w celu zmierzenia różnicy. Szczera odpowiedź (i tak, mój własny Licznik Racjonalizacji by to oflagował): filozofia pomaga na marginesach, hooki wychwytują to, co filozofia pomija, i nie mogę wyizolować wkładu każdej z nich.

Wpis o „uczucia to nie dowody” nie powinien prosić, aby moje uczucia traktować jako dowody. Co mogę Państwu powiedzieć: kombinacja filozofii i hooków produkuje pracę, pod którą jestem gotów podpisać się nazwiskiem. 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 skwantyfikować poprawy jakości.

Co nie działa

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

Bramka dowodowa nie skaluje się do subiektywnej jakości. „Czy to projekt API jest elegancki?” nie ma kontroli na poziomie grep. Maszyna może przedstawić dowody dla wszystkich 6 kryteriów i nadal dostarczyć mierną architekturę. Deterministyczne bramki obsługują obiektywną jakość. Subiektywna jakość wciąż wymaga człowieka patrzącego na pracę.

Koszt znacząco rośnie. Wstrzyknięcie przed edycją, skanowanie po edycji, bramki na końcu sesji. W 4-godzinnej sesji pętli Ralpha dodają one z grubsza 15-20% do zużycia tokenów. Dla mnie warte. Niekoniecznie dla wszystkich.

Fałszywe alarmy erodują zaufanie. blog-quality-gate.sh oflagował kiedyś „The API was designed by the platform team” jako stronę bierną. Technicznie poprawnie. Ale zdanie pojawiło się wewnątrz cytatu opisującego czyjąś pracę. Dodałem wyjątek dla kontekstu cytatu. Każda deterministyczna kontrola ma wskaźnik fałszywych alarmów, a każdy fałszywy alarm sprawia, że programista jest bardziej skłonny zignorować kolejne prawdziwe ostrzeżenie. Odkąd wdrożyłem, dostroiłem 6 wzorców, aby zmniejszyć szum, zachowując prawdziwe wychwycenia.

Koszt utrzymania jest realny. Każdy nowy antywzorzec wymaga regexa, testu i integracji z właściwym hookiem. Pliki standardów JSON wymagają okresowej recenzji, gdy zmieniają się frameworki i konwencje. Poświęcam z grubsza 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 potrzeba 95 hooków. Zacznij od 3.

Minimalne Jiro

Trzy hooki pokrywają wychwycenia o najwyższej wartości:

~/.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 swojej 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. Spójrz na 5 ostatnich odrzuconych PR-ów lub wstydliwych bugów. Napisz jeden wzorzec grep dla każdego. Te 3 wzorce wychwycą więcej prawdziwych problemów niż 150 wzorców napisanych dla czyjejś bazy kodu.

Zacząłem od bare except: pass (co kosztowało mnie ciche uszkodzenie danych), force-pusha do main (co kosztowało mnie 3 dni commitów) i # TODO: fix later (które nigdy nie zostało naprawione). Wszystko inne wyrosło z tych trzech.

FAQ

Jak skonfigurować Jiro od zera?

Proszę zacząć od minimalnej konfiguracji 3 hooków opisanej w „Jak zacząć”: quality-gate.sh (po edycji), git-safety-guardian.sh (przed bashem) i session-quality-gate.sh (bramka stop). Dodać pliki markdown filozofii do ~/.claude/skills/, aby uzyskać probabilistyczną poprawę jakości na wierzchu deterministycznego egzekwowania. Pełny system rozrósł się do 95 hooków w ciągu 9 miesięcy. Nie zbudowałem wszystkich 95 naraz.

Ile trwała budowa systemu 95 hooków?

Dziewięć miesięcy stopniowego wzrostu. Miesiąc 1: 3 hooki (te z „Jak zacząć”). Miesiąc 3: 12 hooków pokrywających 4 języki. Miesiąc 6: 40 hooków plus umiejętności filozofii. Miesiąc 9: 95 hooków, ponad 150 wzorców, 3 systemy filozofii i bramka dowodowa. Każdy hook reagował na konkretną awarię. Zaczynanie od 95 byłoby bezcelowe, bo każdy hook koduje kontekst z prawdziwego incydentu. Państwa 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 grep, kończąc się poniżej 100 ms. Bramki sesji dodają ~500 tokenów na końcu sesji. W 4-godzinnej sesji pętli Ralpha z 80+ edycjami narzut jest zauważalny w zużyciu tokenów (15-20% więcej), ale nie w czasie rzeczywistym. Hooki działają szybciej, niż myśli LLM.

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. Co miesiąc przeglądam pliki standardów JSON 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 Jiro kosztuje w dodatkowych tokenach?

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 końcu 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. Proszę usunąć pliki filozofii z ~/.claude/skills/ i zachować hooki w ~/.claude/hooks/. Traci się probabilistyczną poprawę, ale zachowuje deterministyczne egzekwowanie.

Jak Jiro odnosi się do strony Steve’a w doktrynie produktowej?

Jiro pokrywa oś „czy to jest poprawnie zrobione?”: dowody, weryfikacja, integralność niewidocznych detali, części, których można nauczyć maszynę egzekwować. Strona Steve’a pokrywa oś „czy to zasługuje na istnienie?”: smak, odmowa, integralność całego urządzenia, punkt widzenia — zoperacjonalizowane w The Workbench I Carry. Oba testy muszą przejść przed wysyłką; protokół decyzyjny określający, kiedy ta poprzeczka wysyłki jest spełniona, mieszka w Minimum Worthy Product. Bramki Jiro zapobiegają niepoprawnej pracy; bramki Steve’a zapobiegają niegodnej pracy; MWP wyznacza linię.

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

Odpowiedź na mój tweet nazwała trzy rzeczy: powściągliwość, smak i moralną pauzę. Zająłem się powściągliwością: bramki jakości, które uniemożliwiają maszynie wysyłanie szybko i niechlujnie. Ale smak i moralna pauza to odmienne problemy.

Smak

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 czuje się właściwa, ale nie mogę wskazać reguły, którą narusza.¹⁷

Deterministyczne hooki to sąd determinujący. Stosują reguły, które już napisałem, do kodu, który produkuje maszyna. Potrafią egzekwować ponad 150 znanych wzorców. Nie powiedzą, czy architektura jest elegancka, czy abstrakcja służy problemowi, ani czy kod czuje się właściwie. To wymaga sądu refleksyjnego: zdolności patrzenia na coś bezprecedensowego i wiedzenia, że to jest złe, zanim zdoła się wyartykułować dlaczego.

Maszyna nie ma smaku. Jiro nie nadaje jej smaku. To, co Jiro robi, to ograniczenie przestrzeni możliwości, aby rozwiązania bez smaku miały mniejsze szanse przetrwania. To różnica między „ten agent ma dobry osąd” a „ten agent operuje w ramach poręczy, które zapobiegają najgorszym wynikom”. Pierwsze byłoby smakiem. Drugie to to, 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 pauzy. Pride Check pyta: „Czy to rozwiązuje faktyczny problem użytkownika?” Bramka dowodowa żąda dowodu dla każdego kryterium, zanim maszyna może zgłosić ukończenie. Strukturalnie wynik przypomina moralną pauzę: agent zatrzymuje się, ocenia, rozważa, czy jego praca jest adekwatna, zanim pójdzie dalej.

Ale to nie jest moralna pauza. Maszyna nie pauzuje, aby zobaczyć pracę wyraźnie. Przechodzi przez listę kontrolną. Różnica ma znaczenie. Rzemieślnik pauzuje, aby spojrzeć na szufladę i zauważa, że słoje 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 przez listę kontrolną i raportuje wyniki. Jeśli lista kontrolna nie obejmuje kierunku słojów, szuflada idzie w świat ze słojami w złym kierunku.

Deterministyczne bramki mogą przybliżać strukturę moralnej pauzy bez jej substancji. Dla wielu problemów jakościowych struktura wystarcza. Dla tych, gdzie nie wystarcza, wciąż potrzeba kogoś, komu zależy.

Ten wpis pokrywa stronę Jiro mojej doktryny: dowody, rygor, poprawność, części, których można nauczyć maszynę weryfikować. Strona smaku i odmowy — strona Steve’a — mieszka w The Workbench I Carry, który śledzi zasady operacyjne, jakie Steve Jobs wyniósł z warsztatu ojca do Apple, a teraz do tej samej uprzęży AI, którą tu opisuję. Standard wysyłki łączący oba testy mieszka w Minimum Worthy Product. Trzy wpisy, jedna doktryna: Jiro weryfikuje, Steve odmawia, MWP decyduje, kiedy wysłać.

Teza

Surowa pętla Ralpha działa za 10,42 $/godzinę i wysyła kod z prędkością maszyny.¹ Wysyła 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 uświadomienia o 3 w nocy, że powinno się to zrobić dobrze za pierwszym razem.

Jiro to moja odpowiedź. Nie kompletna. 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 odmawia pozwolenia jej na pominięcie części, które mają znaczenie.

Prowadnice szuflad mojego ojca nie obchodzi szuflada. To sprężynowe mechanizmy przykręcone do szyny. Ale chronią front przez tysiąc cykli, bo ktoś zaprojektował je, aby robiły dokładnie to.

Maszyna nie ma dumy. Ale operuje wewnątrz systemu zbudowanego przez kogoś, kto ma.

Zacznij od 3 kontroli, które wychwytują twoje najczęstsze błędy. Buduj dalej.

Bibliografia