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. Lista artykułów znajduje się na dole tej strony, poza indeksem odwrotnym.
Ta tabela zakłada użycie Claude Code (agenta programistycznego firmy Anthropic). hook, CLAUDE.md, subagent i auto memory to nazwy jego funkcji.
Zdanie, które człowiek wpisuje, gdy coś idzie nie tak
「Wyczyść wszystkie todo. Sprawdź https://typing-tube.net/articles/pl/lookup.md, przejrzyj tę sesję i zobacz, czy coś poszło nie tak.」
Wychodzi z tego tylko lista problemów. Jak je naprawić, decydujesz ty, stosownie do swojego projektu.
| Co się dzieje | Proponowane podejście |
|---|---|
| No.1 Za każdym razem, gdy AI uruchamia testy, dziesiątki tysięcy linijek outputu zalewają kontekst |
Przykład:Testy uruchamia się przez jeden wrapper, a AI dostaje tylko podsumowanie błędów. |
| No.2 Im więcej notatek z wnioskami zapisuje AI, tym więcej musi przeczytać każda kolejna sesja |
Przykład:Przed zapisem do pamięci każe się przeczytać checklistę, a w stale czytanym pliku zostaje jedna linijka. |
| No.3 Testy przechodzą, ale nie wiadomo, czy faktycznie coś chronią |
Przykład:AI dostaje polecenie przeprowadzenia mutation testing. |
| No.4 Zarejestrowany skill AI czasem używa, a czasem nie |
Przykład:Błędne wywołanie blokuje się na wejściu i wskazuje dokumentację do przeczytania. |
| No.5 Po zleceniu zadania sub-agentowi nie widać, co się dzieje, aż do końca |
Przykład:Zadania możliwe do zlecenia spisuje się na liście i sprawdza hookiem przed startem. |
| No.6 Im więcej reguł dodaje się do pliku instrukcji, tym gorzej przestrzegane są te dodane wcześniej |
Przykład:Każdy zakaz „nie rób X“ przepisuje się na automatyczny test wykrywający naruszenie. |
| No.7 Pamięć współdzielona przez równolegle działające sesje robi się chaotyczna. Kazanie im przeczytać zasady nie pomaga |
Przykład:Treść zostaje ta sama, zmienia się tylko moment pokazania — zaraz po zapisie. |
| No.8 Nawet gdy sposób radzenia sobie z danym błędem jest spisany, AI za następnym razem popełnia go ponownie |
Przykład:Gdy wykryty zostanie błąd, zasady ponownej próby wstawia się automatycznie. |
| No.9 Nawet po przeczytaniu notatki przekazującej pracę i raportu z ukończenia, niewygodne fakty są pomijane |
Przykład:Obok raportu z ukończenia zawsze umieszcza się liczby policzone maszynowo. |
| No.10 Liczba policzona maszynowo zmienia się w inną, zanim trafi do raportu |
Przykład:Linijkę z liczbą oznacza się stałym prefiksem, a hook sprawdza, czy skopiowano ją dosłownie. |
| No.11 Przerwanie AI w trakcie pracy psuje wszystko, co robi potem |
Przykład:W trakcie pracy nie przerywa się — czeka się do naturalnego punktu. Przerwanie zostawia się mechanizmom. |
| No.12 Pod koniec sesji nie wiadomo, co trzeba przeczytać, a co można pominąć |
Przykład:Nie czyta się ani wyniku pracy, ani logu — liczy się tylko exit code. |
| No.13 Raz odrzucona propozycja wraca w kolejnej sesji |
Przykład:Odrzucone decyzje zbiera się w jednym dokumencie. |
| No.14 Mimo spisania zakazu w jednej linijce, jest on interpretowany zarówno zbyt szeroko, jak i zbyt wąsko |
Przykład:Przy każdym zakazie dopisuje się „powód“ obok wniosku. |
| No.15 Zakaz jest zapisany poprawnie, ale nie jest przestrzegany, i za każdym razem ktoś o niego pyta |
Przykład:Przy każdym zakazie dopisuje się „zakres“ i wypisuje wątpliwe przypadki graniczne. |
| No.16 Te same instrukcje wysłane do kilku sub-agentów wracają za każdym razem w innej formie |
Przykład:Na liście zadań dla sub-agenta podaje się wymagane pliki wejściowe. |
| No.17 Zakazy bez automatycznego testu piętrzą się, pozostając wyłącznie zapisanym tekstem |
Przykład:Przy każdym zakazie zaznacza się, czy istnieje odpowiadający mu automatyczny test. |
| No.18 Praca AI za każdym razem kończy się słowami „proszę otworzyć ekran i sprawdzić“ |
Przykład:O powodzeniu decyduje zapis w bazie danych, nie wygląd ekranu. |
| No.19 Za każdym razem, gdy AI mówi coś lekko obok tematu, to człowiek musi to wytłumaczyć i poprawić |
Przykład:Człowiek nie tłumaczy i nie poprawia — odpowiada hook i komunikat błędu testu. |
| No.20 Lista odrzuconych decyzji ciągle rośnie i w końcu nikt jej nie będzie czytał |
Przykład:Odrzucone propozycje trafiają do sekcji „nieprzyjęte pomysły“ na końcu. |
| No.21 Liczba poleceń „koniecznie uruchom“ w pliku instrukcji wcale nie maleje |
Przykład:Sprawdza się, czy komenda oznaczona „koniecznie uruchom“ istnieje też w mechanizmie. |
| No.22 Mimo spisania dokładnego sposobu wykonania, poprawka nie wraca zgodnie z nim |
Przykład:Nie dyktuje się procedury — ustala się tylko wymagane dane wejściowe przed startem. |
| No.23 Zgłaszanie błędu za każdym razem wymaga, żeby to człowiek spisywał kroki i objawy |
Przykład:Człowiek pisze tylko jedno zdanie o objawie — resztę zbiera się automatycznie. |
| No.24 Wpisywanie za każdym razem „najpierw przedstaw plan“ to osobny, powtarzający się wysiłek |
Przykład:Wystarczy jeden dokument projektowy — AI przejmuje jego format. |
| No.25 Linijki, które najbardziej zależy nam, żeby były przestrzegane, są zapisane najmocniej, ale nie wiadomo, czy to działa |
Przykład:Zamiast mierzyć skuteczność, liczy się linijki z podkreśleniem i ustala próg. |
| No.26 Wynik pracy sub-agenta wraca w innej formie, niż się zakładało |
Przykład:Warunki odbioru wyniku ustala się, zanim zleci się zadanie. |
| No.27 Znalezienie błędu wywołuje chęć zapytania: „czy w ogóle to przeczytałeś?“ |
Przykład:Zamiast przesłuchiwać, pyta się w formie „czy nie jest tak, że…?“. |
| No.28 Odpowiadanie „nie o to chodziło“ na otrzymaną odpowiedź niczego nie poprawia |
Przykład:Człowiek nie wytyka błędu — zaraz po zapisie pokazuje się zakaz razem z diffem. |
| No.29 AI mówi o zawartości pliku, którego nie otworzył, tak jakby go otworzył |
Przykład:Każe się wpisać ten sam identyfikator w odniesieniu i w implementacji, a test automatyczny sprawdza, czy ten identyfikator istnieje. |
| No.30 Ciągłe pytania AI typu „A czy B?“ zatrzymują pracę, bo trzeba czekać na decyzję |
Przykład:Nie odpowiada się od razu — kryterium wyboru ustala mechanizm. |
| No.31 AI przeprowadza review, ale nie wiadomo, czego nie sprawdza |
Przykład:Licząc z zewnątrz, znajduje się test automatyczny, który skanuje, ale nie ma dolnego progu liczby wyników. |
| No.32 Zrzuty ekranu się gromadzą, ale nie wiadomo, który z nich co właściwie potwierdza |
Przykład:Przed zrzutem każe się zapisać, co się sprawdza, i próbuje od najtańszego sposobu. |
| No.33 Mimo wprowadzenia kroku wymagającego zapisu, nie da się policzyć, ile uruchomień go pominęło |
Przykład:Przed zrzutem lub E2E każe się zapisać, co się sprawdza — bez tego nic się nie uruchamia. |
| No.34 Ten sam test uruchamia się ponownie, mimo że kod się nie zmienił, i trzeba na to czekać |
Przykład:Poprzedni log można odczytać ponownie, więc nie powtarza się tego samego uruchomienia. |
| No.35 Nic nie zostało zepsute, a mimo to pojawia się cała seria nieznanych błędów |
Przykład:Uruchomienie testów zakłada blokadę wzajemnego wykluczenia — bez niej test się nie uruchamia. |
| No.36 Raport „testy przechodzą“ nie wspomina o tym, co się w ogóle nie uruchomiło |
Przykład:Ciężkie testy pomija się domyślnie, a listę pominiętych obszarów wypisuje się za każdym razem. |
| No.37 Nie da się później sprawdzić, czy instrukcja opisująca sposób postępowania została faktycznie zastosowana |
Przykład:Nie wzmacnia się instrukcji — ślad wykonania procedury zostaje w wyniku pracy. |
| No.38 Wprowadzony wrapper w pewnym momencie jest zastępowany z powrotem zwykłą komendą |
Przykład:Nie wzmacnia się instrukcji — sprawdza się, czy powrót do zwykłej komendy ma powód. |
| No.39 Zadanie tego samego pytania wielokrotnie daje za każdym razem inną odpowiedź, a przy zbieraniu ich w jedno coś ginie |
Przykład:Przed połączeniem odpowiedzi wypisuje się liczbę wystąpień każdego rodzaju uwagi. |
| No.40 Nie wiadomo, czy linijka z zapisem „jeśli trzeba, zrób X“ w ogóle zadziałała |
Przykład:Nie pisze się „jeśli trzeba“ — bez tego kroku nie da się przejść dalej. |
| No.41 Odpowiedź na „przemyśl to jeszcze raz“ się zmienia, ale nie wiadomo, czy AI faktycznie się przekonało |
Przykład:Zamiast odsyłać, wskazuje się konkretnie, które założenie jest błędne. |
| No.42 Po zapisaniu „nie zgaduj“ AI zaczęło wracać, nie tworząc niczego |
Przykład:Oprócz zakazu podaje się furtkę — możliwość wpisania „nie dotyczy“. |
| No.43 Kontynuowanie rozmowy, która dobrze idzie, sprawia, że sprawdzanie jej wymaga coraz więcej pracy |
Przykład:Sesję kończy się na granicy zadania, kolejne zaczyna nowa sesja. |
| No.44 Wszystkie wyniki pracy są poprawne, ale narasta marnotrawstwo, którego w nich nie widać |
Przykład:Gdy wyniki pracy są gotowe, log sesji podsumowuje się jednorazowo. |
| No.45 Wiedza spisana z myślą o kolejnej osobie zaczyna odbiegać od rzeczywistości i się dezaktualizuje |
Przykład:Wiedzy nie zapisuje się w dokumencie — osadza się ją w komunikacie zatrzymania. |
| No.46 Szukanie przyczyny trwa dalej, a czytanie nie ustaje nawet po znalezieniu odpowiedzi |
Przykład:Liczy się odczyty, które niczego nie zmieniły, a warunek końca zapisuje się przed drążeniem. |
| No.47 Najtańszy pod względem ceny model staje się domyślnym wyborem bez sprawdzenia, czy pasuje do zastosowania |
Przykład:To samo zadanie przekazuje się tańszemu i droższemu modelowi, licząc tury i ilość tekstu. |
| No.48 Gdy coś nie działa, zamiast poprawić mechanizm, sięga się po lepszy model |
Przykład:To samo zadanie przekazuje się obu modelom, a miejsca porażki tańszego zamienia się w automatyczny test. |
| No.49 Zbadanie czegoś, co główna sesja mogłaby zrobić sama, na wszelki wypadek przekazuje się sub-agentowi |
Przykład:Gdy agent nadrzędny ma już kontekst, nie zleca się — przekazuje tylko brakujące czytanie. |
| No.50 Zadanie dzieli się na cztery na wszelki wypadek i uruchamia jednocześnie |
Przykład:Sub-agentowi zleca się tylko tyle, ile zmieści się w jednej odpowiedzi. O koszcie decyduje liczba wymian, nie liczba agentów. |
| No.53 W trakcie pracy z zewnątrz wtrąca się „spójrz jeszcze na to“ |
Przykład:Czeka się do przerwy i prosi się o węższy zakres, dodając „jeśli wystarczy, napisz to“. |
| No.52 Decyzję, którego modelu użyć, próbuje się podjąć przez bezpośrednie porównanie |
Przykład:Zanim zacznie się porównywać, liczy się, ile mechanizmów kosztowałoby to porównanie. |
| No.51 Weryfikację chce się zakończyć stwierdzeniem „nie było różnicy“ |
Przykład:Przed zakończeniem liczy się ponownie wyniki wyłączone z zestawienia i pozycje zerowe. |
| No.54 Pewnego dnia AI zaczęła pracować inaczej, choć nie zmieniłeś ani instrukcji, ani ustawień |
Przykład:Nie pisze się niczego sprzecznego z instrukcjami produktu — dopisuje się tylko to, czego one nie rozstrzygają. Zmianę sposobu pracy wprowadza się przełącznikiem ustawień. |
Lista artykułów
Od tego miejsca to już nie indeks odwrotny: to linki do artykułów, dla każdej serii, 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 校正の方法に、先に本編を当てる技術 —— AI が書いた方針に、その本自身の地雷が 10 個あった日
- 番外編 C-2 仕組みと人を分ける技術 —— 自動テストを置いたその手で、自動テストの外側で 2 度転んだ日
- 番外編 C-3 要素ごとに観点を変える技術 —— 一様に当てた点検が、要素をまたいだところで数を落とす
- 番外編 C-4 似た指示語を読み分ける技術 —— 1 字違いで、別の作業を頼んだことになる
- 番外編 C-5 作業の流れを見る技術 —— 終わりにしたつもりの日に、まだ起きていたこと
- 番外編 C-6 作業を進める技術 —— 選ぶ場面が、1 つも残らなかった日
- 番外編 C-7 読まずに止める技術 —— 決まったはずの判断が、1 分後に取り消されました
- 番外編 D-1 症状で読む —— 片付いた報告に、症状が混ざります
- 番外編 D-2 根拠で読む —— 突き合わせた報告に、症状が混ざります
- あとがき —— 本当の事実はどうでもいい話