สิ่งที่กำลังเกิดขึ้น → ต้องทำอะไร
ค้นหาตามอาการแทนที่จะค้นตามชื่อเรื่อง ลิงก์ใต้ "ต้องทำอะไร" จะพาไปยังหัวข้อที่เขียนวิธีแก้นั้นไว้ สารบัญของบทความทั้งหมดอยู่ด้านล่างของหน้านี้
ตารางนี้อ้างอิง Claude Code (เอเจนต์เขียนโค้ดของ Anthropic) โดย hook, CLAUDE.md, subagent และ auto memory คือชื่อฟีเจอร์ของมัน
| สิ่งที่กำลังเกิดขึ้น | ต้องทำอะไร |
|---|---|
| ทุกครั้งที่ AI รันเทสต์ เอาต์พุตหลายหมื่นบรรทัดจะไหลเข้ามาใน context |
รวมการรันเทสต์ทั้งหมดให้ผ่าน wrapper script ตัวเดียว เขียนเอาต์พุตทั้งหมดลงไฟล์ log แล้วส่งกลับให้ AI แค่สรุปรายการที่ล้มเหลวเท่านั้น. |
| ยิ่ง AI บันทึกความรู้ที่ได้เรียนรู้ไว้มากเท่าไหร่ ทุกเซสชันในอนาคตก็ยิ่งต้องอ่านมากขึ้นเท่านั้น |
ใช้ PreToolUse hook ที่ทำงานก่อนเขียนความจำทันที เพื่อให้ AI อ่าน checklist ก่อน แล้วเหลือไว้ในไฟล์คำสั่ง (CLAUDE.md) แค่บรรทัดเดียวว่า "อ่านก่อนเขียน". |
| เทสต์ผ่านหมด แต่ไม่รู้ว่ามันปกป้องอะไรจริง ๆ หรือเปล่า |
เขียนนโยบายเรื่อง mutation testing (วิธีจงใจทำให้โค้ดพังเพื่อดูว่าเทสต์จับได้หรือไม่) เป็นเอกสารหน้าเดียว แล้วให้ AI อ่านทุกครั้งที่ขอให้ตรวจสอบเทสต์. |
| บางครั้ง AI ก็ใช้ skill ที่ลงทะเบียนไว้ บางครั้งก็ไม่ใช้ |
เก็บคำสั่งไว้เป็นสคริปต์ธรรมดา บล็อกการเรียกใช้ที่ผิดด้วย PreToolUse hook แล้วชี้ให้ AI ไปอ่านเอกสารที่ควรอ่าน. |
| เมื่อมอบงานให้ sub-agent แล้ว จะมองไม่เห็นว่าเกิดอะไรขึ้นจนกว่างานจะเสร็จ |
กำหนดใน YAML ว่างานแบบไหนมอบให้ sub-agent ได้ และไฟล์อินพุตใดต้องมีอยู่ก่อนเริ่มงาน แล้วตรวจสอบด้วย hook ก่อนเริ่ม. |
| ยิ่งเพิ่มกฎในไฟล์คำสั่งมากเท่าไหร่ กฎที่เพิ่มไว้ก่อนหน้าก็ยิ่งไม่ถูกปฏิบัติตาม |
เขียนกฎ "ห้ามทำ X" แต่ละข้อใหม่ทีละข้อ ให้กลายเป็น automated test (Minitest) ที่ตรวจจับการละเมิดได้. |
| ความจำที่เซสชันคู่ขนานใช้ร่วมกันเริ่มยุ่งเหยิง แม้จะให้อ่านนโยบายแล้วก็ไม่ได้ผล |
ย้ายไฟล์นโยบายเดียวกันไปไว้ใน PostToolUse hook แล้วแสดงคู่กับ diff ทันทีหลังบันทึก โดยไม่เปลี่ยนเนื้อหา เปลี่ยนแค่จังหวะเวลาเท่านั้น. |
| แม้จะเขียนวิธีรับมือกับความล้มเหลวไว้แล้ว AI ก็ยังทำผิดซ้ำแบบเดิมในครั้งถัดไป |
สรุปนโยบายตอน retry ไว้ในไฟล์สั้น ๆ ไม่กี่บรรทัด แล้วให้ hook ที่ตรวจจับความล้มเหลวแทรกเข้าไปโดยอัตโนมัติ. |
| แม้จะอ่านข้อความส่งต่องานและรายงานความสำเร็จแล้ว ส่วนที่ไม่สะดวกใจก็ยังหายไป |
วางตัวเลขที่ได้จากการรันคำสั่งเชิงกลไก เช่น git diff --stat ไว้ข้างรายงานความสำเร็จทุกครั้ง. |
| ตัวเลขที่เครื่องนับได้เปลี่ยนเป็นตัวเลขอื่นก่อนจะไปถึงรายงาน |
ใส่ prefix ตายตัวไว้หน้าบรรทัดตัวเลข แล้วให้ hook ตรวจสอบว่าถูกคัดลอกมาตรงตัวหรือไม่. |
| การขัดจังหวะ AI ระหว่างทำงานทำให้การทำงานหลังจากนั้นพังไปหมด |
แทนที่จะให้คนขัดจังหวะระหว่างทำงาน ให้ PostToolUse hook ที่ส่งนโยบายกลับทันทีหลังบันทึก และ hook ที่ตรวจจับความล้มเหลวแล้วส่งงานกลับ เป็นผู้เข้าแทรกแซง ส่วนคนรอจนถึงจุดแบ่งงาน. |
| ตอนจบเซสชัน ยังไม่มีการตัดสินใจว่าอะไรควรอ่านและอะไรไม่ต้องอ่าน |
ไม่ต้องอ่านทั้งผลงานและ log การทำงาน ให้ตัดสินผ่านหรือไม่ผ่านจาก exit code ของเทสต์หรือ linter เท่านั้น. |
| ข้อเสนอที่เคยปฏิเสธไปแล้วกลับมาอีกครั้งในเซสชันถัดไป |
รวมการตัดสินใจที่ปฏิเสธไปแล้วทั้งหมดไว้ในเอกสารเดียว โดยใช้รูปแบบตายตัว. |
| แม้จะเขียนข้อห้ามไว้แค่บรรทัดเดียว ก็ยังถูกตีความทั้งกว้างเกินไปและแคบเกินไป |
ในเอกสารฉบับเดียวที่รวบรวมการตัดสินใจที่ปฏิเสธไปแล้ว (เช่น non_goals.md) ให้เพิ่มหัวข้อ "เหตุผล" คู่กับข้อสรุปในข้อห้ามแต่ละข้อ. |
| ข้อห้ามเขียนไว้ถูกต้องแล้วแต่ไม่ถูกปฏิบัติตาม แล้วก็มีคนมาถามซ้ำทุกครั้ง |
ในเอกสารการปฏิเสธ ให้เพิ่มหัวข้อ "ขอบเขตการบังคับใช้" ในข้อห้ามแต่ละข้อ แล้วเขียนกรณีคาบเส้นที่ทำให้ลังเลไว้ทีละบรรทัด. |
| แจกคำสั่งเดียวกันให้ sub-agent หลายตัว แต่ผลลัพธ์ที่ได้กลับมามีรูปแบบต่างกันไปในแต่ละตัว |
ระบุไฟล์อินพุตที่ต้องเตรียมไว้ก่อนเริ่มงานให้ชัดเจนในรายการงานที่มอบให้ sub-agent ได้. |
| ข้อห้ามที่ไม่มี automated test คอยตรวจ ก็ยังคงเป็นแค่ข้อความที่เขียนทิ้งไว้เพิ่มขึ้นเรื่อย ๆ |
ในรายการของเอกสารการปฏิเสธ ให้เพิ่มหัวข้อ "การตรวจสอบเชิงกลไก" แล้วระบุทีละข้อว่ามี automated test (Minitest) รองรับหรือไม่. |
| งานของ AI จบลงด้วยคำว่า "กรุณาเปิดหน้าจอตรวจสอบ" ทุกครั้ง |
เตรียม smoke test ด้วย Playwright ไว้หนึ่งชุด แล้วตัดสินผ่านหรือไม่ผ่านจาก record ที่อยู่ใน DB แทนที่จะดูหน้าตาของหน้าจอ. |
| ทุกครั้งที่ AI พูดอะไรเพี้ยนไปนิดหน่อย เราต้องเป็นคนอธิบายและแก้ไขเอง |
แทนที่จะให้คนอธิบายและแก้ไขความคลาดเคลื่อนเอง ให้เขียนข้อชี้แนะไว้ใน stderr ของ hook (exit 2) และในข้อความล้มเหลวของ automated test เพื่อให้เส้นทางที่ไปถึง AI เป็นทางนั้น. |
| รายการการตัดสินใจที่ปฏิเสธไปเพิ่มขึ้นเรื่อย ๆ จนดูเหมือนสักวันจะไม่มีใครอ่านอีก |
เพิ่มหัวข้อ "ข้อเสนอที่ไม่รับมาใช้" ไว้ท้ายเอกสารการปฏิเสธ แล้วบันทึกข้อเสนอที่ถูกปฏิเสธไว้ที่นั่น. |
| บรรทัด "ต้องรันทุกครั้ง" ในไฟล์คำสั่งไม่เคยลดจำนวนลงเลย |
ใช้ automated test ตรวจสอบไขว้ว่าคำสั่งที่ไฟล์คำสั่งเขียนว่า "ต้องรันทุกครั้ง" มีอยู่ใน pre-commit hook ด้วยหรือไม่. |
| แม้จะเขียนวิธีทำไว้ให้ละเอียดแล้ว การแก้ไขที่ได้กลับมาก็ไม่ได้เป็นไปตามนั้น |
แทนที่จะสั่งขั้นตอนวิธีทำ ให้กำหนดไฟล์อินพุตที่ต้องมีอยู่ก่อนเริ่ม sub-agent แยกตามแต่ละกรณีใช้งานแทน. |
| ทุกครั้งที่แจ้งบั๊ก ต้องเขียนขั้นตอนและอาการเองทุกครั้ง |
ทำแบบฟอร์มแจ้งบั๊ก ให้คนพิมพ์แค่ประโยคเดียวบอกอาการ ส่วน URL ประวัติการใช้งาน และข้อมูลเบราว์เซอร์ให้ JavaScript เก็บอัตโนมัติ. |
| การพิมพ์ "ขอแผนงานก่อน" ทุกครั้งกลายเป็นภาระที่ต้องทำซ้ำ ๆ |
ไม่ต้องสร้างอะไรใหม่ แค่วางเอกสารออกแบบไว้หนึ่งฉบับ AI ก็จะอ่านเอกสารที่มีอยู่และทำตามรูปแบบเดียวกัน. |
| บรรทัดที่อยากให้ปฏิบัติตามมากที่สุดกลับเขียนเน้นย้ำแรงที่สุด แต่ก็ไม่รู้ว่าได้ผลจริงหรือเปล่า |
เลิกวัดผลของการเน้นย้ำ แล้วนับจำนวนบรรทัดที่ใช้คำเน้นในไฟล์คำสั่งแทน พร้อมวาง automated test (ratchet) ที่จะล้มเหลวเมื่อจำนวนเกินเกณฑ์. |
| ผลงานของ sub-agent กลับมาในรูปแบบที่ต่างจากที่คาดไว้ |
กำหนดเงื่อนไขการรับผลงานของแต่ละกรณีใช้งาน sub-agent เช่น ชื่อไฟล์ รูปแบบ และรายการที่จำเป็น ไว้ในเอกสารฉบับเดียว. |
| เมื่อพบข้อผิดพลาด อดใจไม่ได้ที่จะถามว่า "อ่านจริง ๆ หรือเปล่า" |
แทนที่จะถามซักไซ้ ให้กำหนดประโยคที่สองของคำขอทุกครั้งเป็นแม่แบบคำถามว่า "...ไม่ใช่หรือ". |
| แม้จะตอบกลับคำตอบที่ได้ว่า "ไม่ใช่แบบนี้" ผลลัพธ์ก็ไม่ดีขึ้น |
แทนที่จะชี้ข้อผิดพลาดเอง ให้แสดงข้อห้ามที่ไม่มีทางเลือกอื่นผ่าน PostToolUse hook คู่กับ diff ทันทีหลังบันทึก. |
| AI พูดถึงเนื้อหาของไฟล์ที่ยังไม่ได้เปิด ราวกับว่าเปิดอ่านไปแล้ว |
ให้ AI เขียน marker ที่สอดคล้องกันทั้งในเอกสารที่อ้างอิงและในโค้ด แล้วตรวจสอบด้วย automated test ว่า marker นั้นมีอยู่จริง. |
| AI ถามซ้ำว่า "เลือก A หรือ B" จนมือหยุดชะงักรอการตัดสินใจ |
เลิกตอบทันทีในจุดนั้น แล้วให้การตัดสินตัวเลือกเกิดขึ้นฝั่ง automated test หรือ hook แทน. |
| ให้ AI รีวิวอยู่ แต่ไม่รู้ว่ามันไม่ได้ดูอะไรบ้าง |
ใช้ automated test จากภายนอกที่นับจำนวน เพื่อตรวจจับ automated test ที่สแกนไฟล์แต่ไม่มีเงื่อนไขขั้นต่ำของจำนวน (เช่น assert_operator ... :>=). |
| ภาพหน้าจอที่ถ่ายไว้เพิ่มขึ้นเรื่อย ๆ แต่ไม่รู้ว่าภาพไหนยืนยันอะไร |
ก่อนตรวจสอบหน้าจอ ให้ตอบคำถามสองข้อคือ "กำลังยืนยันอะไร" และ "ทำไมวิธีที่ถูกกว่าถึงใช้ไม่ได้" พร้อมวางแนวทางหน้าเดียวให้ลองวิธีที่ถูกก่อน ตามลำดับ unit test → integration test → E2E. |
| วางขั้นตอนให้เขียนบันทึกไว้แล้ว แต่นับไม่ได้ว่ามีกี่ครั้งที่รันโดยไม่ได้เขียน |
ก่อนถ่ายภาพหน้าจอหรือรัน E2E ให้เขียนไฟล์ประกาศว่า "จะยืนยันอะไร" (เช่น tmp/visual_verification.md) แล้วกำหนดให้การมีอยู่ของไฟล์นั้นเป็นเงื่อนไขของ PreToolUse hook เพื่อไม่ให้การถ่ายภาพหน้าจอหรือ E2E เริ่มทำงานได้ถ้าไม่มีไฟล์นั้น. |
| โค้ดไม่ได้เปลี่ยนแปลง แต่เทสต์ชุดเดิมก็ยังรันซ้ำ ทำให้ต้องรอเสียเวลาไปด้วย |
เพิ่ม option --last ให้ wrapper script ของเทสต์ เพื่อแสดง log ครั้งก่อนซ้ำแทนการรันใหม่. |
| ไม่ได้ทำอะไรพังเลย แต่กลับมี error ที่ไม่เคยเห็นมาก่อนเรียงเต็มไปหมด |
ให้ wrapper script ของเทสต์ล็อกแบบ exclusive (ใช้ความเป็น atomic ของ mkdir) และไม่รันถ้าล็อกไม่สำเร็จ. |
| รายงาน "เทสต์ผ่านแล้ว" ไม่ได้เขียนบอกว่าส่วนไหนที่ไม่ได้รัน |
ติด tag ชื่อโดเมนให้ E2E ที่หนักแล้ว skip ไว้เป็นค่าเริ่มต้น พร้อมพิมพ์รายการโดเมนที่ไม่ได้รันออกมาทุกครั้ง. |
| ไม่มีทางรู้ในภายหลังว่าคำสั่งที่ระบุวิธีดำเนินงานถูกปฏิบัติตามจริงหรือไม่ |
เมื่ออยากให้ปฏิบัติตามขั้นตอน อย่าเพิ่มความเข้มของคำสั่ง แต่เปลี่ยนให้ร่องรอยของการทำตามขั้นตอนนั้นปรากฏอยู่ในผลงาน (เช่น ให้พิมพ์หนึ่งบรรทัดต่อไฟล์ที่เปิด). |
| wrapper ที่วางไว้ถูกเปลี่ยนกลับไปใช้คำสั่งดิบระหว่างทาง |
เมื่ออยากให้ใช้ wrapper อย่าเพิ่มความเข้มของคำสั่ง แต่ตรวจสอบว่ายังมีเหตุผลให้ต้องกลับไปใช้คำสั่งดิบหรือไม่ นั่นหมายความว่า wrapper ยังขาดความสามารถบางอย่างอยู่. |
| ถามคำถามเดิมซ้ำหลายครั้งก็ได้คำตอบต่างกันทุกครั้ง พอสรุปรวมก็มีบางอย่างหายไป |
ก่อนรวมคำตอบหลายชุดให้เป็นหนึ่งเดียว ให้พิมพ์จำนวนครั้งที่แต่ละประเภทของข้อสังเกตปรากฏ ว่ากี่ในกี่คนที่ยกขึ้นมา. |
| ไม่มีทางรู้ว่าบรรทัดที่เขียนว่า "ถ้าจำเป็นให้ทำ X" เคยทำงานจริงหรือไม่ |
อย่าเขียนคำสั่งแบบมีเงื่อนไขอย่าง "ถ้าจำเป็นให้ทำ X" แต่ให้บังคับขั้นตอนนั้นด้วย hook ที่ไม่ให้ไปต่อจนกว่าจะผ่านขั้นตอนนั้น. |
| การตอบว่า "ลองคิดใหม่อีกที" ทำให้คำตอบเปลี่ยนไป แต่ไม่รู้ว่า AI เข้าใจจริงหรือแค่เปลี่ยนตาม |
แทนที่จะส่งกลับไปด้วย "ลองคิดใหม่อีกที" ให้ชี้เจาะจงว่าสมมติฐานข้อไหนผิด. |
| พอเขียนว่า "ห้ามเดา" AI ก็เริ่มกลับมาโดยไม่สร้างอะไรเลย |
อย่าให้แค่ข้อห้ามอย่างเดียว ให้ระบุทางออกสำรองไปด้วย เช่น "ถ้าไม่มีกรณีที่ตรงกัน ให้พิมพ์ว่า 'ไม่มีกรณีที่เกี่ยวข้อง'". |
| ยิ่งดำเนินบทสนทนาที่ไปได้ด้วยดีต่อไปนานเท่าไหร่ ความพยายามในการตรวจสอบก็ยิ่งเพิ่มขึ้น |
จบเซสชันทุกครั้งที่ถึงจุดแบ่งงาน แล้วเริ่มงานถัดไปในเซสชันใหม่. |
| ผลงานทุกชิ้นถูกต้องหมด แต่ความสูญเปล่าที่ไม่ปรากฏในผลงานกลับสะสมมากขึ้นเรื่อย ๆ |
เมื่อผลงานครบแล้ว ให้รันสคริปต์นับรวมฝั่ง log การทำงาน (transcript) หนึ่งครั้ง. |
| ความรู้ที่จดไว้ให้คนถัดไปค่อย ๆ เพี้ยนไปจากความจริงและล้าสมัย |
อย่าจดความรู้ไว้ในเอกสาร แต่ฝังไว้ในข้อความล้มเหลวของ automated test หรือข้อความหยุดของ hook เพื่อให้แสดงออกมาตอนที่จำเป็นจริง ๆ. |
| ขุดหาสาเหตุต่อไปเรื่อย ๆ และยังคงอ่านต่อแม้จะได้คำตอบแล้ว |
นับจาก log การทำงานว่ามีการอ่านต่อเนื่องกี่ครั้งโดยไม่ได้เปลี่ยนแปลงอะไรเลย แล้วเขียนเงื่อนไขจบไว้หนึ่งบรรทัดก่อนเริ่มขุด. |
| ตั้งโมเดลที่ราคาถูกที่สุดเป็นค่าเริ่มต้นโดยไม่ได้วัดว่าเหมาะกับงานหรือไม่ |
ให้งานเดียวกันแก่ทั้งโมเดลราคาถูกและโมเดลราคาแพง แล้วตัดสินใจหลังจากนับจำนวนรอบจนเสร็จ และปริมาณที่อ่านใหม่ ใช้ซ้ำ (cache read) และเขียน แยกกันเท่านั้น. |
| เมื่อสิ่งใดไม่ได้ผล ทางแก้ที่เลือกคือเปลี่ยนไปใช้โมเดลที่ใหญ่กว่า แทนที่จะแก้กลไก |
ให้งานเดียวกันแก่ทั้งโมเดลราคาแพงและโมเดลราคาถูก แล้วเปลี่ยนจุดที่มีแต่โมเดลราคาถูกที่ล้มเหลวให้เป็นการตรวจสอบถาวร. |
| งานค้นคว้าที่ตัวหลักทำเองได้จบอยู่แล้ว กลับถูกส่งต่อให้ sub-agent เผื่อไว้ |
ก่อนมอบงาน ให้ดูก่อนว่า agent แม่มีบริบทนั้นอยู่แล้วหรือไม่ ถ้ามีให้ทำต่อใน agent แม่ มอบให้ sub-agent เฉพาะส่วนอ่านจำนวนมากที่ agent แม่ยังไม่มีเท่านั้น. |
| แบ่งงานเป็นสี่ส่วนแล้วรันพร้อมกันทันทีโดยไม่ได้คิดอะไรมาก |
มอบงานให้ sub-agent หนึ่งตัวแค่เท่าที่ส่งกลับได้ในการตอบครั้งเดียว สิ่งที่กำหนดต้นทุนไม่ใช่จำนวนตัว แต่คือจำนวนรอบที่ sub-agent แต่ละตัวที่แบ่งออกไปต้องไปกลับกับ agent แม่. |
| "ดูตรงนี้ด้วย" ถูกแทรกเข้ามาจากภายนอกระหว่างทำงาน |
รอจนถึงจุดแบ่งงานก่อน แล้วค่อยใส่คำขอเพิ่มเติมเข้าไปโดยจำกัดขอบเขตให้แคบลง เมื่อถาม AI เองเรื่องส่วนที่ขาด ต้องเพิ่มเสมอว่า "ถ้าเพียงพอแล้ว ให้บอกว่าเพียงพอ" เพื่อเปิดทางออก (escape hatch) ให้มันไม่ต้องคิดข้อบกพร่องขึ้นมาเอง. |
| กำลังตัดสินใจว่าจะใช้โมเดลไหนโดยการเปรียบเทียบกันโดยตรง |
ก่อนเริ่มเปรียบเทียบโมเดล ให้นับก่อนว่าการเปรียบเทียบนั้นใช้แรงเท่ากับ hook หรือ automated test กี่ตัว ถ้ากลไกที่เขียนออกมาได้มีมากกว่าจำนวนนั้น ให้วางกลไกเหล่านั้นก่อนแล้วค่อยเปรียบเทียบ. |
| ใช้คำว่า "ไม่มีความแตกต่าง" เป็นเหตุผลในการปิดการตรวจสอบ |
ก่อนปิดงานด้วยคำว่า "ไม่มีความแตกต่าง" ให้นับสองอย่าง ถ้ามีผลลัพธ์ที่ถูกตัดออกจากการรวม (เช่น sub-agent ที่ล้มเหลว) ให้นำกลับมานับใหม่ และถ้ามากกว่าครึ่งของรายการได้ 0 ในทุกเงื่อนไข ให้เปลี่ยนวิธีตั้งโจทย์แล้ววัดใหม่. |
สารบัญบทความทั้งหมด
เรียงตามซีรีส์ ตั้งแต่บทนำจนถึงตอนจบ
はじめに —— 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 分前に開いたページに、答えが書いてありました
- あとがき —— 本当の事実はどうでもいい話