AI เขียนโค้ดไม่ใช่คอขวดอีกต่อไป แล้วทำไมทีมยังช้า? 4 กระบวนการที่ทีม Claude Code รื้อทิ้ง

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI · 18 ตุลาคม 2026

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

ทุกกระบวนการที่ทีมซอฟต์แวร์ใช้อยู่ทุกวันนี้ ถูกสร้างขึ้นบนสมมติฐานเดียว

สมมติฐานนั้นคือ การเขียนโค้ดเป็นส่วนที่แพงที่สุด

waterfall เกิดจากสมมติฐานนี้ agile ก็เกิดจากสมมติฐานนี้ ทุกพิธีกรรมที่เราเคยทำ ตั้งแต่การเขียน design doc หนา ๆ ไปจนถึงการประชุมรีวิวรายสัปดาห์ ล้วนเป็นวิธีจัดการกับความจริงข้อนั้น

Fiona Fung หัวหน้าฝ่ายวิศวกรรมและผลิตภัณฑ์ของ Claude Code และ Cowork [2] บอกว่า ความจริงข้อนั้นเปลี่ยนไปแล้ว และกระบวนการที่เราตั้งไว้ยังไม่รู้ตัว

หมายเหตุเรื่องตำแหน่ง: คำว่า "หัวหน้าฝ่ายวิศวกรรมและผลิตภัณฑ์" ผมยึดจากคำแนะนำตัวของเธอเองในวินาทีที่ 0:34 ของวิดีโอ ที่เธอพูดว่า "and I lead Claude Code and CoWork Engineering and Products" [2]

หน้าทางการของ Anthropic เรียกเธอต่างกันในแต่ละหน้า คือหน้าซีชชันรุ่นโตเกียวและลอนดอนเขียนว่า Leader for Engineering and Product for Claude Code and Cowork [13][20]

ขณะที่หน้าซีชชันรุ่นซานฟรานซิสโกเขียนว่า Director of Engineering for Claude Code และช่องผู้บรรยายว่า Manager of the Claude Code and Cowork Team [19] ส่วนหน้าบทความเขียนว่า Director of Engineering ประจำ Claude Code และ Claude Cowork [1]

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

"On the Claude Code team, writing code, writing tests, and refactoring rarely slows us down anymore. But the bottlenecks didn't go away when agentic coding took away the actual need to type code. Verification, code review, and security took their place." [1]

คำแปล: ที่ทีม Claude Code การเขียนโค้ด เขียนเทสต์ และ refactor แทบไม่ทำให้เราช้าอีกแล้ว

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

ทอล์กของเธอเปิดที่งาน Code with Claude ที่ซานฟรานซิสโก วันที่ 6 พฤษภาคม 2026 [2][11] และถูกจัดซ้ำในรุ่นลอนดอนกับโตเกียว [13][20]

บทความนี้ผมเขียนจากสามชั้นของหลักฐาน คือตัวทอล์กความยาว 28 นาที หน้าบทความฉบับเต็มของ Anthropic และเอกสารทางการของเครื่องมือทุกตัวที่เธอพูดถึง

เป้าหมายคือให้อ่านจบแล้วลงมือได้จริง ไม่ใช่ให้อ่านแล้วเห็นด้วยอย่างเดียว

ไม่มีตัวเลขผลลัพธ์ในทอล์ก 28 นาที

ผมต้องบอกก่อนว่าทอล์กนี้ ไม่มีตัวเลขผลลัพธ์สักตัว

ผมไล่ตัวเลขทุกตัวที่เธอเอ่ยในบทพูด 28 นาที แล้วไม่พบตัวใดที่เป็นผลลัพธ์ของงานเลย

ตัวอย่างตัวเลขที่เธอเอ่ย:

• "50 people" คือขนาดห้องประชุมที่เธอเสนอให้ยกเลิก
• "10 ICs to one manager" คือบรรทัดฐานการรับคนแบบเดิมที่ทีมเธอไม่ใช้แล้ว
• "Visual Studio 2005" คือจุดเริ่มอาชีพของเธอ
• "stay up at 3PM" คือตัวอย่างวัฒนธรรมที่ต้องระวัง ไม่ใช่ตัวชี้วัด

⇒ ไม่มีตัวเลขสักตัวที่เป็นค่าก่อนหรือค่าหลังของผลลัพธ์ ไม่มีเปอร์เซ็นต์ว่าเร็วขึ้นเท่าไร และไม่มีเป้าให้เทียบ

คำอย่าง "onboarding เร็วขึ้นมาก" ของเธอจึงเป็นคำบอกทิศทาง ไม่ใช่ตัวเลข

⇒ ผมจะไม่เขียนเป็นตัวเลขให้คุณ เพราะเธอไม่ได้ให้มา และผมจะบอกตรง ๆ ทุกจุดที่ตัวเลขขาด

ตัวเลขจริงที่ Anthropic เปิดเอง นอกทอล์ก

แต่เดี๋ยวก่อน การที่ทอล์กไม่มีตัวเลข ไม่ได้แปลว่าไม่มีตัวเลขอยู่เลย

Anthropic เปิดตัวเลขชุดจริงของ Code Review ไว้ในประกาศผลิตภัณฑ์ของตัวเอง ฉบับวันที่ 9 มีนาคม 2026 [14]

• ผลผลิตโค้ดต่อวิศวกรหนึ่งคนของ Anthropic โตขึ้น 200% ในปีที่ผ่านมา
• สัดส่วน PR ที่ได้คอมเมนต์รีวิวอย่างมีเนื้อหา เพิ่มจาก 16% เป็น 54%
• ข้อที่ระบบรายงานแล้ววิศวกรไม่เห็นด้วย มีน้อยกว่า 1%
• PR ใหญ่ที่เปลี่ยนเกิน 1,000 บรรทัด 84% ตรวจเจอประเด็น เฉลี่ย 7.5 เรื่อง
• PR เล็กต่ำกว่า 50 บรรทัด ลดลงเหลือ 31% เฉลี่ย 0.5 เรื่อง
• เวลารีวิวเฉลี่ยราว 20 นาที คิดเงินเฉลี่ย 15 ถึง 25 ดอลลาร์ต่อครั้ง

⇒ สองบรรทัดแรกของชุดนี้คือคำอธิบายทั้งหมดของทอล์ก 28 นาทีนั้น

ผลผลิตโต 200% แต่สัดส่วนที่ได้รีวิวจริงขยับจาก 16% เป็น 54% ⇒ คอขวดไม่ได้อยู่ที่การเขียน มันอยู่ที่การอ่าน

และให้สังเกตความต่างระหว่าง PR ใหญ่กับ PR เล็ก PR ใหญ่เจอประเด็น 84% ส่วน PR เล็กเจอแค่ 31%

⇒ ถ้าทีมคุณเปิดรีวิวทุก PR รวมใบเล็ก ๆ คุณจ่ายเต็มจำนวนครั้ง แต่ได้ผลตอบแทนต่อครั้งต่ำกว่ามาก

และหลังเปิดใช้เต็มรูปแบบเมื่อวันที่ 15 ตุลาคม 2026 ตัวเลขเวลาถูกอัปเดตว่า เร็วขึ้นราวสามเท่า จากราว 20 นาที เหลือ 6 ถึง 10 นาที [15]

และในบทความแยกที่ทีม Claude Code เขียนเรื่องกระบวนการรีวิวของตัวเอง มีตัวเลขที่ผมคิดว่าสำคัญที่สุดในบรรดาทั้งหมด [18]

• Claude เขียนโค้ดของ Claude Code เองราว 90 เปอร์เซ็นต์
• PR ที่ merge ได้ในคลังของ Claude Code เพิ่มขึ้นมากกว่าสองเท่า ระหว่างเดือนมิถุนายนถึงกันยายน ขณะที่สัดส่วนที่ต้องย้อนกลับลดลงมากกว่า 40 เปอร์เซ็นต์
• การเปลี่ยนแปลงที่ลงสู่ monorepo ของ Anthropic เพิ่มจากราว 2,500 ครั้งต่อวันในเดือนพฤษภาคม เป็นมากกว่า 30,000 ครั้งต่อวันในเดือนกันยายน

⇒ คู่ตัวเลขคู่ที่สองคือคู่ที่คุณควรสนใจที่สุด งานเพิ่มมากกว่าสองเท่า แต่ของที่ต้องย้อนกลับลดลง 40 เปอร์เซ็นต์

⇒ นั่นคือคำตอบว่า "รีวิวน้อยลงแล้วคุณภาพไม่ตกได้ไหม" ซึ่งเป็นคำถามที่คนสงสัยมากที่สุด และเป็นคำถามที่ Anthropic ตอบด้วยตัวเลขของตัวเอง ไม่ใช่ด้วยคำโฆษณา

บริบท: สิ่งที่เปลี่ยนไม่ใช่ความเก่งของ AI

เธอเริ่มอาชีพช่วงต้นทศวรรษ 2000 กับ Visual Studio [1]

ตอนนั้นซอฟต์แวร์ส่งถึงมือลูกค้าด้วยแผ่น CD-ROM และมีกำหนดส่งของโรงงานผลิตที่ขยับไม่ได้ [1]

พอมนุษย์แจกซอฟต์แวร์ผ่านอินเทอร์เน็ตได้ ทุกอย่างก็เปลี่ยนเป็นส่งอัปเดตต่อเนื่อง [1]

และตอนนี้มันเปลี่ยนอีกรอบ คราวนี้เปลี่ยนที่ เวลาและจำนวนคนที่ต้องใช้ในการเขียนซอฟต์แวร์ [1]

จุดที่ผมคิดว่าสำคัญที่สุดของทอล์กนี้คือประโยคสั้น ๆ ประโยคหนึ่ง

และประโยคที่เธอพูดไว้ตอนนาทีที่ 6:16 คือ

"... rarely do processes kill themselves." [2]

คำแปล: กระบวนการแทบไม่เคยฆ่าตัวเอง

ชื่อช่วงของวิดีโอตอนนั้นก็ตั้งไว้ว่า Processes rarely kill themselves ซึ่งเป็นใจความเดียวกัน [2]

เราตั้งกระบวนการขึ้นมาเพราะมีช่องว่างที่ต้องปิด

พอช่องว่างนั้นหายไป กระบวนการไม่หายตาม มันค้างอยู่ตรงนั้น กินเวลา กินคน และไม่มีใครกล้าถามว่าทำไมยังต้องทำ

4 กระบวนการที่เธอบอกว่าใช้ไม่ได้แล้ว

1. การวางแผน: จาก roadmap หกเดือน ไปเป็น JIT

ตอนที่เธอเข้าร่วมทีม เธอเขียน roadmap หกเดือนที่ค่อนข้างดีไว้ฉบับหนึ่ง

แล้วมันก็ตกยุคไปตอนเดือนที่สาม

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

วิธีที่ทีมใช้ตอนนี้ เธอเรียกมันว่า just-in-time planning เทียบกับการ compile แบบ JIT

แนวคิดคือ ทำเท่าที่จำเป็น ในจังหวะที่จำเป็น

พิธีกรรมการวางแผนย้ายจาก design doc มาเป็นการคุยกันใน PR หรือใน prototype

เธอบอกว่าพื้นที่นี้เคลื่อนเร็วมาก ทีมจึงแทบไม่ทำ product review แบบเดิม

ลำดับที่ทีมใช้ตอนนี้คือ prototype ก่อน เอา user ภายในมาใช้เยอะ ๆ แล้วลงมือตาม feedback

2. การตามหาบริบท: เลิกถามคนเขียนโค้ด

ในอดีต ถ้าอยากรู้ว่าทำไมโค้ดถึงเป็นแบบนี้ ขั้นแรกคือหาคนที่เขียนมัน

ตอนนี้คำถาม "ใครทำการเปลี่ยนแปลงนี้" ไม่ใช่คำถามที่ดีพออีกแล้ว เพราะ PR ทุกใบมี Claude ช่วย

norm ใหม่คือ ถามให้ลึกหนึ่งชั้นว่า คุณต้องการอะไรกันแน่ [1]

• ต้องการรู้ว่าใครทำให้เกิด regression
• ต้องการผู้เชี่ยวชาญมาตอบคำถามลูกค้า
• หรือต้องการบริบทของการตัดสินใจครั้งนั้น

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

และมีคำถามที่สองที่ทีมถามตามทุกครั้ง: มีวิธี automate สิ่งนี้ไหม

"Having Claude summarize customer feedback channels every morning went from a ritual I did manually with my coffee to something I just have running automatically in the background." [1]

คำแปล: การให้ Claude สรุปช่องทาง feedback ของลูกค้าทุกเช้า เคยเป็นพิธีกรรมที่เธอทำเองพร้อมกาแฟ ตอนนี้มันทำงานเบื้องหลังเองอัตโนมัติอยู่แล้ว

3. การรีวิวโค้ด: trust but verify

ทีมนี้ใช้ Code Review หนักมาก [3]

Claude รับงานเหล่านี้ไป

• จัดการสไตล์และ linting ทั้งหมด
• ขอ feedback ใน PR
• จับบั๊กและแก้ก่อน commit เต็มรูปแบบ
• เพิ่มเทสต์ให้

จุดที่ยังต้องมีคน คือจุดที่ต้องใช้ความชำนาญเฉพาะทาง

• การรีวิวด้านกฎหมาย เธอต้องการให้คู่หูฝ่ายกฎหมายของเธออยู่ในวงเสมอ เมื่อเป็นเรื่องระดับความเสี่ยงที่ยอมรับได้
• ขอบเขตความไว้ใจและโค้ดที่อ่อนไหวด้านความปลอดภัย ต้องให้ผู้เชี่ยวชาญด้านนั้น
• product manager และ designer ต้องอยู่ในวงเรื่องรสนิยมและ product sense

และเธอกำกับหนึ่งอย่างที่ผมคิดว่าสำคัญสำหรับคนที่กำลังจะลอกวิธีนี้ไปใช้

"It's important to continually evaluate, though, because the right balance of trust vs. verify will keep changing as the models improve. What you need humans for today might look different with the next model." [1]

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

⇒ นี่ไม่ใช่สูตรตายตัว และเธอไม่ได้ขายเป็นสูตรตายตัว

4. โครงทีม: บทบาทเบลอ

นี่คือส่วนที่ผมคิดว่าหลายทีมจะรู้สึกได้เร็วที่สุด

PM ที่ทีมเธอเขียนโค้ดกันเยอะแล้ว และเธอบอกว่าเป็นเรื่องน่าสนุกที่ได้เห็น

คนที่ไม่ได้จบสายเขียนโค้ดก็ทำวิศวกรรมได้มากขึ้น ขณะที่วิศวกรก็รับงานอย่างงานเนื้อหาและงานออกแบบ ซึ่งเดิมไม่เคยอยู่ในฝั่งเทคนิค

เธอให้น้ำหนักกับคนสองแบบ

• creative builder ที่มี product sense คนที่อยากรู้อยากเห็นและอยากส่งผลิตภัณฑ์ที่แก้ปัญหาจริง
• วิศวกรที่เชี่ยวชาญระบบลึก เธอเล่าว่าตอนเข้า ทีมขาดคนสาย systems และต้องใช้ตอนสร้าง Claude Code บนเว็บ เพื่อให้รัน Claude ได้ทุกที่ [1][4]

ส่วนที่เธอให้น้ำหนักน้อยลง คือ throughput ดิบ

เธอบอกตรง ๆ ว่าโมเดลจัดการส่วนนั้นไปแล้ว คำถามที่สำคัญกว่าคือ ตรงไหนที่คุณยังต้องใช้ความชำนาญของมนุษย์ และนั่นคือจุดที่เธอโฟกัส

สิ่งที่หน้าสรุปตัดออก แต่ผมคิดว่าคมที่สุดในทอล์ก

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

เถียงกันด้วยโค้ด ไม่ใช่ไวต์บอร์ด

เมื่อเธอเข้าร่วมทีมใหม่ ๆ เธออยากทำ refactor สักชิ้นเพื่อทำความรู้จักโค้ดเบส

เธอกับ Boris มีการถกเถียงเชิงเทคนิคกันว่าไปทางไหนดี และเธอเล่าว่าเธอ เกือบหยิบเครื่องมือเก่าของตัวเองออกมาใช้

"I almost tapped him on the shoulders, go, let's go to that room and have a whiteboard and we can and I'm like, wait a minute. Nowadays, I can just generate all the different options we've been discussing. I generated three PRs." [2]

คำแปล: เธอเกือบจะแตะไหล่เขาแล้วบอกว่า ไปห้องนั้นกัน ไปเขียนไวต์บอร์ดกันเถอะ

แล้วเธอก็นึกได้ว่า เดี๋ยวก่อน ตอนนี้เธอสร้างทุกทางเลือกที่เราเถียงกันอยู่ได้เลย เธอสร้าง PR สามใบ

แต่จุดที่เธอให้ความสำคัญไม่ใช่จำนวน PR

เธอบอกว่าเธอไม่ได้สนแค่การ implement ของ API แต่สน ผลกระทบต่อทุกคนที่เรียก API นั้น

การมีสามเวอร์ชันให้เทียบทำให้การถกเถียงไม่ใช่เรื่อง "แบบไหนสวยกว่า" อย่างเดียว แต่เป็น "แบบไหนกระทบคนอื่นน้อยกว่า"

⇒ ตอนที่การสร้างแพง การเถียงกันเป็นวิธีประหยัดที่ถูก แต่ตอนที่การสร้างถูก การเถียงกันกลับกลายเป็นส่วนที่แพง

และเธอเตือนวัฒนธรรมที่ต้องระวังไว้ด้วย ซึ่งผมคิดว่าเป็นคำเตือนที่ตรงที่สุดในทอล์ก

เธอบอกว่าเรื่องที่ยอมรับไม่ได้คือการปล่อยให้กลายเป็น "ใครเช็กอินทีหลังชนะ"

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

⇒ ตั้งวัฒนธรรมเรื่อง alignment ให้ชัด ก่อนที่ความเร็วจะสร้างเกมที่ไม่มีใครตั้งใจสร้าง

Shift left: ย้ายการตรวจจับไปต้นทาง

เธอบอกว่ามีงานที่ทีมยังต้องทำอีกเยอะ และเรียกว่า shift left

แนวคิดคือ ในอดีตเราเอาโค้ดออกไปก่อน แล้วรอให้มีคนเจอบั๊ก

เป้าหมายคือ automate ให้จับได้เร็วขึ้น ใกล้ต้นทางมากขึ้น

เธอเล่าเคสของตัวเองว่าแก้บั๊กในระบบ resume แล้ววันถัดมาอ่านเธรดของ Boris เจอมีคนแท็กเขาว่าเจอบั๊ก

เธอบอกว่ารู้สึกเหมือนหัวใจวายแวบหนึ่ง และถามตัวเองว่า ฉันเพิ่งสร้างบั๊กไปใช่ไหม

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

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

3 หลักที่ทีมห้ามต่อรอง

เธอแบ่งชัดว่าอะไรเป็น หลักของทีมที่ต้องทำ และอะไรที่ปล่อยให้แต่ละ pod หาทางเอง

หนึ่ง: dogfood ผลิตภัณฑ์ตัวเองอย่างไม่ลดละ

สมาชิกทีม Claude Code ทุกคน รวมพันธมิตรข้ามสาย ต้องใช้ทั้ง Claude Code และ Claude Cowork

สอง: รักษาทีมให้แบนที่สุด

ตอนเธอเข้าทีม เธอต้องการให้ ผู้จัดการทุกคนเริ่มจากเป็น individual contributor ก่อน

เพื่อเรียนรู้ว่าจะเป็นวิศวกรที่มีประสิทธิภาพในทีมนี้ได้อย่างไรด้วยการส่งงานจริง

ทีมมีพันธกิจเดียวคือ Claude Code กับ Claude Cowork ผู้จัดการดูแล pod ของงาน แต่ทีมยังคล่องตัวพอจะย้ายคนไปตรงที่มีงาน

สาม: อย่าลังเลที่จะฆ่ากระบวนการที่ใช้ไม่ได้แล้ว

"When something doesn't make sense anymore, team members have explicit permission to question and kill old processes." [1]

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

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

ภายในกรอบไม่กี่ข้อ แต่ละ pod ตัดสินใจเองได้ว่าจะใช้ Claude ทำ triage อย่างไร จะจัดพิธีกรรมวางแผนหรือ standup แบบไหน และ workflow ไหนจะถูก automate ก่อน

3 ตัวชี้วัดที่เธอบอกว่าหัวหน้าวิศวกรรมทุกคนควรเริ่มวัด

หนึ่ง: เวลาตั้งตัวของคนใหม่ ลดลง

คำถามคือวิศวกร designer หรือ PM ใช้เวลานานแค่ไหนถึงจะเริ่มทำงานได้จริง [1]

เธอบอกว่าในทีมของเธอเร็วขึ้นมากเมื่อเทียบกับปีก่อน ถึงขั้นที่วิศวกรส่งโค้ดจริงได้ภายในสัปดาห์แรก [1][2]

แต่เธอไม่ได้ให้ค่าตัวเลข ทั้งค่าเดิมและค่าใหม่

สอง: วงจรชีวิตของ PR สั้นลง

อันนี้เธอบอกว่าน่าสนใจเป็นพิเศษ เพราะมันช่วยบอกได้ว่าคอขวดของคุณไปโผล่ที่อื่นแล้วหรือยัง [1]

เมื่อทีมสร้างโค้ดได้มากขึ้น ระบบ build และ CI อาจตามไม่ทันกลายเป็นตัวใหม่ที่ทำให้ช้า [1]

⇒ ถ้า PR cycle time ไม่ลด ทั้งที่คุณลดงานเขียนโค้ดได้แล้ว ให้ไปดู CI ก่อน

สาม: สัดส่วน commit ที่มี Claude ช่วย เพิ่มขึ้น

ในทีมของเธอ ค่าเริ่มต้นคือ ทุก commit มี Claude ช่วย [1]

เธอบอกว่าเธอแทบไม่เห็น commit ที่ไม่มี Claude ช่วยเลยในสี่เดือนที่ผ่านมา [1][2]

และเธอกำกับไว้ทันที

"Don't confuse throughput with success. Throughput is one metric, but the real metric is measuring the thing you're trying to solve." [1]

คำแปล: อย่าสับสนระหว่าง throughput กับความสำเร็จ throughput เป็นตัวชี้วัดตัวหนึ่ง แต่ตัวชี้วัดจริงคือการวัดสิ่งที่คุณกำลังพยายามแก้

เธอวิจารณ์พาดหัวข่าวที่ว่า "บริษัทนี้มีโค้ดที่ AI ไม่ได้สร้างกี่เปอร์เซ็นต์" ว่าเป็นตัวเลขที่ดูดี แต่ไม่ได้ตอบว่าผลิตภัณฑ์ดีขึ้นไหม [2]

⇒ ถ้าตัวเลขเพิ่มแต่ผู้ใช้ไม่ดีขึ้น แปลว่าวัดผิด

ทำไมการเขียนโค้ดถึงถูกลง แต่การตรวจกลับแพงขึ้น

ย่อหน้านี้ผมอธิบายเอง ไม่ได้ยกมาจากทอล์กหรือเอกสารของใคร เพื่อให้เห็นว่าทำไมคอขวดถึงย้ายที่แบบนี้

agent ที่ขับด้วย LLM ผลิตข้อความทีละโทเคน

แต่ละก้าว โมเดลคำนวณ Probability ของโทเคนถัดไป แล้วแปลงเป็นน้ำหนักด้วย Softmax

ตัวโมเดลเป็น Transformer ที่ใช้กลไก Attention ชั่งน้ำหนักทุกส่วนของบริบทที่สะสมมา ซึ่งในทางคณิตศาสตร์คือการคำนวณบน Vector และ Matrix ขนาดใหญ่

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

ตอนฝึก น้ำหนักถูกปรับด้วย Gradient Descent เพื่อลด Cross-entropy ซึ่งเป็นค่าที่มาจาก Information Theory และวัดด้วย Entropy

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

⇒ การสร้างโค้ดที่ ดูน่าเชื่อถือ จึงเป็นการคำนวณรอบเดียวบน Linear Algebra ที่ GPU ทำได้เร็วและถูก

⇒ แต่การรู้ว่าโค้ดนั้น ทำงานได้จริง ต้องรันจริง ลองเคสจริง และตัดสินด้วยบริบทที่โมเดลไม่ได้ถูกฝึกให้วัด

นั่นคือเหตุผลเชิงกลไกที่เธอบอกว่า verification, code review และ security เข้ามาแทนที่ ไม่ใช่เพียงคำพูดเชิงบริหาร

ภาคปฏิบัติ: ทำตามได้จริงโดยไม่ต้องอยู่แผน Enterprise

นี่คือส่วนที่ผู้บริหารหลายคนอยากรู้ และเป็นส่วนที่หน้าสรุปไม่ตอบ

ทีม Claude Code ใช้ Code Review ที่เป็นบริการจัดการให้ ซึ่งมีกำแพงอยู่ และผมจะบอกตรง ๆ ก่อนว่ากำแพงนั้นคืออะไร

แต่คุณไม่จำเป็นต้องซื้อแผน Enterprise เพื่อเริ่มทำตามหลักของเธอ

เพราะ Claude Code มีคำสั่งรีวิวในตัวที่ ใช้ได้ทุกแผน

ทางที่ 1: /code-review ในเซสชันของคุณ ใช้ได้ทุกแผน

พิมพ์ที่พรอมป์ตของ Claude Code ในเซสชันที่คุณทำงานอยู่ [5]

/code-review

ถ้าไม่ระบุเป้าหมาย มันจะรีวิวการเปลี่ยนแปลงบนแบรนช์ปัจจุบัน

มันทำงานเป็น subagent เบื้องหลังที่มี context window ของตัวเอง คำค้นจึงไม่ไปกินบริบทของบทสนทนาหลัก และผลลัพธ์จะโผล่มาในบทสนทนาเมื่อเสร็จ

ระบุเป้าหมายได้ตามนี้ [5]

• /code-review สำหรับแบรนช์ปัจจุบันรวมงานที่ยังไม่ commit
• /code-review HEAD~15..HEAD สำหรับ 15 คอมมิตล่าสุด
• /code-review main...my-feature สำหรับเทียบสองแบรนช์
• /code-review abc1234^..abc1234 สำหรับคอมมิตเดียว
• /code-review 1234 สำหรับ pull request หมายเลขนั้น
• /code-review src/auth สำหรับไฟล์หรือโฟลเดอร์

แฟล็กที่ใช้บ่อย

• --fix ให้ Claude ลงมือแก้ผลที่เจอในเวิร์กทรีของคุณ การแก้ทุกครั้งยังผ่านโหมดสิทธิ์ของคุณตามปกติ
• --comment ให้โพสต์ผลเป็นคอมเมนต์ใน pull request บน GitHub หรือเป็นโน้ตเดียวบน merge request ของ GitLab

ข้อควรรู้เรื่องค่าใช้จ่าย: คำสั่งนี้ นับเข้าโควตาของแผนคุณหรือการเรียกเก็บแบบ API เหมือนส่วนอื่นของเซสชัน ไม่ใช่บริการแยกที่คิดเงินต่างหาก [5]

⇒ สรุปสั้น ๆ คือ ถ้าคุณมี Claude Code อยู่แล้ว คุณเริ่มทดลองหลัก "trust but verify" ได้วันนี้โดยไม่ต้องขออนุมัติงบอะไร

ทางที่ 2: Claude Code GitHub Action (โอเพนซอร์ส ใช้ได้ทุกแผน)

Anthropic ระบุเองในประกาศว่า Code Review เป็นตัวเลือกที่ แพงกว่า ทางเลือกเดิมอย่าง Claude Code GitHub Action ซึ่ง ยังเป็นโอเพนซอร์สและยังใช้ได้อยู่ [14]

ตัวรีโป anthropics/claude-code-action อยู่ที่ 9,561 ดาว สัญญา MIT และ push ล่าสุดเมื่อ 16 ตุลาคม 2026 [16]

⇒ ถ้าคุณอยากได้บอตรีวิวที่รันบน CI ของตัวเอง ควบคุมค่าใช้จ่ายเอง และไม่ต้องมีแผน Team หรือ Enterprise ทางนี้คือทางของทีมเล็ก

ทางที่ 3: Code Review แบบบริการจัดการ (Team และ Enterprise)

ถ้าคุณต้องการให้ ทุก pull request ในรีโปถูกรีวิวอัตโนมัติ อันนี้ต้องใช้บริการจัดการ

ตอนเปิดตัว Anthropic อธิบายกลไกไว้สั้น ๆ ว่า "เมื่อ PR เปิดขึ้น Claude จะกระจายทีม agent ออกไปตามหาบั๊ก" [12]

โพสต์นั้นมีการตอบรับสูงถึง 61,184 ไลก์ และ 23.5 ล้านวิว [12]

สถานะล่าสุด: Code Review ออกจากช่วงพรีวิวและ เปิดใช้เต็มรูปแบบแล้วเมื่อวันที่ 15 ตุลาคม 2026 โดยยังจำกัดที่สองแผนนี้ [15]

องค์กร Enterprise ที่มีคุณสมบัติ ขอเครดิต Code Review ได้ขั้นต่ำ 10,000 ดอลลาร์ ภายในวันที่ 15 มกราคม 2027 เครดิตมีอายุ 30 วันนับจากวันที่ขอรับ [15]

หลังเปิดเต็มรูปแบบ แอดมินเลือกได้ สามระดับต่อรีโป คือ Quick, Standard (ค่าเริ่มต้น) และ Deep โดยตั้งค่าเริ่มต้นระดับองค์กรไว้ แล้ว override รายรีโปได้ [3]

เช็คก่อนว่าองค์กรคุณมีคุณสมบัติ [3]

• แผน Team หรือ Enterprise เท่านั้น
• ต้องเป็นรีโปบน GitHub รวมทั้ง GitHub Enterprise Server และ GitHub Enterprise Cloud ที่มี data residency
• ใช้ไม่ได้กับองค์กรที่เปิด Zero Data Retention หรือตั้งค่าตาม HIPAA และไม่อยู่ในความคุ้มครองของ BAA
• ยังไม่รองรับ customer-managed encryption keys (CMEK)
• ต่อให้ทีมเรียก Claude Code ผ่าน Amazon Bedrock, Google Cloud หรือ Microsoft Foundry ก็ยังต้องมีองค์กร Claude บนสองแผนนี้อยู่ดี

สิ่งที่ต้องมีก่อนเริ่ม [6]

• บทบาท Owner ในองค์กร Claude ของคุณ สำหรับทุกขั้นบนหน้าแอดมิน
• Owner ขององค์กร GitHub สำหรับติดตั้ง Claude GitHub App และเชื่อมกับองค์กร Claude ถ้าคุณไม่ใช่ owner ต้องให้ owner ติดตั้งและเชื่อมให้ก่อน
• สิทธิ์เขียนในแต่ละรีโป จากบัญชี GitHub ที่เชื่อมกับ Claude

ขั้นตอนเปิดใช้ [6]

1. ไปที่ Admin settings > Claude Code บน claude.ai แล้วเปิดสวิตช์ Allow code review
2. ถ้ามีหน้าต่าง Connect GitHub เด้งขึ้น ให้กด Connect กรณีใช้ GitHub Enterprise Server ให้เลือกระบบของคุณในหน้าต่างนั้นก่อน
3. ติดตั้ง Claude GitHub App และเลือก หรือค้นหารีโปที่ต้องการ
4. ตั้ง ระดับความเข้มของการรีวิว และ จังหวะที่รีวิวทำงาน ในแต่ละรีโป

จุดที่ผมชอบที่สุดของดีไซน์นี้: รีวิวทั้งหมดรันบนโครงสร้างพื้นฐานของ Anthropic ⇒ คุณไม่ต้องเพิ่มไฟล์ workflow ลงในรีโปเลย [6]

⇒ ถ้าคุณเคยเจ็บกับการดูแลไฟล์ CI ของบอตตรวจโค้ดที่พังทุกครั้งที่ dependency อัปเดต ข้อนี้คือข้อดีที่จับต้องได้

จังหวะที่รีวิวทำงาน มีสามโหมด และมันคือตัวคุมค่าใช้จ่ายหลัก [7]

• Once after PR creation รีวิวครั้งเดียวตอนเปิด รีโอเพน หรือมาร์กว่าพร้อมรีวิว
• After every push รีวิวทุกครั้งที่ push ซึ่งคูณค่าใช้จ่ายตามจำนวนครั้งที่ push
• Manual ไม่รีวิวอัตโนมัติเลย

ข้อควรระวังเรื่องค่าใช้จ่าย เอกสารระบุว่ารีโปที่เพิ่งเพิ่ม

เริ่มต้นที่ After every push ซึ่งเป็นโหมดที่รีวิวมากที่สุด ⇒ ตรวจโหมดนี้ก่อนเพิ่มรีโปทุกครั้ง [7]

และ Code Review ไม่มีราคาต่อครั้งแบบคงที่ มันคิดตามการใช้งานโทเคนผ่าน usage credits แยกจากโควตาที่มากับแผน โดยเก็บกับ องค์กร ไม่ใช่คนที่เปิด PR [7]

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

คำสั่งในคอมเมนต์ที่ใช้ได้ [8]

• @claude review เริ่มรีวิวครั้งเดียว โดยไม่สมัครรับการรีวิวทุก push
• @claude review always เริ่มรีวิวและสมัครให้ PR ใบนั้นถูกรีวิวทุก push ต่อจากนี้
• @claude review once เหมือน @claude review

ปรับให้ตรงกับทีมคุณด้วย REVIEW.md และ CLAUDE.md

นี่คือส่วนที่ทำให้เครื่องมือกลายเป็นของทีมคุณจริง ๆ ไม่ใช่ของกลาง [9]

• CLAUDE.md เป็นคำสั่งระดับโปรเจกต์ที่ Claude Code อ่านทุกงาน รวมถึงตอนรีวิว การเปลี่ยนแปลงที่ขัดกับกฎในไฟล์นี้จะกลายเป็นประเด็นที่ถูกรายงาน
• REVIEW.md เป็นคำสั่งเฉพาะการรีวิว ใช้บอกว่าทีมอยากให้รายงานอะไร ระดับไหน และข้ามอะไร

วิธีใช้: วาง REVIEW.md ไว้ที่รากของรีโป แล้ว merge เข้าไป

จุดที่หลายทีมมองข้าม: เอกสารเตือนให้ ป้องกันแบรนช์หลักของคุณ เพราะไฟล์นี้กำหนดว่าอะไรจะถูกรายงาน ถ้าใครแก้ได้ การรีวิวก็เปลี่ยนตามเขา [9]

ทีมยังวาง REVIEW.md ในโฟลเดอร์ย่อยเพื่อเพิ่มกฎเฉพาะทางของโฟลเดอร์นั้นได้ด้วย

และทั้งตัวที่หาประเด็นกับตัวที่ตรวจซ้ำจะได้รับเนื้อหาของ REVIEW.md ⇒ กฎที่คุณเขียนจึงมีผลทั้งตอนหาและตอนยืนยัน

เจอผลลัพธ์แบบไหน

ผลการรีวิวจะมาเป็นคอมเมนต์บนบรรทัดที่เกี่ยวข้อง พร้อมเครื่องหมายสามระดับ [10]

• แดง = Important บั๊กที่ควรแก้ก่อน merge
• เหลือง = Nit เรื่องเล็ก ควรแก้แต่ไม่บล็อก
• ม่วง = Pre-existing บั๊กที่มีอยู่เดิมในโค้ด ไม่ได้เกิดจาก PR ใบนี้

ถ้าการรีวิวบันทึกเหตุผลไว้ จะมีส่วน Why this was flagged ให้กางดูได้ว่า Claude เห็นอะไรและยืนยันปัญหาอย่างไร

และประเด็นที่ผมคิดว่าสำคัญต่อวัฒนธรรมทีม: การรีวิวของ Claude ไม่เคยอนุมัติหรือบล็อก PR การตัดสินใจ merge ยังอยู่ที่ทีมคุณ [3]

เช็กลิสต์ทำตามได้จริง เรียงตามขั้นตอน

ส่วนนี้ผมไม่ได้คิดเอง ยกมาจากหัวข้อ "How you can adopt this process" ในบทความของทีม Claude Code โดยตรง

ซึ่งเป็นส่วนที่ผมคิดว่ามีค่าที่สุดของเอกสารทั้งหมด เพราะเขียนเป็นลำดับที่ทำได้จริง [18]

ก่อนเปิด pull request

• ให้ agent งานที่มันรันเองได้ และเขียนไว้ใน CLAUDE.md ให้สั้น
• เพิ่ม hook ที่รัน formatter กับ linter อัตโนมัติ
• รัน /code-review และ /security-review ในเครื่อง หรือให้ subagent ที่มีบริบทใหม่เป็นคนรีวิว diff
• เริ่ม REVIEW.md และย้ายคอมเมนต์ที่ทีมพูดซ้ำ ๆ เข้าไปในนั้น

ในทุก pull request

• บังคับ CI ให้ผ่านก่อนจึง merge ได้
• เพิ่มสามหัวข้อในเทมเพลต PR คือ Testing Risk และ How to revert
• เปิด AI reviewer ที่รีโปเดียวก่อน อาจเป็น Code Review หรือ Claude Code GitHub Action แล้วปรับ REVIEW.md สองสามสัปดาห์จึงค่อยขยาย
• เพิ่มการตรวจความปลอดภัยอัตโนมัติ และบังคับให้ทุกเธรดรีวิวปิดก่อน merge
• ปรับความเข้มให้ตรงกับความเสี่ยง งานประจำใช้รอบเร็ว งานที่พลาดแล้วแพงใช้รอบลึก ซึ่งตรงกับ Quick, Standard และ Deep
• จำกัดจำนวนรอบรีวิว หลังรอบแรก ๆ ให้รีวิวเฉพาะ diff ใหม่

การอนุมัติ

• เขียนชั้นความเสี่ยงเป็นลายลักษณ์อักษร และตัดสินจาก ตัวการเปลี่ยนแปลง ไม่ใช่ตัวคนเขียน
• เริ่มจากเข้ม แล้วผ่อนเมื่อมีหลักฐาน
• ใช้ CODEOWNERS และ branch protection ให้เส้นทางที่เกี่ยวกับ auth, billing, CI, workflow การปล่อยเวอร์ชัน และตัวติดตั้ง ต้องมีคนเสมอ
• ห้ามให้บอตอนุมัติแทนคนที่ระบบบังคับว่าต้องมี และยกเลิกการอนุมัติเดิมเมื่อมีคอมมิตใหม่

การ merge และหลังจากนั้น

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

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

ส่วนที่ผมเพิ่มเอง (ไม่มาจากเอกสาร)

สองข้อนี้ผมต่อยอดจากหลักของเขา ไม่ได้ยกมาจากเอกสารของ Anthropic

หนึ่ง: ทำ reversibility ก่อนทำ automation ถ้าทีมคุณยังเลือกได้อย่างเดียว ให้เลือกความสามารถในการย้อนกลับ

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

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

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

เสียงคัดค้านจากคนที่ต้องจ่ายเอง

ก่อนจบ ผมต้องพาคุณไปฟังอีกด้าน เพราะที่ผ่านมาทั้งบทความเล่าจากมุมของทีมที่สร้างเครื่องมือ

Anthropic เก่งเรื่องนี้จริง แต่เขาก็เป็นคนขายเครื่องมือ

ในเธรดของนักพัฒนาบน Reddit เรื่องการเปิดตัว Code Review มีข้อวิจารณ์ที่ผมคิดว่าตรงและควรค่าแก่การอ่าน [17]

ข้อแรกคือเรื่องค่าใช้จ่าย ผู้ใช้รายหนึ่งในเธรด [17] คำนวณว่าบริษัทเล็กที่ทำ PR วันละ 10 ถึง 15 ใบ จะจ่ายราว

300 ดอลลาร์ต่อวัน แล้วสรุปว่า "สุดท้ายคนจริงก็ยังต้องรีวิว PR อยู่ดี ฉะนั้น ณ จุดนั้นยังไม่ประหยัดอะไรเลย"

อีกคนในเธรดเดียวกัน [17] เขียนสั้น ๆ ว่า "ดูเหมือน codex จะได้ทำงานเป็นนักรีวิวโค้ดต่อไป" ซึ่งสะท้อนว่าเรื่องนี้ยังไม่ใช่ข้อสรุปของตลาด

ข้อที่สอง และผมคิดว่านี่คือข้อที่คมที่สุดของเธรดนั้น [17]: ถ้า PR ส่วนใหญ่ถูกสร้างโดย Claude แล้ว Claude มาเป็นคนรีวิว PR ใบนั้น นี่มัน Claude ตรวจงานตัวเองไม่ใช่หรือ

⇒ หลัก trust but verify ใช้ได้ก็ต่อเมื่อคนตรวจเป็นอิสระจากคนสร้าง

⇒ ถ้า Claude ทั้งเขียนและรีวิว คุณไม่ได้กำลังตรวจสอบคุณภาพ คุณกำลังตรวจทานความสม่ำเสมอของโมเดลตัวเดิมสองรอบ

Anthropic ตอบข้อนั้นไว้แล้ว อย่างจริงจัง

ตรงนี้ผมต้องให้เครดิตเขา เพราะคำตอบไม่ใช่การบอกว่า "ไม่เป็นไร เชื่อเรา"

ทีม Claude Code เขียนบทความแยกเรื่องกระบวนการรีวิวของตัวเองไว้ และลงวันที่ 15 ตุลาคม 2026 [18]

เขาเปิดด้วยข้อเท็จจริงที่ผมคิดว่าหลายคนไม่รู้ว่า "Claude เขียนโค้ดของ Claude Code เองราว 90 เปอร์เซ็นต์" แล้วตั้งคำถามกลับว่า แล้วเรารีวิวโค้ดกันอย่างไรในปริมาณแบบนั้น

คำตอบคือมีหกชั้น ไม่ใช่ชั้นเดียว [18]

1. ตรวจก่อนเปิด PR ให้ Claude รันเทสต์ บิลด์ และ linter แล้วให้ subagent ตัวที่สองรีวิว diff ในบริบทใหม่ที่ยังไม่เห็นการทำงานก่อนหน้า
2. CI ที่บังคับ ทั้ง lint, types, เทสต์ข้ามแพลตฟอร์ม, บิลด์ และแพ็กเกจจิง ถ้าแดงคือ merge ไม่ได้
3. Claude code review agent หลายตัวช่วยกันหาบั๊กแบบขนาน แล้ว ตัวยืนยันลงคะแนนทีละข้อที่พบ ก่อนจัดอันดับตามความรุนแรง
4. ตรวจความปลอดภัยแยกอีกชั้น ข้อที่ค้างจากสองชั้นบนบล็อกการ merge
5. จัดชั้นตามความเสี่ยง ตัวแยกประเภทกำหนดว่าใบนี้ต้องมีคนดูศูนย์คน หนึ่งคน หรือสองคน และบางเส้นทางบังคับว่าต้องมีคนเสมอ
6. คิว merge แล้วตรวจซ้ำ บน main ล่าสุด จากนั้นใช้ flag, ปล่อยเป็นขั้น และย้อนกลับได้ในขั้นตอนเดียว

และจุดที่ผมคิดว่าฉลาดที่สุดคือเขาเปลี่ยนคำถามทิ้ง

"We think 'did a human read the code?' is an imprecise proxy for 'what could go wrong with this change, and which check, automated or human, is the right one to catch it?'" [18]

คำแปล: เรามองว่า "มีคนอ่านโค้ดไหม" เป็นตัวแทนที่ไม่แม่นนักของคำถามที่แท้จริงว่า การเปลี่ยนแปลงนี้มีอะไรผิดพลาดได้ และการตรวจแบบไหน ทั้งอัตโนมัติหรือโดยคน คือตัวที่เหมาะจะจับมัน

และเกณฑ์ตัดสินของเขาคือบรรทัดที่ผมคิดว่าทีมไหนก็ควรก็อปไปใช้

"Revert and incident rates are the guardrail: if they rise, we haven't saved human time, we've only moved it." [18]

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

⇒ ถ้าคุณจะบอกว่าลดเวลารีวิวได้ ตัวเลขที่ต้องเฝ้าคืออัตราการย้อนกลับกับเหตุขัดข้อง ไม่ใช่จำนวนชั่วโมงที่ประหยัดได้

⇒ และในทอล์กที่ซานฟรานซิสโก เธอพูดหลักเดียวกันกับตัวชี้วัดอื่นว่า อย่าสับสนระหว่าง throughput กับความสำเร็จ

ตัวเลขที่ทำให้คำตอบนี้มีน้ำหนักคือคู่นี้ ในคลังของ Claude Code ตั้งแต่เดือนมิถุนายนถึงกันยายน

PR ที่ merge ได้เพิ่มขึ้นมากกว่าสองเท่า ขณะที่สัดส่วนที่ต้องย้อนกลับลดลงมากกว่า 40 เปอร์เซ็นต์ [18]

⇒ งานเพิ่มสองเท่า ของที่พังลดลง ⇒ นี่คือหลักฐานว่า "รีวิวน้อยลงแล้วคุณภาพไม่ตก" เป็นไปได้จริง ไม่ใช่เพียงคำโฆษณา

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

เพราะมีตัวยืนยันที่แยกกันลงคะแนน และมี CI กับชั้นความปลอดภัยที่อิสระจากตัวเขียนจริง

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

⇒ สำหรับทีมที่ยังไม่มีหกชั้นนี้ ทางลัดที่ให้ผลใกล้เคียงที่สุดคือทำให้ทุกอย่างย้อนกลับได้ง่าย

เพราะนั่นคือชั้นที่ยังทำงานอยู่แม้ตัวตรวจจะพลาด และเป็นชั้นที่ทีมเล็กทำได้ตั้งแต่วันแรก

4 ข้อควรระวังก่อนลอกวิธีนี้ไปใช้

หนึ่ง: ทอล์กไม่มีตัวเลขผลลัพธ์ ผมย้ำอีกครั้งเพราะคนมักอ่านข้าม ตัวอย่างตัวเลขที่เธอเอ่ย (50 คน · 10 ICs ต่อผู้จัดการ · Visual Studio 2005 · stay up at 3PM) ไม่มีตัวใดเป็นผลลัพธ์ของงาน

ทุกคำว่า "เร็วขึ้น" ในทอล์กมาจากคำพูดของเธอ ไม่มีค่าก่อนและไม่มีค่าหลัง

⇒ ตั้งค่าตั้งต้นของทีมคุณเอง แล้วใช้ของทีมคุณเป็นหลัก

สอง: กำแพงแพ็กเกจ เครื่องมือที่ทอล์กชูเป็นพระเอกอย่าง Code Review บริการ ต้องอยู่แผน Team หรือ Enterprise

และใช้ไม่ได้กับองค์กรที่เปิด Zero Data Retention หรือตั้งค่า HIPAA

⇒ ถ้าองค์กรคุณติดข้อนี้ ให้ใช้ /code-review แทน อย่าเพิ่งสรุปว่าทำตามไม่ได้เลย

สาม: สมดุลที่ต้องประเมินซ้ำ เธอเตือนเองว่าสิ่งที่ต้องใช้คนทำวันนี้อาจต่างจากตอนโมเดลรุ่นถัดไปออกมา

⇒ วางแผนว่าใครจะทบทวนเรื่องนี้ และทุกกี่เดือน ดีกว่าตั้งเป็นนโยบายตายตัว

สี่: เธอเองก็ยังไม่จบ เธอบอกตรง ๆ ในทอล์กตอนนาทีที่ 26 ว่ายังมีคำถามที่ตัวเธอเองยังถามตัวเองอยู่ โดยยกเรื่องทีม iOS และ Android เป็นตัวอย่าง [2]

⇒ ผู้นำของทีมที่เล่าเรื่องนี้ก็ยังกำลังหาคำตอบอยู่ ไม่มีคู่มือสำเร็จรูปให้ลอกทั้งเล่ม

ปิดท้าย: คำถามเดียวที่ควรถาม

ถ้าจะเก็บอะไรจากทอล์กนี้ไปใช้ ผมคิดว่าเก็บอันนี้

เลือก workflow ที่เสียงดังที่สุดในทีมคุณ แล้วถามว่ามันยังทำหน้าที่เดิมอยู่ไหม

ถ้ายังมีทาง automate ก็ automate ถ้าไม่มีก็เลิกทำ

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

"And I'm like, this is a very expensive meeting. And I just asked that simple question of why are we having it?" [2]

คำแปล: และเธอพูดว่า นี่มันการประชุมที่แพงมาก แล้วเธอก็ถามคำถามง่าย ๆ ว่า เรามีประชุมนี้ทำไม

คำถามเดียวก็พอ และที่ประชุมก็เห็นพร้อมกันว่ามันไม่จำเป็น แล้วก็ยกเลิกไป [1]

⇒ คุณไม่ต้องมี AI เก่ง ๆ เพื่อเริ่มข้อนี้ก่อนเลย คุณต้องมีแค่คำถาม

แล้วทีมคุณล่ะ มีกระบวนการอะไรที่ยังทำอยู่ทั้งที่ไม่มีใครรู้ว่าทำไม?

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

[1] Fiona Fung (Director of Engineering, Claude Code และ Claude Cowork), "Running an AI-native engineering org" (บทความสรุปทอล์กจากงาน Code with Claude SF 2026 · เนื้อหาหลักของบทนี้มาจากหน้านี้ · หน้าบทความลงวันที่ 3 มิถุนายน 2026), 3 มิถุนายน 2026. https://claude.com/resources/articles/running-an-ai-native-engineering-org

[2] Fiona Fung, "Running an AI-native engineering org" (วิดีโอทอล์กความยาว 28:37 นาที · ช่อง Claude ทางการของ Anthropic · ใช้ยืนยันถ้อยคำและเรื่องเล่าที่หน้าสรุปไม่ได้เก็บไว้), 6 พฤษภาคม 2026. https://www.youtube.com/watch?v=igO8iyca2_g

[3] Anthropic, "Code Review" (เอกสารทางการ · ระบุคุณสมบัติขององค์กรที่ใช้ได้ รวมข้อจำกัดเรื่อง Zero Data Retention, HIPAA และ CMEK), 2026. https://code.claude.com/docs/en/code-review

[4] Anthropic, "Claude Code on the web" (ประกาศเปิดตัว · ทีม Claude Code อ้างถึงงานนี้ในทอล์กตอนอธิบายการรับคนสาย systems · URL นี้คือปลายทางที่ลิงก์เดิมบน anthropic.com ส่งต่อไป), 20 ตุลาคม 2025. https://claude.com/resources/articles/claude-code-on-the-web

[5] Anthropic, "Review locally with /code-review" (เอกสารทางการ · ระบุว่าใช้ได้ทุกแผน เป้าหมายที่รองรับ แฟล็ก และวิธีคิดค่าใช้จ่าย), 2026. https://code.claude.com/docs/en/code-review-local

[6] Anthropic, "Set up Code Review" (ขั้นตอนเปิดใช้ · สิทธิ์ที่ต้องมี · และการที่รีวิวรันบนโครงสร้างพื้นฐานของ Anthropic จึงไม่ต้องเพิ่มไฟล์ workflow), 2026. https://code.claude.com/docs/en/code-review-setup

[7] Anthropic, "Code Review costs and usage" (วิธีคิดค่าใช้จ่าย · สามโหมดของ Review runs · ค่าเริ่มต้นของรีโปที่เพิ่งเพิ่มคือ After every push), 2026. https://code.claude.com/docs/en/code-review-costs

[8] Anthropic, "Read and request reviews on a pull request" (คำสั่งในคอมเมนต์ · ระดับความรุนแรงของสิ่งที่พบ · การตอบกลับผลการรีวิว), 2026. https://code.claude.com/docs/en/code-review-pull-requests

[9] Anthropic, "Customize Code Review" (วิธีใช้ REVIEW.md และ CLAUDE.md · ไฟล์ไหนอ่านเมื่อไร · คำเตือนให้ป้องกันแบรนช์หลัก), 2026. https://code.claude.com/docs/en/code-review-customize

[10] Anthropic, "Read Code Review findings" (ส่วนระบุระดับความรุนแรงของผลที่พบใน pull request), 2026. https://code.claude.com/docs/en/code-review-pull-requests#severity-levels

[11] Chris Ebert, "Notes from Code with Claude 2026" (บันทึกจากผู้เข้าร่วมงาน · ใช้ยืนยันวันที่จัดงาน 6 พฤษภาคม 2026 ที่ซานฟรานซิสโก), 8 พฤษภาคม 2026. https://chrisebert.net/notes-from-code-with-claude-2026/

[12] Claude (@claudeai ทางการ), โพสต์เปิดตัว Code Review บน X (Twitter) (บอกกลไก "ทีม agent" และใช้ยืนยันวันเปิดตัว 9 มีนาคม 2026 · 61,184 ไลก์ · 23,589,946 วิว ณ วันที่เก็บข้อมูล), 9 มีนาคม 2026. https://x.com/claudeai/status/2031088171262554195

[13] Anthropic, "Running an AI-native engineering org" หน้าซีชชันทางการ รุ่นโตเกียว งาน Code w/ Claude 2026 (ใช้ยืนยันชื่อเรื่อง วลีตำแหน่งผู้พูด และเกริ่นนำทางการที่ระบุว่า "เครื่องมือไม่ใช่ส่วนที่ยาก กระบวนการของคุณต่างหาก" · รุ่นลอนดอนใช้ถ้อยเดียวกัน ดู [20] ส่วนรุ่นซานฟรานซิสโกใช้ถ้อยต่างออกไป ดู [19]), 2026. https://claude.com/code-with-claude/session/tyo-running-an-ai-native-engineering-org

[14] Anthropic, "Introducing Code Review" (ประกาศเปิดตัว · ต้นทางของตัวเลขผลผลิต 200% · PR ที่ได้คอมเมนต์จาก 16% เป็น 54% · ความแม่นต่ำกว่า 1% ที่ถูกโต้แย้ง · 84% ของ PR ใหญ่ · ค่าใช้จ่ายเฉลี่ย 15 ถึง 25 ดอลลาร์ · และการที่ Claude Code GitHub Action ยังเป็นโอเพนซอร์ส), 9 มีนาคม 2026. https://claude.com/blog/code-review

[15] Anthropic, "Code Review is now generally available" (ประกาศเปิดใช้เต็มรูปแบบ 15 ตุลาคม 2026 · รีวิวเร็วขึ้นราวสามเท่าเป็น 6 ถึง 10 นาที · เครดิตขั้นต่ำ 10,000 ดอลลาร์สำหรับ Enterprise ที่มีคุณสมบัติ), 15 ตุลาคม 2026. https://claude.com/blog/code-review-is-now-generally-available

[16] GitHub, anthropics/claude-code-action (ที่เก็บโค้ดโอเพนซอร์ส สัญญา MIT · 9,561 ดาว · push ล่าสุด 16 ตุลาคม 2026 ณ วันที่เก็บข้อมูล), เข้าถึง 18 ตุลาคม 2026. https://github.com/anthropics/claude-code-action

[17] เธรดนักพัฒนาบน r/ClaudeAI เรื่องการเปิดตัว Code Review (เสียงผู้ใช้จริงที่ไม่ได้อยู่ฝ่าย Anthropic · ใช้เป็นมุมค้านเรื่องค่าใช้จ่าย และข้อกังวลว่าโมเดลกำลังตรวจงานตัวเอง), 9 มีนาคม 2026. https://www.reddit.com/r/ClaudeAI/comments/1rp9dps/introducing_code_review_a_new_feature_for_claude/

[18] Addy Osmani, Morgan Westlee Lunt และ Qing Wang (ทีม Claude Code), "How the Claude Code team does code review" (บทความทางการบน claude.dev · ต้นทางของตัวเลข 90% · หกชั้นการตรวจ · และเช็กลิสต์ "How you can adopt this process" ที่ใช้ในหัวข้อภาคปฏิบัติของบทนี้ · หน้าบทความลงวันที่ 15 ตุลาคม 2026 ขณะที่รายการบทความที่เกี่ยวข้องบน claude.com แสดง 16 ตุลาคม), 15 ตุลาคม 2026. https://claude.dev/blog/solving-code-review-at-anthropic/

[19] Anthropic, "Running an AI-native engineering org" หน้าซีชชันทางการ รุ่นซานฟรานซิสโก งาน Code w/ Claude 2026 (ใช้ยืนยันวันที่ 6 พฤษภาคม 2026 สถานที่ และตำแหน่งผู้พูดที่หน้านี้เขียนว่า Director of Engineering for Claude Code พร้อมช่องผู้บรรยายว่า Manager of the Claude Code and Cowork Team ซึ่งต่างจากหน้าซีชชันรุ่นโตเกียวและลอนดอน), 2026. https://claude.com/code-with-claude/session/sf-running-an-ai-native-engineering-org

[20] Anthropic, "Running an AI-native engineering org" หน้าซีชชันทางการ รุ่นลอนดอน งาน Code w/ Claude 2026 (ใช้ยืนยันว่าหน้ารุ่นลอนดอนใช้ถ้อยตำแหน่ง "Leader for Engineering and Product for Claude Code and Cowork" แบบเดียวกับรุ่นโตเกียว · จัดที่ลอนดอน 19 พฤษภาคม 2026), 19 พฤษภาคม 2026. https://claude.com/code-with-claude/session/ldn-running-an-ai-native-engineering-org