เหตุผลที่ Software Factory ล้มเหลว: แค่ Harness Engineering อย่างเดียวยังไม่พอ

 (github.com/humanlayer)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Software factory แบบไร้คน (lights-off) ที่ไม่มีคนอ่านหรือเขียนโค้ดช่วยเพิ่มความเร็วในการสร้างได้ แต่ก็เท่ากับตัดมนุษย์ที่ใช้ตัดสินความสามารถในการบำรุงรักษาระยะยาวออกไปด้วย จึงยากที่จะใช้ได้กับโค้ดเบส production ที่ซับซ้อน
  • การทำ reinforcement learning ให้โมเดลเขียนโค้ด มักปรับให้เหมาะกับรางวัลที่เร็วและชัดเจน เช่น การผ่านเทสต์ แต่ไม่สามารถลงโทษ ต้นทุนจากการออกแบบที่แย่ ซึ่งจะเผยออกมาหลังจากนั้นอีกหลายเดือนได้
  • กลุ่มเบนช์มาร์กอย่าง SWE-bench ประเมินการแก้บั๊กและการคงเทสต์เดิมไว้ แต่ไม่สามารถกรอง การเปลี่ยนแปลงที่ค่อย ๆ ทำให้คุณภาพโค้ดแย่ลง เช่น try/catch แบบสะเปะสะปะ, type cast ที่ไม่ระวัง, หรือ shotgun surgery
  • ตอนนี้ยังต้องให้มนุษย์ทำ code review และตรวจทาน ข้อกำหนดผลิตภัณฑ์, สถาปัตยกรรมระบบ, การออกแบบโปรแกรม, vertical slice ก่อนลงมือ implement เพื่อลดงานแก้ซ้ำและลดการรีวิวโค้ดจำนวนมากที่ AI สร้างขึ้น
  • หากยอมรับข้อจำกัดของโมเดล ก็สามารถพัฒนาได้ เร็วขึ้น 2~3 เท่า โดยยังรักษาคุณภาพใกล้ระดับมนุษย์ แทนที่จะฝืนไล่ตามระบบอัตโนมัติ 10~100 เท่า และการตัดสินใจสำคัญกับการอ่านโค้ดยังไม่อาจโยนออกไปให้ที่อื่นทำแทนได้

คำสัญญาและความจริงของ software factory ที่ขับเคลื่อนด้วยลูป

  • ในการแข่งขันนำ AI coding ไปใช้จริงใน production มีแนวคิดแพร่หลายว่าแค่เพิ่ม harness และ agent loop ก็พอ
  • แนวทางนี้ตั้งอยู่บนสมมติฐานว่าคนคือคอขวด โมเดลดีพอแล้ว และต้นทุนการสร้างโค้ดแทบเป็นศูนย์ ดังนั้นก็แค่ปล่อยของให้มากขึ้น
  • เป้าหมายคือทำให้ได้พร้อมกันทั้ง ความเร็ว 10~100 เท่า, คุณภาพสูง, และการตัด human code review ออกไป
    • มีมุมมองว่าเพียงเพิ่ม linter และสั่งให้ PR review bot วิจารณ์แบบเข้มข้น ซอฟต์แวร์ก็จะปลอดภัยได้ด้วยตัวเอง
  • แต่ในสนามจริงเริ่มมีกรณีที่ coding agent พลาดจนเกิด incident และโค้ดเบสพังลงอย่างรวดเร็ว
  • รายงานของ Faros AI สังเกตการเปลี่ยนแปลงต่อไปนี้หลังนำเครื่องมือ AI coding มาใช้
    • จำนวนและความยาวของคอมเมนต์รีวิวเพิ่มขึ้น แต่ PR ที่ถูก merge โดยไม่มีรีวิวก็เพิ่มขึ้นเช่นกัน
    • incident และจำนวนบั๊กต่อ developer เพิ่มขึ้น
    • อย่างไรก็ตาม นี่ยังเป็นสัญญาณเชิงสหสัมพันธ์มากกว่าความเป็นเหตุเป็นผลที่พิสูจน์แล้ว
  • หา data เชิงยืนยันที่แสดงผลลัพธ์ของ StrongDM ได้ยาก และ update ที่เผยแพร่ระหว่างกุมภาพันธ์ถึงมิถุนายนก็มีไม่มาก

โค้ดเบสที่ซับซ้อนเป็นปัญหาคนละแบบกับ vibe coding

  • ทีมที่ทำ side project ให้คนใช้ไม่กี่คน กับทีมที่ดูแลระบบ enterprise อายุ 10 ปี แทบไม่มีข้อจำกัดร่วมกันเลย
  • สิ่งที่กำลังพูดถึงไม่ใช่ vibe coding เอง แต่คือ ปัญหายากของโค้ดเบสที่ซับซ้อน และการดูแล production ระยะยาว
  • แต่ก่อนคำว่า brownfield มักหมายถึงระบบ Java เก่า ๆ แต่โค้ดเบสที่ agent สร้างขึ้นก็อาจแก้ไขยากได้หลังผ่านไปประมาณ 3~6 เดือน เพราะความเร็วในการพัฒนาที่สูงมาก
  • เวลาผลลัพธ์ออกมาแย่ มักมีคำแนะนำว่าเป็นเพราะ token หรือเทคโนโลยียังไม่พอ แต่ปัญหาหลักจริง ๆ อยู่ที่ วิธีฝึกโมเดล มากกว่า harness

วิวัฒนาการของ software factory

  • ตั้งแต่ปี 1968 จนถึงก่อนยุค AI

    • คำว่า software factory ย้อนกลับไปได้ถึง การประชุม NATO ปี 1968 ที่คำว่า software engineering ปรากฏขึ้น
    • factory ทั่วไปราวปี 2022 มีวงจรดังนี้
      • มนุษย์ตัดสินใจว่าจะสร้างอะไร แล้วบันทึกลง tracker อย่าง Linear หรือ Jira
      • ผู้รับผิดชอบลงมือ implement และทดสอบ
      • ผ่านการตรวจอัตโนมัติและ human code review ถ้ามีปัญหาก็ย้อนกลับไปขั้น implement
      • หลัง deploy ขึ้น production ก็ monitor ต่อ และนำ incident กับ feedback จากผู้ใช้กลับเข้า tracker
    • เนื่องจากทั้งการ implement และการ review ใช้เวลาหลายชั่วโมงหรือหลายวัน ทีมจึงมักวางการวางแผน, ข้อเสนอสถาปัตยกรรม, และ sprint planning ไว้ข้างหน้าเพื่อสร้างฉันทามติก่อน
    • การตกลงกันก่อน implement ช่วย ลดงานแก้ซ้ำ และ PR ที่เสร็จใกล้เคียงทิศทางที่ตกลงกันไว้ก็รีวิวได้เร็ว แม้อ่านทุกบรรทัดก็ตาม

  • Factory แบบ agent

    • Ramp, Stripe, WorkOS, Brex และบริษัทอื่น ๆ บอกว่า factory แบบ agent ส่งมอบโค้ดได้ราว 75%
    • พวกเขาแทนขั้น implement ของเดิมที่เป็นงานมนุษย์ด้วย agent และผสาน orchestration, harness, sandbox, model, และการใช้งานคอมพิวเตอร์เข้าด้วยกัน
    • เวลา implement ลดจากหลายชั่วโมงหรือหลายวันเหลือเป็นนาทีหรือไม่กี่ชั่วโมง แต่การอ่านโค้ดและการทดสอบโดยมนุษย์ยังอยู่เหมือนเดิม ทำให้ รีวิวกลายเป็นคอขวด
    • เพื่อลดคอขวดนี้จึงมีการเพิ่มลูปหลายแบบ
      • agent รีวิวโค้ดที่ตรวจ style, bug, และ security
      • regression test ที่ตรวจพฤติกรรมภายนอกผ่าน browser และการใช้งานคอมพิวเตอร์
      • flow ที่เชื่อม incident เข้า PR อัตโนมัติเพื่อให้ผู้รับผิดชอบได้รับตัวเลือกการแก้ไข
      • flow ที่เชื่อม feedback ผู้ใช้เข้าสู่คิวงานโดยตรง
    • สุดท้ายปัญหาการปฏิบัติการก็แคบลงเหลือว่าใส่งานเข้าคิวได้มากแค่ไหน และตรวจผลลัพธ์กับทดสอบได้เร็วเพียงใด

  • Factory แบบไร้คน

    • factory แบบไร้คนที่ Dan Shapiro ตั้งชื่อนั้น ตัดขั้นที่มนุษย์อ่านทุกการเปลี่ยนแปลงออกไป
    • แทนที่จะลงทุนกับ code review ก็ไปลงทุนกับด้านต่อไปนี้
      • การทดสอบตัวเองของ agent
      • sandbox และ orchestration
      • การรีวิวอัตโนมัติและ monitoring
      • gradual rollout และการเก็บสัญญาณ feedback จากผู้ใช้
    • เมื่อเอาการตัดสินใจของคนออกไป ก็จะเหลือเพียงถามว่าให้ agent รับงานได้มากแค่ไหน แต่แนวทางนี้ใช้ไม่ได้กับโค้ดเบส production ที่ซับซ้อน

ความล้มเหลวของแนวทางไร้คนที่ทดลองใช้จริง

  • ตั้งแต่กรกฎาคม 2025 มีการใช้ แนวทางไร้คนเต็มรูปแบบ โดยให้อ่านแค่สเปกและ ticket แล้วมอบงานขนาดเล็กถึงกลางให้ background agent ทำ
  • ผ่านไปไม่กี่เดือนก็เริ่มเกิดปัญหาซับซ้อนที่แก้ไม่ได้ แม้ใช้ prompt และ workflow ขั้นสูง
    • รวบรวม context ที่จำเป็นส่งให้โมเดล
    • ให้ agent ลองทำซ้ำปัญหาในราว 10 วิธี
    • สุดท้ายมนุษย์ต้องลงไปค้นหาต้นเหตุในโค้ดเบสที่ไม่ได้อ่านมา 3 เดือนด้วยตัวเอง
  • ระหว่างนั้นเว็บไซต์ล่ม ผู้ใช้ได้รับผลกระทบ และมนุษย์ต้องกลับมาอ่านโค้ดคุณภาพต่ำที่สะสมไว้
  • ตอนล้มเหลวครั้งแรกยังคิดว่าน่าจะคุ้มที่จะรับความเสี่ยงเพื่อแลกความเร็ว แต่พอเกิดปัญหาราวครั้งที่สามในเดือนพฤศจิกายน การ เขียนใหม่ตั้งแต่ต้น กลับง่ายกว่า
    • ผู้ร่วมก่อตั้งใช้เวลา 2 สัปดาห์ใน VS Code เพื่อ implement แพตเทิร์นต่าง ๆ ขึ้นมาใหม่ด้วยตัวเอง

เหตุผลที่โมเดลทำให้คุณภาพโค้ดเบสลดลง

  • โมเดลในปัจจุบันยังไม่สามารถรักษาและปรับปรุงคุณภาพโค้ดเบสในระยะยาวได้ หากไม่มีการกำกับทิศทางจากมนุษย์อย่างมาก
  • คำว่าบำรุงรักษาง่ายในที่นี้ หมายถึงความสามารถในการหลีกเลี่ยงสถานะที่เปลี่ยนส่วนหนึ่งแล้วส่วนอื่นพัง และต้องแก้การเปลี่ยนแปลงเดียวกันหลายจุดแบบ shotgun surgery
  • โมเดลเก่งขึ้นมากในงานแก้ปัญหาเฉพาะครั้งหรือสร้าง marketing site ใหม่ แต่ ความสามารถในการปรับปรุงคุณภาพโค้ดเมื่อเวลาผ่านไป ยังยากจะบอกว่าดีขึ้นชัดเจน
  • และยังไม่มี benchmark ที่ดีพอสำหรับวัดความสามารถในการบำรุงรักษา จึงยากจะพิสูจน์หรือโต้แย้งความแตกต่างนี้
  • แม้โมเดลอย่าง GPT-5.5 xhigh จะทำ refactor ได้ยอดเยี่ยม แต่ถ้ามนุษย์ยังต้องเข้าใจโค้ดเบสและสั่งงานอย่างละเอียดอยู่ดี ปัญหาของ factory แบบไร้คนก็ยังไม่ถูกแก้

Claude Code และ reinforcement learning ภายใน harness

  • ก่อนยุค Claude Code ก็มี CLI agent อย่าง aider, cline, codebuff ที่ให้ความสามารถอ่าน, เขียน, แก้ไข, ค้นหา, shell tool และ context engineering อยู่แล้ว
  • agent รุ่นก่อนหน้ามักมีปัญหา ความเสถียรในการใช้เครื่องมือ เช่น ล้มเหลวกับการแก้ไขเดิมซ้ำ ๆ
  • บทความ SWE-Agent วิเคราะห์ว่าแม้แต่ความต่างเล็กน้อยของการออกแบบเครื่องมือ เช่น ใส่เลขบรรทัดในผลลัพธ์ของ ReadFile หรือเปลี่ยน Edit จาก find/replace เป็นการแก้ไขตามช่วงบรรทัด ก็ส่งผลต่อประสิทธิภาพได้
  • หนึ่งในเหตุผลสำคัญที่ Claude Code เติบโตเร็ว คือ Anthropic ทำ reinforcement learning ให้โมเดลภายใน harness ที่จะใช้ปล่อยจริง
    • ปรับน้ำหนักโมเดลให้เรียกชุดเครื่องมือที่ถูกต้องภายใน agent loop
    • ต่างจากนักพัฒนาภายนอกที่ต้องปรับนิยามเครื่องมือและการประเมินให้เข้ากับความชอบของโมเดล ผู้ถือครองโมเดลสามารถ เปลี่ยนตัวโมเดลให้เข้ากับเครื่องมือ ได้
  • ทีมที่มีทั้ง harness และน้ำหนักโมเดลจึงได้เปรียบกว่าทีมที่ทำได้เพียงสร้าง harness แต่ปรับน้ำหนักไม่ได้

ข้อจำกัดของรางวัลใน reinforcement learning สำหรับ coding agent

  • reinforcement learning ของโมเดลเขียนโค้ดมักวนขั้นตอนต่อไปนี้หลายล้านครั้ง
    1. สร้าง execution trace ของ agent เพื่อแก้ปัญหาอย่างการแก้เทสต์
    2. ให้ตัวตรวจสอบประเมิน execution trace
    3. อัปเดตน้ำหนักโมเดลเพื่อเพิ่มโอกาสของ execution trace ที่ดี และลดโอกาสของ execution trace ที่แย่
  • ปัญหาคือคะแนนประเมินอาจ มีมิติเดียวเกินไป

  • กรณีของ SWE-bench Multilingual

    • SWE-bench Multilingual ใช้งานขนาดราว 15 นาทีจาก repository โอเพนซอร์สอย่าง Redis, jq, Django
    • รางวัลเป็น 0 หรือ 1 โดยตรวจสองเงื่อนไข
      • FAIL_TO_PASS: แก้ปัญหาที่ร้องขอได้หรือไม่
      • PASS_TO_PASS: ทำพฤติกรรมเดิมพังหรือไม่
    • งาน fastlane__fastlane-19304 เป็นบั๊กที่เมื่อไม่มีพารามิเตอร์ include, exclude ซึ่งเป็น optional จะเรียก .empty? กับ nil จนล้มเหลว
    • การแก้โดยมนุษย์จริง ๆ คือ เปลี่ยนแค่สองบรรทัด เพื่อให้ nil มีค่าเริ่มต้นเป็นอาร์เรย์ว่าง
    • โมเดลได้รับเพียง commit พื้นฐานก่อนแก้ กับรายงานบั๊ก ไม่ได้เห็น patch คำตอบหรือ patch เทสต์สำหรับให้คะแนน
    • การประเมินทำตามลำดับนี้
      1. เก็บ patch ที่โมเดลสร้างไว้
      2. ลบการแก้ไขไฟล์เทสต์ที่โมเดลทำ
      3. นำ patch เทสต์ลับของ benchmark มาใช้
      4. รันทั้งเทสต์เดิมและเทสต์ใหม่ร่วมกัน
    • เหตุที่ทิ้งการแก้เทสต์ของโมเดล เพราะบางครั้งโมเดลอาจคอมเมนต์เทสต์ที่ล้มเหลวทิ้ง หรือใส่ mock ที่ไม่มีความหมายเพื่อให้ผ่าน
    • benchmark กับตัวตรวจสอบสำหรับ reinforcement learning ไม่ใช่สิ่งเดียวกันและควรแยกจากกัน แต่ทั้งคู่ต่างสะท้อนข้อจำกัดเชิงโครงสร้างในการตัดสินคุณภาพของ execution trace สำหรับงาน coding

  • ไม่มีบทลงโทษต่อการทำให้การออกแบบแย่ลง

    • ถ้าเทสต์ผ่าน กระบวนการที่ใช้ไปและคุณภาพเชิงโครงสร้างของวิธีแก้จะไม่สะท้อนในคะแนน
    • การห่อทุกอย่างด้วย try/catch หรือ type cast แบบหลวม ๆ ที่ทำลายข้อดีของ type system ก็อาจถูกนับเป็นคำตอบที่ถูก
    • ความเสียหายต่อความสามารถในการบำรุงรักษา จะไม่ถูกลงโทษ ตราบใดที่เทสต์เดิมและเทสต์ใหม่ยังผ่าน

การตรวจสอบคุณภาพที่ยากกว่าการผ่านเทสต์

  • เทสต์ให้ผลสำเร็จหรือความล้มเหลวที่ชัดเจนภายในไม่กี่วินาที จึงสามารถวน reinforcement learning ได้หลายล้านครั้ง
  • แต่ต้นทุนของสถาปัตยกรรมที่แย่จะเผยออกมาอีกหลายสัปดาห์ หลายเดือน หรือหลายปี เมื่อการเปลี่ยนเล็ก ๆ ต้องถูกแก้ในหลายจุด
  • benchmark ปัจจุบันยังประเมิน ต้นทุนการออกแบบระยะยาว แบบนี้ไม่ได้
  • แม้ reinforcement learning กับ benchmark จะไม่ใช่สิ่งเดียวกัน แต่หากความสามารถด้านบำรุงรักษาถูกแก้ได้แล้วใน reinforcement learning ก็มีแนวโน้มว่าจะสะท้อนออกมาใน benchmark design ด้วย
  • ดังนั้น การที่คะแนน benchmark เดิมดีขึ้น จึงไม่ใช่หลักฐานว่าโมเดลเลิกทำโค้ดเบสสกปรกแล้ว

ความพยายามใหม่ในการประเมินความสามารถในการบำรุงรักษา

  • แนวหน้าของคุณภาพโมเดลกำลังดีขึ้น แต่ความคาดหวังและการโหมประชาสัมพันธ์ยังนำหน้าไปไกลกว่าวินัยทางเทคนิค
  • ตัวอย่างที่พยายามประเมินให้ใกล้กับความสามารถในการบำรุงรักษามากขึ้น ได้แก่
    • SWE-Marathon: ใช้งานขนาดประมาณ 400 ชั่วโมง อย่างการทำซ้ำฟีเจอร์ทั้งหมดของ Excel และใช้ช่องรางวัลหลายมิติแทนการสำเร็จ/ล้มเหลวแบบค่าเดียว
    • DeepSWE: ใช้งานโอเพนซอร์สขนาดใหญ่ที่ยังไม่เคยถูก implement จริงในโลกความเป็นจริง เพื่อลดการปนเปื้อนของข้อมูลฝึก แต่ไม่ได้แก้ปัญหาคุณภาพโดยตรง
    • Frontier Code: ประเมินงานที่กินหลาย PR และลงโทษหากเขียนเทสต์ที่ไม่ล้มเหลวแม้ในโค้ดก่อน patch
      • ใช้วิธีคล้าย mutation testing เพื่อตรวจสอบความใช้ได้ของเทสต์แบบกำหนดผลได้แน่นอน
      • ยังรัน judge model ที่ตรวจ diff ตามกฎคุณภาพโค้ดด้วย
  • หาก judge model สามารถแยกคุณภาพได้อย่างเสถียร ก็มีข้อโต้แย้งว่าโมเดลนั้นน่าจะสร้างโค้ดดีตั้งแต่แรกได้อยู่แล้ว
  • reinforcement learning ต้องการ oracle ที่เร็วและเชื่อถือได้ แต่ ความสามารถในการบำรุงรักษาไม่มี oracle แบบนั้น
  • review agent และ token เพิ่มเติมช่วยจับความผิดพลาดชัด ๆ และยกระดับคุณภาพขั้นต่ำได้ แต่ไม่สามารถดันเพดานคุณภาพสูงสุดให้เกินสิ่งที่สอนโมเดลไว้ผ่าน reinforcement learning
  • SWE-Marathon, DeepSWE, Frontier Code เป็นความพยายามระยะแรกในการประเมินความสามารถในการบำรุงรักษาให้เกินกว่าตัดสินแค่สำเร็จหรือล้มเหลว แต่ยังไม่ถึงระดับที่เอาไปฝากทั้งโค้ดเบสได้

4 ขั้นตอนในการพามนุษย์กลับเข้าลูป

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

  • 1. การทบทวนผลิตภัณฑ์

    • เปลี่ยนประโยคสั้น ๆ หรือบันทึกเสียงยาว ๆ ให้เป็นเอกสารกึ่งมีโครงสร้าง เพื่อยึดให้ชัดว่าจะสร้างอะไรและทำไปทำไม
    • เริ่มจากนิยาม ปัญหาที่ต้องการแก้ ด้วยภาษาของผู้ใช้ และกำหนดเกณฑ์วัดความสำเร็จหลังปล่อยใช้งาน
      • ลดเวลาทำ workflow
      • ทำ milestone การ onboard ได้เร็วขึ้น
      • ปรับปรุงอัตราความผิดพลาดหรือ latency
      • ลด support ticket บางประเภท
    • โฟกัสที่ประสบการณ์ผู้ใช้มากกว่ารายละเอียดทางเทคนิค และหากการตัดสินใจทางเทคนิคเริ่มขวางการตัดสินใจด้านผลิตภัณฑ์ ให้เก็บเอกสารปัจจุบันไว้ก่อนแล้วค่อยย้ายไป review สถาปัตยกรรมหรือ prototype เพื่อตรวจความเป็นไปได้
    • สำหรับพฤติกรรมบนหน้าจอ การดู mockup HTML แบบหยาบมักช่วยสร้างฉันทามติได้ดีกว่าคำอธิบายยาว ๆ
    • ขั้นตอนนี้ไม่จำเป็นสำหรับการแก้ข้อความ, script ใช้ครั้งเดียว, หรือบั๊กที่มีวิธีทำซ้ำชัดเจน และสามารถมอบให้ agent ได้เลย
    • ควรเลือกมาทำ product review เฉพาะการเปลี่ยนแปลงที่มีต้นทุนสูงหาก agent เข้าใจเจตนาผิด
    • ผู้รีวิว PR ควรได้รีวิวทั้งสเปกผลิตภัณฑ์และเทคนิคก่อนล่วงหน้า โดยอาจใช้คอมเมนต์เอกสารแบบอะซิงก์ หรือ GitHub, Notion เป็นต้น

  • 2. สถาปัตยกรรมระบบ

    • ตกลงกันว่าสื่อสารกันอย่างไรระหว่าง service, endpoint, schema, queue, และ storage โดยยังไม่ลงลึกถึง implementation ภายในโปรแกรม
    • เพื่อเพิ่ม bandwidth ในการสื่อสารระหว่างมนุษย์กับ agent ให้ใช้รูปแบบต่อไปนี้
      • sequence diagram ระหว่าง UI, API, service, และ storage
      • API contract ที่แสดง request/response
      • data model ที่แสดงตารางใหม่และรูปแบบ query
    • Mermaid มีประโยชน์ แต่ถ้าใช้มากเกินไปอาจทำให้มั่นใจผิด ๆ ว่าได้ข้อสรุปจริงแล้ว
    • การ review สถาปัตยกรรมช่วยกันนิสัยแย่ของโมเดลตั้งแต่ต้นได้ดี แต่ยังไม่พอจะรับประกันโค้ดคุณภาพสูง

  • 3. การออกแบบโปรแกรม

    • ก่อน implement ให้ตัดสิน รูปร่างของโค้ด ซึ่งอยู่ต่ำกว่าสถาปัตยกรรมลงมาอีกหนึ่งระดับ
      • type
      • method signature
      • การจัดวางโปรแกรม
      • call stack
    • ภาพ pseudo-code แบบเบากว่าอ่านง่ายกว่า Mermaid ที่ซับซ้อน
    • หากเป็นการเปลี่ยน orchestration หรือ control flow ให้ใช้ต้นไม้ call stack และหากส่วนที่เปลี่ยนสำคัญให้ใช้ syntax แบบ diff
    • ใช้ file tree diff เพื่อตรวจตำแหน่งและบทบาทของไฟล์ใหม่กับไฟล์ที่แก้ไข
    • การกำหนด type และ method signature ของฟังก์ชันสำคัญล่วงหน้าช่วยลดโอกาสที่ agent จะเลือกการออกแบบภายในผิดทาง
    • โมเดลสามารถร่างให้ก่อน แล้วมนุษย์ค่อยปรับแต่ง เป็นการดึงการตัดสินใจที่ปกติจะเกิดแบบแฝงใน code review ให้มาเกิด ในช่วงที่ต้นทุนถูกกว่า

  • 4. Vertical slice

    • โมเดลมักชอบ แผนแนวนอน ที่ค่อยซ้อนจาก database migration → service layer → API → frontend
    • แผนแนวนอนทำให้ระหว่างทำงานยากที่จะลองจับของจริงและตรวจสอบวิธีแก้ผ่าน browser หรือ curl
    • ก่อนยุค AI นักพัฒนามักไม่เขียนทีเดียว 500 หรือ 2,000 บรรทัด แต่จะขยายจากตรงกลางออกด้านนอกพร้อมตรวจสอบไปเรื่อย ๆ
      1. สร้าง API contract กับ mock data และตรวจด้วย curl
      2. ให้ frontend ใช้ mock data แล้วขัดเกลาใน browser
      3. เชื่อม API เข้ากับ service layer
      4. เพิ่ม database migration และการเชื่อมกับ storage
      5. เพิ่ม business logic
      6. เพิ่ม error handling
    • vertical slice หรือ tracer bullets ทำให้ทดสอบและปรับปรุงการทำงานจริงได้ในแต่ละขั้น
    • ในพื้นที่ที่คุณภาพสำคัญเป็นพิเศษ การรีวิวทีละ 100~200 บรรทัด แล้วปรับทิศทางใหม่ในแต่ละขั้น ถูกกว่าการมาแก้เกิน 2,000 บรรทัดทีหลัง
    • แม้เป็นโมเดลรุ่นล่าสุดก็ยังวางแผนแบบนี้ได้ยากหากไม่มีการกำกับจากมนุษย์ และยัง generalize ข้ามโค้ดเบสกับชนิดงานได้ไม่ดี จึงยังต้องให้มนุษย์อยู่ในลูป

วิธีใช้ตามขนาดงาน

  • การวางแผนล่วงหน้า 30 นาที อาจลดเวลาการรีวิวหลัง implement ได้หลายชั่วโมง
  • หากต้องการรักษาคุณภาพใกล้ระดับมนุษย์ ต้องให้มนุษย์เข้ามาเกี่ยวข้องใน product design, system architecture, program design, และ vertical slice
  • ไม่ได้ใช้กระบวนการเต็มรูปแบบกับทุกงาน
    • ประมาณ 40% ของงาน สร้างทีเดียวจบหรือใช้ feedback เบา ๆ 1~2 รอบก็เสร็จ
    • งานขนาดกลางสามารถรวม product/system design ไว้ในเอกสารแผนเดียวและไม่ต้องแยกขั้น implement
    • งานใหญ่ให้ผ่านครบทั้งสี่ขั้น แต่หากบางขั้นไม่เหมาะ เช่น refactor ขนาดใหญ่ที่ไม่เข้ากับ product review ก็ข้ามขั้นนั้นได้
  • โดยทั่วไปจะให้โมเดลทำทีละ 1~3 slice และตรวจโค้ดที่กำลังคืบหน้าไปด้วย
  • การแก้โครงสร้างภายในหรือฟังก์ชันให้ถูกตั้งแต่ต้น ง่ายกว่าการสร้างจำนวนมากแล้วค่อยไล่หาว่าอะไรผิด

คอขวดไม่ใช่จำนวน PR แต่คือคุณภาพของ PR

  • คอขวดไม่ใช่ PR เยอะเกินไป แต่คือ PR ที่แย่มีมากเกินไป
  • PR ที่สะอาด ทำตามแบบแผนที่ตัดสินไว้ และสอดคล้องกับธรรมเนียมของทีม สามารถรีวิวได้เร็วแม้จะอ่านทุกไฟล์
  • แค่ 20% ของ PR ต้องแก้ซ้ำ ก็สร้างภาระทั้งด้านการคิดและอารมณ์ให้กับทั้งผู้ส่งและผู้รีวิวแล้ว
  • PR ที่ AI สร้างรวดเดียวมักมีอัตราต้องแก้ซ้ำ ใกล้ 50%
  • ต่อให้ผู้ส่งเป็น AI ก็ยังต้องมีใครสักคนเริ่มงาน ขัดเกลาผลลัพธ์ หรือรับผิดชอบมันอยู่ดี ดังนั้นต้นทุนการแก้ซ้ำไม่ได้หายไป

ความเร็วในการพัฒนาที่เกิดจากการยอมรับข้อจำกัด

  • ข้อจำกัดหลักตอนนี้คือ โมเดลมีสิ่งที่ทำได้ดีและทำได้ไม่ดีชัดเจน และมนุษย์ยังต้องอ่านโค้ดไปอีกพักใหญ่
  • แทนที่จะไล่ตามความเร็ว 10~100 เท่าด้วยสมมติฐานว่าคุณภาพโค้ดไม่สำคัญ หากปรับระบบให้เหมาะภายใต้ข้อจำกัดนี้ ก็สามารถได้ ความเร็ว 2~3 เท่า อย่างปลอดภัย
  • หลักปฏิบัติจริงมี 4 ข้อ
    1. ทำงานกับโมเดลให้มากพอจนเกิดสัญชาตญาณต่อข้อจำกัดของมัน
    2. ปรับระบบการพัฒนาให้เหมาะภายใต้ข้อจำกัดนั้น
    3. มองหาจุดที่มีแรงทดสูง
    4. อ่านโค้ดจริง
  • harness และ loop เป็นเครื่องมือสำหรับลดข้อผิดพลาดที่เห็นชัด แต่ไม่สามารถแทนที่ การตัดสินเรื่องความสามารถในการบำรุงรักษาและการคิดเชิงออกแบบ ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • เรียกสิ่งนี้ว่า ปัญหาเจตนา-การทำให้เป็นจริง-คุณภาพ
    โรงงานซอฟต์แวร์สามารถทำแอป ฟีเจอร์ การแก้บั๊ก การเปลี่ยนแปลงดีไซน์ ไปจนถึงการรีแฟกเตอร์ได้จาก requirement แค่บรรทัดเดียว แต่การจะสร้างเจตนาของมนุษย์และทิศทางวิวัฒนาการของผลิตภัณฑ์ที่อยู่เบื้องหลัง requirement นั้นได้อย่างถูกต้อง เป็นคนละประเด็นกัน
    วิธีทำให้เป็นจริงนั้นเกิดการระเบิดเชิงจัดหมู่ได้ และวิธีที่ “ถูกต้อง” ซึ่งสอดคล้องกับระบบ ขยายต่อได้ เข้าใจง่าย และรองรับผู้ใช้นับล้านอย่างปลอดภัยนั้น เป็นเรื่องอัตวิสัยขึ้นกับคนและปัญหา แม้การทดสอบและหลักฐานการทำงานจะช่วยยกระดับคุณภาพบางส่วนได้ แต่ไม่มี feedback loop สำหรับตรวจสอบและปรับแก้ คุณภาพเชิงอัตวิสัย แบบนี้

    • ต่อให้ลูกค้าบอกว่า “ต้องการ X” ก็อาจเป็นได้ว่าต้องการ X จริง ๆ, ไม่ได้ต้องการ X, หรือจริง ๆ แล้วต้องการ Y แต่แค่พูดออกมาไม่ได้ ลูกค้ารายอื่นอาจไม่ต้องการ X หรืออาจเขย่านักพัฒนาโดยไม่มีเหตุผลชัดเจนก็ได้
    • โรงงานซอฟต์แวร์เหมาะกับซอฟต์แวร์ส่วนตัว/งานอดิเรกที่แทบไม่มีผู้ใช้และรายได้ และแก้บั๊กได้ด้วยพรอมป์ Claude ครั้งเดียว หรือ สตาร์ทอัพก่อนพบ product-market fit
      อาจสร้างสมดุลโดยไม่ดูโค้ดเลยและใช้เพียงผลสำเร็จของ requirement เป็น feedback ได้ แต่สำหรับซอฟต์แวร์อื่น ๆ ปัญหาเรื่องเจตนาและคุณภาพเชิงอัตวิสัยยังไม่ได้รับการแก้ไข
    • สมมติฐานตั้งต้นที่ว่ามีวิธีเดียวในการเปลี่ยน requirement ให้เป็น implementation นั้นก็ไม่เป็นจริงแล้ว

  • บทความมีเนื้อหาดี แต่ยากที่จะเหมารวม การทดลองดำเนินงานแบบไร้คนควบคุมในเดือนกรกฎาคม 2025 ว่าเป็นข้อจำกัดของ agent ปัจจุบัน
    ความมีประโยชน์ของโมเดลก้าวกระโดดครั้งใหญ่ราวฤดูใบไม้ร่วงปี 2025 หรือฤดูใบไม้ผลิปี 2026 และผมเองก็เพิ่งเริ่มมอบทั้งฟีเจอร์ให้ agent ทำได้หลังจากนั้น บทความกล่าวถึงการพัฒนาโมเดล แต่แทบจะมองข้ามไป ซึ่งไม่ตรงกับความรู้สึกจากการใช้งานของผม

    • ทั้งบทความและเว็บไซต์ผลิตภัณฑ์ดูเหมือนยังติดอยู่ในปี 2025 โดยเฉพาะบทความที่ว่า “คอนเท็กซ์ยาวไม่ใช่คำตอบ” ดูเหมือนนำประสิทธิภาพในอดีตไป extrapolate ใส่โมเดลล่าสุดตรง ๆ
      โมเดลหลัง Opus 4.6 เสถียรจนแทบไม่รู้สึกว่าความฉลาดลดลงแม้ที่ 700,000~900,000 โทเคน แม้ประสิทธิภาพด้านต้นทุนจะแย่มาก แต่ก็ใช้งานได้
    • สัปดาห์ที่แล้วผมฟังพอดแคสต์ที่ Dex Horthy ไปออก บริษัทของเขา Humanlayer ยังคงผลักดันขีดจำกัดของ agent และใช้งานอย่างจริงจัง
      เขาน่าจะรู้ดีถึงความสามารถของโมเดลปัจจุบัน ดังนั้นถ้าเขาตัดสินว่าโรงงานซอฟต์แวร์ไร้คนควบคุมเป็นไปได้ในตอนนี้ ก็คงกำลังลองใหม่อยู่
    • Opus 4.5 เป็นการก้าวกระโดดครั้งใหญ่อย่างชัดเจน การประเมินจากคนที่ไม่ได้ทดลองโมเดลหลังจากนั้นย่อมมีคุณค่าน้อยลง แต่แม้โมเดลจะไม่สมบูรณ์แบบ ก็ยังมีประโยชน์มาก
    • ถ้าอย่างนั้น การเขียนว่า “นำมาใช้เต็มรูปแบบในปี 2025 และแม้ในปี 2026 ก็ยังไม่มีอะไรดีขึ้นในสาระสำคัญ” น่าจะชัดเจนกว่า
      ผมมองว่า frontier model รุ่นล่าสุดก็ยังจัดการกับการหลุดบริบทหรือ shotgun surgery ได้ไม่ดีขึ้นนัก หากจะโต้แย้ง ก็ควรเสนอหลักฐานเฉพาะและประสบการณ์ใช้งานที่ต่างออกไป ไม่ใช่แค่มองข้าม
    • อาจเป็นประเด็นถกเถียงได้ แต่ในงานวิศวกรรมที่ซับซ้อน ผมรู้สึกว่า Opus 4.1 ฉลาดกว่า 4.5
      4.5 เร็วกว่า และอ่านพรอมป์ง่าย ๆ กับเจตนาโดยนัยได้ดี จึงเหมาะกับการดึงผู้ใช้ใหม่เข้ามาได้เร็ว

  • ผม สร้างและดำเนินงาน โรงงานซอฟต์แวร์ของตัวเองมา 8 เดือน แล้ว แม้ยังไม่มีการรวบรวมงานอัตโนมัติและการส่ง PR แต่หลังจากกำหนด requirement แล้ว ส่วนใหญ่ดำเนินต่อเองไปจนถึง deploy ได้ ผมหยุด code review ในช่วง 4 เดือนที่ผ่านมา หลังผ่านการประเมินระบบแล้ว
    แทนที่จะใช้พรอมป์บรรทัดเดียว จะใช้กระบวนการสัมภาษณ์เพื่อเคลียร์คำถามค้างคาและความคลุมเครือก่อน และใช้การ review แผน, QA ผ่านเบราว์เซอร์, การ review แบบปฏิปักษ์, unit test, linter, type checker, hook หลัง commit และการติดตาม formal methods เป็นมาตรการป้องกัน
    เมื่อเกิดความผิดพลาดซ้ำ ๆ ก็สามารถตรวจจับบริเวณที่เริ่มรกได้โดยไม่ต้องดูโค้ด เมื่อ requirement เพิ่มขึ้นและตัวแปรสถานะซ้อนทับกัน จะรีแฟกเตอร์เป็น sum type เดียว และถ้าซับซ้อน ก็สร้าง formal model และ trace ด้วย Quint แล้วรันเป็น unit test
    codebase ประกอบด้วย frontend และ backend ที่มีอายุมากกว่า 1 ปี agent จะคัดลอก pattern เดิมตามเดิม ดังนั้นหลักการที่ชัดเจนจึงสำคัญ และเมื่อต้องแบ่งขอบเขตระบบใหม่ โมเดลระดับ Sonnet มักตัดสินผิดบ่อย ส่วน Opus ทำได้ดีกว่า

    • ยังไม่ใช่โรงงานเต็มรูปแบบ แต่ผมก็รู้สึกคล้ายกันในโปรเจกต์ vibe coding ที่ mature แล้วหลายโปรเจกต์
      โดยมากตรวจจับการเสื่อมคุณภาพได้ และยังไม่เคยมีกรณีที่เปิดโค้ดไปหาปัญหาแล้วให้ agent จัดระเบียบไม่ได้ ผมก็ยังไม่เคยเห็นสถานการณ์ที่วิศวกรทั่วไป ไม่สามารถย้อนคืนการปนเปื้อนของ codebase ได้
    • ไม่ได้สงสัยตัวโรงงานโค้ดเอง แต่อยากรู้ว่าสร้างอะไรขึ้นมา จำเป็นต้องมีผลลัพธ์ที่พิสูจน์ได้ว่าสามารถสร้างผลิตภัณฑ์อื่นนอกเหนือจากเครื่องมือเขียนโค้ดด้วย AI ได้
    • ถ้าเผยแพร่ โครงสร้างและ workflow แบบเฉพาะเจาะจง ในรูปแบบบทความยาวหรือ repository ก็อยากอ่าน

  • มีอยู่สองกรณี: ต้องเข้าใจวิธีการทำงานของ codebase หรือไม่ก็ไม่จำเป็นต้องเข้าใจ
    Claude อาจเขียนโค้ดแทนได้ แต่ไม่ได้เข้าใจแทนเรา และกระบวนการนั้นยังคงเดินไปด้วย ความเร็วของมนุษย์ มีบางกรณีที่ไม่จำเป็นต้องเข้าใจทุกอย่าง แต่ต้องแยกแยะให้ละเอียดกว่านี้ และต่อให้ Claude เขียนโค้ดสมบูรณ์แบบ ข้อเท็จจริงนี้ก็ไม่เปลี่ยน

    • Claude สามารถ สำรวจ codebase แบบสปาเกตตี ได้เร็วกว่ามนุษย์มาก ปัญหากลับอยู่ตรงที่ถ้า outsource ความเข้าใจโปรเจกต์ให้ Claude ก็จะยังทำงานต่อได้แม้หลังจากที่มนุษย์ใช้งานมันไม่ได้แล้ว
    • แทนที่จะมองการเข้าใจเป็นสองขั้ว อาจมองว่าใน codebase หนึ่ง ๆ จำเป็นต้องมี ความเข้าใจมากแค่ไหน จึงจะทำงานได้อย่างมีประสิทธิภาพ
      ก่อนยุค LLM ก็ไม่มีใครรู้จัก codebase ขนาดใหญ่ทั้งหมดอยู่แล้ว แต่อย่างน้อยโดยทั่วไปก็เข้าใจ PR ที่ตัวเองสร้างและพื้นที่ที่ตัวเองรับผิดชอบ
    • ประสบการณ์ของผมกลับตรงกันข้าม ผมทำให้ Claude เข้าใจ codebase ขนาดใหญ่สองชุดที่ผมเขียนเองเป็นส่วนใหญ่และออกแบบแนวคิดเอง ได้ลึกกว่าผมมาก และตอนนี้ผมให้ Claude อธิบายเรื่องที่ลืมไปนานแล้วให้ฟังอยู่

  • รู้สึกโล่งใจเพราะคล้ายกับประสบการณ์ของผมมาก นึกถึงคำว่า รสนิยมและวิจารณญาณ ที่ถูกพูดถึงบ่อยในช่วงหลัง
    คุณภาพของสถาปัตยกรรมอาจไม่มีคำตอบที่ถูกต้องแบบเป็นภววิสัยเหมือนแฟชั่น และหลังจากยกเหตุผลกับความเป็นเหตุเป็นผลให้เครื่องจักรแล้ว มนุษย์อาจต้องหันไปศึกษาสุนทรียศาสตร์ก็ได้
    มันเหนื่อยเพราะต้องตัดสินใจประนีประนอมระหว่างตัวเลือกที่แทบเท่าเทียมกันอยู่เรื่อย ๆ โดยไม่มีช่วงพักที่กระบวนการลงมือ implement เคยให้ แม้กับโมเดลระดับ Fable หรือ GPT-5.6 ก็ยังต้อง review code อยู่ดี ข้อบกพร่องเล็ก ๆ จะจำไว้ก่อน แล้วค่อยแก้พร้อมกันเมื่อปัญหาคล้าย ๆ กันสะสมมากพอ
    สำหรับ agent ก็ต้องเลือกว่าจะร่วมงานอย่างใกล้ชิดกับคนเก่งจำนวนน้อย หรือจะรัน sub-agent จำนวนมากแล้วคัดแยกของดีของเสียโดยอัตโนมัติ รสนิยมของผมคือ ทีมขนาดเล็กที่ปรับจูนมาอย่างสูง แต่เวลาจะเป็นผู้บอกว่านั่นคือคำตอบที่ถูกหรือไม่

    • Jake Nations เคยพูดตอนทำงานที่ Netflix ว่า “pattern แย่ ๆ น่ะ ถ้าเคย debug ตอนตีสองมาแล้ว พอเห็นก็รู้ทันที”
      รสนิยมคือ สัญชาตญาณที่ได้มาหลังผ่านความลำบาก จาก anti-pattern และกับระเบิดทั้งหมดที่เราเคยทำให้ระเบิดด้วยตัวเองระหว่างสร้างซอฟต์แวร์
      https://www.youtube.com/watch?v=eIoohUmYpGI

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

    • สุดท้ายก็เป็นแค่ โฆษณายาว ๆ เพื่อโปรโมต Humanlayer ผลิตภัณฑ์ของเขาเท่านั้น

  • ปัญหาที่สะดุดตาที่สุดในตอนนี้คือ ประสบการณ์ผู้ใช้ในการ review PR
    ผมไม่เคยชอบหน้าจอ PR ของ GitHub เลย จึงมัก checkout branch มาดู diff ใน $EDITOR แต่ตอนนี้ไม่มีเหตุผลให้ต้องลำบากแบบนั้นแล้ว Linear ซึ่งไม่ใช่บริษัท code review ด้วยซ้ำ ใช้โมเดลขนาดเล็กจัดกลุ่มไฟล์ที่เปลี่ยนตามหัวข้อ พร้อมคำอธิบายและลำดับความสำคัญ ทำให้มีฟีเจอร์พื้นฐานที่ดีกว่า GitHub
    ภาระทางความคิดลดลงมากโดยไม่ต้องให้ reviewer หรือผู้ขอ review ทำงานเพิ่ม และฟีเจอร์ต่อยอดอย่าง visualization ก็เป็นไปได้เต็มที่ อยากรู้ว่าแนวทางนี้ผิดตรงไหน หรือมีทางเลือกที่ใช้กันแพร่หลายอยู่หรือไม่
    https://linear.app/docs/diffs#guides

    • ทีมที่ดีที่สุดไม่ทำ PR review พวกเขาคุยเรื่อง design และ architecture ร่วมกันระหว่างที่เปลี่ยนแปลงงาน, ทำให้การตรวจเล็ก ๆ อย่าง linting/formatting เป็นอัตโนมัติ และยึดกฎ ห้ามทำให้ build พัง อย่างเข้มงวดด้วย test และ check จำนวนมาก
      หากมีขั้นตอน rollback ที่แข็งแรงด้วย ประตู PR ก็กลายเป็นกระบวนการไม่จำเป็นที่จับปัญหาที่มีประโยชน์ไม่ได้ และสมาชิกทีมสามารถ merge กันได้โดยตรง
    • นโยบายที่ใช้ code review เป็นประตูสู่การ integrate นั้นไม่มีความหมาย agent ของผมตอบคำขอ review และ review แทนผมได้ และยังเลี่ยงนโยบายบริษัทที่บังคับให้มนุษย์ review ได้ด้วย
      เราควร review ซอฟต์แวร์ที่ทำงานได้จริง และต้องมีระบบที่สาธิต change ได้ทันที สัดส่วนความสำคัญของ code และ specification จะลดลง และการผลิตซอฟต์แวร์ในอนาคตจะ ใกล้กับ Replit มากกว่า GitHub
    • ก่อนยุค agent PR review ก็ยากอยู่แล้ว แต่ตอนนี้แย่ลงมากเพราะ PR ที่ต้อง review ก็เพิ่มขึ้นด้วย
    • การจัดกลุ่มและอธิบายการเปลี่ยนแปลงไฟล์ตามหัวข้อ นั่นไม่ใช่สิ่งที่ commit ควรทำ อยู่แล้วหรือ
    • ผมมองว่าความสามารถของ LLM ในการตัดสินความสำคัญหรือสรุป code ยังไม่ค่อยดีนัก
      เคยลองแนวทางที่ใช้ Tree-sitter อย่าง https://github.com/0x007BA7/codebook แล้วชอบ ยังไม่ถึงระดับใช้ใน production แต่มีช่องว่างให้ทำ product ด้วยแนวทางคล้ายกันได้

  • มีความรู้สึกสองด้านต่อ software factory
    ผลิตภัณฑ์หลักมีขนาดใหญ่จนทุกการเปลี่ยนแปลงต้องอาศัย input จากมนุษย์ แต่การทำ refactoring เบา ๆ, เขียน test, และ automate การเปลี่ยน UI นั้นทำงานได้ดี ในทางกลับกัน ในการทดลองเล็ก ๆ แม้ code ที่ได้จะไม่ได้พิเศษ แต่ก็เห็นความเป็นไปได้ที่จะขยายต่อในอนาคต และผมคิดว่าสามารถออกแบบ กลยุทธ์และสถาปัตยกรรมใหม่ โดยตั้งต้นตั้งแต่แรกว่า agent จะเป็นผู้เขียน
    ผมบันทึกการทดลองสาธารณะที่ไม่เข้าไปแทรกแซงทิศทางเลยไว้ที่ https://relentless.works/ ส่วน trading agent ก็กำลังสังเกตโดยไม่แทรกแซงเช่นกัน ตอนนี้ขาดทุนประมาณ 3% แต่ไม่ได้เสียหมด และล่าสุดก็เปิด position ใหม่ด้วย
    software factory ดูเป็นไปได้ แต่ต้องอาศัยแนวคิดใหม่ การเปลี่ยนวิธีคิด และความอดทนในการรอ AI

  • มีปัญหาพื้นฐานตั้งแต่ว่าการสร้างซอฟต์แวร์หมายถึงอะไร
    ถ้าแค่มอบหมาย ticket บน GitHub ให้ AI agent แล้วนั่งพัก มีโอกาสสูงที่ abstraction และชั้นทางอ้อม จะสะสมเพิ่มขึ้นเรื่อย ๆ ระหว่างเขียน code จะเกิดมุมมองอย่าง “ถ้าใช้ Redis ตรงนี้ล่ะ?”, “API ส่งข้อมูลที่ต้องการมาให้อยู่แล้วไม่ใช่หรือ?”, “ลูกค้าที่ไม่มี activity ในรอบ 1 ปี เอาออกจากรายงานเถอะ” และถึงจุดหนึ่งมนุษย์ก็ต้องเป็นคนตัดสินเรื่องเหล่านี้

    • เรื่องนี้เชื่อมโยงกับมุมมอง programming คือการสร้างทฤษฎี ซึ่งสูญเสียได้ง่ายในการเขียน code ด้วย agent
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • เห็นด้วยอย่างยิ่ง workflow และชุดเทคนิคของ coding agent ที่ใช้กันแพร่หลายถูกออกแบบมาเพื่อดึง insight และสัญชาตญาณของมนุษย์ออกมาในขั้นวางแผนหรือขั้นเขียน code
      เช่น planning mode ของ Claude Code, mattpocock/skills, obra/superpowers, flow แบบ research-plan-implement เป็นต้น
    • ถ้าเป็น developer top 1% ที่คิดแบบนั้นก็ใช่ แต่เมื่อเทียบกับ developer ส่วนใหญ่ที่ผมเจอมาหลายสิบปี โมเดลปัจจุบันเก่งกว่ามนุษย์ยกเว้นกลุ่มหัวแถวสุด
    • เครื่องจักรสร้างสิ่งที่ยังไม่มีอยู่ตามที่เราขอได้ ความสามารถในการขอให้ถูกต้องโดยใช้ทฤษฎีสารสนเทศ ทฤษฎีการตัดสินใจ และทฤษฎีความคิดสร้างสรรค์ สำคัญกว่าการทำงานไร้คนควบคุมแบบสมบูรณ์
      ความจำของโมเดลไม่ได้ถูกรวมเข้าด้วยกันเหมือนมนุษย์ที่นอนหลับแล้วสลักลงใน weight แต่ใกล้เคียงกับการยื่น memo ให้คนที่จำเมื่อวานไม่ได้มากกว่า จึงไม่น่าแปลกหาก ระบบที่มี entropy สูง จะเพิ่ม entropy ให้ project เมื่อเวลาผ่านไป
    • ปัญหา “API คืนข้อมูลที่ต้องการมาให้อยู่แล้ว” ใหญ่มากเป็นพิเศษ ผมเห็นหลายครั้งที่โมเดลระดับบนสุดแก้ปัญหาซึ่งเปลี่ยนแค่บรรทัดเดียวด้วยข้อมูลที่มีอยู่แล้วใน client ได้ แต่กลับเลียนแบบ pattern client-server เดิม ๆ แล้วแก้ด้วย code และ token มหาศาล
      project แบบ vibe coding เต็มไปด้วยความสูญเปล่าแบบนี้ แต่คนที่เขียน prompt อาจไม่รู้ก็ได้ ดีที่เครื่องมือช่วยประหยัดเวลาให้ทุกวัน แต่ การ implement เกินจำเป็น เป็นปัญหาร้ายแรง

  • เป็นเรื่องน่าขันที่พอพูดถึงโรงงานซอฟต์แวร์ไร้คน แล้วกลับวัดประสิทธิภาพด้วย จำนวน PR หรือคอมมิต ถ้าจะไปทางนั้น หน่วยของโค้ดก็ควรถูกเรียกว่า bos (bunch of shit) ไปแล้ว

    • กำลังทำผิดพลาดแบบเก่าๆ ซ้ำ คือปรับให้ utilization สูงสุดแทนที่จะปรับ throughput โดยรวมให้เหมาะสม ทั้งที่เป็นปัญหาที่ Eli Goldratt พูดถึงมาตั้งแต่ทศวรรษ 1970 ก็ยังไม่เรียนรู้
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • ถ้าจะนำแนวคิดนี้ไปใช้งานอย่างจริงจัง ก็ยอมรับ metric ที่เป็นแค่ vanity metric หรือความไม่รู้เรื่องโค้ดไม่ได้ ยิ่งมี automation มาก เกณฑ์มาตรฐานยิ่งไม่ได้ต่ำลง แต่ต้องสูงขึ้น และต้องใช้คณิตศาสตร์กับความพยายามมากกว่ามาก
      มันใกล้เคียงกับการแลกแบบสตาร์ทอัพสุดขั้ว คือแทนที่จะประหยัดเงินทุน ก็ ทุ่มเวลาหลายปีในชีวิตลงไปแลก