เมื่อ AI เขียนโค้ดแทนเป็นส่วนใหญ่: 3 ทีมจริงเจออะไร และเราเอาอะไรไปใช้ได้

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

เดือนนี้มี 3 เรื่องที่เปิดอ่านต้นฉบับได้ มาจากบริษัทฐานข้อมูล บริษัท AI และโปรเจกต์โอเพนซอร์ส บทความนี้แยกให้เห็นว่าอะไรคือสิ่งที่ต้นฉบับเขียนไว้ และอะไรคือการตีความของเรา แล้วจบด้วยเช็กลิสต์สำหรับคนที่ทำงานคนเดียวหรือทีมเล็ก

ข้อมูล ณ 16 ตุลาคม 2569 จากบล็อกของ Cockroach Labs (9 ต.ค.) บล็อกวิศวกรรมของ Anthropic (13 ต.ค. แก้ไขเพิ่ม 15 ต.ค.) และหน้าข้อเสนอ QEP428 ของ QGIS บน GitHub (รวมเข้ากติกาเมื่อ 7 ต.ค.)

อ่านก่อน: ตัวเลขทุกตัวของ Cockroach Labs และ Anthropic ในบทความนี้ บริษัทรายงานเอง และยังไม่มีผู้ตรวจสอบอิสระ ทั้งสองเรื่องใช้ Claude ซึ่ง Anthropic เป็นบริษัทที่ทำ Claude เอง

เรื่องที่ 1: Cockroach Labs ให้ AI ทำงานเป็นทีมแบบโรงพยาบาล

Cockroach Labs เป็นบริษัทที่ทำฐานข้อมูล วิศวกร 2 คนของบริษัทเล่าถึงการทดลอง 5 เดือน (21 เมษายน ถึง 11 กันยายน) ที่ให้ AI หลายตัวทำงานต่อกันเป็นสายพาน โดยตั้งบทบาทตามโรงพยาบาล งานแต่ละชิ้นคือคนไข้ และการรวมโค้ดเข้าระบบหลักคือการให้คนไข้กลับบ้าน

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

กติกา 4 ข้อที่บริษัทบอกว่าทำให้ระบบปลอดภัย

• ไม่มีโค้ดก่อนแผน และไม่มีแผนที่ไม่ผ่านรีวิว AI ต้อง Reproduce ปัญหา (ทำตามขั้นตอนแล้วเจอปัญหาเดียวกัน) ให้เห็นก่อน แล้วเขียนแผนว่าจะแก้ไฟล์ไหน เพิ่ม Test อะไร และมีความเสี่ยงอะไร จากนั้น AI อีกตัวที่ถูกตั้งให้หาจุดผิดเป็นผู้อนุมัติแผน ถ้าขอบเขตงานเปลี่ยนกลางทาง ต้องหยุดแล้วเสนอแผนใหม่ ("ห้ามด้นสด")
• ห้ามแก้ ปิด หรือข้าม Test เพื่อให้ผ่าน ถ้า Test ไม่ผ่าน ให้ถือว่า Test ถูกจนกว่าจะพิสูจน์ได้ว่าผิด
• ด่านสุดท้ายตรวจว่าการรีวิวเกิดขึ้นจริง ด่านนี้เช็กว่ามีการอนุมัติแล้ว ไม่มีคอมเมนต์ค้าง และผลทดสอบผ่าน เพราะ AI ไม่ได้ทำตามที่สั่งทุกครั้ง
• งานใหญ่ต้องแบ่ง งานที่เกิน 1,000 บรรทัดต้องแตกเป็นงานย่อย เพื่อให้ผู้รีวิวจำรายละเอียดทั้งหมดได้ในหัว

ตัวเลขที่บริษัทรายงานเอง

• งานรองรับฐานข้อมูล IBM Db2 เสร็จในไม่ถึง 2 วัน ค่า Token 4,172 ดอลลาร์ เทียบกับงานคล้ายกันเมื่อปี 2567 (รองรับ Oracle) ที่ใช้เวลา 9 เดือน และค่าแรงวิศวกรราว 160,000 ดอลลาร์ แต่ตัวเลข 2 วันนี้ไม่รวมเวลาสร้างระบบโรงพยาบาล ที่บริษัทสร้างไว้ก่อนเริ่มงานนี้
• ตลอด 5 เดือน ระบบรวมโค้ดได้กว่า 1 ล้านบรรทัด และต้องย้อนงานที่รวมไปแล้ว (Revert) ทั้งหมด 7 ครั้ง
• ค่า Token รวมกว่า 135,000 ดอลลาร์ เฉลี่ยราว 84 ดอลลาร์ต่องาน 1 ชิ้น

ส่วนที่บริษัทเขียนไว้เอง แต่มักไม่ถูกเล่าต่อ

• ช่วงที่ทำงาน Db2 ไม่มีใครรีวิวโค้ดที่ AI เขียนเลย และตอนที่เขียนโพสต์ บริษัทยังตรวจอยู่ว่างานนั้นถูกต้องจริงหรือไม่ ตัวเลข "ไม่ถึง 2 วัน" จึงเป็นเวลาของงานที่ยังตรวจไม่เสร็จ
• หลังสัปดาห์แรกที่ปล่อยให้ระบบทำงานเอง บริษัทเปิด "โหมดคนอนุมัติ" ให้การรวมโค้ดทุกครั้งต้องผ่านตาคน และบอกว่ามีแค่โหมดนี้ที่มั่นใจพอจะส่งงานให้ลูกค้า
• ระบบเริ่มมีขั้นตอนแบบราชการ งานแก้คำบนหน้าจอคำเดียววนอยู่ 5 รอบ และงานด่วนที่แก้แค่ 1 บรรทัดวน 11 รอบใน 2 วัน จนต้องเพิ่มกติกาตัดวงจร
• ไฟล์คำสั่งของ AI ยาวขึ้นเรื่อยๆ เพราะเพิ่มกติกาทุกครั้งที่มีปัญหา เมื่อตรวจจริง มี 23% ที่ถูกระบุว่าตัดออกได้โดยไม่เปลี่ยนกติกาเลย
• ระบบนี้ไม่ได้ฝึกวิศวกรมือใหม่ ตอนนี้บริษัทกำลังปรับให้คนเขียนแผนเอง แล้วให้ AI ช่วยรีวิว

เรื่องที่ 2: Anthropic มีโค้ดเยอะจนระบบเก็บโค้ดรับไม่ไหว

ตามที่ Anthropic รายงานเอง การรวมโค้ดต่อวันเพิ่มจากราว 2,500 ครั้งในเดือนพฤษภาคม 2569 เป็นกว่า 30,000 ครั้งในเดือนกันยายน จนระบบเก็บประวัติโค้ด (Source Control) กลายเป็นคอขวดอันดับหนึ่ง ทีม 7 คนจึงสร้างระบบของตัวเองชื่อ Scion พร้อมเครื่องมือรีวิวโค้ด และย้ายออกจาก Git (ระบบเก็บประวัติโค้ดที่คนส่วนใหญ่ใช้) ได้ภายใน 5 เดือน

สิ่งที่น่าสนใจกว่าตัวระบบ คือบทเรียนเรื่องคน 3 ข้อที่บริษัทเขียนไว้

• งานของวิศวกรหลายครั้งคือการบอก Claude ว่า "ไม่" เพราะบางครั้ง AI ฝืนกติกาหลักของระบบ เพื่อทำตามรูปแบบที่ไม่ควรได้รับอนุญาตตั้งแต่แรก
• การรีวิวแบบจับผิดก็พลาดได้ บางครั้งการรีวิวมองแคบเกินไป เช่น รีวิวครั้งหนึ่งระแวงบริการภายในอีกตัวมากเกินไป จน Claude ใส่การตรวจซ้ำซ้อนเกินจำเป็น ต้องมีวิศวกรที่เข้าใจระบบมาดึงกลับ
• คนยังรีวิวการเปลี่ยนแปลงทุกครั้ง แต่เปลี่ยนจากการอ่านโค้ดทุกบรรทัด มาเป็นการดูว่าการเปลี่ยนแปลงนั้นตั้งใจทำอะไร

Anthropic เขียนกำกับไว้เองว่า Scion ไม่ใช่ระบบที่จะมาแทน Git สำหรับคนทั่วไป และบริษัทใช้ Token ภายในได้มากกว่าที่ธุรกิจอื่นจะยอมจ่าย

เรามองว่าข้อ "ดูเจตนาแทนอ่านทุกบรรทัด" ใช้ได้เพราะบริษัทมี Automated Test จำนวนมากรองรับ (บริษัทบอกว่าโค้ดชุดนี้ทดสอบหนาแน่นที่สุดชุดหนึ่งที่เคยทำ) ถ้าโปรเจกต์ของคุณยังไม่มี Test อย่าเพิ่งข้ามการอ่านโค้ด

เรื่องที่ 3: QGIS เลือกไม่รับโค้ดจาก AI

QGIS เป็นโปรแกรมทำแผนที่แบบโอเพนซอร์สที่ใช้ฟรี กติกาเดิมของ QGIS (ดัดแปลงจากกติกาของโปรเจกต์ LLVM) อนุญาตให้ใช้ AI ได้ แต่ต้องมีคนอยู่ในวงจร (Human in the Loop) คนส่งงานต้องอ่านและรีวิวโค้ดที่ AI เขียนเองทั้งหมดก่อนขอให้คนอื่นรีวิว ต้องตอบคำถามเรื่องงานของตัวเองได้ และต้องแจ้งเมื่องานมีส่วนที่เครื่องมือสร้างขึ้นเป็นจำนวนมาก

วันที่ 24 กันยายน 2569 มีคนเสนอให้เปลี่ยนเป็นข้อห้ามเด็ดขาด ข้อเสนอผ่านการโหวตและรวมเข้ากติกาเมื่อ 7 ตุลาคม ข้อความทั้งหมดของกติกาใหม่มีเพียงเท่านี้ (เราแปลเป็นไทย)

ไม่อนุญาตให้ส่งโค้ดที่ใช้ LLM, AI หรือ agent ช่วยเขียน เข้าที่เก็บโค้ด qgis/qgis ถ้าเราพบภายหลังว่าคุณใช้ AI, LLM หรือขั้นตอนทำงานแบบ agent ใดๆ กับงานที่ส่งมา โค้ดจะถูกถอนออก และคุณจะถูกลงโทษเรื่องสิทธิ์ของผู้ร่วมพัฒนา

เหตุผลที่ QGIS เปลี่ยนกติกา

• สมาชิกทีม QGIS คนหนึ่งเขียนในเธรดว่า งานที่ใช้ AI ส่งเข้ามามากเกินกว่าที่คนจะรีวิวได้จริงจัง ผลคืองานที่ค้างรีวิวยาวขึ้น หรือมีโค้ดที่ไม่ได้รีวิวอย่างเต็มที่
• ผู้เสนอบอกว่ากติกาเดิม "เห็นชัดว่าไม่ได้ผล" ในทางปฏิบัติ และโปรเจกต์เสียผู้ร่วมพัฒนาที่มีคุณค่าสูงมากไปอย่างน้อยหนึ่งคน
• ผู้เสนอบอกด้วยว่านี่ไม่ใช่กติกาถาวร แต่เป็นการ "เริ่มจากปิดประตู" แล้วค่อยพิจารณาเปิดทีละกรณี

ข้อที่ยังถกเถียงกันอยู่: คำว่า "ช่วย" ครอบคลุมแค่ไหน

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

อย่าสรุปว่า "โอเพนซอร์สห้าม AI" นี่คือกติกาของ QGIS เพียงโปรเจกต์เดียว และใช้กับโค้ดในที่เก็บโค้ดหลักที่เดียว ผู้เสนอบอกว่าคณะกรรมการของโปรเจกต์ขอให้จำกัดขอบเขตไว้แบบนี้ และแม้แต่ QGIS เอง ก่อนวันที่ 7 ตุลาคมก็ยังอนุญาตให้ใช้ AI อยู่

สิ่งที่ 3 เรื่องนี้บอกเรา (การตีความของเรา)

1. คอขวดย้ายจาก "เขียน" ไปที่ "ตรวจ" Cockroach Labs สร้างด่านรีวิวหลายชั้น และบอกว่างานแต่ละชิ้นมักใช้เวลาส่วนใหญ่ไปกับการรอคนรีวิว ส่วน Anthropic ต้องสร้างระบบใหม่เพราะปริมาณโค้ด และ QGIS ปิดประตู โดยสมาชิกคนหนึ่งให้เหตุผลว่าคนรีวิวไม่พอ
2. คนยังเป็นคนตัดสิน แต่หน้าที่เปลี่ยนไป จากคนที่เขียนทุกบรรทัด มาเป็นคนอนุมัติ คนบอก "ไม่" และคนตัดสินว่างานไหนคุ้มกับเวลาที่ใช้ตรวจ
3. กติกาที่ตรวจได้ ได้ผลกว่าความตั้งใจดี Cockroach Labs ไม่เชื่อแค่คำบอกว่า AI รีวิวแล้ว จึงมีด่านตรวจว่าการรีวิวเกิดขึ้นจริง ส่วน QGIS เคยพึ่งให้คนส่งงานรีวิวเอง แล้วพบว่าในทางปฏิบัติไม่ได้เกิดขึ้นจริง
4. ตัวเลขความเร็วไม่ได้เล่าเรื่องทั้งหมด ตัวเลข 2 วันมาพร้อมข้อยอมรับว่าตอนนั้นยังไม่มีใครรีวิวโค้ดเลย

เช็กลิสต์ 7 ข้อ สำหรับคนที่ทำงานคนเดียวหรือทีมเล็ก

เราดัดแปลงจากสิ่งที่ 3 ทีมทำ ยังไม่ได้วัดผลว่าช่วยลดบั๊กได้แค่ไหน

1. สั่งให้เขียนแผนก่อน ยังไม่ให้แก้โค้ด อ่านแผนให้เข้าใจก่อนพิมพ์ว่า "ทำได้"
2. รีวิวในแชตใหม่ ที่สั่งให้หาจุดผิดอย่างเดียว ไม่ใช่ถามแชตเดิมที่เพิ่งเขียนโค้ดว่า "ดีหรือยัง" ใช้คู่กับ Prompt ฟรี: Code Review ที่เรียงปัญหาตามความรุนแรง ได้ (ต้องสมัครสมาชิกฟรี)
3. ห้าม AI แก้ ปิด หรือข้าม Test เพื่อให้ผ่าน ถ้า AI บอกว่า Test ผิด ให้แยกเป็นอีกงาน แล้วตรวจเอง
4. ทำงานชิ้นเล็กพอที่คุณอ่านได้ทั้งหมด Cockroach Labs ตั้งเพดานไว้ 1,000 บรรทัดต่องาน ถ้าคุณอ่านเองคนเดียว ควรเล็กกว่านั้นมาก
5. เขียนกติกาที่ห้ามละเมิด 3–5 ข้อ เช่น ห้ามแก้ไฟล์ไหน ห้ามเก็บรหัสผ่านไว้ในโค้ด แล้วกล้าบอก "ไม่" เมื่อ AI เสนอทางลัดที่ผิดกติกา
6. ถ้าวนแก้เกิน 3 รอบแล้วยังไม่จบ ให้หยุด กลับไปดูแผน หรือเริ่มถามใหม่ Cockroach Labs เองก็ส่งงานที่วนเกิน 3 รอบไปทบทวน
7. ก่อนส่งโค้ดเข้าโปรเจกต์ของคนอื่น อ่านกติกาเรื่อง AI ของเขาก่อน มักอยู่ในไฟล์ CONTRIBUTING หรือหน้านโยบายของโปรเจกต์

คำสั่งสำเร็จรูป: ขอแผนก่อนให้ AI แก้โค้ด

คัดลอกคำสั่งนี้ไปใช้ก่อนให้ AI แก้โค้ด

ยังไม่ต้องแก้โค้ด เขียนแผนก่อน:
1. ปัญหาคืออะไร และทำให้มันเกิดซ้ำได้ยังไง
2. จะแก้ไฟล์ไหนบ้าง และทำไม
3. จะเพิ่มหรือแก้เทสต์อะไร
4. ความเสี่ยง และสิ่งที่ยังไม่แน่ใจ

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

คำสั่งนี้ดัดแปลงจากกติกา "ไม่มีโค้ดก่อนแผน" และ "ห้ามด้นสด" ของ Cockroach Labs เรายังไม่ได้ทดลองเทียบผลคำสั่งนี้

ข้อจำกัดของบทความนี้

• ตัวเลขของ Cockroach Labs และ Anthropic เป็นตัวเลขที่บริษัทรายงานเอง Cockroach Labs ใช้ค่า Token รวมกว่า 135,000 ดอลลาร์ ส่วน Anthropic บอกเองว่าบริษัทใช้ Token ได้มากกว่าที่ธุรกิจทั่วไปจะใช้ และเรื่องของ Anthropic เป็นการที่บริษัทเล่าถึงเครื่องมือของตัวเอง
• QGIS เป็นเพียงโปรเจกต์เดียว กติกาใหม่ยังถกเถียงกันอยู่ และอาจเปลี่ยนอีก
• เช็กลิสต์และคำสั่งข้างบนเป็นของเรา ยังไม่ได้วัดผล

สรุป: งานตรวจคือคอขวดใหม่

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

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

อ่านต่อ

• ให้ AI เขียนโค้ดแทนแล้ว ยังต้องสนใจไหมว่าโค้ดดีหรือไม่ดี (ต้องสมัครสมาชิกฟรี)
• Vibe coding: บอก AI ว่าอยากได้แอปอะไร แล้วตรวจให้เป็น ก่อนเอาไปใช้จริง

อาทิตย์ละสกิล เดี๋ยวก็เก่ง