เมื่อเช้าอ่านบทความของ Addy Osmani ชื่อ "Own the Outer Loop" จบแล้วมีประโยคหนึ่งค้างอยู่ในหัวทั้งวัน โมเดลเขียนบรรทัดนั้นได้ แต่คำตัดสินว่าจะปล่อยไหม เป็นของคน
ตกเย็นวันเดียวกัน ประโยคนั้นกลายเป็นไฟล์จริงชื่อ ACCOUNTABILITY.md วางอยู่ใน repo ของตัวเอง 5 ตัว นี่คือเรื่องของวันนั้น และหลักที่มันทิ้งไว้
พอ AI เขียนโค้ดแทนเรามากขึ้น ตัวที่ขาดไม่ใช่ความสามารถ แต่คือ คนที่เซ็นชื่อรับผิดชอบ และมันต้องเขียนลงไฟล์ ไม่ใช่เก็บไว้ในหัว
เรื่องจะเล่าไล่เป็นขั้น เริ่มจากปัญหาที่ตอนโชว์ไม่เคยตอบ ต่อด้วยหลักการว่าความรับผิดต้องเป็นของที่ commit ติดงาน แล้ววันที่หลักการกลายเป็นไฟล์จริง ปิดท้ายด้วยว่าหยิบไปใช้กับงานตัวเองยังไง
ช่วงที่ 1ปัญหาที่ไม่มีใครพูดตอนโชว์ตัวอย่าง
ตอนโชว์ AI เขียนโค้ด ทุกอย่างดูง่าย พิมพ์คำสั่ง โค้ดโผล่ ทดสอบผ่าน จบ แต่ของจริงมีคำถามที่การสาธิตไม่เคยตอบ โค้ดก้อนนี้ถ้าพังขึ้นมา ใครอธิบายได้ว่ามันเปลี่ยนอะไร ปลอดภัยเพราะอะไร และถ้าผิดจะทำยังไง
Osmani วางกรอบไว้คมมาก แบ่งงานเป็นในลูปกับนอกลูป งานในลูปคือสิ่งที่โมเดลทำได้ ค้นหา ลงมือ ทดสอบ รายงาน เขาเรียกว่า capability ส่วนงานนอกลูปมีอย่างเดียวคือ agency การตัดสินใจ ตรวจ อนุมัติ และเป็นเจ้าของผล สิ่งที่ข้ามเส้นจากในไปนอกคือ หลักฐาน ไม่ใช่โค้ด
ปัญหาคือช่องว่างมันโตเร็ว Osmani อ้างรายงาน Sonar ปี 2026 ว่าโค้ดที่ commit ไปแล้วราว 42% เป็นโค้ดที่ AI เขียนหรือช่วยเขียนเป็นหลัก การผลิตถูกลงเรื่อยๆ แต่ของที่หายากขึ้นคือการตรวจ การเข้าใจ และการดูแลระยะยาว ความเร็วในการสร้างแซงความเร็วในการคุมไปแล้ว
ช่วงที่ 2ความรับผิดต้องเป็นของที่ commit ติดงาน
หลายทีมคิดว่า "มี human review แล้ว" เท่ากับมีความรับผิดชอบ ยังไม่พอ review เป็นพฤติกรรม พอคนเปลี่ยน กะเปลี่ยน มันหายไปกับความจำ สิ่งที่ทำให้ ความรับผิดกลายเป็นของจริง คือมันต้องถูกเขียนลงไฟล์และ commit ติดไปกับงาน ให้คนที่มาทีหลังเปิด git log แล้วประกอบเรื่องกลับได้เอง ว่าเปลี่ยนอะไร ปลอดภัยเพราะอะไร ถ้าผิดทำยังไง โดยไม่ต้องตามตัวคนเขียน
Osmani ให้สามเสาไว้ เอามาเรียงเป็นภาษาช่างได้แบบนี้
- Quality คือด่านตรวจทั้งหมดก่อนปล่อยงาน มันผลิต หลักฐาน ออกมา
- Verdict คือคำตัดสินสุดท้ายก่อนงานข้ามเข้าระบบจริง เป็นของคน
- Answerability คือการรับประกันว่ามีคนอธิบายได้ว่าทำไมถึงตัดสินแบบนั้น
จุดที่คนพลาดบ่อยคือคิดว่าต้องกด AI ให้อิสระน้อยที่สุด จริงๆ ตรงข้าม ให้อิสระ พอดี ที่ระบบวิศวกรรมปกติยังหยุดมันได้ทัน type check, test, sandbox, audit log พวกนี้คือแรงต้านที่คอยรั้ง ตราบใดที่ AI ยังส่งสัญญาณเหล่านี้ออกมา งานวิศวกรรมธรรมดาก็คุมมันได้ ราวกันตกไม่ได้แปลว่ากำแพงตัน มันแค่กันไม่ให้ตก
ช่วงที่ 3วันที่หลักการกลายเป็นไฟล์
หลักการสวยแค่ไหนก็ไร้ค่าถ้าไม่ลงมือ เลยลองทำจริงในวันเดียว หน้าตาของ contract ที่ลงไปในแต่ละ repo มี สี่บรรทัดหลัก
- ผู้รับผิด (คน) ระบุชื่อใน PR คนที่แบกผลถ้าพัง AI เลือก route merge ในกติกาได้ แต่รับผิดแทนไม่ได้
- หลักฐาน บรรทัด Acceptance ที่รันจริงเห็นผลจริง
คำสั่ง → ผลที่คาดว่าจะเห็นไม่ใช่คำว่า "ใช้ได้แล้ว" - Checklist ที่ยอมรับตอนรับงาน invariant ของ repo นั้น เช่น ไม่มี secret หลุด เพิ่มของบน branch ตัวเองเท่านั้น
- ถ้าผิด rollback ยังไง พร้อมขอบเขตความเสียหาย
ที่สำคัญคือมันไม่ได้ก๊อปเหมือนกันทุก repo แต่ปรับกติกาตามหน้างาน repo ที่ยุ่งกับเงินจริงเขียนชัดว่า path เงิน เท่ากับคนอนุมัติเท่านั้น repo ที่ deploy ขึ้นเว็บลูกค้าเขียนว่าห้ามมีข้อมูลส่วนตัวหลุดในไฟล์ และต้องผ่าน staging ก่อน ตัวสัญญาเดียวกัน แต่กติกาคนละชุด
แล้วเอาไปฝังในเครื่องมือที่ใช้จริง ไม่ใช่แค่ไฟล์ลอยๆ ทุกครั้งที่เปิด PR ตอนนี้มีช่อง Accountability ให้กรอกอัตโนมัติ ระบุผู้รับผิด หลักฐานที่รัน rollback ทำให้ของพวกนี้ commit ติดงานไปเอง แทนที่จะอยู่ในหัวคนเขียนคนเดียว
ช่วงที่ 4หยิบไปใช้กับงานตัวเอง
ถ้ากำลังให้ AI ช่วยเขียนโค้ดในงานตัวเอง สามอย่างที่หยิบไปใช้ได้เลย
- แยกในลูปกับนอกลูป ปล่อยให้ AI ทำงานในลูป (ค้น ลงมือ ทดสอบ) แต่คำตัดสินก่อนขึ้นระบบจริงเป็นของคน และตัวที่ข้ามเส้นมาคือหลักฐาน ไม่ใช่คำรับรองลอยๆ
- ทำ answerability เป็นไฟล์ ไม่ใช่แค่ "เดี๋ยวรีวิวเอง" เขียน contract สั้นๆ ว่าใครรับผิด หลักฐานอะไร ถ้าพลาด rollback ยังไง แล้ว commit ติดไปกับงาน
- ระวังหนี้ความเข้าใจ ยิ่งปล่อยให้ AI คิดแทนนาน ช่องว่างระหว่างโค้ดที่ได้กับความเข้าใจของเรายิ่งกว้าง Osmani อ้างงานทดลองของ Anthropic ว่าคนที่ใช้ AI ทำคะแนนควิซความเข้าใจต่ำกว่าคนที่ไม่ใช้ ทางแก้คือถือความเข้าใจเป็น จุดตัดสินใจ ไม่ใช่แค่ขั้นส่งงาน
เริ่มจากอันเดียวพอ PR ตัวถัดไป เพิ่มสี่บรรทัด ใครรับผิด หลักฐานที่รันจริง checklist rollback แค่นั้นก็เปลี่ยนจาก "AI เขียนให้" เป็น "มีคนเซ็นชื่ออยู่หลังงาน"
เครื่องจักรผลิตของได้เร็วขึ้นเรื่อยๆ คำถามเลยขยับจาก "เราสร้างมันได้ไหม" ไปเป็น "มันควรมีอยู่ไหม และเราตอบแทนมันได้หรือเปล่า" ทักษะให้พลัง แต่ความรับผิดต่างหากที่เปลี่ยนพลังเป็นความไว้ใจ AI เขียนบรรทัดนั้นได้ แต่ก่อนมันถึงมือคนใช้ ต้องมีใครสักคนอธิบายได้ว่าทำไมมันควรมีอยู่ ปลอดภัยพอไหม และถ้าผิดจะทำยังไง นั่นแหละคืองานที่เหลือให้คน
ที่มาและอ้างอิง
- Addy Osmani, "Own the Outer Loop" (addyo.substack.com, 9 ก.ค. 2026) กรอบ inner/outer loop และสถิติที่อ้างในบทความ ตัวเลข Sonar 42% กับงานทดลอง Anthropic เป็นตัวเลขที่ Osmani อ้างต่อ
- งานจริงของผู้เขียน 10 ก.ค. 2026 วาง
ACCOUNTABILITY.mdลง 5 repo และเพิ่มช่อง Accountability ใน PR template