Anthropic 的 AI-native SDLC 如何改變軟件開發六個階段？

โดย Nokka (นก-กา) | สรุปและวิเคราะห์จาก The AI-native SDLC playbook ของ Anthropic | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ทีมส่วนใหญ่ที่เริ่มใช้ AI เขียนโค้ด เจออาการเดียวกัน คือช่วงแรกเร็วขึ้นมาก แต่พอผ่านไปสองสามสัปดาห์ ความเร็วโดยรวมกลับมาเท่าเดิม

สาเหตุไม่ใช่โมเดลไม่เก่ง แต่เป็นเพราะขั้นตอนอื่นรอบ ๆ การเขียนโค้ดยังทำงานด้วยความเร็วเดิม

Anthropic เรียกปัญหานี้ว่าโค้ดไม่ใช่คอขวดอีกต่อไป และเผยแพร่เอกสารชื่อ The AI-native SDLC playbook เมื่อ 21 ส.ค. 2026 เพื่ออธิบายว่าจะแก้อะไรและแก้อย่างไร [1]

บทนี้ผมจะสรุปเอกสารนั้นแบบอ่านเข้าใจได้ในครั้งเดียว และเติมมุมที่ผมคิดว่าคนอ่านไทยต้องคิดเองก่อนทำตาม

ปัญหาที่เอกสารนี้ชี้ และทำไมมันเกิดกับทุกทีม

วงจรพัฒนา software แบบเดิม (SDLC) แบ่งงานเป็นหกระยะ คือ วางแผน ออกแบบ สร้าง ทดสอบ ส่งมอบ และดูแลระบบ

แต่ละระยะมีเจ้าของ มีเอกสารส่งต่อ และมีจุดเซ็นรับ

โครงสร้างนี้ถูกออกแบบมาในยุคที่การเขียนโค้ดคือขั้นที่แพงและกินเวลาที่สุด จึงต้องมีพิธีกรรมรอบข้างเพื่อให้แน่ใจว่าทีมเดินไปทางเดียวกัน

เมื่อ agent เขียนโค้ดได้เร็วขึ้นหลายเท่า ระยะที่เคยสมเหตุสมผลกลับกลายเป็นคอขวด

เอกสารระบุผลที่ตามมาสามข้อ [1]

คอขวดย้ายไปอยู่ที่ระยะซ้ายและขวาของการสร้าง คือวางแผน ตรวจสอบ และส่งมอบ ซึ่งยังวิ่งด้วยความเร็วคน
มาตรการควบคุมไม่ตรงกับความจริงอีกต่อไป การตรวจทีละบรรทัดเคยสมเหตุสมผลเมื่อคนเขียน แต่ใช้ไม่ได้เมื่อ agent เขียน diff ส่วนใหญ่
ต้นทุนด้าน governance สูงขึ้น เพราะข้อยกเว้นยังต้องผ่านการประชุมที่จัดกันสัปดาห์ละครั้งหรือเดือนละครั้ง

ตัวอย่างที่เอกสารยกคือทีมความปลอดภัย ซึ่งถูกจัดกำลังคนให้รับงานได้เท่าที่คนผลิตไหว พอ agent ผลิตโค้ดเพิ่ม ทางเลือกมีสองทางคือคิวตรวจยาวขึ้น หรือโค้ดถูกปล่อยโดยตรวจไม่พอ

องค์กรที่มีการกำกับดูแลรับทั้งสองทางไม่ได้ จึงต้องยกเครื่องกระบวนการทั้งเส้น ไม่ใช่แค่เร่งการเขียนโค้ด

AI-native SDLC คืออะไรในนิยามของ Anthropic

นิยามสั้น ๆ คือการใช้เป้าหมายการควบคุมแบบเดิม แต่เปลี่ยนวิธีบังคับใช้

จากเส้นตรงกลายเป็นวงจร และมี AI อยู่ในทุกจุดของวงจร

คำที่คนใช้เรียกสิ่งเดียวกันนี้มีหลายคำ เช่น agentic SDLC, AI SDLC หรือ agentic software development

หัวใจที่ผมคิดว่าสำคัญที่สุดในเอกสารนี้ ไม่ใช่รายชื่อเครื่องมือ แต่คือข้อความบรรทัดนี้

ทุกระยะจบด้วยการ commit สิ่งที่ส่งต่อได้ และระยะถัดไปเริ่มด้วยการอ่านสิ่งนั้น

สิ่งส่งต่อในระยะแรก ๆ เป็นไฟล์ markdown เพราะทั้งเจ้าของผลิตภัณฑ์และ agent อ่านเข้าใจได้จากไฟล์เดียวกัน

พอเข้าสู่ระยะสร้าง สิ่งส่งต่อกลายเป็นโค้ดและบันทึกของมัน

และเพราะทุกอย่างอยู่ใน git ประวัติการ commit จึงกลายเป็นเส้นทางการตรวจสอบย้อนหลัง ว่าใครขออะไร agent ทำอะไร และใครอนุมัติ

ทั้งหกระยะ เปลี่ยนอะไรบ้าง

ผมจะไล่ทีละระยะในรูปแบบเดียวกัน คือ เดิมเป็นอย่างไร ตอนนี้เป็นอย่างไร มีหลักฐานอะไร และวัดผลด้วยอะไร

ระยะที่ 1 วางแผน: จาก backlog เป็น intent.md

แบบเดิม ไอเดียต้องผ่าน backlog, user story, story point และการประชุม refine หลายรอบ กว่าจะถึงมือวิศวกร เนื้อหาอาจเพี้ยนไปจากที่เจ้าของความคิดหมายไว้

แบบใหม่ เจ้าของไอเดียคุยกับ Claude ในภาษาของตัวเอง แล้วให้มันร่างเป็นไฟล์ intent.md ที่เก็บว่า ต้องการอะไร ทำไม และมีข้อจำกัดอะไร

จากนั้นเจ้าของไอเดียแก้ไขสิ่งที่โมเดลเข้าใจผิด แล้ว commit เข้าที่เก็บกลาง

intent.md ในแม่แบบของเอกสารมีห้าหัวข้อตายตัว ซึ่งผมคิดว่าเป็นส่วนที่คนมักข้าม

Problem คือปัญหาจริงที่เจอ ไม่ใช่วิธีแก้ที่อยากได้
Proposed outcome คือผลลัพธ์ที่วัดได้ ถ้าทำสำเร็จจะเห็นอะไรเปลี่ยน
Affected users and systems คือใครและระบบไหนได้รับผล
Constraints คือข้อจำกัดที่ห้ามละเมิด เช่น งบ เวลา กฎหมาย หรือข้อตกลงกับลูกค้า
Open questions คือคำถามที่ยังไม่มีคำตอบ และต้องตอบก่อนเริ่มเขียนโค้ด

หัวข้อสุดท้ายสำคัญที่สุด เพราะมันบังคับให้คนยอมรับว่า "ยังไม่รู้" ตั้งแต่ต้น แทนที่จะปล่อยให้ agent เติมช่องว่างด้วยการเดา

เริ่มลงมือระยะที่ 1: สิ่งที่ต้องมีและขั้นตอนจริง

สิ่งที่ต้องมีก่อนเริ่ม ไม่มีข้อบังคับ แต่เอกสารระบุว่าต้องเตรียมสามอย่าง

คนที่ไม่ใช่วิศวกรต้องเข้าถึง Claude ได้ ผ่าน claude.ai หรือ Cowork
ต้องมีแม่แบบ intent.md ที่ตกลงกันทั้งองค์กร
ต้องมีที่เก็บ intent ที่อยู่ใน version control และเจ้าของผลิตภัณฑ์เฝ้าอยู่ ที่ง่ายที่สุดคือโฟลเดอร์ intent/ ใน repo ของผลิตภัณฑ์ เพื่อให้ไฟล์อยู่ติดกับโค้ดที่เกิดจากมัน ส่วน repo แยกจะคุ้มก็ต่อเมื่อ intent กระจายข้ามหลาย repo

การตั้งที่เก็บเป็นงานครั้งเดียวของทีมแพลตฟอร์ม และต้องตัดสินว่าใครเขียนได้บ้าง เพราะคนที่เข้ามาเขียนจะมาจากทั่วองค์กร

เมื่อมี repo แล้ว คนที่ไม่มีประสบการณ์ git ไม่ต้องใช้ git เอง ให้ต่อ connector กับ GitHub แล้วให้ Claude commit แทนจาก claude.ai หรือ Cowork

ขั้นตอน

เจ้าของไอเดียเล่าปัญหาให้ Claude ฟังด้วยคำของตัวเอง สิ่งที่ทำไม่ได้ตอนนี้ ใครได้รับผล อะไรคือดีขึ้น และอะไรอยู่นอกขอบเขต ไม่ต้องใช้ภาษาเป็นทางการ
ระดมกันจนไอเดียเป็นรูปเป็นร่าง Claude จะถามคำถามที่นักวิเคราะห์ธุรกิจถาม คือขอบเขต ผู้ใช้ ข้อจำกัด และความสำเร็จหน้าตาเป็นอย่างไร
สั่งให้ Claude เขียนเป็น intent.md ตามแม่แบบขององค์กร ซึ่งเขียนเป็น skill ได้
เจ้าของไอเดียแก้จุดที่ Claude เข้าใจผิด
commit เข้าที่เก็บกลาง ชื่อผู้เขียนกับเวลาเข้าสู่บันทึก แล้วเจ้าของผลิตภัณฑ์รับช่วงต่อ [1]

ไฟล์ที่ได้หน้าตาแบบนี้

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

ตัวอย่างนี้มาจากเอกสารต้นทางและเป็นตัวอย่างที่แสดงจุดสำคัญ คือข้อจำกัดที่ห้ามละเมิดถูกเขียนก่อนเริ่มออกแบบ และคำถามที่ยังไม่มีคำตอบถูกจดไว้ ไม่ใช่ปล่อยให้ agent เดา

หลักฐานคือ intent.md ที่มีชื่อผู้เขียน เวลา และประวัติการแก้ไขอยู่ใน git การอนุมัติให้ไปต่อคือการ merge หรือการปิด review

ตัวชี้วัดที่เอกสารแนะนำคือ เวลาจากบทสนทนาแรกถึงตอน commit ซึ่งคาดว่าจะลดจากหลายสัปดาห์เหลือไม่กี่ชั่วโมง

ตัวชี้วัดฝั่ง lagging มีสองตัว คืออัตราการรอด ซึ่งเป็นสัดส่วน intent.md ที่เจ้าของผลิตภัณฑ์รับเข้าสู่ระยะออกแบบ เทียบกับที่ถูกปิดทิ้ง และจำนวนครั้งที่ intent.md ถูกแก้หลัง commit spec.md ครั้งแรกของงานเดียวกัน ซึ่งบอกว่า intent ต้นทางเขียนชัดพอหรือยัง

ระยะที่ 2 ออกแบบ: รวม requirement กับ design เป็นรอบเดียว

แบบเดิม analyst เขียน requirement แล้ว designer ตีความเป็น design อีกที การแยกเพื่อความรับผิดชอบแต่แลกมาด้วยความช้าและการสูญเสียรายละเอียด

แบบใหม่ product owner ส่ง intent.md ให้ Claude แล้วให้มันสร้าง spec ที่ยึดตาม skill ขององค์กร เช่น แบรนด์ ความปลอดภัย การปฏิบัติตามกฎ และ UX

จุดที่ผมชอบคือคำสั่งให้ระบุ "จุดที่กังวล" ไว้ด้วย เช่นจุดที่ข้อกำหนดขัดกันเอง

เพราะในงานจริง ปัญหามักไม่ได้อยู่ที่เขียนไม่ครบ แต่อยู่ที่ข้อกำหนดสองข้อขัดกันและไม่มีใครกล้าตัดสิน

หลักฐานคือ spec.md ที่ commit คู่กับ intent.md พร้อมเวอร์ชันของ skill ที่ใช้ตอนนั้น

ตัวชี้วัดคือเวลาระหว่าง commit ของ intent.md ถึง spec.md และจำนวนครั้งที่ spec ถูกแก้หลังเริ่มสร้าง

เริ่มลงมือระยะที่ 2: เตรียมอะไรและทำอย่างไร

ของที่ต้องเตรียม มีแค่ intent.md หนึ่งไฟล์ และนโยบายแบรนด์ ความปลอดภัย การปฏิบัติตามกฎ และ UX ที่เขียนเป็น skill ไว้แล้ว

โครงสร้างพื้นฐาน คือเจ้าของผลิตภัณฑ์ที่มีสิทธิ์ใช้ Claude ไม่ต้องมีทักษะวิศวกรรม

ขั้นตอน

เจ้าของผลิตภัณฑ์เปิด session โดยมี skill ขององค์กรโหลดอยู่ แล้วแนบ intent.md
สั่งให้ยึด intent.md ระบุข้อจำกัด และบังคับให้ตั้งธงจุดที่น่ากังวล ตอนแรกทำมือก่อน แล้วค่อย encode เป็น slash command ระดับองค์กร จากนั้นให้การ merge intent.md เป็นตัวกระตุ้นงานที่ไม่ต้องมีคนกด
เจ้าของผลิตภัณฑ์ตรวจ spec เทียบกับไอเดีย ว่ามันแก้ปัญหาที่ตั้งไว้จริงไหม และคำถามเปิดใน intent.md ถูกตอบหรือถูกยกต่อ
เคลียร์จุดที่น่ากังวลก่อน เพราะเป็นจุดที่นักวิเคราะห์ธุรกิจจะยกขึ้นมาถาม เจ้าของผลิตภัณฑ์ต้องคุยกับเจ้าของนโยบายให้จบก่อนที่วิศวกรจะเห็น spec
commit spec.md คู่กับ intent.md ให้ทั้งคู่เป็นบันทึกว่าขออะไรและตัดสินอะไร
เจ้าของผลิตภัณฑ์ตัดสินว่า spec กับ intent ไปต่อถึงระยะสร้างหรือไม่ โดยปรึกษาหัวหน้าทางเทคนิคในเรื่องที่องค์กรจัดว่าความเสี่ยงสูง และการรับ spec คือจุดที่ระยะสร้างเริ่ม [1]

พรอมป์ตของระยะนี้ที่เอกสารให้มา

Read the attached intent.md and produce a requirements and design spec for
integrating it into our existing codebase. Apply the skills available to you
so the plan conforms to our brand guidelines, security policies and UX
standards. Document the spec fully as spec.md, ready to hand to the
engineering team. Describe clearly any areas of concern, especially where
you cannot satisfy contradicting policies.

ระยะที่ 3 สร้าง: plan mode เป็นจุดเริ่มต้น ไม่ใช่โค้ด

แบบเดิม วิศวกรอ่าน design แล้วเริ่มเขียนโค้ด แผนว่าจำเป็นต้องแตะไฟล์ไหนและจะพิสูจน์อย่างไรอยู่แต่ในหัว

แบบใหม่ เริ่ม session ใน plan mode ให้ Claude อ่านโค้ดโดยยังแก้ไม่ได้ [2] แล้วให้มันเสนองานเป็นแผนที่ระบุไฟล์ที่จะเปลี่ยน ลำดับงาน และเทสต์ที่จะพิสูจน์

จากนั้นวิศวกรซักถามจนกว่าคนที่ไม่เคยเห็นบทสนทนาจะทำงานต่อได้จากแผนเพียงอย่างเดียว

คำถามที่เอกสารแนะนำให้ถามมีสามข้อ ซึ่งผมคิดว่าใช้ได้จริงทุกทีม

การเปลี่ยนแปลงนี้อาจทำให้อะไรพัง
ขั้นตอนไหนเสี่ยงที่สุด
มีทางเลือกอื่นที่ Claude ไม่ได้เลือก เพราะอะไร

พอแผนผ่าน จึง commit เป็น plan.md แล้วปล่อยให้ลงมือ

หลักฐานคือ plan.md และตัว diff ที่จะถูกตรวจย้อนกับแผนในระยะส่งมอบ

ตัวชี้วัดฝั่ง leading คือสัดส่วนการเปลี่ยนแปลงที่ merge ได้ตั้งแต่รอบแรก และเวลาจากการอนุมัติแผนถึงตอน PR ถูก merge

ฝั่ง lagging คือจำนวนรอบการแก้งานซ้ำต่อหนึ่งการเปลี่ยนแปลง และสัดส่วนที่ diff ที่ merge แล้วยังตรงกับ plan.md ที่ commit ไว้

เริ่มลงมือระยะที่ 3: เตรียมอะไรและทำอย่างไร

ของที่ต้องเตรียม คือ artifact ต้นทาง (intent.md หรือ spec.md ถ้ามี) และ CLAUDE.md ที่ช่วยให้ agent รู้บริบทของ repo

โครงสร้างพื้นฐาน คือ Claude Code ที่เข้าถึง repository ได้

ขั้นตอน

เปิด session ใน plan mode
ให้ intent.md กับ spec.md แก่ Claude แล้วขอแผนงานที่ระบุไฟล์ที่จะเปลี่ยน ลำดับงาน และเทสต์ที่จะพิสูจน์
ซักแผนด้วยสามคำถาม คือการเปลี่ยนแปลงนี้อาจทำให้อะไรพัง ขั้นตอนไหนเสี่ยงที่สุด และมีทางเลือกอื่นที่ Claude ไม่ได้เลือกเพราะอะไร
วนจนกว่าวิศวกรที่ไม่เคยเห็นบทสนทนาจะทำงานต่อจากแผนได้คนเดียว
commit แผนที่อนุมัติแล้วเป็น plan.md เพื่อให้แผนเข้าสู่ audit trail และให้ระยะส่งมอบตรวจ diff ย้อนกับมันได้
ปล่อยให้ Claude ลงมือ เมื่อแผนแน่น การทำรอบเดียวมักจบ
เมื่อการทำจริงเบี่ยงจากแผน ให้แก้ plan.md ใน commit เดียวกัน และพิจารณาใช้ hook บังคับให้สองอย่างตรงกันตลอด [1]

ข้อ 7 คือข้อที่คนมักข้าม และเป็นสาเหตุที่ plan.md กลายเป็นเอกสารตายภายในสองสัปดาห์

auto mode: เมื่อไรควรปล่อยให้ลงมือเอง

plan mode คือค่าเริ่มต้น แต่เอกสารบอกว่ามีจุดที่เลื่อนขึ้นไปได้ เรียกว่า auto mode ซึ่งวิศวกรอนุมัติแผนครั้งเดียว แล้ว Claude ลงมือแก้ทีละจุดโดยไม่ถามทุกครั้ง

เงื่อนไขที่เอกสารให้ไว้มีสามข้อ [1]

spec.md แน่นพอ
ขอบเขตผลกระทบเล็ก (blast radius) คือจำนวนไฟล์และระบบที่จะพังตามถ้าแก้งานนี้ผิด
โค้ดส่วนนั้นมีเทสต์คลุมอยู่แล้ว

เมื่อสามข้อนี้จริง การรีวิวก็ย้ายจาก "ดูทุกการกระทำ" ไปเป็น "ดูสิ่งที่ส่งมอบหลังจบ session ยาว" ซึ่งเปลี่ยนงานของวิศวกรจากผู้เฝ้าเป็นผู้ตรวจ

ระบบเก่าและแหล่งความจริง

ธุรกิจจริงไม่ได้เริ่มจากกระดาษเปล่า [1] งานอาจอยู่ใน Jira requirement อยู่ในเครื่องมือที่มีร่องรอยตามกฎระเบียบ design อยู่ใน Figma และการอนุมัติอยู่ในคณะกรรมการเปลี่ยนระบบ

เอกสารยอมรับตรง ๆ ว่าพวกนี้แทนที่ยาก เพราะผู้ตรวจสอบและทีมอื่นพึ่งมันอยู่แล้ว คำแนะนำคือ ทุก artifact ต้องรู้ว่าใครเป็นแหล่งความจริง แล้วให้ที่เหลือเป็นสำเนาหรือลิงก์มาที่ต้นทาง

ใช้ repo เป็นแหล่งความจริง: markdown คือบันทึกหลัก ระบบเดิมลิงก์มาที่ commit
ใช้ระบบเดิมเป็นแหล่งความจริง: markdown เก็บสาระ แต่ Jira ถือสถานะ
เชื่อมสองทางเป็นขั้นต่ำ: ทุก artifact จด record ID ของระบบเดิม และระเบียนเดิมบรรจุ commit SHA ของไฟล์ markdown ทางนี้ยอมรับว่ามีสองแหล่งความจริง แต่มีลิงก์ถึงกัน ซึ่งเอกสารบอกว่าเป็นจุดเริ่มที่ใช้ได้ตอนย้ายระบบ [1]

เอกสารยอมรับว่าสองระบบอยู่ร่วมกันได้ ตราบใดที่มีลิงก์ระหว่างกัน หรือมีอันหนึ่งถูกประกาศว่าเป็นแหล่งความจริง [1]

session ขนานและ subagent

วิศวกรหนึ่งคนดูแลงานหลายเส้นพร้อมกันได้ เมื่อแต่ละ session แยก worktree ของตัวเอง และไม่รับรู้กันเลย

parallel session คือ Claude Code อีกตัว ทำงานอีกงาน ใน git worktree แยก [8]
subagent คือผู้ช่วยใน session เดียว มี context และสิทธิ์เครื่องมือของตัวเอง เหมาะกับงานที่เกิดซ้ำ เช่นตรวจว่าแอปรันได้จริง [7]

ของที่ต้องเตรียม คือ CLAUDE.md เพราะทุก session อ่านไฟล์นี้ และ feedback loop จากระยะทดสอบ เพราะ session ที่ตรวจงานตัวเองได้จะต้องมีคนเฝ้าน้อยลง

โครงสร้างพื้นฐาน คือ git repository เพราะ isolation มาจาก worktree และ permission settings ที่ปรับไว้ให้ session ไม่ต้องรออนุมัติคำสั่งที่องค์กรถือว่าปลอดภัย [7] [8]

ขั้นตอน

แบ่งงานเป็นชิ้นที่แตะไฟล์คนละชุด โดยดูจาก plan.md ว่างานไหนแยกกันได้จริง งานที่ใช้ไฟล์ร่วมกันให้ทำใน session เดียวแบบเรียงคิว [1]
ให้แต่ละงานมี worktree ของตัวเอง เช่น claude --worktree feature-auth ในเทอร์มินัลหนึ่ง และ claude --worktree fix-rate-limit ในอีกอัน เพราะ worktree คือ checkout แยกบน branch ของตัวเอง จึงไม่ชนไฟล์กัน
เริ่มที่สองถึงสาม session ก็พอ เพราะเพดานจริงคือจำนวนงานที่คนหนึ่งตรวจได้อย่างมีคุณภาพ ให้เพิ่มเมื่อการตรวจยังตามทัน
เปลี่ยนงานที่เกิดซ้ำเป็น subagent ที่นิยามเป็นไฟล์ markdown ใน .claude/agents/ โดยมีชื่อ คำอธิบายว่าเมื่อไรใช้ และเครื่องมือที่แตะได้ ตัวอย่างเช่นตัว simplifier ที่ตัดความซับซ้อนส่วนเกินหลัง agent หลักเสร็จ ตัว verifier ที่รันแอปและตรวจพฤติกรรม และตัว researcher ที่สำรวจโค้ดเบสแล้วรายงานกลับโดยไม่ทำให้ context หลักบวม และให้ commit นิยามเหล่านี้เข้า git เพื่อให้ทั้งทีมใช้ร่วมกัน [7] [8]

ตัวอย่าง subagent ที่เอกสารให้มา

---
name: verifier
description: "Runs the app and checks the change works before the session"
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

สังเกตบรรทัดสุดท้าย "ห้ามแก้ รายงานเท่านั้น" ซึ่งเป็นหัวใจของการตรวจ เพราะผู้ตรวจที่ไม่ลงมือแก้จะไม่เอนเอียงเข้าข้างโค้ดตัวเอง

ระยะที่ 4 ทดสอบ: ให้ agent ตรวจงานตัวเองก่อนคนเห็น

แบบเดิมสัญญาณว่าโค้ดใช้ได้มาช้า ไม่ว่าจะเป็น CI ที่ใช้เวลาหลายนาที tester ที่มาถึงวันถัดไป หรือ production ที่รู้เรื่องเป็นสัปดาห์

แบบใหม่ ให้ agent มีวิธีตรวจงานตัวเอง เช่นรันเทสต์ รัน build หรือเทียบภาพหน้าจอ แล้ววนแก้จนผ่านก่อนส่งให้คนดู

เอกสารแยกคำสองคำที่คนมักใช้ปนกัน

feedback loop คือการตรวจที่เกิดตลอดงาน ทำซ้ำได้หลายรอบ
verifier subagent คือการตรวจครั้งสุดท้ายด้วย context ใหม่ เพื่อไม่ให้คำตัดสินถูกอคติจากการที่โมเดลเป็นคนเขียนโค้ดเอง

ส่วน evals คือสิ่งที่เอกสารเรียกว่า QA ยุคใหม่ เป็นชุดทดสอบที่รันเมื่อใดก็ตามที่คอนฟิกของ agent เปลี่ยน เช่นเปลี่ยนโมเดล เปลี่ยน prompt หรือเปลี่ยน skill

จุดนี้ผมคิดว่าสำคัญมาก เพราะทีมส่วนใหญ่อัปเดต prompt โดยไม่มีการทดสอบย้อนกลับ แล้วพบปัญหาก็ต่อเมื่อผู้ใช้เจอ

ตัวชี้วัดคืออัตราการผ่านของ eval และเวลาที่ใช้เปลี่ยน incident ใน production ให้กลายเป็น eval ถาวร

ในทางปฏิบัติ eval คือชุดทดสอบที่รันใน CI ด้วย API key ของโมเดล และควรตั้งเพดาน token ต่อการรันหนึ่งครั้ง เพราะค่าใช้จ่ายจะโตตามจำนวนกรณีทดสอบ

เริ่มลงมือระยะที่ 4: สิ่งที่ต้องมีและขั้นตอนจริง

ของที่ต้องเตรียมก่อน ไม่มีอะไรเป็นพิเศษ

โครงสร้างพื้นฐาน คือชุดเทสต์และ build ที่รันในเครื่องได้ด้วยคำสั่งเดียว และสำหรับงาน UI ต้องมีทางให้ Claude เห็นผลลัพธ์ เช่นเครื่องมือเบราว์เซอร์หรือตัวจับภาพหน้าจอที่ต่อผ่าน MCP

ขั้นตอน

ถ้าการตรวจงานวันนี้ต้องรันหลายคำสั่งและรู้จัก environment ให้ห่อเป็นเป้าหมายเดียว เช่น make test หรือ npm test ที่คืนค่าไม่ใช่ศูนย์เมื่อพัง
ในหัวข้อ Commands ของ CLAUDE.md ให้เขียนแต่ละคำสั่งพร้อมตัวอย่างผลลัพธ์ที่ปกติ
ตั้งเป้าหมายที่วัดได้ เพื่อให้ Claude ตรวจเองได้โดยไม่ต้องถาม เช่น "เทสต์ใน test_status.py ผ่านทั้งหมด" หรือ "ภาพหน้าจอตรงกับ mock ที่แนบ" หรือ "endpoint คืน 200 พร้อมฟิลด์ใหม่"
สำหรับงานแก้บั๊ก ให้เขียนเทสต์ที่พังก่อน สั่งให้ Claude ทำให้บั๊กกลายเป็นเทสต์ รันแล้วยืนยันว่ามันพังด้วยเหตุผลที่คาด แล้ว commit เทสต์นั้น จากนั้นจึงสั่งให้แก้โดยห้ามแตะเทสต์ และใช้ hook กันการแก้ไฟล์เทสต์ เทสต์ที่เกิดก่อนการแก้และ agent เขียนทับไม่ได้ คือหลักฐานว่าบั๊กหายจริง
สำหรับงาน UI ให้ปิดวงจรด้วยการตรวจภาพ ให้เครื่องมือเบราว์เซอร์กับ mock แล้วปล่อยให้วนแก้เอง สองถึงสามรอบเป็นเรื่องปกติ
ทำให้การตรวจเป็นส่วนหนึ่งของคำว่าเสร็จ คำสั่งอยู่ใน CLAUDE.md คือรันเทสต์ก่อนรายงานว่าเสร็จ และต้องโชว์ผลลัพธ์

บล็อกตรวจงานที่ควรอยู่ใน CLAUDE.md

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

ปกป้องตัวลูปเองด้วย เพราะ agent ที่กำลังแก้โค้ดต้องไม่สามารถทำให้การตรวจอ่อนลงได้ hook ที่บล็อกการแก้ไฟล์เทสต์ระหว่างงานแก้บั๊กทำหน้าที่นี้ ทางเลือกอื่นคือตรวจ diff ในรีวิวแล้วปฏิเสธการเปลี่ยนแปลงที่แตะเทสต์ [1]

eval ใน CI: ทำอย่างไรให้มีของจริง

ของที่ต้องเตรียม คือ CLAUDE.md และ feedback loop จากระยะที่แล้ว

โครงสร้างพื้นฐาน คือ CI ที่รัน Claude Code แบบไม่ต้องมีคนกด และ API key ที่มีงบพอสำหรับการรัน eval

ขั้นตอน

วิศวกรแพลตฟอร์มเก็บงานจริง 20 ถึง 50 งานจากงานล่าสุด พร้อมผลลัพธ์ที่ยอมรับได้
เขียนแต่ละงานเป็น eval คือ prompt บวกเงื่อนไขที่บอกว่าอะไรเรียกว่าผ่าน เช่นเทสต์ผ่าน lint สะอาด พฤติกรรมไม่เปลี่ยน หรือทำตามนโยบาย
รันชุดนี้ใน CI ตามตาราง และรันทุกครั้งที่มีการแก้ CLAUDE.md skill หรือ hook เพราะการตั้งค่าเหล่านี้คือสิ่งที่บังคับพฤติกรรมของ agent จึงสมควรได้ regression test เท่ากับโค้ด
ใช้ผลลัพธ์เป็นประตูสำหรับการเปลี่ยนการตั้งค่า skill ที่ทำให้อัตราผ่านลดลงต้องถูกรีวิวก่อน merge
ทุก incident ใน production ได้ eval หนึ่งตัว เขียนโดยทีมที่รับ incident และเก็บไว้ในชุดทดสอบตลอดไป [1]

workflow ที่รัน eval ใน CI มีหน้าตาแบบนี้

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

ระยะที่ 5 ส่งมอบ: การรีวิวทำงานสองทาง

แบบเดิม PR รอคนอ่าน ความละเอียดของการรีวิวขึ้นกับว่าคนอ่านมีเวลามากแค่ไหน

แบบใหม่ Claude รีวิว PR ที่เข้ามาตามนโยบายขององค์กร และตอบคอมเมนต์ใน PR ของตัวเองด้วย

คนจึงยกระดับการดูขึ้นไปเป็น "การเปลี่ยนแปลงนี้ทำตามเจตนาหรือไม่ และความเสี่ยงที่เหลือยอมรับได้ไหม"

นโยบายการรีวิวเขียนเป็นไฟล์ REVIEW.md ที่แบ่งเป็นรอบการตรวจ เช่น bug, security, compliance และกำหนดว่าอะไรเรียกว่า Important อะไรเป็นแค่ nit [6]

หลักการที่เอกสารย้ำคือ agent ทำได้ถึงประตู production แต่ผ่านประตูไม่ได้

กฎรีวิวที่เขียนไว้ล่วงหน้า

ถ้าไม่กำหนดกฎ คนรีวิวจะไล่จับทุกอย่างจนไม่ได้ดูเรื่องสำคัญ เอกสารจึงเสนอโครงสี่ชั้น [1]

Passes คือการตรวจสามรอบ แล้วติดป้ายว่าข้อค้นพบมาจากรอบไหน: บั๊กและข้อผิดพลาดเชิงตรรกะ, ความปลอดภัยและช่องโหว่, การปฏิบัติตาม spec.md plan.md และหลักการออกแบบของทีม [1]
Important สงวนไว้สำหรับข้อที่จะทำให้พฤติกรรมพัง ข้อมูลรั่ว หรือผิดนโยบาย ส่วนสไตล์และการตั้งชื่อเป็นได้แค่ nit [1]
Cap the nits คือรายงานเรื่องเล็กไม่เกินห้าข้อต่อรีวิว ที่เหลือสรุปเป็นจำนวน [1]
Do not report คือไฟล์ที่ generate ใต้ src/gen/ และอะไรก็ตามที่ CI บังคับอยู่แล้ว [1]

ผลข้างเคียงที่ผมเคยเจอในทีมคือ ถ้าไม่มีข้อสามและข้อสี่ คนรีวิวจะเขียน 40 ความเห็น แล้วเจ้าของ PR จะแก้ตามทั้งหมดโดยไม่รู้ว่าอันไหนสำคัญจริง

hooks ในฐานะประตูอนุมัติ

ในระยะสร้าง hook ทำหน้าที่เป็นรั้ว บล็อกหรืออนุญาตโดยไม่ต้องมีคน แต่ hook ยังสั่ง "ถาม" ได้ด้วย คือหยุดรอคนที่ระบุอนุมัติ ซึ่งตรงกับความต้องการของการปล่อยของ

ตัวอย่างในเอกสารคือ hook ที่ผูกกับเครื่องมือ Bash แล้วเรียกสคริปต์ของโปรเจกต์ก่อนคำสั่งจะทำงาน ซึ่งสคริปต์นั้นตัดสินได้ว่าจะอนุญาต ถาม หรือบล็อก [1]

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
        ]
      }
    ]
  }
}

hook ของทีมเก็บใน .claude/settings.json ซึ่งอยู่ใน git และแก้ได้ ส่วน hook ที่ห้ามต่อรองเก็บใน managed settings ที่ผู้ดูแลระบบเป็นเจ้าของ วิศวกรปิดเองไม่ได้

ขั้นตอน

ผู้บริหารฝ่ายวิศวกรรมร่วมกับทีม change management และ compliance ระบุประตูที่คนต้องเซ็นอนุมัติและต้องคงอยู่ เช่นการเซ็นรับการเปลี่ยนแปลง การอนุญาตรีลีส และการแก้ไฟล์ในเส้นทางหวงห้าม
วิศวกรแพลตฟอร์มเขียนแต่ละประตูเป็น hook ซึ่งเป็นสคริปต์ที่รันก่อน Claude ลงมือ และเลือกได้ว่าจะอนุญาต ถาม หรือบล็อก
hook ของทีมเก็บใน .claude/settings.json ที่อยู่ใน git ส่วน hook ที่ต่อรองไม่ได้เก็บใน managed settings ที่แพลตฟอร์มหรือไอทีเป็นเจ้าของ ซึ่งวิศวกรคนเดียวปิดไม่ได้
การบล็อกต้องอธิบายตัวเองได้ เมื่อ hook หยุดการกระทำ ต้องมีเหตุผลและช่องทางขออนุมัติปรากฏในผลลัพธ์ที่ Claude เห็น [1]

สคริปต์ประตูที่เอกสารให้มา

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

managed settings สำหรับองค์กรที่มีกฎ

องค์กรที่มีผู้ตรวจสอบภายนอกไม่ต้องการคำสัญญา ต้องการการบังคับใช้ [1] เอกสารยกตัวอย่างไฟล์ managed settings ที่ผู้ดูแลระบบติดตั้งผ่าน MDM หรือคอนโซลกลาง โดยมีกลุ่มค่าที่สำคัญดังนี้

permissions.deny กันไม่ให้ agent อ่าน .env หรือโฟลเดอร์ secrets และกันการเรียก curl หรือ wget ออกนอก
permissions.allow อนุมัติคำสั่งที่ปลอดภัยไว้ล่วงหน้า เพื่อไม่ให้ deny list กลายเป็นป๊อปอัปถามทั้งวัน
sandbox บังคับให้รันในแซนด์บ็อกซ์ และจำกัดโดเมนเครือข่ายกับไฟล์ credential ที่เข้าถึงได้
disableBypassPermissionsMode และ allowManagedPermissionRulesOnly ทำให้ไม่มีใครขยายสิทธิ์เองได้ แม้จะแก้ไฟล์โปรเจกต์หรือใส่แฟล็กบนบรรทัดคำสั่ง

กลุ่มสุดท้ายนี้คือสิ่งที่ทำให้คำว่า governance เป็นจริง ไม่ใช่แค่ประกาศเจตนา

ในทางปฏิบัติหมายความว่า agent เขียนได้แค่ PR ไม่มีสิทธิ์ push ตรงเข้า main และการ deploy ไป production ต้องมี release manager อนุมัติ

ตัวชี้วัดคือสัดส่วน pipeline ที่ล้มแล้วถูกวินิจฉัยโดยไม่ต้องปลุกคน และตัวชี้วัด DORA ที่ระบบมีอยู่แล้ว

เริ่มลงมือระยะที่ 5: การรีวิวด้วย AI

ของที่ต้องเตรียม คือ CLAUDE.md ที่อัปเดตแล้ว, skill ถ้าการรีวิวต้องบังคับนโยบายที่เป็นลายลักษณ์ และ subagent ที่นิยามไว้

โครงสร้างพื้นฐาน คือ repo ที่ติดตั้งส่วนเชื่อม Claude แล้ว ไม่ว่าจะเป็นบริการ Code Review ที่ผู้ดูแลเปิดให้ หรือ claude-code-action ที่รันใน CI ของตัวเอง พร้อม branch protection ที่กำหนดให้ต้องมี code owner อนุมัติ

ขั้นตอน

เริ่มจากบริการ Code Review ที่ผู้ดูแลเปิดและเลือก repo ได้เร็วที่สุด ถ้าต้องคุมไปป์ไลน์เองหรือต้องการให้คำขอโมเดลวิ่งผ่านสัญญาคลาวด์ขององค์กร ให้ใช้ claude-code-action
หัวหน้าทีมเขียนนโยบายรีวิวเป็น REVIEW.md ที่ราก repo แบ่งเป็นรอบที่องค์กรสนใจ และนิยามว่า Important ต่างจาก nit อย่างไร และอะไรข้ามได้
กำหนดระดับที่คนต้องอนุมัติ ผลการรีวิวไม่ได้อนุมัติหรือบล็อก PR ด้วยตัวเอง branch protection ยังต้องมี code owner อนุมัติ ถ้าอยากให้ severity เป็นประตูจริง ให้อ่านค่าที่ check run เผยแพร่เป็นตัวเลข
ถ้าคนรีวิวหรือเจ้าของ PR พิมพ์ @claude ใต้ความเห็น Claude จะเข้าไปแก้แล้ว push กลับ เธรดนั้นจึงเก็บทั้งคำขอและผลลัพธ์ไว้ด้วยกัน ส่วนบริการแบบจัดการ ถ้าต้องการรอบตรวจใหม่ให้ใช้คำสั่ง @claude review
ผลรีวิวไหลกลับเข้า CLAUDE.md เมื่อเจอข้อผิดพลาดเดิมเป็นครั้งที่สอง การแก้จะถูกเขียนลงไฟล์พร้อมรีวิวนั้น และเพราะการรีวิวอ่าน CLAUDE.md ข้อผิดพลาดนั้นจะถูกจับตั้งแต่ PR ถัดไป
เดือนละครั้ง หัวหน้าทีมปรับตั้งค่าโดยให้คะแนนผลรีวิว และคุมปริมาณ nit ใน REVIEW.md [1]

REVIEW.md ที่เอกสารให้มาเป็นตัวอย่างมีหน้าตาแบบนี้

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

ต่อ Claude เข้ากับ CI/CD และการปล่อยของ

ของที่ต้องเตรียมก่อน คือการรีวิวด้วย AI และ hook ที่เป็นประตูอนุมัติ เพราะประตูต้องมีก่อนที่ automation จะเร่งอะไรผ่านมันไป

โครงสร้างพื้นฐาน คือ CI ที่ติดตั้ง claude-code-action หรือ runner ใดก็ได้ที่เรียก claude -p ได้, สิทธิ์โมเดลผ่าน API หรือ Bedrock, Foundry, Vertex ถ้าต้องอยู่ในสัญญาคลาวด์ขององค์กร, MCP server ของเป้าหมายที่ deploy และ sandbox profile สำหรับงานของ agent ที่ไม่มี credential production ติดตัว

ขั้นตอน

เริ่มจากงานที่ตัดสินอย่างเดียวและอ่านอย่างเดียว ใช้ claude -p ในไปป์ไลน์เพื่อจัดหมวด build ที่พัง สรุป flaky test หรือร่าง changelog

ตัวอย่างขั้นในไปป์ไลน์ที่เอกสารให้มา

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

เพิ่มงานที่เขียนไฟล์ได้ แต่ต้องอยู่หลังประตูเดิม เช่นแก้ lint อัปเดตเอกสารที่ generate หรือรับความเห็นรีวิวผ่าน @claude ทุกอย่างที่ agent เขียนต้องมาเป็น PR และ agent ไม่มีทาง push ตรงเข้า main
รันในแซนด์บ็อกซ์ งานของ agent อยู่ในคอนเทนเนอร์ที่มีนโยบายเครือข่ายและ token อายุสั้น ไม่มี credential production โดยค่าเริ่มต้น
เปิดทาง deploy ผ่าน MCP ทำให้ deploy ดูสถานะ และ rollback กลายเป็นเครื่องมือที่จำกัดตามสภาพแวดล้อม สิทธิ์ของ agent จึงเป็นรายการที่อนุญาต ไม่ใช่สคริปต์ที่มี credential ฝังอยู่
แบ่งระดับ autonomy ตามสภาพแวดล้อม ใน development agent ปล่อยได้เอง ใน production agent เตรียมรีลีสและผู้จัดการรีลีสเป็นคนอนุมัติ โดยมี hook บังคับประตูนั้น staging อยู่ตรงกลาง
rollback ต้องเป็นเส้นทางที่ซ้อมมากที่สุดในไปป์ไลน์ คือคำสั่งเดียวที่ agent รันได้ และถูกซ้อมใน staging สม่ำเสมอ เพราะระยะดูแลระบบจะเรียกมันเมื่อค่าเบี่ยงเบนทะลุขอบ [1]

ระยะที่ 6 ดูแลระบบ: วงจรปิดที่เริ่มจากค่าเบี่ยงเบน

แบบเดิมระบบดูแลเป็นงานตั้งรับ รอคนเปิด ticket หรือรอคนเห็น alert

แบบใหม่ สคริปต์ที่เขียนด้วยกฎตายตัวคอยดูค่า metric เทียบกับ baseline แล้วเรียก Claude เมื่อค่าเบี่ยงออกนอกแถบที่กำหนด

เอกสารกำหนดระดับการตอบสนองไว้สามขั้น ซึ่งผมคิดว่าเป็นไอเดียที่ยืมไปใช้ได้ทันที

เบี่ยงเล็กน้อย บันทึก log อย่างเดียว
เบี่ยงปานกลาง เรียก Claude แบบอ่านอย่างเดียวเพื่อวินิจฉัย
เบี่ยงมาก Claude ลงมือได้ แต่ได้แค่เปิด PR เข้าประตูตรวจ หรือรัน runbook ที่อนุมัติไว้ล่วงหน้า

ผลวินิจฉัยถูกเขียนกลับเป็น intent.md แล้วไหลเข้าสู่วงจรเดิมอีกครั้ง

ตัวชี้วัดฝั่ง leading คือเวลาจากตอนค่าเบี่ยงเบนถูกตรวจพบจนถึงตอนมี intent.md เข้าคิวตรวจ เทียบกับเวลาเดิมจาก incident ถึง post-mortem

ฝั่ง lagging คือสัดส่วนข้อค้นพบที่กลายเป็นการแก้ที่ merge แล้ว และจำนวน incident ซ้ำในกลุ่มเดียวกัน

เริ่มลงมือระยะที่ 6: การปิดวงจร

ของที่ต้องเตรียม คือ intent.md ที่ให้ปลายทางของลูปมีรูปแบบไว้เริ่มใหม่, การรีวิว PR ที่เร็วขึ้น, hook ที่เป็นขอบเขตการกระทำ และเส้นทาง rollback

โครงสร้างพื้นฐาน คือที่เก็บเมตริกที่สคริปต์ตรวจจับเรียกได้ เช่น Prometheus หรือ API ของระบบ CI, สิทธิ์อ่าน repo และทางรัน Claude Code แบบไม่ต้องมีคนกดใน CI หรือ Agent SDK สำหรับบริการที่รับ webhook

ขั้นตอน

เจ้าของบริการหรือวิศวกรแพลตฟอร์มเลือกเมตริกหนึ่งตัวที่มีฐานแบบ rolling ที่นิ่ง เช่นอัตราเทสต์พังใน CI, อัตรา 5xx หลัง deploy หรือเวลาวนของ PR
เขียนสคริปต์ตรวจจับ มักใช้ค่าเฉลี่ยและส่วนเบี่ยงเบนมาตรฐานบนหน้าต่างเลื่อน พร้อมกฎอย่าง Western Electric เพื่อจับทั้งการเลื่อนช้าและอาการกระตุก สคริปต์อยู่ใน version control มี unit test และการตรวจจับเป็น deterministic ไม่มีโมเดลเกี่ยวข้อง
กำหนดระดับการตอบสนองในไฟล์ config ที่อยู่ใน version control ที่ 1σ แค่บันทึกไว้ ที่ 2σ เรียก Claude แบบอ่านอย่างเดียวมาวินิจฉัย ที่ 3σ Claude ลงมือได้ แต่ได้แค่เปิด PR เข้าประตูรีวิวหรือสั่ง runbook ที่อนุมัติไว้แล้ว
ชั้นกระตุ้นจะเป็น scheduled workflow ใน GitHub หรือ GitLab, webhook จากระบบมอนิเตอร์ หรือ Cron Job ในเครือข่ายก็ได้ Claude รันแบบ stateless จึงเริ่มและจบได้โดยไม่มีคนกด
agent เขียนวินิจฉัยเป็น intent.md ตามรูปแบบระยะที่ 1 ครอบคลุมความผิดปกติกับหลักฐาน ผลลัพธ์ที่เสนอ ระบบที่กระทบ และคำถามเปิด
เจ้าของบริการหรือวิศวกร on-call คัดกรองคิว ส่งเรื่องที่กระทบผู้ใช้ให้เจ้าของผลิตภัณฑ์ แล้วเลือกแก้เลย ตั้งคิว หรือปิดทิ้ง การปิดทิ้งคือข้อมูลไว้ปรับขอบให้เงียบลง
เมื่อแก้เสร็จ ให้เพิ่ม eval ของ incident นั้นเข้าไปในชุดทดสอบ เพื่อกันไม่ให้เกิดซ้ำ [1]

ไฟล์ bands.yaml ที่เอกสารให้มาเป็นตัวอย่างของการกำหนดระดับนี้

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

สแกนโค้ดตามรอบ ไม่ใช่สแกนตอนจะปล่อย

ผลสแกนความปลอดภัยเป็นคำตัดสิน ณ เวลาหนึ่ง และเน่าได้ทั้งสองด้าน คือโค้ดเปลี่ยนทุกสัปดาห์ และโมเดลรุ่นใหม่จับสิ่งที่รุ่นก่อนมองข้ามได้

เอกสารจึงเสนอให้สแกนตามตารางโดยไม่มีคนอยู่ในเส้นทางการเรียก แล้วส่งสิ่งที่เจอเข้าประตูเดียวกับงานอื่น ถ้าแก้ได้ใน PR เดียวก็เข้ารีวิวปกติ ถ้าใหญ่กว่านั้นก็กลายเป็น intent.md

รูปโฮสต์ของแนวนี้คือ Claude Security ซึ่งเปิดให้องค์กรระดับ Enterprise ใช้ในสถานะ public beta ต่อ repo แล้วสแกนด้วย Claude Mythos 5 บนโครงสร้างของ Anthropic โดยตรวจผลก่อนรายงานและแนบระดับความมั่นใจมาด้วย [9]

ขั้นตอน

หัวหน้าฝ่ายความปลอดภัยเชื่อม repo และจัดกลุ่มเป็นโปรเจกต์ตาม repo บริการ หรือทีม เพื่อให้เจ้าภาพของผลลัพธ์ชัดตั้งแต่ต้น
สแกนเต็มรอบแรกกับ repo ที่สำคัญที่สุด รวมถึง repo ที่เคยสแกนด้วยเครื่องมืออื่นหรือโมเดลรุ่นก่อน เพราะรอบแรกมักเจอเรื่องในโค้ดที่เคยถือว่าสะอาด และให้ถือรอบนี้เป็นเส้นฐาน
ตั้งตารางต่อโปรเจกต์ สัปดาห์ละครั้งเป็นค่าตั้งต้นที่เหมาะกับบริการที่ยังพัฒนาอยู่ และจำกัดขอบเขตเป็นโฟลเดอร์หรือ branch ถ้า repo ใหญ่หรือปนหลายงาน
คัดกรองผลโดยดูระดับความมั่นใจควบคู่ไปด้วย การปิดทิ้งต้องระบุเหตุผล เพื่อให้บันทึกไว้และไม่ให้เรื่องเดิมโผล่มาเป็นของใหม่ในรอบถัดไป
ถ้าผลนั้นจำกัดวง ให้เปิดแพตช์ที่ระบบเสนอใน Claude Code บนเว็บ ตรวจแล้วส่งเข้าประตูรีวิวเหมือนการเปลี่ยนแปลงอื่น เพราะ agent ที่เสนอแพตช์ไม่มีสิทธิ์อนุมัติเอง
ถ้าใหญ่กว่าหนึ่งแพตช์ เช่นจุดอ่อนเชิงสถาปัตยกรรมหรือรูปแบบที่ซ้ำหลายบริการ ให้เขียนเป็น intent.md ตามรูปแบบระยะที่ 1 แล้วเริ่มที่ระยะวางแผน
เมื่อปล่อยของที่แก้ขึ้น production แล้ว ให้เพิ่ม eval ของช่องโหว่ประเภทนั้นเข้าในชุดทดสอบ เพื่อกันไม่ให้การตั้งค่าที่บังคับ agent ถอยหลังในเรื่องเดียวกัน
ส่งออกผลเป็น CSV หรือ Markdown หรือผ่าน webhook เพื่อให้ระบบติดตามและตรวจสอบเดิมยังเป็นระบบบันทึกหลักในที่ที่ผู้ตรวจสอบคาดหวัง
นับความครอบคลุมจากวันที่สแกนครั้งล่าสุด ไม่ใช่วันแรกที่เริ่ม [1] [9]

on-call ที่มี agent เป็นผู้ตอบคนแรก

เหตุขัดข้องจำนวนมากมาในรูปข้อความตอนสี่ทุ่มในช่อง Slack ไม่ใช่ตั๋วที่มีขั้นตอนครบ [1]

Claude Tag ซึ่งเป็น public beta บน Slack ทำให้ agent เป็นสมาชิกช่องในชื่อของตัวเอง รับเหตุเป็นผู้ตอบคนแรก ตรวจว่าเมตริกกลับมาที่ฐานหรือยัง เขียน post-mortem ลงไฟล์บทเรียนที่อยู่ใน version control และเมื่อเจองานที่ใหญ่กว่าการแก้เฉพาะหน้า ก็เขียนเป็น intent.md ส่งกลับเข้าสู่วงจรตั้งแต่ต้น

จุดนี้เองที่ทำให้เอกสารเรียกว่านี่คือวงจรที่เลี้ยงตัวเอง เพราะปลายทางของระยะดูแลระบบกลายเป็นจุดเริ่มของระยะวางแผน

สี่กลไกที่ทำให้ทั้งชุดนี้ทำงานได้จริง

ถ้าอ่านแค่หกระยะ อาจเข้าใจว่าเปลี่ยนเครื่องมือก็พอ แต่เอกสารระบุกลไกสี่อย่างที่ทำให้มันไม่พัง

หนึ่ง CLAUDE.md คือไฟล์ที่บอก context ที่คนใหม่ต้องรู้ ตั้งแต่คำสั่ง build, convention, สถาปัตยกรรม ไปจนถึงข้อผิดพลาดที่ทีมเจอบ่อย [3]

กฎที่ผมชอบคือ ถ้า Claude ทำผิดซ้ำสองครั้ง ให้เขียนการแก้ลงไฟล์นี้ทันที

สอง skills คือที่เก็บความรู้ขององค์กรที่ต้องบังคับใช้สม่ำเสมอ เขียนเป็นโฟลเดอร์ที่มี SKILL.md ระบุว่าเมื่อไรควรถูกเรียกใช้ [5]

สาม hooks คือชั้นที่บังคับใช้แบบตายตัว ต่างจาก skill ที่เป็นคำแนะนำ เช่นบล็อกการแก้ไฟล์ที่ถูก generate ขึ้นมา หรือกันไม่ให้ credential หลุดเข้า diff [4]

สี่ evals คือชุดทดสอบของตัว agent เอง ไม่ใช่ของโค้ดที่ agent เขียน

สี่อย่างนี้ทำให้ "นิสัยของทีม" กลายเป็นกฎที่ตรวจสอบได้

วิธีสร้าง CLAUDE.md ให้ได้ผลจริง

ของที่ต้องเตรียม คือ repo, Claude Code ที่ติดตั้งแล้ว และวิศวกรหนึ่งคนที่รู้โค้ดเบสดี

ขั้นตอน

รัน /init ใน repo ให้ Claude สร้าง CLAUDE.md ตั้งต้นจากสิ่งที่มันเห็น
ตัดให้เหลือเท่าที่คนใหม่ต้องรู้วันแรก คือคำสั่ง build test lint, convention ที่สำคัญ และเรื่องที่ Claude ทำผิดซ้ำ
commit ไว้ที่ราก repo เพื่อให้ทั้งทีมใช้เวอร์ชันเดียว และแก้กันผ่านรีวิวเหมือนโค้ด
กฎที่ใช้ได้จริงคือ ถ้า Claude ทำผิดเรื่องเดิมสองครั้ง ให้เขียนข้อแก้ไขลง CLAUDE.md
คุมให้ยาวไม่เกินหนึ่งหน้า เพราะ Claude อ่านทั้งหมดตอนเริ่ม session และอะไรที่เก่าคือกิน context ฟรี [1]

ตัวอย่าง CLAUDE.md ของบริการชำระเงินที่เอกสารให้มา

# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
  adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.

หัวข้อสุดท้ายคือหัวข้อที่ผมคิดว่าคุ้มที่สุด เพราะมันเก็บความผิดพลาดจริงของทีมไว้ ไม่ใช่ทฤษฎี

วิธีเขียน skill ให้ไม่กลายเป็นเอกสารรก

ของที่ต้องเตรียม คือนโยบายหนึ่งเรื่องที่มีเจ้าของชัดเจนและมีแหล่งความจริงเป็นลายลักษณ์

ขั้นตอน

เลือกความรู้หนึ่งเรื่องที่วันนี้ถูกบังคับใช้ไม่สม่ำเสมอ เช่นมาตรฐานความปลอดภัย convention ของ API หรือกฎแบรนด์
เขียนเป็น skill คือโฟลเดอร์ที่มี SKILL.md ซึ่ง frontmatter บอกว่าเมื่อไรควรถูกเรียก และเนื้อในบอกว่าต้องทำอะไร
วางไว้ที่ .claude/skills/<name>/ ใน repo เพื่อให้ไปกับโค้ด หรือแจกทั้งองค์กรผ่าน plugin
ทดสอบว่ามันถูกเรียกจริง ลองสั่งงานหลายวิธีแล้วดูว่า skill โหลดทุกครั้ง
เมื่อนโยบายเปลี่ยน ให้แก้ skill และให้เจ้าของนโยบายเซ็นรับ
วิศวกรได้เวอร์ชันใหม่เองใน session ถัดไป [1]

ตัวอย่าง SKILL.md ของมาตรฐาน API ความปลอดภัย

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

hook ในระยะสร้าง ต่างจาก skill ตรงไหน

skill เป็นคำแนะนำที่โมเดลอาจทำตามหรือไม่ก็ได้ ส่วน hook เป็นชั้นที่กำหนดแน่นอน ทำงานทุกครั้งที่เข้าเงื่อนไข

hook ในระยะสร้างมีสามงานหลัก

บล็อกการแก้ไฟล์ในเส้นทางที่หวง เช่นคลาสที่ generate ขึ้นมาหรือแพ็กเกจที่ถูก freeze
รัน formatter และ linter หลังแก้ไฟล์ เพื่อไม่ให้ความต่างสะสม
กันไม่ให้ credential หลุดเข้า diff

ข้อควรระวังที่เอกสารย้ำคือ hook ทำงานทุกครั้งที่ match จึงต้องเร็วและจำกัดขอบเขตที่ไฟล์ที่เปลี่ยน ส่วนการตรวจหนัก เช่นรันเทสต์ทั้งชุด ควรอยู่ที่ commit หรือตอนเปิด PR

และ hook ที่ต้องรอคนอนุมัติไม่ควรอยู่ในระยะสร้าง เพราะจะดึงคนกลับมาเป็นคอขวดของการทำงานขนานทุก session ให้ไปอยู่ในระยะส่งมอบแทน [1]

plan.md ที่ดีหน้าตาเป็นอย่างไร

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.

## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

สังเกตว่าหัวข้อ Proof บังคับให้ระบุตั้งแต่ก่อนเขียนโค้ดว่าจะพิสูจน์อย่างไร ซึ่งเป็นเหตุผลที่ระยะทดสอบทำงานได้เร็วขึ้น

สิ่งที่ผมคิดว่าต้องคิดเองก่อนทำตาม

เอกสารนี้เขียนจากประสบการณ์ของ Anthropic กับลูกค้าองค์กรขนาดใหญ่ ซึ่งมีบริบทต่างจากทีมเล็กในไทยหลายเรื่อง

ข้อแรก เอกสารสมมติว่าองค์กรใช้ผลิตภัณฑ์ของ Claude เป็นแกน ตั้งแต่ Claude Code, Cowork ไปจนถึง Claude Tag ซึ่งเป็น beta

ถ้าทีมคุณใช้เครื่องมืออื่น แนวคิดยังใช้ได้ แต่ชื่อไฟล์และคำสั่งต้องแปลงเอง

ข้อที่สอง การเปลี่ยนทั้งหกระยะพร้อมกันจะล้มเหลว เอกสารเองก็บอกว่าควรเริ่มจาก play ที่ไม่มีลูกศรชี้เข้า

สำหรับทีมส่วนใหญ่ ผมคิดว่าจุดเริ่มที่คุ้มที่สุดคือ CLAUDE.md กับ feedback loop เพราะสองอย่างนี้ให้ผลเร็วโดยไม่ต้องขออนุมัติองค์กร

ข้อที่สาม ต้นทุนไม่ได้อยู่ที่ค่าโมเดลอย่างเดียว แต่อยู่ที่เวลาของคนตรวจ ซึ่งเป็นทรัพยากรที่หายากกว่า

ถ้าทีมคุณมีคนรีวิวสองคน การเปิด session ขนานกันห้าวันพร้อมกันจะทำให้คิวตรวจยาวขึ้น ไม่ใช่เร็วขึ้น

ข้อที่สี่ เรื่อง source of truth เอกสารเตือนว่าองค์กรมักมี Jira หรือเครื่องมือ requirement ที่ auditors ยอมรับอยู่แล้ว

ทางที่ปลอดภัยคือประกาศให้ชัดว่าอะไรคือต้นฉบับ และให้อีกฝั่งเก็บลิงก์พร้อม commit SHA

ถ้าจะเริ่มในทีมคุณ สามสัปดาห์แรกที่ผมแนะนำ

สัปดาห์แรก เขียน CLAUDE.md ให้สั้นไม่เกินหนึ่งหน้า ใส่คำสั่ง build test lint, convention ที่สำคัญ และข้อผิดพลาดที่ทีมเจอบ่อย

สัปดาห์ที่สอง เลือกงานหนึ่งงานที่เล็กและมีเทสต์ครอบอยู่แล้ว ลองใช้ plan mode เขียน plan.md ก่อนลงมือ แล้ววัดว่ากี่รอบถึง merge

สัปดาห์ที่สาม เอา incident หรือ bug ที่เพิ่งเจอมาเขียนเป็น eval หนึ่งข้อ แล้วผูกเข้ากับ CI เมื่อคอนฟิกเปลี่ยน

ถ้าสามสัปดาห์นี้รอด ค่อยขยับไปเรื่องประตูอนุมัติและการ deploy

สรุป

สาระของ AI-native SDLC ไม่ใช่การใช้ AI ให้เขียนโค้ดเร็วขึ้น แต่คือการย้ายจุดที่คนใช้ความคิดไปอยู่ตรงประตูตัดสินใจ

โค้ดเร็วขึ้นเท่าไร ประตูก็ต้องชัดขึ้นเท่านั้น ไม่งั้นความเร็วจะกลายเป็นความเสี่ยงที่ไม่มีใครเห็น

ถ้าคุณกำลังมองว่าจะเริ่มจากตรงไหนในทีมตัวเอง เล่าให้ผมฟังได้ว่าตอนนี้คอขวดอยู่ที่ขั้นไหน ผมช่วยเลือก play แรกให้ได้

แหล่งอ้างอิง

[1] Anthropic, "The AI-native SDLC playbook", 21 ส.ค. 2026, สืบค้น 23 ต.ค. 2026. https://claude.com/resources/articles/the-ai-native-sdlc-playbook

[2] Anthropic, "Claude Code: Plan mode and permission modes", สืบค้น 23 ต.ค. 2026 (คำอธิบาย plan mode ที่ agent อ่านโค้ดได้แต่ยังแก้ไฟล์ไม่ได้). https://code.claude.com/docs/en/permission-modes

[3] Anthropic, "Claude Code: Memory (CLAUDE.md)", สืบค้น 23 ต.ค. 2026 (ไฟล์ context ที่ agent อ่านทุก session). https://code.claude.com/docs/en/memory

[4] Anthropic, "Claude Code: Hooks reference", สืบค้น 23 ต.ค. 2026 (กลไก hook สำหรับบังคับใช้กฎแบบตายตัว). https://code.claude.com/docs/en/hooks

[5] Anthropic, "Claude Code: Skills", สืบค้น 23 ต.ค. 2026 (วิธีเขียนและติดตั้ง skill ขององค์กร). https://code.claude.com/docs/en/skills

[6] Anthropic, "How the Claude Code team does code review", 15 ต.ค. 2026, สืบค้น 23 ต.ค. 2026 (บริบทเพิ่มเติมเรื่องการรีวิวโค้ดที่ agent produce). https://claude.dev/blog/solving-code-review-at-anthropic/

[7] Anthropic, "Claude Code: Subagents", สืบค้น 23 ต.ค. 2026. https://code.claude.com/docs/en/sub-agents

[8] Anthropic, "Claude Code: Worktrees", สืบค้น 23 ต.ค. 2026. https://code.claude.com/docs/en/worktrees

[9] Anthropic, "Claude Security", สืบค้น 23 ต.ค. 2026 (การสแกนโค้ดตามรอบแบบโฮสต์). https://claude.com/product/claude-security