งานของคุณคือส่งมอบโค้ดที่พิสูจน์แล้วว่าใช้งานได้

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

---

ปัญหาของการส่งโค้ดที่ยังไม่ผ่านการตรวจสอบยืนยัน

• มีการกล่าวถึงกรณีที่วิศวกรมือใหม่ซึ่งใช้เครื่องมือ LLM ส่ง PR ขนาดใหญ่ที่ยังไม่ตรวจสอบยืนยัน แล้วพึ่งพา code review
  • สิ่งนี้ถูกชี้ว่า ไม่ให้เกียรติและไม่มีประสิทธิภาพ และเป็นการละเลยความรับผิดชอบในฐานะนักพัฒนา
• บทบาทของวิศวกรซอฟต์แวร์ไม่ใช่แค่การผลิตโค้ด แต่คือการส่งมอบ โค้ดที่พิสูจน์แล้วว่าใช้งานได้
  • โค้ดที่ยังไม่ผ่านการตรวจสอบยืนยันถือเป็นการผลักภาระไปให้ผู้รีวิว

สองขั้นตอนในการพิสูจน์ว่าโค้ดทำงานได้

• ขั้นตอนแรกคือ การทดสอบด้วยตนเอง โดยต้องตรวจสอบด้วยตัวเองว่าโค้ดทำงานได้ถูกต้อง
  • จำเป็นต้องมีขั้นตอนตั้งค่าระบบให้กลับสู่สถานะเริ่มต้น ใช้การเปลี่ยนแปลง แล้วตรวจสอบผลลัพธ์
  • สามารถแนบคำสั่งเทอร์มินัลและผลลัพธ์ที่ได้ในคอมเมนต์ code review หรือพิสูจน์ด้วย วิดีโอบันทึกหน้าจอ
  • หลังจากยืนยันว่าทำงานปกติแล้ว ควรค้นหาปัญหาผ่าน การทดสอบกรณีขอบ เพิ่มเติม
• ขั้นตอนที่สองคือ การทดสอบอัตโนมัติ ซึ่งถูกย้ำว่าเป็นกระบวนการจำเป็นจากพัฒนาการของเครื่องมือ LLM
  • ควรใส่การทดสอบอัตโนมัติไปพร้อมกับการเปลี่ยนแปลง และหากย้อนการแก้ไขกลับ การทดสอบต้องล้มเหลว
  • การเขียนเทสต์ใช้ขั้นตอนเดียวกับการทดสอบด้วยตนเอง และ ความสามารถในการผสานรวม test harness เป็นสิ่งสำคัญ
  • การคิดว่าการทดสอบอัตโนมัติเพียงอย่างเดียวเพียงพอแล้วจึงข้ามการทดสอบด้วยตนเอง เป็นแนวทางที่ผิด

บทบาทและการตรวจสอบยืนยันของ coding agent

• กระแสสำคัญของวงการ LLM ในปี 2025 คือ การเติบโตอย่างรวดเร็วของ coding agent โดยมี Claude Code และ Codex CLI เป็นตัวอย่างเด่น
  • เครื่องมือเหล่านี้สามารถรันโค้ดและแก้ปัญหาด้วยตัวเองได้
• coding agent ก็ต้อง พิสูจน์การเปลี่ยนแปลงของตัวเอง และต้องทำทั้งการทดสอบด้วยตนเองและการทดสอบอัตโนมัติ
  • ในกรณีของเครื่องมือ CLI สามารถฝึกให้เอเจนต์รันเองโดยตรง หรือทำให้อัตโนมัติด้วยระบบอย่าง CLIRunner ของ Click
  • หากเป็นการแก้ไข CSS ก็สามารถตั้งค่าให้ตรวจสอบผลลัพธ์ผ่าน การจับภาพหน้าจอ ได้
• หากในโปรเจกต์มีเทสต์เดิมอยู่แล้ว เอเจนต์จะขยายต่อหรือใช้แพตเทิร์นเดิมซ้ำ
  • โครงสร้างและคุณภาพของโค้ดเทสต์ มีผลโดยตรงต่อคุณภาพการสร้างเทสต์ของเอเจนต์
  • สุนทรียะต่อโค้ดเทสต์ ถูกกล่าวถึงว่าเป็นความสามารถหลักที่แยกวิศวกรอาวุโสออกจากคนอื่น

ความรับผิดชอบของมนุษย์และคุณค่าของโค้ด

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

[ethanhur]

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

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

[roxie]

โอ้ Google ใช้แนวคิดแบบนั้นสินะ

[tested]

> ไวบ์ Engineering

[GN⁺]

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

• ช่วงนี้มีเรื่องเล่าน่าหดหู่ที่เห็นบ่อยมาก: วิศวกรจูเนียร์ที่ได้พลังจากเครื่องมือ LLM โยน PR ขนาดมหึมาที่ยังไม่ได้ทดสอบให้เพื่อนร่วมงานหรือเมนเทนเนอร์โอเพนซอร์ส แล้วคาดหวังว่า code review จะจัดการที่เหลือให้เอง ที่แย่กว่านั้นคือพฤติกรรมแบบนี้ไม่ได้มาจากแค่จูเนียร์ แต่ยังมาจากนักพัฒนาระดับซีเนียร์ด้วย

  • เมื่อวานกับวันนี้ฉันก็ทำแบบนั้นพอดี ทีมเราได้รับรายงานบั๊กและตัดสินว่าเป็นปัญหาจาก vendor ภายนอก แต่ vendor ตีกลับมาบอกว่าเป็นปัญหาฝั่งเรา ฉันเลยให้ Codex ช่วยดู แล้วมันก็หาปัญหาเจอและเตรียม PR ไว้ให้ ฉันไม่ได้รีวิวหรือทดสอบเองโดยตรง แต่ให้ทีมช่วยตรวจสอบแทน กระบวนการนั้นก็ช่วยฝึกให้ทีมใช้ LLM เป็นเครื่องมือในการทำงาน
  • ในช่วงสองวันที่ผ่านมา มีสมาชิกทีมที่ไม่ใช่นักพัฒนาสองคนไปถาม AI agent ว่าจะแก้บั๊กบนมือถืออย่างไร แล้วเอาคำตอบนั้นไปใส่เป็นเนื้อหาหลักของ ticket สุดท้ายฉันต้องอ่านทั้งหมดแล้วกลับมาทำความเข้าใจ requirement ที่แท้จริงใหม่
  • มีคนจำนวนมากที่ติดป้ายว่า “ซีเนียร์” แต่ทำตัวเหมือนจูเนียร์ คงเป็นเพราะทุกวันนี้แค่จบมา 2 ปีก็ถูกเรียกว่าซีเนียร์แล้ว
  • นักพัฒนาที่เพิกเฉยหรือหาทางเลี่ยงกฎคือคนที่อันตรายที่สุด มันทำให้นึกถึงพวกนักพัฒนา 10xที่เคยเจอ ถ้าเมินกฎแล้วเอาแต่ปล่อยฟีเจอร์ออกมา สุดท้ายก็เป็นคนอื่นที่ต้องตามเก็บกวาด
  • ระหว่างทำ code review ฉันสงสัยว่าจูเนียร์หายไปไหน ถ้าไม่ได้เข้าร่วมรีวิว ก็ยากที่จะทำให้พวกเขารู้สึกรับผิดชอบต่อคุณภาพโค้ดของตัวเอง

• วิธีเขียน PR ที่ดีใช้ได้กับทุกกรณี ไม่ใช่แค่โค้ดที่ AI สร้าง ฉันมักเขียนคำอธิบาย PR โดยเรียงลำดับเป็น วิธีทำงานปัจจุบัน, เหตุผลที่ต้องเปลี่ยน, และสิ่งที่เปลี่ยน พร้อมใส่วิธีทดสอบ สกรีนช็อต และคำสั่ง E2E test เพื่อลดภาระของ reviewer วิธีนี้ยังช่วยมากกับการทำงานแบบ async หรือทีมที่อยู่คนละ time zone

  • ก่อนจะขอรีวิว ฉันจะทบทวนเองอีกครั้ง ถ้าเก็บพวกคำผิดเล็กน้อยหรือเอา log ที่ไม่จำเป็นออกก่อน ก็ช่วยประหยัดเวลาของ reviewer ได้ Copilot review ก็จับเรื่องพวกนี้ได้ดีเหมือนกัน
  • ต่อให้เขียนคำอธิบายละเอียดแค่ไหน หลายครั้งก็ไม่มีใครอ่านอยู่ดี แต่ฉันยังเขียนต่อเพราะมันคือความรับผิดชอบของฉัน
  • ไม่ว่าจะเป็น PR ที่ AI ช่วยหรือไม่ ก็ควรต้องมีหลักฐานการทดสอบและการตรวจสอบยืนยัน
  • เมื่อก่อนฉันเคยเขียนคำอธิบายยาวมาก แต่พอรู้ว่าไม่มีใครอ่าน ก็พบว่าสรุปเฉพาะประเด็นสำคัญเป็นbullet pointได้ผลกว่า
  • เทมเพลต PR ของทีมเรามีทั้งหมายเลข ticket, คำอธิบายคำขอ, สถานะปัจจุบัน, สถานะหลังเปลี่ยน และแม้แต่ ‘mood gif’

• แก่นของการเป็นวิศวกรคือการเข้าใจ requirement แปลงมันเป็นลำดับตรรกะที่ทำงานได้, จัดการ trade-off, และรับผิดชอบต่อผลลัพธ์ การสร้างโค้ดหรือสุ่มส่ง PR ไปเรื่อยคืออาการของการขาดพื้นฐานเหล่านี้เสียมากกว่า coding agent กลับยิ่งเป็นตัวเตือนให้เห็นแก่นแท้ของงานวิศวกรรมอีกครั้ง

  • ถ้าอ่านบทความนี้ จะเห็นกรณีที่โค้ดแค่ 1 บรรทัดทำให้เสียหาย 60 ล้านดอลลาร์ PR ยาว 10,000 บรรทัดที่ AI ทำโดยไม่มีความเข้าใจโค้ดคือหายนะที่อาจเกิดขึ้นได้
  • ในความเป็นจริง บริษัทให้ความสำคัญกับการตลาดและความสามารถในการทำกำไรมากกว่าคุณภาพ สินค้าที่ติดป้าย ‘พรีเมียม’ ขายดีกว่าสินค้าคุณภาพสูงเสียอีก สุดท้ายสิ่งที่ “ขายได้” จึงมาก่อนวิศวกรรม
  • แต่ปัญหาคือถ้าองค์กรกดดันว่า “ใช้ AI แล้วทำฟีเจอร์ให้เสร็จภายใน 3 วัน ไม่งั้นคุยกับ HR” มันก็ยากที่จะยึดหลักวิศวกรรมในอุดมคติไว้ได้

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

  • ฉันก็คิดเหมือนกัน ต่อให้เป็นโค้ดที่ทำงานได้ดีก็ยังอาจเป็นโค้ดที่แย่มากได้
  • แทนที่จะใช้คำว่า “พิสูจน์” คำว่า “สาธิต (demonstrate)” น่าจะเหมาะกว่า การทดสอบเป็นเพียงหลักฐานในบางกรณีเท่านั้น
  • ฉันไม่ได้เชื่อแค่ผลการทดสอบ แต่จะลองทำแอปให้พังด้วยหลายวิธีด้วย และในกระบวนการนั้นก็มักได้ปรับปรุงให้โค้ดดีขึ้น
  • โค้ดส่วนใหญ่พิสูจน์เชิงรูปแบบไม่ได้อยู่แล้ว ดังนั้นแนวทางอย่างproperty-based testingน่าจะมีประโยชน์
  • ต่อให้ทำ test coverage ได้ 100% ถ้าโค้ดไม่แข็งแรงพอก็ไม่มีความหมาย

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

• ฉันได้ยินเรื่องที่ว่าด้วย LLM แล้วจูเนียร์จะโยน PR ก้อนใหญ่เข้ามา แต่ในองค์กรของเรายังไม่ค่อยมีแบบนั้น

  • อาจไม่ถึงกับเป็น PR ก้อนใหญ่ แต่โค้ดที่ LLM สร้างแล้วนักพัฒนาเองก็ไม่เข้าใจ ฉันเห็นบ่อย
  • ในองค์กรเราก็มีกรณีแบบนั้น ปัญหามีประมาณนี้
    • agent ย้อนทับ feedback ก่อนหน้า
    • ไม่ทำตามมาตรฐานของ codebase
    • ประดิษฐ์วิธีแก้ที่มีอยู่แล้วขึ้นมาใหม่
    • ตอบ feedback บน PR ด้วย output จาก agent
    • เรื่องที่แก้แค่ 10~20 บรรทัดก็ส่งมาเป็น PR 50,000 บรรทัด
    • การทดสอบไม่พอ, การจัดการ error ก็ไม่ดี
  • คนที่เมื่อก่อนก็ส่ง PR คุณภาพต่ำอยู่แล้ว ตอนนี้แค่ส่งได้เร็วขึ้นด้วย LLM เท่านั้น
  • ดู WireGuard Android PR #82, #80 จะเห็นว่าคำตอบที่ AI คัดลอกมาแปะยังคงอยู่เหมือนเดิม พอเปิดแท็บ “files changed” แล้วชวนสับสนมาก
  • เพื่อนฉันทำงานที่สตาร์ตอัป 11 คน แล้ว CTO ดัน push โค้ด 10,000 บรรทัดเข้า main ตรง ๆ ตอนตีสาม ถ้าเป็นช่วงสำรวจก็พอเข้าใจได้ แต่ถ้าเป็นช่วงรักษาเสถียรภาพนี่คือความเสี่ยงที่น่ากลัวมาก

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

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

• ที่ทำงานเก่าของฉันเป็นผู้ผลิตฮาร์ดแวร์คุณภาพสูงในญี่ปุ่น ถ้าแผนก QA เจอบั๊ก การปล่อยผลิตภัณฑ์จะถูกหยุดทันที เพราะงั้นแต่ละแผนกพัฒนาจึงสร้างทีม QC ของตัวเองขึ้นมาเพื่อเพิ่มการทดสอบล่วงหน้า สุดท้ายซอฟต์แวร์ก็ถูกตรวจสอบอย่างเข้มงวดมาก

  • ฉันสงสัยว่า “get dinged” หมายความว่าอะไร โครงสร้างแบบนี้อาจทำให้คนยิ่งกลัวการเปลี่ยนแปลงหรือเปล่า

• ทุกวันนี้แก่นของงานกลายเป็นแค่ปิด ticket ให้ได้ คุณภาพโค้ดไม่ถูกนับในสถิติ เลยกลายเป็นว่าไม่สำคัญ ฉันไม่ร่วมกับระบบแบบนี้อีกแล้ว ตอนนี้ความเป็นช่างฝีมือหายไปหมด ทุกคนอยากได้แต่ไม้อัดราคาถูกกับกาว

  • ทันทีที่องค์กรเอา LLM มาใช้เต็มรูปแบบและคาดหวังให้ทุกคนใช้ software engineering ก็ไม่ใช่งานวิศวกรรมที่จริงจังอีกต่อไป
  • และก็มีคนที่พอคุณวิจารณ์ท่าทีแบบนั้น ก็จะย้อนถามว่า “งั้นคุณอยู่ได้ด้วยเงินอุดหนุนจากรัฐเหรอ?”

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

  • เพราะแบบนั้นฉันจึงเน้นmanual test การโชว์การทำงานจริงผ่านสกรีนช็อตหรือวิดีโอก็ช่วยสร้างความเชื่อมั่นได้มาก