ดูเหมือนว่า AI จะไม่ได้ทำให้กระบวนการของคุณเร็วขึ้น

• มีการคาดหวังต่อ AI แบบ ไม่สมจริง แพร่กระจายในกระแสการปรับกระบวนการให้เหมาะสม แต่การนำ AI มาใช้เพียงอย่างเดียวไม่ได้ทำให้ความเร็วในการดำเนินงานดีขึ้น
• สาเหตุที่แท้จริงที่ทำให้การพัฒนาซอฟต์แวร์ใช้เวลานาน ไม่ใช่ความเร็วในการเขียนโค้ด แต่คือ กระบวนการเปลี่ยนความต้องการที่คลุมเครือให้เป็นนิยามปัญหาที่ชัดเจน
• การสร้างโค้ดด้วย AI ก็เผชิญกับ ปัญหาต้นน้ำ แบบเดียวกัน และจำเป็นต้องมีการมีส่วนร่วมเชิงลึกจากผู้เชี่ยวชาญด้านโดเมนและผลิตภัณฑ์เพื่อให้ได้ผลลัพธ์ที่ถูกต้อง
• ในกรณีเปรียบเทียบการใช้ AI มักละเลย กระบวนการประคับประคอง (handholding) ซึ่งเป็นสิ่งที่สร้างความต่างด้านผลิตภาพจริง ๆ และหากนักพัฒนามนุษย์ได้รับเอกสารรายละเอียดในระดับเดียวกัน ผลิตภาพก็จะพุ่งสูงขึ้นเช่นกัน
• หากต้องการเร่งกระบวนการอย่างแท้จริง ตามบทเรียนจาก The Goal สิ่งสำคัญลำดับแรกคือ "ป้อนข้อมูลที่คาดการณ์ได้และมีคุณภาพสูงให้กับคอขวด"

---

การปรับกระบวนการและความคาดหวังต่อ AI ท่ามกลางภาวะตลาดซบเซา

• เมื่อภาวะตลาดชะลอตัว องค์กรส่วนใหญ่มักหันมาให้ความสำคัญกับการปรับกระบวนการอย่างน้อยบางส่วน และช่วงหลังยังมีองค์ประกอบของ AI เข้ามาพร้อมกับ ความคาดหวังที่ไม่สมจริง
• The Toyota Way และ The Goal ชวนให้นึกได้ว่าหลายคนมักเข้าใจผิดว่าการปรับกระบวนการควรโฟกัสที่อะไร
  • ช่วงที่ใช้เวลานานอาจเป็นสัญญาณให้เริ่มปรับปรุงก็จริง แต่ไม่ได้แปลว่าจุดนั้นคือที่ที่ปัญหาเกิดขึ้นจริงเสมอไป
  • หากแค่เพิ่มคนเข้าไป หรือคาดหวังว่า AI จะเร่งความเร็วได้มาก ก็จะมองไม่เห็นว่าเหตุใดงานจึงล่าช้า
  • หากต้องการทำให้กระบวนการเร็วขึ้น ต้องตรวจสอบก่อนว่าผู้ปฏิบัติงานมี ข้อมูลนำเข้าและเงื่อนไข ที่ทำให้เริ่มและจบงานได้จริงหรือไม่

คอขวดเชิงภาพ (The visual bottleneck)

• จากตัวอย่างแผนภูมิ Gantt สามารถเห็นได้ชัดว่าขั้นตอนที่ใช้เวลานานที่สุดคือ การพัฒนาซอฟต์แวร์
  • ปกติแล้วมักใช้ BPMN แต่เพื่อให้เข้าใจง่ายจึงยกตัวอย่างด้วยแผนภูมิ Gantt
• หากเป้าหมายคือปรับปรุง throughput ของโปรเจ็กต์ วิธีที่เริ่มจากการดูขั้นตอนที่ใช้เวลานานที่สุดก่อนนั้นถือว่าถูกต้อง
• ปัญหาอยู่ที่วิธีที่ผู้คนใช้แก้เรื่องนี้
  • โยนคนเข้าไปแก้ปัญหา (throw people at the problem)
  • สมมติว่า AI จะทำให้เร็วขึ้นมาก
• แต่กลับไม่ได้พิจารณาเลยว่า "ทำไมขั้นตอนนี้จึงใช้เวลานาน" และที่สำคัญยิ่งกว่านั้นคือ การใช้เวลานานไม่ได้หมายความว่าสาเหตุของปัญหาอยู่ในขั้นตอนนั้น

แก้ปัญหาจากต้นน้ำ

• แม้จะยกตัวอย่างการพัฒนาซอฟต์แวร์ แต่แนวคิดนี้ใช้ได้เหมือนกันกับทุกกระบวนการที่ใช้เวลานานกว่าที่ต้องการ
• การพัฒนาซอฟต์แวร์ไม่ได้เร็วขึ้นเพียงเพราะ พิมพ์ได้เร็วขึ้น ไม่เช่นนั้นทุกคนคงไปเรียนพิมพ์สัมผัสกันหมดแล้ว
• แก่นของการพัฒนาซอฟต์แวร์คือ การแปลงปัญหาให้เป็นโซลูชันที่คอมพิวเตอร์สามารถแก้ได้โดยอัตโนมัติ โดยควรทำในรูปแบบที่ปลอดภัยและขยายต่อได้
• การทำเช่นนี้ต้องอาศัยความเข้าใจภาพรวมของปัญหา
  • หากเป็นแนวทางใกล้เคียง waterfall ก็ต้องมีเอกสารฟีเจอร์หรือเอกสารขอบเขตงาน
  • หากเป็น agile ก็ต้องมีการทำซ้ำร่วมกับผู้เชี่ยวชาญด้านโดเมนอย่างต่อเนื่อง (iteration)
• สิ่งที่ทำให้การพัฒนาช้าจริง ๆ คือ กระบวนการทำความเข้าใจว่าคำขอฟีเจอร์ที่คลุมเครือและมีเพียงชื่อเรื่องนั้นหมายถึงอะไร
• แม้แต่คำขอ "ส่งอีเมลให้ผู้ใช้เมื่อการขายเสร็จสมบูรณ์ (send mail to user once sale is completed)" ก็ยังไม่ใช่ข้อกำหนดที่พร้อมนำไปพัฒนาได้ทันที
  • ส่งอีเมลได้ก็จริง แต่ในอีเมลต้องมีอะไรบ้าง
  • หากมีปัญหาในกระบวนการขาย ควรส่งอีเมลแจ้งข้อผิดพลาดด้วยหรือไม่
  • เมื่อใดจึงจะถือว่าการขาย "เสร็จสมบูรณ์"

ข้ออ้างว่าโยนให้ AI ทำทั้งหมดก็พอ

• ข้ออ้างที่ได้ยินบ่อยคือใช้ AI สร้างโค้ด เพื่อข้ามขั้นตอนการพัฒนา แล้วให้นักพัฒนาซอฟต์แวร์ทำหน้าที่คล้ายผู้จัดการโครงการแทน
• หลายคนคาดหวังว่าช่วงการพัฒนาซอฟต์แวร์ที่เดิมยาวนานจะถูกแทนที่ด้วยช่วง การพัฒนาด้วย AI ที่ใช้เวลาเพียงประมาณ 3 วัน
• ผู้คนมีภาพในใจว่าผลลัพธ์ของการพัฒนาด้วย AI จะออกมาอย่างไร แต่ในความเป็นจริงมันไม่ได้ทำงานแบบนั้น และยังเผชิญกับ ปัญหาต้นน้ำ แบบเดิมทุกประการ
• ที่ว่า AI สามารถสร้างโค้ดได้รวดเร็วนั้นเป็นเรื่องจริง (แม้ว่าจะเป็นเรื่องดีหรือไม่ยังเป็นอีกประเด็นหนึ่ง) แต่ การสร้างได้เร็วไม่ได้แปลว่าสร้างโค้ดที่ถูกต้องได้เสมอไป
• สิ่งที่มักถูกมองข้ามเสมอในการเปรียบเทียบการพัฒนาระหว่างมนุษย์กับ AI คือกระบวนการ ประคับประคอง (handholding) เพื่อให้ AI ทำงานได้อย่างถูกต้อง
• วิธีนี้อาจเร็วกว่าแนวทางเดิมได้ แต่ ไม่ใช่การเปรียบเทียบที่ยุติธรรม
• หากการพัฒนาด้วย AI จะใช้ได้จริง ก็ต้องอาศัยการมีส่วนร่วมที่ลึกกว่ามากจากผู้เชี่ยวชาญด้านโดเมนและผู้เชี่ยวชาญด้านผลิตภัณฑ์
  • ต้องเขียนทุกฟีเจอร์ลงไปจนถึงรายละเอียดเล็กมาก
  • การแก้ทุกบั๊กก็ต้องสรุปอย่างละเอียดว่าผลลัพธ์ที่ต้องการคืออะไร
• ซึ่งนี่ก็คือสิ่งที่นักพัฒนาซอฟต์แวร์เรียกร้องมาโดยตลอดตั้งแต่เริ่มมีอาชีพนี้ นั่นคือ การให้ภาพรวมที่ละเอียดของปัญหาและผลลัพธ์ปลายทาง
• หากให้นักพัฒนามนุษย์ได้รับเอกสาร feature/scope ในระดับรายละเอียดเท่ากัน ผลิตภาพก็จะเพิ่มขึ้นอย่างมากเช่นกัน

วิธีเพิ่มความเร็วของกระบวนการได้จริง

• หากต้องการเพิ่มความเร็วของกระบวนการ ต้องทำให้แน่ใจว่าผู้ที่ต้องลงมือทำงาน มีทุกอย่างพร้อมที่จะทำงานนั้นได้จริง
• หากกระบวนการอนุมัติทางกฎหมายล่าช้า ต้องเริ่มจากดูว่า อะไรคือสิ่งที่จำเป็นในการเริ่มกระบวนการอนุมัติทางกฎหมาย
  • หากต้องวิ่งตามคนห้าคนเพราะเอกสารไม่ครบ ต่อให้เพิ่มทนายเข้าไปในแผนก ความเร็วก็ไม่ได้ดีขึ้น
• หนึ่งในบทเรียนสำคัญจาก The Goal คือคอขวดควรได้รับข้อมูลนำเข้าที่คาดการณ์ได้และมีคุณภาพสูง
  • "bottlenecks should receive predictable, high-quality inputs"
• จุดเริ่มต้นอันดับแรกของระบบอัตโนมัติกระบวนการ จึงไม่ควรเป็นตัวคอขวดเอง แต่ควรเป็นการยกระดับ คุณภาพของข้อมูลนำเข้า และความสามารถในการคาดการณ์ของสิ่งที่คอขวดจะได้รับ

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีคนบอกว่าสิ่งที่การพัฒนาซอฟต์แวร์ต้องการมาตลอดตั้งแต่แรกคือ “การได้รับคำอธิบายปัญหาและผลลัพธ์ที่ต้องการอย่างละเอียด” แต่จริง ๆ แล้วนั่นเองก็คือ วิศวกรรมซอฟต์แวร์
  ถึงปี 2026 ก็ควรเลิกคิดได้แล้วว่าแค่มี requirement และ specification ที่ละเอียดพอ ก็จะสร้างคำตอบที่สมบูรณ์ได้ในครั้งเดียว
  จากประสบการณ์ของผม AI ทำให้สามารถวนรอบฟีเจอร์หรือไอเดียได้เร็วขึ้นมาก และตอนนี้แรงเสียดทานส่วนใหญ่เกิดจากการทำให้ทีมอื่นสอดคล้องกันและประสานงานกัน
  ถ้าจะทำให้กระบวนการเร็วขึ้น ต้องลด ต้นทุนการประสานงาน และให้ทั้งรายบุคคลและทีมมีอำนาจในการตัดสินใจและลงมือทำมากขึ้น

  • ถึงปี 2026 ก็ควรเลิกคิดได้แล้วว่า ต่อให้มี requirement ที่ละเอียดพอ ก็ยังจะสร้างแม้แต่โซลูชันที่ใช้งานได้ในครั้งเดียวได้
    แม้แต่ Anthropic ที่มีทั้งสเปกสมบูรณ์ implementation อ้างอิง และเทสต์ที่มนุษย์เขียนไว้หลายพันรายการตลอดหลายปี ก็ยังสร้างสิ่งง่าย ๆ อย่าง C compiler ที่ใช้งานได้ไม่สำเร็จ
    โมเดลปัจจุบัน ต่อให้มีสเปกสมบูรณ์และเทสต์สมบูรณ์ ก็ยังไม่ดีพอจะสร้างซอฟต์แวร์ production ที่ไม่ใช่งานจิ๊บจ๊อยได้โดยไม่มีการกำกับดูแลอย่างใกล้ชิดจากมนุษย์
    ถ้าไม่มีทั้งสเปกสมบูรณ์และชุดเทสต์สมบูรณ์ที่มนุษย์เขียนเอง มันก็ยิ่งยากขึ้น และอาจจะพอเป็นไปได้ราวปี 2027
  • ไม่เห็นด้วย
    ผมมักได้รับงานที่คนดูแลผลิตภัณฑ์นึกขึ้นได้ตอนบ่าย ซึ่งพวกเขาสนใจแค่ happy path และบางครั้งก็สนใจเพียงบางส่วนของมัน
    บริษัทเป็นบริษัทระดับโลก จึงต้องปฏิบัติตามข้อบังคับและกฎหมายของแต่ละประเทศ แต่พอทำฟีเจอร์เสร็จแล้วกลับได้ยินว่า “จริง ๆ แล้วใน 90% ของตลาดที่เราดำเนินงานอยู่ เราทำแบบนี้ไม่ได้ตามกฎหมาย” แล้วก็ต้องกลับไปใส่ฟังก์ชันปิดการทำงานเพิ่ม
    จากนั้นก็มีการย้อนกลับมาบอกว่า “แต่ในบางตลาดทำได้ถ้าผ่าน ขั้นตอนกำกับดูแล ดังนั้นช่วยทำให้เป็นแบบนั้นหน่อย”
    พอเดดไลน์ใกล้มาก ก็ลงเอยด้วยการแก้แบบแฮ็ก ๆ
    นี่ไม่ใช่วิศวกรรมซอฟต์แวร์ และไม่ได้เกี่ยวกับตัวซอฟต์แวร์ด้วย
    งานของวิศวกรซอฟต์แวร์คือรับรายการ requirement แล้วหาวิธีบรรลุ requirement นั้น ส่วน การเก็บ requirement ไม่ใช่ปัญหาของวิศวกรรมซอฟต์แวร์
    ซอฟต์แวร์คือการนำไปสร้างจริง และผลิตภัณฑ์คือพฤติกรรม ดังนั้นพฤติกรรมของสิ่งที่จะสร้างควรต้องรู้ก่อนจะลงมือทำอย่างจริงจัง
    ถ้ามีใครเลื่อนออกไปสักหนึ่งสัปดาห์แล้วทำการตรวจสอบอย่างจริงจัง ก็น่าจะออกแบบโครงสร้างที่ขยายได้ง่าย บำรุงรักษาง่าย และทำให้อนาคตสบายขึ้นได้
  • เห็นด้วยอย่างยิ่ง
    ผมเขียนโปรแกรมมานานกว่า 40 ปีแล้ว แต่ไม่เคยเห็นกรณีที่ทำสเปกให้เสร็จก่อน แล้วค่อยเขียนซอฟต์แวร์ แล้วทุกอย่างออกมาดี
    ส่วนที่ยากที่สุดของวิศวกรรมที่ไม่ใช่งานจิ๊บจ๊อยคือ การทำความเข้าใจปัญหา และเวอร์ชันแรก ๆ ของซอฟต์แวร์ก็คือวิธีไปให้ถึงความเข้าใจนั้น
    เพราะงั้นผมจึงมองว่า “โรงงานซอฟต์แวร์” ที่ขับเคลื่อนด้วย AI จะไม่มีวันทำงานได้ดีจริง
    สุดท้ายมันก็กลับไปเป็นการพัฒนาแบบ waterfall อีกครั้ง มีสถาปนิกวาด UML diagram แล้วส่งงาน implementation ที่โดยเนื้อแท้เรียบง่ายให้ทีมโปรแกรมเมอร์ แต่ดันให้พวกเขาไปสร้าง สิ่งที่ผิด
    AI เก่งมากในการพาเราจากเวอร์ชันแรกที่ผิด ไปสู่เวอร์ชันที่สองที่ผิดน้อยลงอย่างรวดเร็ว
    แต่อย่าลืมว่าภารกิจหลักคือการเข้าใจปัญหาที่กำลังพยายามแก้
  • ผมเข้ามาทำงานวิศวกรรมเพราะชอบการหาวิธีที่ดีที่สุดในการจัดการกับ requirement ที่คลุมเครือ
    ถ้าได้รับมาแค่สเปกละเอียด ๆ ผมก็เป็นแค่หุ่นยนต์เขียนโค้ด และงานแบบนั้นก็โยนให้ junior ทำ
  • ทุกวันนี้ผมเห็นคนตัดสินใจหรือคนเขียน requirement เริ่มใช้ AI กันมากขึ้นในชีวิตประจำวัน
    งานของผมก็ยังเหมือนเดิม คืออ่าน requirement เหล่านั้น ทำความเข้าใจ และตรวจสอบเทียบกับความจริงที่ผมรู้
    โค้ดก็เช่นกัน
    อย่างน้อยตลอด 20 ปีที่ผ่านมา แก่นของ วิศวกรรมซอฟต์แวร์ คือ อย่าเชื่อใครทั้งนั้น และสิ่งนี้ไม่เคยเปลี่ยน แถมยังคงใช้เวลาและแรงมหาศาล

• ตอนที่ LLM ออกมาใหม่ ๆ ดูเหมือนคนจะคิดว่าแค่พูดประมาณว่า “ช่วยสร้าง Facebook clone ให้หน่อย” ก็พอ
  ตอนนี้ผู้คนกำลังตระหนักว่าต้องเขียน requirement ให้แม่นยำขึ้นและกำหนดให้ชัดเจนขึ้น
  นี่แหละคือ คอขวด ของซอฟต์แวร์มาโดยตลอด
  ตอนที่ผมทำงานอยู่ เคยได้รับ requirement จริง ๆ อย่าง “ดึงข้อมูลมาแล้วส่งให้ผู้ใช้”
  ซึ่งไม่มีนิยามเลยว่าเป็นข้อมูลอะไร เก็บไว้ที่ไหน หรือควรคืนค่าเป็นรูปแบบไหน จนต้องใช้เวลานานมากคุยกับคนดูแลผลิตภัณฑ์เพื่อหาว่าจริง ๆ แล้วเขาต้องการอะไร
  การจะได้ผลลัพธ์ที่ดีจาก LLM ก็ต้องทำอะไรคล้ายกัน และ requirement ที่คลุมเครือก็ย่อมให้ผลลัพธ์ที่คลุมเครือ

  • เท่าที่ผมเห็น PM ใช้ AI ที่เชื่อมกับ codebase อย่าง Claude Code หรือ Codex แล้วทำให้ ticket ละเอียดขึ้นมาก
    พวกเขากรอกเทมเพลตว่าปัญหาคืออะไรและทำไมถึงเกิด เช่น backend มีฟิลด์ X แต่ frontend ไม่มี พร้อมอธิบายว่าจะดึงข้อมูลจากไหนอย่างไร และ acceptance criteria คืออะไร
    เมื่อก่อนคงไม่ทำเพราะขี้เกียจหรือคิดว่า “เดี๋ยวนักพัฒนาจัดการเอง”
    หลังจากนั้นนักพัฒนาก็สามารถคัดลอกเนื้อหาใน Jira ticket นี้ไปวางใน LLM agent ที่ต้องการ หรือให้ LLM อ่านอัตโนมัติผ่าน Atlassian MCP ก็ได้
    สิ่งนี้ช่วยนักพัฒนาได้มาก และทำให้ requirement ชัดเจนมาก
    พูดตรง ๆ แค่ดูจากขั้นแรกก็รู้สึกว่า PM ไปได้ถึงครึ่งทางของการทำฟีเจอร์แล้ว ดังนั้นในอนาคต PM อาจจะทำทุกอย่างเองหมด และนักพัฒนาบางคนอาจเหลือบทบาทคล้าย SDET มากกว่าจะเป็นผู้ลงมือสร้างเต็มตัว
  • เรื่องนี้ Fred Brooks คาดการณ์ไว้ค่อนข้างมากแล้วในบทความคลาสสิกปี 1986 No Silver Bullet ตรงส่วน “Expert Systems” และ “Automatic Programming”
    เขาอธิบายลักษณะสำคัญของ vibe coding และประสบการณ์ที่เรากำลังเผชิญอยู่ตอนนี้ได้อย่างตรงเป๊ะ
    เนื้อหาคือหลังจากประสบความสำเร็จช่วงแรกในบางโดเมนที่เลือกมาอย่างระมัดระวัง เมื่อขยายออกไปนอกโดเมนเหล่านั้น ก็จะได้การเพิ่มผลิตภาพที่สมเหตุสมผลแต่ไม่ถึงขั้นปฏิวัติ
    https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
  • ถูกต้องเลย และผมคิดว่าเป็นเรื่องธรรมดาอยู่แล้ว
    ผมไม่เคยใช้พรอมป์ต์แบบ “ช่วยสร้าง Facebook clone ให้หน่อย” หรืออะไรใกล้เคียง แต่จะอธิบายว่ามันควรทำงานอย่างไร
    ตัวอย่างเช่น ผมขอ Python script ที่อ่าน /etc/hosts, หา host value เฉพาะที่ตั้งค่าไว้ใน .conf, ตั้งชื่อแต่ละ configuration, ตรวจสอบ environment ปัจจุบัน, สร้างไอคอนที่มุมขวาบนของ GNOME ค่าเริ่มต้นบน Ubuntu 22, เมื่อคลิกแล้วให้แสดงรายชื่อ configuration และเมื่อเลือกแล้วให้สำรอง /etc/hosts ก่อน จากนั้นแก้เฉพาะบรรทัด hostname ที่กำหนด
    ผลลัพธ์คือได้ตัวสลับ environment สำหรับ GNOME app indicator แบบเรียบง่ายที่เกือบสมบูรณ์ในครั้งเดียว และแก้แค่ไม่กี่บรรทัดก็ใช้งานได้เป็นส่วนใหญ่
    ถ้าคุณให้สเปกที่ดีพอกับ LLM มันก็สร้างได้ดี และต่อให้ต้องสร้าง DSL ปลอม ๆ ขึ้นมาเพื่ออธิบายสิ่งที่ต้องการ มันก็เข้าใจได้เอง
  • ตอนนี้เจ้าของผลิตภัณฑ์พยายามโยนงานของตัวเองให้ LLM
    สาเหตุที่กระบวนการเดิมใช้ไม่ได้ก็เพราะคนเขียน requirement ไม่เข้าใจเจตนาทางธุรกิจ หรือสะเพร่าจนเขียน requirement ที่คลุมเครือหรือแย่
    LLM แค่ทำให้ requirement ที่คลุมเครือหรือแย่แบบเดิมดูน่าเชื่อถือขึ้น แต่พอขุดลึกลงไป ปัญหาก็จะโผล่ออกมา
  • ที่แย่กว่านั้นคือ ถ้าเป็นทีมซอฟต์แวร์ที่เป็นมนุษย์ อย่างน้อยในองค์กรที่ทำงานกันดี ก็จะมีการขอรายละเอียดเพิ่มเมื่อเจอ requirement ที่คลุมเครือ
    จะมีคำถามอย่าง “‘ดึงข้อมูลมา’ หมายความว่าอะไร?”
    แต่ LLM จะตอบแค่ว่า “ได้เลย! นี่คือโค้ดที่เสร็จสมบูรณ์สำหรับการดึงข้อมูลและส่งให้ผู้ใช้” แล้วก็จบ

• บทความนี้ตั้งสมมติฐานว่า AI กระทบแค่ขั้นตอนการพัฒนา แต่แน่นอนว่านั่นไม่จริง
  มันสามารถเร่งความเร็วได้ทุกขั้น ตั้งแต่การระดมไอเดีย กฎหมาย เอกสาร การพัฒนา ไปจนถึงการ deploy
  ในขั้นการระดมไอเดีย คุณสามารถโยนไอเดียไปมา เทียบกับฐานความรู้ และสร้าง design document ได้ ส่วนในด้านเอกสาร ก็สร้างเนื้อหาจำนวนมากของเอกสารได้
  ด้านการพัฒนาก็แน่นอนอยู่แล้ว และด้าน deployment ก็ช่วยสร้าง deployment manifest, เครื่องมือทดสอบ และความรู้เกี่ยวกับ cloud platform ได้
  ทุกขั้นสามารถดีขึ้นและเร็วขึ้นได้ด้วย AI ถึงจะไม่ใช่ทั้งหมด แต่ก็ได้จำนวนมาก
  ในการพัฒนาก็เหมือนกัน บางส่วนคือการเข้าใจปัญหาและสร้างโซลูชันได้ดีกว่าใคร แต่บางส่วนก็เป็นงานจิปาถะล้วน ๆ
  ถ้าคุณรู้แล้วว่าปุ่มต้องทำ X งานอย่างการออกแบบปุ่ม วางตำแหน่ง คิดข้อยกเว้นของสถานะ hover กับ press และเชื่อมต่อกับ backend ก็เป็น งานจิปาถะ ที่ข้ามได้ และหลักการเดียวกันนี้ใช้ได้กับแทบทุกขั้นตอน

  • โดยรวมผมเห็นด้วยกับบทความ
    เวลาจะเพิ่มฟีเจอร์ใหม่ที่สำคัญ มักต้องใช้เวลาหลายวัน หลายสัปดาห์ หรือหลายเดือนประชุมกับฝ่ายงานเพื่อทำความเข้าใจว่างานไหลผ่านระบบ X, Y, Z อย่างไร และมีข้อยกเว้นสำคัญอะไรบ้าง
    เช่น กลุ่มย่อย A ต้องจัดการแบบนี้ B ต้องจัดการแบบนั้น แต่ในขั้นสุดท้ายสองกลุ่มนี้ต้องถูกรวมกัน ยกเว้น C ที่ต้องใช้กระบวนการพิเศษ 97
    จากความเข้าใจนั้นก็ตามมาด้วย การออกแบบโซลูชันระดับระบบ ที่ครอบคลุมหลายระบบ ทั้งระบบภายในและระบบของ vendor โดยแต่ละระบบมีระดับการปรับแต่งได้ต่างกัน และสิ่งนี้ผลักดันรูปร่างของโซลูชันสุดท้ายไปคนละทิศละทาง
    การเร่งความเร็วการเขียนโค้ดมีคุณค่าแน่นอน แต่เป็นเพียงชิ้นส่วนหนึ่งของจิ๊กซอว์ และ LLM ปัจจุบันยังช่วยเรื่องการรวบรวมข้อมูลโดเมนและนิยามโซลูชันไม่ได้
  • ประสบการณ์ขององค์กรเราก็ตรงกับที่ว่าไว้
    มีอีกเรื่องหนึ่งคือ ตอนนี้คนในหลายบทบาทสามารถสร้าง เครื่องมือซอฟต์แวร์ เพื่อแก้ปัญหาที่เมื่อก่อนต้องใช้กระบวนการทางกายภาพและแรงคนดันเอาได้
    เราเป็นผู้ผลิตขนาดเล็ก จึงไม่ใช่โครงการองค์กรยักษ์ที่ต้องใช้ประสบการณ์วิศวกรรมซอฟต์แวร์ลึกมาก แต่เครื่องมือซอฟต์แวร์เรียบง่ายเหล่านี้กำลังช่วยปรับปรุงกระบวนการและผลิตภาพไปทั่วทั้งองค์กร
    เวลาผู้รับผิดชอบการจัดส่งสามารถแก้ปัญหาที่เมื่อก่อนเผาเวลาคนงานจำนวนมาก ด้วยเครื่องมือที่ทำขึ้นเฉพาะได้ มันน่าทึ่งจริง ๆ
  • บทความนี้แทบจะตรงกับสิ่งที่เกิดขึ้นจริงในบริษัทเรา
    เราใช้ AI ในการพัฒนาซอฟต์แวร์มาก แต่ไม่ได้ปล่อยของได้เร็วขึ้น และบางทีก็ดูเหมือนช้าลงด้วยซ้ำด้วยเหตุผลคล้าย ๆ หรือเหตุผลอื่น
    มันให้ความรู้สึกแปลก ๆ เหมือนกำลังรอยูโทเปียที่จะมาถึง แต่ก็ไม่มา และก็ชี้ไม่ถูกด้วยว่าจุดไหนกันแน่ที่เป็นปัญหา
  • คนที่ใช้ AI ได้อย่างมีประสิทธิภาพไม่ได้มีหน้าที่ต้องพิสูจน์ให้คนอื่นเห็น
    ตรงกันข้าม ความไม่ลงรอยกันและความไม่เชื่อใจแบบนี้แหละที่สร้าง โอกาสและจุดแตกตัว ในตลาด
  • ผู้คนไม่รู้ว่าท้ายที่สุดแล้วทั้งหมดนี้คือเรื่องของตัวเลข
    ถ้า IQ เฉลี่ยของผู้มีส่วนร่วมในโครงการอยู่ที่ 140 AI ที่มี IQ 150 ก็สามารถทำซ้ำงานของทุกคนใน pipeline ได้
    คนที่บอกว่า AI ทำอย่างนี้ไม่ได้ ทำอย่างนั้นไม่ได้ ต้องยอมรับว่าช่องว่าง IQ gap นี้กำลังขยายแบบทางเดียว

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

  • ฟังดูเศร้าแต่คงจริง
    ตอนนี้แม้แต่การแชร์บทความแบบนี้ในบริษัทก็ยังรู้สึกไม่กล้า เพราะเหมือนสิ่งที่ไม่เข้ากับสภาพเดิมจะไม่ได้รับการต้อนรับนัก
  • ทุกครั้งที่บทความแบบนี้ถูกพูดถึงในบริษัท ประเด็นหลักมักจะไปจบที่ว่าถ้าที่อื่นสามารถออกหรือดึงฟีเจอร์ใหม่ได้เร็วกว่า ความเสี่ยงที่จะตามไม่ทัน หรือพูดให้ชัดคือ FOMO นั้นใหญ่กว่า
  • ไม่เห็นด้วย
    ผมมองว่าสื่อภาพและ Gantt chart คือ ภาษาสไตล์ PM ที่ PM เข้าใจได้อย่างแม่นยำ
    ตราบใดที่ระดับ C และนักลงทุนยังคงส่งสัญญาณเรื่องนวัตกรรมอยู่ มันคงยังไม่จบเร็ว ๆ นี้ แต่เรื่องแบบนั้นก็อยู่ตลอดไปไม่ได้
  • ผมมีความหรูหราที่ผ่อนบ้านหมดแล้ว จึงสามารถเรื่องมากกับงานไปได้อีกพักหนึ่ง
    ช่วงนี้เลยใช้เวลาไปกับงานสวน และหมกมุ่นกับโปรเจกต์เขียนโค้ดส่วนตัวด้วยเครื่องมือแบบ agent
    เช่น สร้างฐานข้อมูล OLTP สมรรถนะสูงตั้งแต่ศูนย์ สร้างสภาพแวดล้อมการเขียนโปรแกรมเชิงคงอยู่แบบ relational logic แบบใหม่ และสร้างซินธิไซเซอร์กับ soft processor บน FPGA ที่อิงคณิตศาสตร์แปลก ๆ
    เป็นเรื่องธรรมดาที่คนธรรมดาทำกัน
    เพราะงั้นผมรู้ว่าเครื่องมือพวกนี้ทำอะไรได้บ้างเมื่ออยู่ในมือของคนคนเดียว และมันน่าทึ่งจริง ๆ
    แต่พอได้ยินเพื่อนที่ยังทำงานบริษัทเล่าว่ามีการกำหนดโควตา token ขั้นต่ำ หรือทำ leaderboard ของ “นักเขียนโค้ด AI ดาวเด่น” แล้วบอกว่า “อย่าทำ code review” หรือ “อย่าเขียนโค้ดด้วยมือ” ผมก็ได้แต่ส่ายหัว
    ช่วงหน้าหนาวผมลองรับงานสัญญาระยะสั้นนิดหน่อย ก็โอเคนะ แต่ code review กลับเสื่อมสภาพจนกลายเป็นเหมือนให้ LLM มาดวลกัน ขณะที่ผู้ก่อตั้ง vibe coding ทั้งโปรเจกต์ใหม่ทุกสุดสัปดาห์
    เครื่องมือพวกนี้ไม่ค่อยเหมาะกับการทำงานเป็นทีมหรือวิศวกรรมซอฟต์แวร์แบบทีมจริง ๆ
    ผมคงถอยออกมาแล้วเฝ้าดูไปจนกว่าอุตสาหกรรมจะเริ่มเข้าที่
    ที่ทำงานที่น่าจะโอเคคงมีแต่ที่ซึ่งพูดได้ว่า “ค่อย ๆ ทำ!” และมีคนแก่ที่ฉลาดพอจะทนยืนหยัดกับคำแบบนั้นได้
    ระหว่างนี้ผมขายรูบาร์บที่ตัดจากแถว Hamilton, Ontario กำละ 5 ดอลลาร์
    มีหน่อไม้ฝรั่งด้วย เยอะมาก

• มีความสองด้านที่น่าสนใจ
  กับงานที่ผมเก่งอยู่แล้ว LLM แทบไม่มีผลมากนัก แต่กับงานที่ผมทำไม่เป็น มันคือ game changer อย่างแท้จริง
  บริษัทใหญ่สามารถจ้างคนมาครบแทบทุกบทบาทที่โปรเจกต์ต้องใช้ได้อยู่แล้ว ดังนั้นผลกระทบโดยรวมจึงค่อนข้างเล็ก
  อย่างมากที่สุดก็อาจเป็นการให้คนหนึ่งคนทำงานแทนห้าคนแบบพอถูไถ เพื่อลดค่าแรง แล้วได้ผลิตภัณฑ์ที่แย่ลงเป็นการแลกเปลี่ยน
  จะออกมาเป็นอย่างไรในแง่ผลประโยชน์ระยะสั้นกับต้นทุนระยะยาวก็คงเดาได้ไม่ยาก
  แต่สำหรับสตูดิโอเล็ก ๆ หรือนักพัฒนาอิสระ LLM คือความเปลี่ยนแปลงครั้งใหญ่
  การทำงานแทนห้าบทบาทได้แบบพอถูไถ ยังถือเป็นก้าวกระโดดที่ใหญ่กว่าการต้องอยู่โดยไม่มีบทบาทเหล่านั้น ต้องพึ่ง asset ของ third-party หรือคอนเทนต์อื่น ๆ หรือแย่กว่านั้นคือต้องด้นสดแบบเละเทะ
  แค่ดู UI ของโปรแกรมแทบทุกตัวที่เห็นชัดว่าโปรแกรมเมอร์จัดวางโดยไม่มีดีไซเนอร์ก็พอ
  หรือไม่ก็กรณีที่พยายามลอกอะไรจาก Dribbble แต่ฝีมือไม่ถึง
  พอใช้ AI อยู่ ๆ ก็ลอกทุกอย่างและทุกคนออกมาให้ดูน่าเชื่อได้ และจริง ๆ แล้วนั่นก็แทบจะเป็นวิธีทำงานทั้งหมดของ AI อยู่แล้ว

  • ประโยคที่ว่า “กับงานที่เก่งอยู่แล้ว LLM แทบไม่มีผล แต่กับงานที่ทำไม่เป็นกลับเปลี่ยนเกม” อาจเป็น ผลกระทบแบบ Gell-Mann Amnesia หรือเปล่า
    ฟังดูเหมือนคำนิยามในตำราเลย
    สำหรับผมมันกลับกันอย่างสิ้นเชิง
    LLM มีประโยชน์ก็ต่อเมื่อผมรู้ชัดอยู่แล้วว่ากำลังทำอะไร

• ผู้คนไม่ค่อยเข้าใจว่าการพัฒนาซอฟต์แวร์ที่ไม่ใช่งานเล็กน้อยนั้นแม้แต่ 50% ก็ยังไม่ใช่การเขียนโค้ด
  ขั้นตอนการเขียนโค้ดมักง่ายที่สุด และมักโยนให้ junior developer ทำ
  ในองค์กรใหญ่ การเปลี่ยนแปลงผลิตภัณฑ์ส่วนใหญ่พาดผ่านหลายระบบและการทำงานของหลายคน
  คนระดับ senior และ mid-level ส่วนใหญ่ใช้เวลาไปกับการจัดเรียงลำดับความสำคัญเฉพาะจุดใหม่ให้เข้ากับ สิ่งมีชีวิตไซเบอร์เนติก ที่มีอยู่แล้ว และทำให้ทีมอื่นที่ต่างก็มีลำดับความสำคัญของตัวเอง เห็นพ้องกับวิสัยทัศน์ใหม่นั้น
  เรื่องนี้ย่อมเต็มไปด้วย trade-off และการเมือง
  วิศวกรอาวุโสมักต่อสู้อย่างหนักเพื่อไม่ให้ระบบที่ตนรับผิดชอบ “มีน้ำหนัก” เพิ่มขึ้น และเพื่อกันไม่ให้มีการเพิ่ม scope หรือเบี่ยงออกจากทิศทางที่ตั้งใจไว้
  ดังนั้นจึงต้องมีการประนีประนอม หรือไม่ก็ต้องยกระดับไปให้ผู้บริหารตัดสินเรื่องลำดับความสำคัญ
  ผมไม่รู้ว่า AI จะแก้เรื่องนี้ได้ไหม แต่มันยากกว่ามาก

  • การบอกว่า LLM เป็นได้แค่คนเขียนโค้ดนั้นอาจจริงเมื่อ 1 ปีก่อน แต่ตอนนี้ไม่ใช่แล้ว
    ตอนนี้มันเป็น ผู้เรียกใช้เครื่องมือ ดังนั้น coding agent สามารถรัน lint, type check, test และแก้ error เหล่านั้นได้ สามารถขุดในแพลตฟอร์ม observability อย่าง Sentry เพื่อหาต้นตอปัญหา รัน benchmark เพื่อหาส่วนที่ช้าหรือ hot path และอ่านกับปรับใช้เอกสาร migration ไปสู่ major version ใหม่ของไลบรารีที่ใช้อยู่เพื่อให้ระบบทันสมัยต่อไปได้
    ถ้าสิ่งเหล่านี้ไม่ได้ถูกตั้งค่าให้สร้างแรงต้านกลับต่อ agent และบังคับให้เข้าใจระบบดีขึ้น มันก็จะยังคงเป็นแค่ LLM เขียนโค้ดโง่ ๆ
    แต่เมื่อทั้งโมเดลและ harness กำลังพัฒนาอย่างรวดเร็ว มันชัดเจนว่าสามารถไปได้ไกลกว่านั้นมาก

• โดยรวมบทความนี้ถูกต้อง และยังให้คำใบ้ว่าถ้าอยากให้ AI ช่วยให้กระบวนการเร็วขึ้น ควรไปโฟกัสที่ตรงไหน
  ตัวอย่างเช่น ผู้จัดการผลิตภัณฑ์คนหนึ่งบอกว่าเขาจินตนาการถึงอนาคตที่ถ้าประชุมกับผู้มีส่วนได้ส่วนเสียเสร็จแล้วไม่มี interactive prototype ออกมา ก็ถือว่าล้มเหลว ซึ่งผมรู้สึกว่าทิศทางนี้ถูกต้อง
  อีกอย่างที่คาดไว้คือ vibe coding จะกลายเป็น “Excel 2.0”
  มันจะทำให้สามารถสร้างแอปแบบโต้ตอบได้ด้วยตัวเองในระดับสูงมาก และทำให้ฝ่าย IT ต้องเข้าสู่สงครามต่อเนื่องในการแปลงสิ่งเหล่านั้นให้มีการรับประกันด้านความปลอดภัยที่ดีกว่า มี access control และ logging ที่เหมาะสม มี scalability มี change management ฯลฯ
  ถ้ามองในมุมประวัติศาสตร์ที่กว้างขึ้น ทุกการเปลี่ยนผ่านแบบปฏิวัติมักสร้าง “ม้าไอน้ำ” ขึ้นมาในช่วงแรก
  ตอนที่เครื่องจักรไอน้ำถูกประดิษฐ์ขึ้น ผู้คนจินตนาการว่าอนาคตของการคมนาคมคือวัตถุรูปร่างเหมือนม้าที่ขับเคลื่อนด้วยไอน้ำมาลากเกวียนแบบเดิม
  กว่าจะถึงภายหลัง เราจึงเริ่มเข้าใจหน้าที่ของการคมนาคมโดยแยกออกจากรูปทรงของมัน
  เดิมทีผมเริ่มพูดคำว่า ม้าไอน้ำ ตอนพูดถึง MOOC เพราะ MOOC เป็นแนวคิดแบบม้าไอน้ำอย่างแท้จริง

  • ถ้าคิดว่าการประชุมกับผู้มีส่วนได้ส่วนเสียจะล้มเหลวหากไม่มี interactive prototype ตอนจบ ก็แค่ไปเรียนใช้ Balsamiq ก็พอ
    การสร้าง prototype ไม่จำเป็นต้องใช้โค้ด
    มันเหมือนกับการถ่ายทอดฉาก ที่ไม่ได้จำเป็นต้องมีนักแสดงกับกล้องเสมอไป แค่มีภาพสเก็ตช์ไม่กี่ภาพก็พอแล้ว

• Gantt ที่ยกมานี้เป็นตัวอย่างของโมเดล waterfall หรือวิธีวิทยาอื่นที่มองว่าซอฟต์แวร์มีจุดหมายปลายทางสุดท้าย
  ปัจจุบันซอฟต์แวร์ 99.999% ไม่ได้ถูกสร้างแบบนั้น
  การพัฒนาซอฟต์แวร์สมัยใหม่ไม่มีจุดหมายปลายทาง
  ทุก ๆ สองสัปดาห์ ธุรกิจก็เปลี่ยนว่าสิ่งที่ซอฟต์แวร์ต้องทำคืออะไร
  มีฟีเจอร์ใหม่ การเชื่อมต่อใหม่ ฟีเจอร์ที่เปลี่ยนไป องค์ประกอบที่อัปเกรดหรือถูกแทนที่ สเกลที่ใหญ่ขึ้น หรือโฮสติ้งแบบใหม่เกิดขึ้นตลอด
  ผ่านไปไม่กี่ปี ซอฟต์แวร์ก็เปลี่ยนรูปไปอย่างสิ้นเชิง และคุณภาพกับการทดสอบก็ถูกโยนทิ้งออกนอกหน้าต่าง
  ไม่ใช่แค่ต้องรับมือกับการเปลี่ยนแปลงแบบแก้ขัด แต่ยังต้องเผชิญกับความทรมานไม่รู้จบในการต่อสู้กับ entropy
  ซอฟต์แวร์กลายเป็น สิ่งมีชีวิต ที่บาดเจ็บ เปลี่ยนวิถีชีวิต และแก่ตัวลง
  บริษัทกลายเป็นผู้ดูแลสัตว์ประหลาด เหมือนคนเลี้ยงสัตว์ในสวนสัตว์ที่พยายามประคองสัตว์ซึมเศร้าให้อยู่รอด
  มนุษย์เป็นสัตว์แห่งความเคยชิน ดังนั้นต่อให้ใช้ AI ปัญหาเดิมทั้งหมดก็จะยังเกิดขึ้น
  เพียงแต่ทุกอย่างจะเร็วขึ้นเล็กน้อย และ code review อาจช่วยให้โค้ดดีขึ้นเล็กน้อย
  ขณะเดียวกัน การขาดเทสต์ที่ดีและความต้องการ deploy ให้เร็วขึ้น ก็จะทำให้ทุกอย่างแย่ลงเล็กน้อย
  ผลของแรงดึงรั้งทั้งสองด้านนี้คือคุณภาพซอฟต์แวร์จะใกล้เคียงเดิม แต่เคลื่อนไหวเร็วขึ้นนิดหน่อย
  สุดท้ายกระบวนการจะเร็วขึ้นจริง แต่ส่วนที่เหลือยังทรมานเหมือนเดิมจนแทบไม่มีใครรู้สึกถึงมันมากนัก
  มีโอกาสสูงกว่าที่ทุกคนจะหมดไฟเร็วขึ้น
  ความซับซ้อนมีเหตุผลของมัน และคุณไม่สามารถกำจัดความซับซ้อนโดยไม่กำจัดสาเหตุนั้นได้
  คุณไม่สามารถแก้ ปัญหาทางธุรกิจ ด้วยเครื่องมือได้

• สำหรับคำพูดที่ว่า “AI อาจสร้างโค้ดได้เร็ว แต่นั่นไม่ได้แปลว่ามันจะสร้างโค้ดที่ถูกต้อง” นั้น ในความเป็นจริงโค้ดแทบจะถูกต้องอยู่เสมอ
  สิ่งที่ผมไม่ชอบมักเป็นวิธีที่โค้ดถูกเพิ่มเข้ามา
  ถ้าคุณรู้จัก codebase ดีพอ มันจะมีพิธีการบางอย่าง เช่น ควรเพิ่มไว้ตรงไหน ควรตั้งชื่ออย่างไร ควรใส่คอมเมนต์มากน้อยแค่ไหนและตรงไหน
  ถ้า agent ทำตรงนี้ไม่ได้ คนแบบผมก็จะหงุดหงิด และดูเหมือนว่าต่อให้เขียนไว้ใน AGENTS.md มันก็ยังล้มเหลว
  ส่วนคำพูดที่ว่า “ถ้าให้เอกสารฟีเจอร์หรือขอบเขตงานในปริมาณเท่ากันกับนักพัฒนาที่เป็นคน ผลิตภาพจะพุ่งขึ้นมาก” นั้น ผมทำงานในสาย IT มาเกือบ 20 ปีแล้วแต่ไม่เชื่อเลยว่าจะเกิดขึ้นได้จริง
  ต่อให้เกิดขึ้นก็หายากเกินกว่าจะคุ้มค่าแก่การพูดถึง

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

• AI ไม่จำเป็นต้องข้ามกระบวนการ แต่อย่างไรก็ยังช่วยเร่งความเร็วได้
  มันช่วยเรื่อง refactoring การเขียน boilerplate การค้นหาข้อผิดพลาดที่ไม่เคยเห็นมาก่อน และสิ่งที่ linter จับไม่ได้
  หลายคอมเมนต์ดูเหมือนไม่ได้ใช้กระบวนการมาตรฐานที่เป็นที่รู้กัน หรือไม่ก็สมมติว่าถ้าใช้ AI แล้วไม่จำเป็นต้องทำตามมาตรฐานนั้น
  ถามว่าสามารถปล่อยโค้ดและฟีเจอร์ได้มากขึ้นไหม ถ้ามี requirement ที่ดีและเทสต์ที่เพียงพอ ก็แน่นอนว่าได้
  โค้ดทุกชิ้นที่ AI เขียนต้องผ่านการ review และ test และต้องถูกแยกเป็น commit กับ pull request ที่แยกกันชัดเจน
  คนที่ส่ง PR ยาวหลายพันบรรทัดคือสัญญาณอันตราย
  ต่อให้ไม่มี AI คุณก็ไม่ควรทำแบบนั้นอยู่แล้ว แล้วทำไมพอใช้ AI ถึงจะทำแบบนั้น
  ข้อยกเว้นที่พอรู้จักมีแค่การ rewrite หรือ refactor ครั้งใหญ่ แต่ถึงตอนนั้นผมก็ยังคิดว่าควรมี commit แยกย่อยที่สลับเปิดใช้ได้ เพื่อให้เห็นกระบวนการเปลี่ยนแปลงและตัดสินได้ดีขึ้น
  ถ้าเอา commit หรือ PR ก้อนยักษ์แบบยิงครั้งเดียวมาให้ดู ผมจะปฏิเสธ
  มันต้องถูกแบ่งเป็นชิ้นที่นักพัฒนาทั่วไปสามารถตรวจสอบได้