Co się dzieje → co z tym zrobić
Szukaj po objawie, nie po tytule. Link pod „co z tym zrobić“ prowadzi do sekcji artykułu, która opisuje dany mechanizm. Pełny spis treści wszystkich artykułów znajduje się na dole tej strony.
Ta tabela zakłada użycie Claude Code (agenta programistycznego firmy Anthropic). hook, CLAUDE.md, subagent i auto memory to nazwy jego funkcji.
| Co się dzieje | Co z tym zrobić |
|---|---|
| Za każdym razem, gdy AI uruchamia testy, dziesiątki tysięcy linijek outputu zalewają kontekst |
Wszystkie uruchomienia testów kieruje się przez jeden skrypt-wrapper, pełny output zapisuje do pliku logu, a AI zwraca tylko podsumowanie błędów. |
| Im więcej notatek z wnioskami zapisuje AI, tym więcej musi przeczytać każda kolejna sesja |
Hook PreToolUse uruchamiany tuż przed zapisem do pamięci każe najpierw przeczytać listę kontrolną. W pliku instrukcji (CLAUDE.md) zostaje tylko jedna linijka: „przeczytaj, zanim zapiszesz“. |
| Testy przechodzą, ale nie wiadomo, czy faktycznie coś chronią |
Zasady mutation testing (metody celowego psucia kodu, żeby sprawdzić, czy testy to wyłapią) spisuje się w jednym dokumencie i każe przeczytać przy każdej prośbie o przegląd testów. |
| Zarejestrowany skill AI czasem używa, a czasem nie |
Komenda zostaje zwykłym skryptem, a błędny sposób jej wywołania blokuje hook PreToolUse, wskazując dokumentację, którą trzeba przeczytać. |
| Po zleceniu zadania sub-agentowi nie widać, co się dzieje, aż do końca |
W pliku YAML definiuje się, jakie zadania wolno zlecać sub-agentowi i jakie pliki wejściowe muszą istnieć przed startem, a hook sprawdza to przed uruchomieniem. |
| Im więcej reguł dodaje się do pliku instrukcji, tym gorzej przestrzegane są te dodane wcześniej |
Każdą regułę typu „nie rób X“ przepisuje się, jedną po drugiej, na automatyczny test (Minitest), który wykrywa naruszenie. |
| Pamięć współdzielona przez równolegle działające sesje robi się chaotyczna. Kazanie im przeczytać zasady nie pomaga |
Ten sam plik z zasadami przenosi się do hooka PostToolUse i pokazuje razem z diffem zaraz po zapisie. Treść zostaje ta sama, zmienia się tylko moment jej pokazania. |
| Nawet gdy sposób radzenia sobie z danym błędem jest spisany, AI za następnym razem popełnia go ponownie |
Zasady postępowania przy ponownej próbie zbiera się w kilkulinijkowym pliku, który hook wykrywający błąd wstawia automatycznie. |
| Nawet po przeczytaniu notatki przekazującej pracę i raportu z ukończenia, niewygodne fakty są pomijane |
Obok raportu z ukończenia za każdym razem umieszcza się liczby uzyskane mechanicznie, np. za pomocą git diff --stat. |
| Liczba policzona maszynowo zmienia się w inną, zanim trafi do raportu |
Do linijki z liczbą dodaje się stały prefiks, a hook sprawdza, czy został skopiowany dosłownie. |
| Przerwanie AI w trakcie pracy psuje wszystko, co robi potem |
Zamiast przerywać AI w trakcie pracy, pozwala się interweniować hookowi PostToolUse, który zaraz po zapisie zwraca zasady, oraz hookowi, który wykrywa błąd i odsyła pracę. Człowiek czeka do naturalnego punktu przerwania. |
| Pod koniec sesji nie wiadomo, co trzeba przeczytać, a co można pominąć |
Nie czyta się ani wyniku pracy, ani logu z sesji — o powodzeniu decyduje wyłącznie exit code testów lub lintera. |
| Raz odrzucona propozycja wraca w kolejnej sesji |
Wszystkie odrzucone decyzje zbiera się w jednym dokumencie, w ustalonym formacie. |
| Mimo spisania zakazu w jednej linijce, jest on interpretowany zarówno zbyt szeroko, jak i zbyt wąsko |
W jednym dokumencie zbierającym odrzucone decyzje (np. non_goals.md) przy każdym zakazie dodaje się nagłówek „powód“ razem z wnioskiem. |
| Zakaz jest zapisany poprawnie, ale nie jest przestrzegany, i za każdym razem ktoś o niego pyta |
W dokumencie odrzuconych decyzji przy każdym zakazie dodaje się nagłówek „zakres stosowania“ i wypisuje, linijka po linijce, przypadki graniczne budzące wątpliwości. |
| Te same instrukcje wysłane do kilku sub-agentów wracają za każdym razem w innej formie |
Na liście zadań, które wolno przekazać sub-agentowi, wprost podaje się pliki wejściowe wymagane przed uruchomieniem. |
| Zakazy bez automatycznego testu piętrzą się, pozostając wyłącznie zapisanym tekstem |
W dokumencie odrzuconych decyzji na liście dodaje się nagłówek „weryfikacja maszynowa“ i przy każdym punkcie zaznacza, czy istnieje odpowiadający mu automatyczny test (Minitest). |
| Praca AI za każdym razem kończy się słowami „proszę otworzyć ekran i sprawdzić“ |
Przygotowuje się jeden smoke test w Playwright, a o powodzeniu decyduje rekord zapisany w bazie danych, a nie wygląd ekranu. |
| Za każdym razem, gdy AI mówi coś lekko obok tematu, to człowiek musi to wytłumaczyć i poprawić |
Zamiast tłumaczyć i poprawiać każde odchylenie samemu, uwagę zapisuje się w stderr hooka (exit 2) i w komunikatach błędu automatycznych testów, tak by docierała do AI właśnie tą drogą. |
| Lista odrzuconych decyzji ciągle rośnie i w końcu nikt jej nie będzie czytał |
Na końcu dokumentu odrzuconych decyzji dodaje się sekcję „propozycje, których nie przyjęto“, i tam zapisuje się odrzucone pomysły. |
| Liczba poleceń „koniecznie uruchom“ w pliku instrukcji wcale nie maleje |
Automatyczny test sprawdza, czy każda komenda oznaczona w pliku instrukcji jako „koniecznie uruchom“ istnieje też w pre-commit hooku. |
| Mimo spisania dokładnego sposobu wykonania, poprawka nie wraca zgodnie z nim |
Zamiast dyktować procedurę, dla każdego zastosowania definiuje się pliki wejściowe, które muszą istnieć, zanim sub-agent zostanie uruchomiony. |
| Zgłaszanie błędu za każdym razem wymaga, żeby to człowiek spisywał kroki i objawy |
Ustawia się formularz zgłaszania błędów, w którym człowiek wpisuje tylko jedno zdanie z opisem objawu, a URL, historię działań i informacje o przeglądarce zbiera automatycznie JavaScript. |
| Wpisywanie za każdym razem „najpierw przedstaw plan“ to osobny, powtarzający się wysiłek |
Nie trzeba nic nowego implementować. Wystarczy umieścić jeden dokument projektowy — AI przeczyta istniejące dokumenty i zachowa ten sam format. |
| Linijki, które najbardziej zależy nam, żeby były przestrzegane, są zapisane najmocniej, ale nie wiadomo, czy to działa |
Zamiast mierzyć skuteczność, liczy się linijki w pliku instrukcji zawierające wyrażenia podkreślające i ustawia automatyczny test (ratchet), który zawodzi po przekroczeniu progu. |
| Wynik pracy sub-agenta wraca w innej formie, niż się zakładało |
Dla każdego zastosowania sub-agenta definiuje się w jednym dokumencie warunki odbioru wyniku — nazwę pliku, format, wymagane pola. |
| Znalezienie błędu wywołuje chęć zapytania: „czy w ogóle to przeczytałeś?“ |
Zamiast przesłuchiwać, drugie zdanie każdej prośby ustala się na stałe jako szablon pytania „czy nie jest tak, że …?“. |
| Odpowiadanie „nie o to chodziło“ na otrzymaną odpowiedź niczego nie poprawia |
Zamiast wytykać błąd, zakazy bez podanej alternatywy pokazuje się przez hook PostToolUse razem z diffem zaraz po zapisie. |
| AI mówi o zawartości pliku, którego nie otworzył, tak jakby go otworzył |
Każe się AI zapisać odpowiadające sobie markery zarówno w przywoływanym dokumencie, jak i w kodzie, a automatyczny test sprawdza, czy markery naprawdę istnieją. |
| Ciągłe pytania AI typu „A czy B?“ zatrzymują pracę, bo trzeba czekać na decyzję |
Zamiast odpowiadać od razu, wybór między opcjami przenosi się do automatycznego testu lub hooka. |
| AI przeprowadza review, ale nie wiadomo, czego nie sprawdza |
Zewnętrzny automatyczny test wykrywa te automatyczne testy, które przeszukują pliki, ale nie mają dolnego progu liczby wyników (assert_operator ... :>=). |
| Zrzuty ekranu się gromadzą, ale nie wiadomo, który z nich co właściwie potwierdza |
Przed sprawdzeniem ekranu każe się odpowiedzieć na dwa pytania — „co jest weryfikowane“ i „dlaczego tańszy sposób nie wystarczy“ — i ustala się jedną zasadę: próbować od najtańszego rozwiązania, w kolejności test jednostkowy → test integracyjny → E2E. |
| Mimo wprowadzenia kroku wymagającego zapisu, nie da się policzyć, ile uruchomień go pominęło |
Przed zrzutem ekranu lub E2E każe się napisać plik deklaracji z tym, co jest weryfikowane (np. tmp/visual_verification.md), jego istnienie staje się warunkiem hooka PreToolUse, a bez niego zrzut ekranu ani E2E się nie uruchomią. |
| Ten sam test uruchamia się ponownie, mimo że kod się nie zmienił, i trzeba na to czekać |
Do skryptu-wrappera testów dodaje się opcję --last, która pokazuje ponownie poprzedni log, dzięki czemu ponowne uruchomienie nie jest potrzebne. |
| Nic nie zostało zepsute, a mimo to pojawia się cała seria nieznanych błędów |
Skrypt-wrapper testów zakłada blokadę wzajemnego wykluczania (wykorzystując atomowość mkdir) i nie uruchamia testu, jeśli nie uda się jej uzyskać. |
| Raport „testy przechodzą“ nie wspomina o tym, co się w ogóle nie uruchomiło |
Ciężkie testy E2E oznacza się tagiem obszaru i domyślnie pomija, a listę pominiętych obszarów wypisuje się za każdym razem. |
| Nie da się później sprawdzić, czy instrukcja opisująca sposób postępowania została faktycznie zastosowana |
Żeby wymusić przestrzeganie procedury, nie wzmacnia się treści instrukcji — zamiast tego zmienia się ją tak, by ślad jej wykonania zostawał w wyniku pracy (np. jedna linijka outputu na każdy otwarty plik). |
| Wprowadzony wrapper w pewnym momencie jest zastępowany z powrotem zwykłą komendą |
Żeby wymusić używanie wrappera, nie wzmacnia się instrukcji — sprawdza się, czy nadal istnieje powód powrotu do zwykłej komendy, czyli czy wrapperowi czegoś nie brakuje. |
| Zadanie tego samego pytania wielokrotnie daje za każdym razem inną odpowiedź, a przy zbieraniu ich w jedno coś ginie |
Przed połączeniem kilku odpowiedzi w jedną wypisuje się liczbę wystąpień każdego rodzaju uwagi — ile razy padła na tyle odpowiedzi. |
| Nie wiadomo, czy linijka z zapisem „jeśli trzeba, zrób X“ w ogóle zadziałała |
Zamiast pisać warunkową instrukcję typu „jeśli trzeba, zrób X“, wymusza się ten krok hookiem, który nie pozwala przejść dalej bez jego wykonania. |
| Odpowiedź na „przemyśl to jeszcze raz“ się zmienia, ale nie wiadomo, czy AI faktycznie się przekonało |
Zamiast odsyłać z prośbą „przemyśl to jeszcze raz“, wskazuje się konkretnie, które założenie jest błędne. |
| Po zapisaniu „nie zgaduj“ AI zaczęło wracać, nie tworząc niczego |
Zamiast samego zakazu, podaje się też alternatywę, np. „jeśli nic nie pasuje, wypisz «nie dotyczy»“. |
| Kontynuowanie rozmowy, która dobrze idzie, sprawia, że sprawdzanie jej wymaga coraz więcej pracy |
Sesję kończy się na granicy zadania, a kolejne zadanie zaczyna w nowej sesji. |
| Wszystkie wyniki pracy są poprawne, ale narasta marnotrawstwo, którego w nich nie widać |
Gdy wyniki pracy są już gotowe, log sesji (transcript) jednorazowo podsumowuje się skryptem. |
| Wiedza spisana z myślą o kolejnej osobie zaczyna odbiegać od rzeczywistości i się dezaktualizuje |
Wiedzy nie zapisuje się w dokumencie — osadza się ją w komunikacie błędu automatycznego testu albo w komunikacie zatrzymania hooka, tak by pojawiała się dokładnie wtedy, gdy jest potrzebna. |
| Szukanie przyczyny trwa dalej, a czytanie nie ustaje nawet po znalezieniu odpowiedzi |
Z logu sesji liczy się ciągi odczytów, które niczego nie zmieniły, a przed rozpoczęciem drążenia tematu zapisuje się w jednej linijce warunek zakończenia. |
| Najtańszy pod względem ceny model staje się domyślnym wyborem bez sprawdzenia, czy pasuje do zastosowania |
To samo zadanie przekazuje się tańszemu i droższemu modelowi, a decyzję podejmuje dopiero po osobnym policzeniu liczby tur do ukończenia oraz ilości nowo przeczytanego, ponownie użytego (cache read) i napisanego tekstu. |
| Gdy coś nie działa, zamiast poprawić mechanizm, sięga się po lepszy model |
To samo zadanie przekazuje się droższemu i tańszemu modelowi, a miejsca, w których zawodzi tylko tańszy, zamienia się w stały test. |
| Zbadanie czegoś, co główna sesja mogłaby zrobić sama, na wszelki wypadek przekazuje się sub-agentowi |
Przed przekazaniem sprawdza się, czy agent nadrzędny już ma potrzebny kontekst. Jeśli tak, kontynuuje się w nim; sub-agentowi zleca się tylko obszerne czytanie, którego agentowi nadrzędnemu brakuje. |
| Zadanie dzieli się na cztery na wszelki wypadek i uruchamia jednocześnie |
Jednemu sub-agentowi przekazuje się tylko tyle, ile może zwrócić w jednej odpowiedzi. O koszcie decyduje nie liczba sub-agentów, lecz to, ile razy każdy z wydzielonych sub-agentów wymienia się z agentem nadrzędnym. |
| W trakcie pracy z zewnątrz wtrąca się „spójrz jeszcze na to“ |
Czeka się do naturalnego punktu przerwania pracy, a potem wprowadza dodatkową prośbę z zawężonym zakresem. Pytając samą AI o braki, zawsze dodaje się: „jeśli wystarczy, napisz to wprost“. Daje to jej furtkę (escape hatch), żeby nie musiała wymyślać braku. |
| Decyzję, którego modelu użyć, próbuje się podjąć przez bezpośrednie porównanie |
Zanim zacznie się porównywać modele, liczy się, ile hooków lub automatycznych testów kosztowałoby to porównanie. Jeśli da się spisać więcej mechanizmów niż wynosi ta liczba, najpierw wprowadza się te mechanizmy. |
| Weryfikację chce się zakończyć stwierdzeniem „nie było różnicy“ |
Zanim zakończy się stwierdzeniem „nie było różnicy“, liczy się dwie rzeczy: jeśli jakieś wyniki zostały wyłączone z zestawienia (np. nieudane sub-agenty), wraca się do nich i liczy ponownie; jeśli ponad połowa pozycji ma wynik zerowy we wszystkich warunkach, zmienia się sformułowanie zadania i mierzy jeszcze raz. |
Spis treści wszystkich artykułów
Dla każdej serii, w kolejności od wprowadzenia do ostatniej części.
はじめに —— 3 つの連載を、1 冊に
バイブコーディングにおける読まない技術
- 読まない技術 序論 AIの出力を、もうほとんど読んでいない
- 読まない技術 第1回 テスト結果を読まない技術
- 読まない技術 第2回 メモリを読まない技術
- 読まない技術 第3回 単体テストを読まない技術
- 読まない技術 第4回 スキルを使わない技術
- 読まない技術 第5回 サブエージェントの出力だけは読め
- 読まない技術 第6回 ルールを読まない技術
- 読まない技術 第7回 共有メモリを整理しない技術
- 読まない技術 第8回 修正履歴を読まない技術
- 読まない技術 第9回 引き継ぎを読まない技術
- 読まない技術 第10回 AIに要約しろと言わない技術
- 読まない技術 第11回 口を挟まない技術
- 読まない技術 第12回 作業結果を読まない技術
- 読まない技術 最終回 AIの出力を、ほとんど読まなくなった
AIの意見を聞かない技術
言わない技術
- 言わない技術 序論 AI に指示することが、ほとんどなくなった
- 言わない技術 第1回 検証を指示しない技術
- 言わない技術 第2回 具体的な指示を出さない技術
- 言わない技術 第3回 不具合詳細を書かない技術
- 言わない技術 第4回 計画を書けと言わない技術
- 言わない技術 第5回 念を押さない技術
- 言わない技術 第6回 サブエージェントの出力だけは、細かく指示しろ
- 言わない技術 第7回 AI を問い詰めない技術
- 言わない技術 第8回 AI にダメ出ししない技術
- 言わない技術 第9回 AI に考えさせない技術
- 言わない技術 第10回 質問に答えない技術
- 言わない技術 第11回 AI にレビューをさせない技術
- 言わない技術 最終回 何もしない技術
付録
はじめに —— 前巻の続きを、もう 1 冊に
確かめない技術
動かさない技術
追わない技術
番外編
- 番外編 A-1 整理する技術 —— 記録が増えたときに、何が起きているか
- 番外編 A-2 指示を残す技術 —— 「調べるだけ」が通らなかった日
- 番外編 A-3 参照するタイミングを変える技術 —— 2,000 行の壁
- 番外編 A-4 導出を依頼者の言葉と分ける技術 —— 誰も言っていない条件が、memory に載った日
- 番外編 A-5 memory を要約しない技術 —— 整理から、要約を抜く
- 番外編 A-6 責務で線を引く技術 —— 仕組みが増えたときに、どれを消すか
- 番外編 A-7 読まれたかを確かめる技術 —— 確かめるのをやめて、読めていない形を止めた
- 番外編 A-8 面積で数える技術 —— 読ませた量で数えていたら、102 倍外していました
- 番外編 A-9 ルールを短くする技術 —— 読みに来るのは、止められた直後の人です
- 番外編 B-1 連載を本にする技術 —— 本単位のスイッチでは、足りなかった日
- 番外編 C-1 校正の方法に、先に本編を当てる技術 —— 方法を決める文が、本文と同じ地雷を踏んでいた日
- 番外編 C-2 仕組みと人を分ける技術 —— 検査を置いたその手で、検査の外側で 2 度転んだ日
- 番外編 C-3 要素ごとに観点を変える技術 —— 一様に当てた点検が、要素をまたいだところで数を落としていた
- 番外編 C-4 指示の揺れを、事故として残す技術 —— 事故を見て置いた仕組みは、まだ一度も鳴っていない
- 番外編 C-5 作業の流れを見る技術 —— 終わりにしたつもりの日に、まだ起きていたこと
- 番外編 C-6 作業を進める技術 —— 選ぶ場面が、1 つも残らなかった日
- 番外編 C-7 基準の出どころを見る技術 —— 2 分前に開いたページに、答えが書いてありました
- あとがき —— 本当の事実はどうでもいい話