ถ้า AI Agent เขียนโค้ดเกือบทั้งหมดแล้ว “Clean Code” ยังจำเป็นอยู่ไหม?
วันที่ 11 ต.ค. 2026 Lauren Tan (@poteto) วิศวกรที่ทำงานกับ Grok Bot ของ SpaceXSI และอดีตทีม React Compiler โพสต์บน X ว่า “codebase มี slop มาตลอด” และในโพสต์ถัดมาเสนอว่าหลัก Clean Code และ maintainability แบบเดิม “ไม่จริงอีกต่อไปแล้ว” เพราะหลักเหล่านี้ออกแบบมาให้คนอ่าน ส่วนตอนนี้ Agent เป็นฝ่ายเขียนโค้ดแทบทั้งหมด เธอบอกว่าเราน่าจะต้องคิดหลัก agent-friendly architecture ขึ้นมาใหม่ สองโพสต์นี้มียอดแสดงผลรวมกันกว่า 9 แสนครั้งตอนที่เราอ่าน
คนบน X ไม่ได้แบ่งเป็นแค่สองฝั่ง “ตาย” กับ “ไม่ตาย” ข้อถกเถียงจริงคือ โค้ดเขียนให้ใครอ่าน และใครเป็นคนรับผิดชอบเมื่อมันพัง DHH เห็นด้วยว่าการออกแบบซอฟต์แวร์ต้องคิดใหม่ทั้งหมด Uncle Bob ผู้เขียนหนังสือ Clean Code ตอบว่าโค้ดรกทำให้ Agent ช้าลงเหมือนที่ทำให้คนช้าลง แค่เกณฑ์อาจต้องผ่อนลง ส่วนอีกกลุ่มชี้ว่าปัญหาจริงย้ายไปอยู่ที่การตรวจงาน ซึ่งสอดคล้องกับงานวิจัยของ Harvard ที่พบว่าบริษัทที่ใช้ Coding Agent ได้โค้ดเพิ่มขึ้น แต่เวลารีวิว Pull Request ก็เพิ่มขึ้น 49%
เกิดอะไรขึ้น ตามที่ตรวจสอบได้
คำว่า Clean Code มาจากหนังสือของ Robert C. Martin หรือ Uncle Bob ที่ตีพิมพ์ครั้งแรกปี 2008 ใจความหลักคือให้เขียนโค้ดที่คนอื่นอ่านแล้วเข้าใจและแก้ต่อได้ง่าย เช่น ตั้งชื่อให้สื่อความหมาย แยกฟังก์ชันให้เล็กและทำหน้าที่เดียว และลดโค้ดซ้ำ หลักการนี้มีทั้งคนรักและคนวิจารณ์มานาน ข้อวิจารณ์ที่ถูกอ้างบ่อยคือวิดีโอ “Clean Code, Horrible Performance” ของ Casey Muratori เมื่อปี 2023 ซึ่งแสดงว่ากฎบางข้อ เช่น การใช้ polymorphism แทน switch ทำให้โค้ดในจุดที่ต้องการความเร็วช้าลงได้หลายเท่า ประเด็นใหม่ในรอบนี้คือ ถ้าผู้อ่านหลักของโค้ดไม่ใช่คนอีกต่อไป หลักเหล่านี้ยังจำเป็นอยู่ไหม
- Ars Technica รายงานงานวิจัยของ Fiona Chen และ James Stratton (Harvard) ซึ่งพบว่าหลังบริษัทใช้ Coding Agent จำนวนบรรทัดโค้ดเพิ่มขึ้น 30% แต่จำนวน issue ที่ปิดได้ไม่เพิ่มขึ้นอย่างมีนัยสำคัญ และเวลารีวิว PR เพิ่มขึ้น 49% CONFIRMED
- @poteto โพสต์ว่า codebase มี slop มาตลอด คนส่วนใหญ่เรียก “โค้ดที่ตัวเองไม่ได้เขียน” ว่า slop และเสนอว่า Good Code คือโค้ดที่ ถูกต้อง ไม่มีบั๊ก และรันได้เร็วและคุ้มค่า เธอมองว่า Agent อาจยังเขียน Good Code ไม่ได้ แต่ “โดยเฉลี่ยในระดับใหญ่” น่าจะเขียนได้ดีกว่า CONFIRMED
- เสียงคัดค้านเริ่มขยายวง นักพัฒนารายหนึ่งตอบว่า “เราไม่เคยโอเคกับ slop” ส่วน Saša Jurić ผู้เขียนหนังสือ Elixir in Action ประชดว่า “เมื่อก่อนเราก็ทำ slop อยู่แล้ว งั้นทำเพิ่มอีก 100 เท่า แล้วเลิกรีวิวไปเลย” CONFIRMED
- @poteto โพสต์ต่อว่ามีคนตอบมามากว่า maintainability ยังสำคัญ แต่เธอเห็นว่า “ไม่จริงอีกต่อไปแล้ว” เพราะ Clean Code มีต้นทุนด้านประสิทธิภาพมาตลอด และหลักเหล่านี้เกิดในยุคที่คนเป็นผู้ดูแลโค้ด CONFIRMED
- Addy Osmani, Uncle Bob, DHH และนักพัฒนาชื่อดังอีกหลายคนตอบหรือโควตโพสต์ จนระบบสรุปข่าวของ X จัดเป็นเรื่องเด่นหัวข้อ “Developers Rethink Clean Code in AI Agent Era” CONFIRMED
- @poteto ย้ำว่า “slop is a slur” เพราะคำนี้ไม่มีนิยามที่ตรงกัน และขอให้คุยกันว่าโค้ดแย่ “ตรงไหน” แทน CONFIRMED
ข้อควรรู้ก่อนอ่านต่อ: @poteto ไม่ได้บอกว่าคุณภาพโค้ดไม่สำคัญ เธอเสนอให้วัดคุณภาพจาก “ผลลัพธ์” คือความถูกต้อง บั๊ก และต้นทุนการรัน แทน “สไตล์ที่คนอ่านสบายตา” และผู้ใช้รายหนึ่งยกคำพูดของเธอที่ว่า PR ส่วนใหญ่ที่เธอ merge เป็นงาน refactor หลายคน จึงมองว่าความเห็นต่างจริงอาจแคบกว่าที่หัวข้อชวนให้คิด
คนบน X พูดถึงเรื่องนี้มากแค่ไหน
เราวัดด้วย X Counts API เมื่อ 13 ต.ค. 2026 เวลาประมาณ 00:16–00:18 น. (เวลาไทย) ตัวเลขนับรวมรีโพสต์และนับตามวันแบบ UTC จึงบอกได้แค่ว่ามีคนพูดถึงมากแค่ไหน ไม่ได้บอกว่าคนส่วนใหญ่คิดอย่างไร
คำค้นกว้าง (มีคำว่า poteto, “clean code”, “good code” หรือ “agent-friendly architecture” ร่วมกับคำว่า slop, maintainability, readability หรือ agent) มีรวม 3,494 โพสต์ ระหว่าง 6–12 ต.ค. และพุ่งจากราว 400 โพสต์ต่อวันขึ้นเป็น 1,122 โพสต์ในวันที่โพสต์ของ @poteto ออกมา ส่วนคำค้นแคบที่ต้องมีคำว่า “clean code” หรือ “agent-friendly” ร่วมกับคำว่า AI หรือ agent มีรวม 746 โพสต์ ส่วนโพสต์ที่พูดถึงงานวิจัย Harvard เรื่องคอขวดการรีวิวมี 130 โพสต์ในช่วงเดียวกัน
หมายเหตุ: คำค้นกว้างใส่คำว่า “poteto” ไว้ด้วย จึงนับโพสต์ที่แท็กบัญชีนี้ในเรื่องอื่นที่มีคำว่า agent ไปด้วยบางส่วน ตัวเลขฐานก่อนวันที่ 11 จึงไม่ได้เป็นศูนย์ ให้ดูที่การเปลี่ยนแปลงของยอด ไม่ใช่ยอดตรงๆ
ค่ายความเห็นหลักบน X และเหตุผลของแต่ละฝั่ง
เราจัดกลุ่มจากโพสต์ที่อ่าน ไม่ได้นับสัดส่วน จึงห้ามอ่านว่าค่ายไหน “ชนะ” หลายคนยืนอยู่มากกว่าหนึ่งค่าย ส่วนบัญชีเล็กที่ไม่ใช่บุคคลสาธารณะ เราสรุปความโดยไม่ระบุชื่อและใส่ลิงก์ให้ตรวจต้นฉบับได้ ยอดไลก์และยอดแสดงผลเป็นค่า ณ เวลาที่เราอ่าน
“ต้องนิยาม Good Code ใหม่ เพราะผู้อ่านเปลี่ยนแล้ว”
@poteto, DHH และนักพัฒนาที่ให้ Agent ทำงานยาวๆ เป็นประจำ
- @poteto ให้เหตุผลในโพสต์ว่า indirection และการทำให้โค้ดอ่านง่ายสำหรับคน “ไม่ฟรี” มักต้องแลกกับประสิทธิภาพ ที่ผ่านมาเรายอมจ่ายเพราะ Moore’s Law และเพราะโค้ดส่วนใหญ่ไม่ได้อยู่ใน hot path โพสต์นี้ได้ 3,989 ไลก์ 403 คำตอบ และ 138 โควต
- DHH ผู้สร้าง Ruby on Rails ตอบว่าเห็นด้วย และการออกแบบซอฟต์แวร์ส่วนใหญ่ต้องคิดใหม่ตั้งแต่ฐาน เพราะเป็นไปไม่ได้ที่วิธีทำงานในยุคที่โค้ดแต่ละบรรทัด “ช้าและแพง” จะเหมือนกับยุคที่มัน “ถูกและเร็ว” (1,089 ไลก์) อีกโพสต์หนึ่งบอกว่า abstraction ทุกตัวควรถูกสงสัยไว้ก่อนจนกว่าจะพิสูจน์ได้ว่าคุ้ม
- David (@dzhng) ผู้สร้าง Duet เล่าว่าหลักใหม่ของเขาคือลบชั้น abstraction ให้มากที่สุด เขียนเว็บแอปด้วย Rust คอมไพล์เป็น WASM ไม่ใช้ React หรือ Next.js แล้วทุ่มแรงไปที่ harness ตรวจผลเฉพาะของแต่ละแอป เพื่อให้ Agent ทำงานต่อได้นาน 12 ชั่วโมงขึ้นไป (2,016 ไลก์ เป็นประสบการณ์ของเขาคนเดียว)
- วิศวกรซอฟต์แวร์รายหนึ่งที่ระบุว่าทำงานที่ Google สรุปว่า Clean Code ตอนนี้สำคัญกับผู้อ่านคนเดียวคือ Agent มนุษย์ถือทิศทางและสถาปัตยกรรม ส่วนผู้ใช้อีกรายเปรียบว่าเครื่องบินเรียนรู้จากนกแต่ไม่ได้กระพือปีก LLM เรียนเขียนโค้ดจากคนก็ไม่จำเป็นต้องทำงานแบบคน
“หลักเดิมยังใช้ได้ แค่ต้องปรับเกณฑ์ให้เข้ากับ Agent”
Uncle Bob, นักสอนเขียนโปรแกรม และคนที่วัดต้นทุนโทเคนจริง
- Uncle Bob ตอบ @potetoว่าโค้ดรกทำให้ Agent ช้าลงเหมือนที่ทำให้คนช้าลง เขาเคยเห็น Agent “ดิ้นวนอยู่นาน” เพราะแก้จุดหนึ่งแล้วพังอีกจุด เขาจำกัด cyclomatic complexity ในโค้ดของตัวเองไว้ราว 4 แต่ให้ Agent ไปได้ถึง 10 เพราะสันนิษฐานว่าความจำระยะสั้นของ Agent ใหญ่กว่าคน เขาจึงเห็นว่าหลักการยังอยู่ แต่ต้องปรับเกณฑ์ (296 ไลก์ 36,887 การแสดงผล)
- Fabio Akita นักพัฒนาชาวบราซิลที่มีผู้ติดตามราว 93,000 คน โพสต์ว่า Agent ทำงานกับ Clean Code ได้ดีที่สุด ถ้าไม่ทำ จะเสียโทเคนมากเกินจำเป็น แล้วไปโทษว่าต้องเปลี่ยนโมเดล โพสต์นี้ถูก Uncle Bob รีโพสต์ต่อ
- Kun Chen ยกตัวอย่างสมมติว่าผลิตภัณฑ์เดียวกัน ถ้า codebase สะอาด ฟีเจอร์ใหม่แต่ละตัวอาจใช้ 5M โทเคน แต่ถ้ารกและบวม อาจใช้ 50M เขาจึงยังนับ maintainability เป็นส่วนหนึ่งของ Good Code (ตัวเลขนี้เป็นภาพสมมติ ไม่ใช่ผลวัด)
- Saša Jurić เขียนว่าโค้ดคือส่วนหนึ่งของ context และน่าจะเป็นส่วนที่ใหญ่ที่สุด ถ้ามันบวมเป็น slop ก็ยากสำหรับ Agent ด้วย การคุม Agent จึง “ต้องอ่านโค้ดบ้าง”
ตรรกะของค่ายนี้คือ ต้นทุนของโค้ดรกไม่ได้หายไป แต่เปลี่ยนรูปจาก “เวลาของคน” เป็น “โทเคน เวลารอ และการแก้ซ้ำ” ของ Agent
“ปัญหาคือปริมาณ และจุดบอดที่ Agent ทุกตัวมีเหมือนกัน”
นักพัฒนาที่ต้องรีวิวงานของ Agent ทุกวัน
- นักพัฒนาสาย Applied AI รายหนึ่งแย้งว่าเราไม่เคยโอเคกับ slop ถ้าถามนักพัฒนาถึงโค้ดแย่ที่เคยเขียน จะได้คำอธิบายเรื่องเวลาบีบหรือสเปกไม่ชัดเสมอ (705 ไลก์ 45,604 การแสดงผล) และในคำตอบต่อมา เขายอมรับว่าโค้ดของ Agent อาจดีกว่าค่าเฉลี่ยของคน แต่ Agent ผลิตโค้ดมากกว่าหลายเท่า slop โดยรวมจึงยังเพิ่มขึ้น
- นักพัฒนาอีกรายเล่าประสบการณ์ว่าโค้ดที่ Agent เขียนมักสร้างเงื่อนไขที่ Agent รุ่นถัดไปเข้าใจผิดว่าเป็นกฎตายตัว ซึ่งแทบจับไม่ได้ถ้าไม่อ่านโค้ด เขามองว่าทีมมนุษย์มีจุดแข็งจุดอ่อนต่างกันจึงช่วยอุดกันได้ แต่ทีม Agent “เก่งเหมือนกันและอ่อนเหมือนกัน” เมื่อรวมกับความเร็ว ปัญหาจึงลามเร็ว
- ผู้ใช้หลายคนพูดในทำนองเดียวกันว่า ใน codebase ที่รก Agent จะ “ลอกความรกไปอย่างมั่นใจ” ลงหลายไฟล์พร้อมกัน เช่นโพสต์นี้ และอีกรายเตือนว่าโค้ดตายและโค้ดซ้ำกลายเป็น “context poisoning” ของงานรอบถัดไป (ลิงก์)
“เลิกอ่านทุกบรรทัด แล้วสร้างวงจรตรวจที่ Agent รันเองได้”
คนทำเครื่องมือ Coding Agent และผู้สอนการทำงานกับ Agent
- Addy Osmani ซึ่งในโปรไฟล์ระบุว่าทำงานกับ Claude Code ที่ Anthropic โควตโพสต์ของ @potetoว่าคำว่า “ดีกว่าโดยเฉลี่ยในระดับใหญ่” ถูกต้อง แต่ “ในระดับใหญ่” มาจากการตรวจ สิ่งที่เคยทำให้ Good Code แพง เช่น test, benchmark, spec และการรัน end-to-end ตอนนี้สั่ง Agent ทำได้ถูกลง งานของคนจึงเปลี่ยนจาก “รีวิวทุกบรรทัด” เป็น “สร้างวงจรที่ Agent ตรวจตัวเองได้” และคนยังเป็นเจ้าของสิ่งที่ปล่อยออกไป แต่รีวิวจากหลักฐาน ไม่ใช่แค่ diff (555 ไลก์) เขายังแนะนำในอีกโพสต์ให้กำหนดคำว่า “เสร็จ” ให้ชัดก่อนเริ่มรีวิว
- Uncle Bob เองก็เล่าว่าเขาบังคับ Agent ด้วยเครื่องมือวัดค่า CRAP (ความซับซ้อนรวมกับ coverage) และ mutation testing ไม่ใช่แค่สั่งให้เขียน test
- Matt Pocock ผู้สอน TypeScript และการทำงานกับ AI ตอบว่าไม่มีทางทำให้โค้ดแย่ “เป็นไปไม่ได้” แต่ตั้งแนวป้องกันได้ คือ automated check, automated review และ human review
“ให้วัดที่ซอฟต์แวร์ดี ไม่ใช่โค้ดสวย และงานบางประเภทผิดไม่ได้”
วิศวกรสายระบบสำคัญ ผู้สอนวิศวกรรมซอฟต์แวร์
- John Crickett ผู้สอนวิศวกรรมซอฟต์แวร์ โพสต์ว่าเราโฟกัสผิด ควรสนใจ “ซอฟต์แวร์ที่ดี” ไม่ใช่ “โค้ดที่ดี” คือซอฟต์แวร์ที่ส่งมอบ ดูแล รัน และซัพพอร์ตได้ โดยรักษาความถูกต้องของข้อมูล ความเป็นส่วนตัว และความปลอดภัย
- Devin Jameson ผู้สร้างเฟรมเวิร์ก Foldkit เขียนว่าคำว่า Clean Code กำกวมและอัตวิสัยเกินไป สิ่งที่สำคัญคือสถาปัตยกรรมที่มีมาตรฐานและข้อจำกัดชัด แต่เขาก็ยืนยันว่าในงานด้านความปลอดภัยและสาธารณสุขที่เขาเคยทำ เขาจะไม่ปล่อยโค้ดที่ตัวเองตรวจไม่ได้
- นักพัฒนาระบบ SCADA อุตสาหกรรมรายหนึ่งตั้งคำถามว่าเราจะยอมให้โรงงานนิวเคลียร์รันด้วยโค้ดที่ไม่มีใครเข้าใจหรือ และผู้ใช้อีกรายยกตัวอย่างซอฟต์แวร์จรวด ธนาคาร และโรงพยาบาลในทำนองเดียวกัน (ข้อนี้ตรงกับที่ @poteto เองยกเว้นงาน mission critical ไว้ตั้งแต่โพสต์แรก)
หมายเหตุเรื่องคำว่า “slop”: การถกส่วนหนึ่งวนอยู่ที่ตัวคำ @poteto บอกว่า “slop is a slur” เพราะไม่มีนิยามที่ตรงกัน นักพัฒนาที่เห็นด้วยกับเธอบางส่วนก็มองว่าข้อนี้เกินไป ส่วน Hillel Wayne ชี้ว่า “Clean Code” ตามหนังสือ ไม่ได้เท่ากับโค้ดที่สะอาด และไม่ได้เท่ากับโค้ดที่เร็ว คำแนะนำที่ใช้ได้จริงจากการถกจึงคือ ให้ระบุว่าโค้ดแย่ “ตรงไหน” เช่น ซ้ำ บวม ช้า หรือตรวจไม่ได้ แทนการติดป้าย
ทดลอง 01 — โค้ดรกทำให้บิลโทเคนของ Agent แพงขึ้นแค่ไหน
การจำลองเชิงการศึกษา ตัวเลขที่ปรับได้ทุกตัวเป็นค่าสมมติ ไม่ใช่ราคาจริงของผู้ให้บริการใด สมมติฐาน “ส่วนต่าง” มาจากงานวิจัยหรือโพสต์ที่ระบุไว้ในปุ่ม ซึ่งวัดในเงื่อนไขเฉพาะเท่านั้น
เลือกสมมติฐานว่าโค้ดรกใช้โทเคนมากกว่าโค้ดสะอาดเท่าไร
จำนวนงานที่ให้ Agent ทำต่อเดือน
โทเคนต่องานบนโค้ดที่สะอาด (ล้านโทเคน)
ราคาสมมติต่อล้านโทเคน (ดอลลาร์สหรัฐ)
ส่วนต่างต่อเดือน: –
เลือกค่าเพื่อดูผล
ที่มาของสมมติฐาน: งานวิจัย SonarSource (Claude Code + Claude Sonnet 4.6, 660 รอบ) พบว่าฝั่งโค้ดสะอาดใช้ input token น้อยกว่า 7.1% โดยเฉลี่ย น้อยกว่า 10.7% ในงานข้ามโมดูล และมากกว่า 1.8% ในงานจุดซับซ้อนที่ถูกแตกเป็น helper หลายตัว ค่า 4M โทเคนต่องานอ้างจากค่าเฉลี่ยบน SWE-bench Verified ที่งานวิจัยนั้นยกมา ส่วนภาพ 5M vs 50M เป็นตัวอย่างสมมติของ Kun Chen บน X ไม่ใช่ผลวัด เราคำนวณจาก input token อย่างเดียวและไม่ได้รวมค่า cache
งานวิจัยว่าอย่างไร: Agent “แคร์” ความสะอาดของโค้ดไหม
คำถามนี้ทดสอบได้ และมีคนเริ่มทดสอบแล้ว แต่หลักฐานยังน้อยและมาจากเงื่อนไขแคบ
SonarSource: สะอาดไม่ช่วยให้ “ผ่าน” แต่ช่วยให้ “ถูกกว่า”
Priyansh Trivedi และ Olivier Schmitt สร้างคู่ repository ที่ทำงานเหมือนกันทุกอย่างแต่ต่างกันที่ความสะอาด 6 คู่ แล้วให้ Claude Code ทำ 33 งาน งานละ 10 รอบต่อฝั่ง อัตราผ่านแทบไม่ต่างกัน (ฝั่งสะอาด 91.3% ฝั่งรก 92.1%) แต่ฝั่งสะอาดใช้ input token น้อยกว่า 7.1% และกลับไปเปิดไฟล์ที่แก้แล้วซ้ำน้อยกว่า 33.8% ผลชัดที่สุดอยู่ในงานข้ามโมดูล ข้อจำกัดคือทดสอบโมเดลเดียว ผู้วิจัยสร้างทั้งคู่ repository และงานเอง และ SonarSource เป็นบริษัทที่ขายเครื่องมือตรวจคุณภาพโค้ด
CodeHealth: โค้ดที่คนอ่านง่าย AI refactor แล้วพังน้อยกว่า
Markus Borg, Nadim Hagatulah, Adam Tornhill และ Emma Söderberg ทดสอบกับไฟล์ Python 5,000 ไฟล์ และรายงานในบทคัดย่อว่า เมื่อให้ LLM ขนาดกลาง refactor โค้ดที่มีค่า CodeHealth ดี ความเสี่ยงที่พฤติกรรมของโปรแกรมจะพังต่ำกว่า 15–30% แต่ Claude Code ไม่แสดงความต่างที่มีนัยสำคัญ ผู้เขียนส่วนหนึ่งมาจาก CodeScene เจ้าของเมตริก CodeHealth
ผลนี้ตอบทั้งสองค่ายได้บางส่วน ค่าย A พูดถูกว่า Agent ที่เก่งพอยัง “ทำงานเสร็จ” ได้แม้โค้ดจะรก ส่วนค่าย B พูดถูกว่าความรกมีต้นทุน แต่ต้นทุนเปลี่ยนรูปเป็นโทเคนและการวนแก้ ที่น่าสนใจคือในงานที่ถูกแตกเป็น helper หลายไฟล์ ฝั่ง “สะอาด” กลับใช้โทเคนมากขึ้นเล็กน้อย ซึ่งสอดคล้องกับข้อสงสัยของ DHH ว่า abstraction ไม่ได้ดีเสมอ
คอขวดที่แท้จริงอาจไม่ใช่การเขียน แต่คือการตรวจ
งานวิจัยของ Fiona Chen และ James Stratton จาก Harvard (working paper ส.ค. 2026 ยังไม่ผ่านการตีพิมพ์ในวารสาร) ใช้ข้อมูลจากแพลตฟอร์มวิเคราะห์งานวิศวกรรม Jellyfish ราว 300 ล้านเหตุการณ์ จากพนักงาน 725,938 คนใน 718 บริษัท ช่วงปี 2021 ถึง มี.ค. 2026 แล้วเทียบก่อนและหลังแต่ละบริษัทเริ่มใช้ Coding Agent
ผู้วิจัยไม่พบการเพิ่มขึ้นอย่างมีนัยสำคัญของจำนวน issue และ epic ที่ปิดได้ และไม่พบการเปลี่ยนแปลงการจ้างงานที่ระบุได้ว่าเป็นผลจาก AI ส่วนสัดส่วนคนที่ทำหน้าที่รีวิวเพิ่มขึ้น 14% Ars Technica รายงานเพิ่มว่า แม้บริษัท 80% จะใช้ AI ช่วยรีวิวบางรูปแบบแล้วในเดือน มี.ค. 2026 แต่ Agent เป็นผู้เขียนคอมเมนต์รีวิวเพียง 23.3% Data Phoenix สรุปข้อจำกัดไว้ว่า งานนี้ไม่ได้พิสูจน์ว่า Agent ทำให้คุณภาพโค้ดแย่ลง แค่พบว่าภาระย้ายไปอยู่ที่การรีวิว
ข้อมูลนี้ทำให้คำถาม “โค้ดต้องอ่านง่ายไหม” กลายเป็นคำถามว่า ใครจะตรวจโค้ดจำนวนมากขึ้นนี้ และตรวจด้วยอะไร ถ้าคนยังอ่านทุกบรรทัด โค้ดที่อ่านยากก็ทำให้คอขวดแย่ลง ถ้าเปลี่ยนไปตรวจด้วย test และหลักฐานแบบที่ค่าย D เสนอ คำถามจะย้ายไปอยู่ที่ว่าการตรวจเหล่านั้นจับปัญหาได้จริงแค่ไหน
ทดลอง 02 — เมื่อ Agent ส่ง PR มากขึ้น คิวรีวิวจะยาวแค่ไหน
การจำลองเชิงการศึกษาแบบโมเดลคิวอย่างง่าย ทีมสมมติส่ง PR ฐาน 20 ชิ้นต่อสัปดาห์ ตัวเลขทั้งหมดเป็นค่าสมมติ ยกเว้นค่าเริ่มต้นของตัวคูณ PR (+23%) และอัตราขอแก้ (13% → 25%) ที่อ้างจากงานวิจัย Harvard ข้างต้น
ตัวคูณจำนวน PR หลังใช้ Agent
กำลังรีวิวของทีม (ชั่วโมงต่อสัปดาห์)
วิธีตรวจ
–
สมมติฐาน: คนอ่านทุกบรรทัดใช้ 1.5 ชั่วโมงต่อ PR, CI + test ช่วยลดเหลือ 1.1 ชั่วโมง, ดูหลักฐานที่ Agent แนบมาใช้ 0.5 ชั่วโมง, merge ทันทีใช้ 0.1 ชั่วโมง PR ที่ถูกขอแก้ต้องรีวิวรอบสองครึ่งหนึ่งของเวลาเดิม ระดับความเสี่ยงเป็นการจัดอันดับเชิงคุณภาพ ไม่ใช่ค่าที่วัดได้
สิ่งที่หลักฐานสนับสนุน และสิ่งที่ยังพิสูจน์ไม่ได้
| ข้ออ้างที่เห็นบน X | สถานะ | เหตุผล |
|---|---|---|
| Agent ทำงานเสร็จได้แม้โค้ดจะรก | มีหลักฐานบางส่วน | งานของ SonarSource พบอัตราผ่านใกล้เคียงกัน แต่ทดสอบแค่ Claude Sonnet 4.6 กับ 33 งานที่ผู้วิจัยสร้างเอง |
| โค้ดรกทำให้ Agent ใช้โทเคนมากขึ้น | มีหลักฐานบางส่วน | ค่าเฉลี่ยต่าง 7–8% และผลต่างกันมากในแต่ละงาน (ตั้งแต่ −47% ถึง +44%) ตัวเลข 10 เท่าที่เห็นบน X เป็นภาพสมมติ |
| โค้ดที่คนอ่านง่าย ก็เหมาะกับ AI ด้วย | มีหลักฐานบางส่วน | งาน CodeHealth พบความเสี่ยงพังต่ำกว่าสำหรับ LLM ขนาดกลาง แต่ไม่พบความต่างชัดใน Claude Code และผู้วิจัยบางส่วนเป็นเจ้าของเมตริก |
| Agent รับความซับซ้อนได้มากกว่าคน จึงผ่อนเกณฑ์ได้ | ประสบการณ์ส่วนตัว | Uncle Bob เล่าว่าให้ Agent ไปถึง cyclomatic complexity 10 ได้ แต่เป็นการสังเกตของเขาเอง ยังไม่มีงานวัดที่เราพบ |
| Coding Agent ทำให้ได้ซอฟต์แวร์มากขึ้น | ยังไม่พบในข้อมูลระดับบริษัท | งาน Harvard พบโค้ดและ PR เพิ่ม แต่ issue ที่ปิดได้ไม่เพิ่มอย่างมีนัยสำคัญ ข้อมูลสิ้นสุด มี.ค. 2026 ก่อนโมเดลรุ่นใหม่หลายตัว |
| Clean Code ต้องแลกกับประสิทธิภาพเสมอ | ยังถกกันอยู่ | มีตัวอย่างที่กฎบางข้อทำให้ช้าลงมาก เช่น benchmark ของ Casey Muratori แต่ก็มีผู้แย้งว่าเป็นกรณีเฉพาะ hot path และในการถกครั้งนี้ก็มีคนขอให้ @poteto แสดงหลักฐานคำว่า “เสมอ” |
| โค้ดของ Agent ดีกว่าค่ากลางของโค้ดที่คนเขียน | ยังไม่ยืนยัน | เป็นความเห็นจากประสบการณ์ของ @poteto และอีกหลายคน เรายังไม่พบงานวัดเทียบโดยตรงที่ตีพิมพ์แล้ว |
ทดลอง 03 — โค้ดส่วนนี้ต้องให้คนอ่านเข้าใจได้แค่ไหน
การจำลองเชิงการศึกษาแบบกำหนดกฎไว้ล่วงหน้า สรุปจากเหตุผลของค่ายต่างๆ บน X ไม่ใช่มาตรฐานอุตสาหกรรมหรือคำแนะนำทางกฎหมาย เลือกประเภทงาน แล้วติ๊กเงื่อนไขที่ตรงกับโปรเจกต์ของคุณ
ประเภทงาน
ผลจะแสดงที่นี่
นำไปใช้อย่างไร ตามบทบาท
สำหรับนักพัฒนาที่ใช้ Agent ทุกวัน
- อย่าเถียงกันด้วยคำว่า “slop” ให้ระบุปัญหาเป็นข้อ เช่น โค้ดซ้ำ ฟังก์ชันที่ไม่มีใครเรียก หรือ abstraction ที่ไม่จำเป็น
- วัดเองได้ ลองให้ Agent ทำงานเดียวกันบนโค้ดก่อนและหลัง refactor แล้วเทียบโทเคนและจำนวนรอบที่แก้
- เมื่อ Agent ผิดซ้ำเรื่องเดิม ให้แก้ที่ระบบ (type, lint, test) ไม่ใช่สั่งซ้ำในแชต
สำหรับหัวหน้าทีมและ CTO
- นับเวลารีวิวและอัตรา PR ที่ถูกขอแก้ ไม่ใช่นับแค่จำนวนบรรทัดหรือ PR
- กำหนดว่า “เสร็จ” คืออะไรก่อนเริ่มงาน และให้ Agent แนบหลักฐาน เช่นผล test หรือการรันจริง
- แยกโซนโค้ดที่ต้องให้คนอ่านและเซ็นรับ ออกจากโซนที่ Agent ดูแลได้
สำหรับนักศึกษาและคนเริ่มเขียนโค้ด
- ยังควรฝึกอ่านโค้ดและตั้งชื่อให้ดี เพราะคนที่ต้องตัดสินว่างานของ Agent ใช้ได้ไหมคือคุณ
- ฝึกเขียน test ที่ตรวจพฤติกรรม เพราะเป็นทักษะที่ทุกค่ายเห็นตรงกันว่าสำคัญขึ้น
- อย่าเชื่อคำพยากรณ์จากทั้งสองฝั่งทั้งหมด ข้อมูลยังน้อยและเปลี่ยนเร็ว
Brief สั้นๆ สำหรับสั่ง Agent: “ก่อนแก้ ให้หาโค้ดเดิมที่ทำหน้าที่คล้ายกันก่อนและใช้ซ้ำ ห้ามสร้าง helper ซ้ำ ห้ามเพิ่ม compatibility layer โดยไม่ถาม หลังแก้ ให้รัน test และแนบผล บอกว่าลบโค้ดอะไรไป และมีจุดไหนที่ควรให้คนอ่านเพราะกระทบข้อมูลหรือเงิน”
อ่านต่อบน Hybrid Mind
- Loop Engineering: เจาะวงจร AI Coding Agents แบบ Interactive ว่าด้วยวงจรตรวจที่ Agent รันเอง
- MOLT Sinai: ทีม AI Coding Agents แบบโรงพยาบาลโค้ด กรณีแยกผู้เขียน ผู้ตรวจ และคนอนุมัติ
- AI Finds A Way: Reward Hacking ทำไม test ที่ออกแบบไม่ดีถึงถูก Agent เล่นงานได้
- Karpathy กับช่องว่างความสามารถของ AI อีกมุมของการถกว่า AI ทำงานจริงได้แค่ไหน
คำถามที่พบบ่อย
1. Clean Code ตายแล้วจริงไหม?
ยังไม่มีหลักฐานพอจะพูดแบบนั้น งานวิจัยที่มีชี้ว่า Agent ที่เก่งพอยังทำงานเสร็จได้บนโค้ดรก แต่ใช้โทเคนและวนแก้มากกว่า ส่วนเสียงจาก X ส่วนใหญ่ รวมถึง Uncle Bob เห็นว่าหลักการยังอยู่ แต่เกณฑ์บางข้อ เช่น ขนาดฟังก์ชัน อาจผ่อนลงได้เมื่อผู้อ่านคือ Agent
2. @poteto บอกว่าไม่ต้องสนใจคุณภาพโค้ดใช่ไหม?
ไม่ใช่ เธอเสนอให้นิยามคุณภาพใหม่ว่าโค้ดที่ดีคือโค้ดที่ถูกต้อง ไม่มีบั๊ก และรันได้คุ้มค่า และยกเว้นงาน mission critical ไว้ตั้งแต่แรก ข้อที่คนแย้งคือคำกล่าวว่า maintainability “ไม่จริงอีกต่อไป” และการเรียกคำว่า slop ว่าเป็นคำดูถูก
3. ถ้า Agent เขียนโค้ดเร็วขึ้น ทำไมงานไม่เสร็จเร็วขึ้น?
งานวิจัย Harvard ชี้ว่าเวลาที่ได้จากการเขียนไปเพิ่มที่การรีวิว เวลารีวิว PR เพิ่มขึ้น 49% และ PR ที่ถูกขอแก้เกือบเพิ่มเป็นสองเท่า ผู้วิจัยจึงไม่พบการเพิ่มขึ้นของงานที่ปิดได้อย่างมีนัยสำคัญ แต่ข้อมูลสิ้นสุดเดือน มี.ค. 2026 และอาจเปลี่ยนเมื่อทีมปรับวิธีทำงาน
4. แล้วควรเขียนโค้ดให้ Agent อ่าน หรือให้คนอ่าน?
ขึ้นกับว่าใครต้องรับผิดชอบเมื่อโค้ดพัง ในต้นแบบหรือเครื่องมือภายใน หลายคนยอมให้ Agent ดูแลเกือบทั้งหมด แต่ในระบบเงิน การแพทย์ หรือระบบควบคุม เกือบทุกค่ายเห็นตรงกันว่าคนต้องตรวจและอธิบายได้ ลองใช้ทดลอง 03 ด้านบนเป็นจุดเริ่มคิด
5. คนเริ่มเขียนโปรแกรมยังต้องเรียน Clean Code ไหม?
ยังควรเรียน แต่ควรเรียนในฐานะ “เหตุผล” มากกว่า “กฎ” เช่น ทำไมชื่อที่ดีช่วยให้ค้นเจอ ทำไมโค้ดซ้ำทำให้แก้ไม่ครบ และฝึกเขียน test ควบคู่ เพราะทักษะที่ทุกค่ายเห็นว่าสำคัญขึ้นคือการตัดสินว่างานที่ Agent ส่งมาใช้ได้จริงหรือไม่
เอกสารอ้างอิงและขอบเขตการตรวจ
- @poteto — “codebases have always contained slop” (11 ต.ค. 2026) และโพสต์ต่อเนื่องเรื่อง Good Code ในปี 2026
- Fiona Chen & James Stratton, “Artificial Intelligence in the Firm: Bottlenecks in Software Production” (Harvard, working paper ส.ค. 2026)
- Ars Technica — AI coding agents generate more code, but not more software (9 ต.ค. 2026)
- Data Phoenix — Harvard study ties coding-agent gains to heavier code review (9 ต.ค. 2026)
- Trivedi & Schmitt (SonarSource), “Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study”, arXiv:2605.20049
- Borg, Hagatulah, Tornhill & Söderberg, “Code for Machines, Not Just Humans: Quantifying AI-Friendliness with Code Health Metrics”, arXiv:2601.02200 / FORGE 2026 (อ้างตามบทคัดย่อ)
- Casey Muratori — “Clean” Code, Horrible Performance (ก.พ. 2023)
- สรุปบทสัมภาษณ์ Uncle Bob ในพอดแคสต์ HangarDX (แหล่งรอง ใช้เป็นบริบทเรื่อง CRAP และ mutation testing)
- โพสต์บน X ทุกโพสต์ที่อ้างในบทความ ลิงก์ไว้ในแต่ละค่าย
ขอบเขตการตรวจ: ช่วงเวลาของโพสต์ที่อ่านคือ 8–12 ต.ค. 2026 (UTC) โดยเน้นวันที่ 11–12 เราใช้เครื่องมืออ่าน X แบบสาธารณะ ค้นหา 9 ครั้ง ดึงโพสต์ที่โควต 2 ครั้ง และดึงโพสต์ตาม ID 3 ครั้ง ได้ผลรวม 282 รายการ (โพสต์ไม่ซ้ำ 255 โพสต์ รวมรีโพสต์และโพสต์นอกประเด็นที่ติดมากับคำค้น) และอ่านโพสต์ที่เกี่ยวกับประเด็นนี้โดยตรงราว 160 โพสต์ ตัวเลขปริมาณมาจาก X Counts API 3 คำค้นหลัก วัดเมื่อ 13 ต.ค. 2026 ราว 00:16–00:18 น. (เวลาไทย)
ตัวอย่างโพสต์นี้ไม่ได้เป็นตัวแทนความเห็นของนักพัฒนาทุกคน และเราไม่ได้คำนวณสัดส่วนความเห็น ยอดไลก์และยอดแสดงผลเป็นค่า ณ เวลาที่อ่าน Hybrid Mind ไม่ได้ทดลองซ้ำงานวิจัยใด ไม่ได้วัดโทเคนบน codebase จริง และอ่านงาน CodeHealth เฉพาะบทคัดย่อ ทุก Lab เป็นการจำลองเชิงการศึกษา
หมายเหตุความโปร่งใส: Lauren Tan (@poteto) ทำงานกับผลิตภัณฑ์ Grok Bot ของ SpaceXSI และ Addy Osmani ระบุว่าทำงานกับ Claude Code ของ Anthropic ทั้งคู่จึงมีส่วนได้เสียกับการใช้ Coding Agent ส่วนงานวิจัยสองชิ้นมาจากบริษัทที่ขายเครื่องมือวัดคุณภาพโค้ด บทความนี้ค้นคว้าและเรียบเรียงโดยใช้เครื่องมือ AI ช่วย
ใส่ความเห็น