คำอธิบายปกป้องแนวคิดการไม่อ่านโค้ด

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

---

ความหมายที่แท้จริงของ “การไม่อ่านโค้ด”

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

กรณีศึกษาที่ใช้เป็นหลักฐาน

• Harness Engineering ของ OpenAI

  • OpenAI อธิบายผ่านบล็อกโพสต์ Harness Engineering ว่าบทบาทศูนย์กลางของทีมวิศวกรรมซอฟต์แวร์ได้ย้ายจากการเขียนโค้ดไปสู่ การออกแบบสภาพแวดล้อม การระบุเจตนา และการสร้าง feedback loop
  • วิศวกร 3 คนสร้างโค้ด 1 ล้านบรรทัดโดยใช้ Codex agent เพียงอย่างเดียว เพื่อสร้างผลิตภัณฑ์ที่มีผู้ใช้ภายในหลายร้อยคน
  • ลงทุนหลักกับ harness รอบตัวโค้ด—เอกสาร กฎ dependency, linter, โครงสร้างพื้นฐานการทดสอบ, ระบบสังเกตการณ์—มากกว่าที่ตัวโค้ดเอง
  • ไม่ได้ลงทุนแยกต่างหากกับการรีวิวโค้ดแบบรายบรรทัด

• OpenClaw

  • OpenClaw ที่สร้างโดยคนคนเดียวไม่มีทีม เป็นหนึ่งในโปรเจกต์โอเพนซอร์สที่เติบโตเร็วที่สุดในช่วงไม่กี่เดือนที่ผ่านมา โดยมี ดาวบน GitHub มากกว่า 100,000 ดวง
  • มีโครงสร้างที่รันเอเจนต์ 5–10 ตัวแบบขนาน และถูกออกแบบ·ดำเนินการโดย วิศวกรที่มีประสบการณ์ ไม่ใช่มือใหม่
  • ในบทสัมภาษณ์ชื่อ “ฉัน deploy โค้ดที่ฉันไม่ได้อ่าน” เขาระบุว่าลงทุนอย่างมากกับรีแฟกเตอร์ริง สถาปัตยกรรม การทดสอบ และ harness รอบการเขียนโค้ดด้วย AI

• จาก Coder สู่ Orchestrator

  • วิศวกรมากประสบการณ์ผู้สร้าง ESLint และ เขียนหนังสือกับ O'Reilly หลายเล่ม คาดการณ์ในบทความล่าสุด ว่า อนาคตของวิศวกรรมซอฟต์แวร์จะมี การ orchestrate AI agent เป็นศูนย์กลาง แทนการเขียนโค้ด
  • ทักษะหลักกำลังย้ายจากไวยากรณ์และการลงมือเขียน ไปสู่ การออกแบบสถาปัตยกรรม การเขียนสเปก และการออกแบบ feedback loop

ข้อโต้แย้งต่อความกังขา

• คำวิจารณ์เรื่องกล่องดำ

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

• ข้อกังวลด้านความปลอดภัย

  • ต่อความกังวลว่าโค้ดที่ AI สร้างอาจ ถูกฝัง backdoor ปัญหานี้ไม่ใช่เรื่องของ “มนุษย์ต้องอ่านทุกบรรทัด” แต่เป็นเรื่องของ tooling และระบบการตรวจสอบ
  • การวิเคราะห์แบบสแตติก การสแกน dependency และ security linter มีอยู่ก็เพราะมนุษย์เองก็เขียนโค้ดที่มีช่องโหว่ได้ ดังนั้นทางออกคือ ระบบตรวจสอบอัตโนมัติที่แข็งแรงกว่าเดิม ซึ่งเป็นทิศทางเดียวกับแนวทางแบบเน้น harness
  • อย่างไรก็ตาม ใน พื้นที่ที่อ่อนไหวด้านความปลอดภัยเป็นพิเศษ ก็ยังจำเป็นต้องมีการรีวิวโดยมนุษย์

• ปัญหาการสะสมของบั๊ก

  • คำวิจารณ์ที่พบบ่อยที่สุดคือ “ถ้าโค้ดล้มเหลว เงินของคนก็หาย เครื่องบินหยุดบิน รถยนต์เสีย จงอ่านโค้ด”
  • ตามข้อมูลจาก CodeRabbit โค้ดที่ AI สร้าง มีข้อบกพร่องมากกว่า 1.7 เท่าในด้านคุณภาพซอฟต์แวร์โดยรวม (อ้างอิง)
  • แต่แนวทางการเขียนโค้ดด้วย AI มีหลายรูปแบบ และ การพัฒนาที่เน้น harness พร้อมสเปก การทดสอบแบบลำดับชั้น และข้อจำกัดเชิงสถาปัตยกรรม แตกต่างโดยพื้นฐานจาก vibe coding แบบง่าย ๆ
  • แนวทางหนึ่งที่มีผู้นำเสนอในคอมเมนต์คือ พึ่งพาสเปก การทดสอบ และการวิเคราะห์แบบสแตติก พร้อมรักษา test coverage มากกว่า 85% สร้าง testing ladders ซึ่งเป็น integration test ที่ค่อย ๆ ขยายขอบเขต และเปิดเผยข้อผิดพลาดตั้งแต่ต้นด้วย benchmarking และ dogfooding แบบเข้มข้น
  • คำถามสำคัญไม่ใช่ว่า “โดยเฉลี่ยแล้วโค้ด AI มีบั๊กมากกว่าหรือไม่” แต่คือ “เมื่อพัฒนาในความเร็วเท่ากันภายใต้ harness ที่ออกแบบมาอย่างดี มันก่อบั๊กมากกว่าทางเลือกอื่นหรือไม่?”
  • Greg Brockman (ผู้ร่วมก่อตั้ง OpenAI) ก็มีจุดยืนว่า ควรใช้มาตรฐานเดียวกับโค้ดที่มนุษย์เขียน

การจัดระบบที่ใช้งานจริง

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

• เวิร์กโฟลว์ที่ขับเคลื่อนด้วยสเปก

  • ก่อนที่เอเจนต์จะเขียนโค้ด จะเริ่มจากการเขียน สเปกที่เฉพาะเจาะจงและละเอียดมาก ผ่านการสนทนากับ AI ก่อน
  • จัดโครงสร้างให้สามารถติดตามจาก product spec ไปถึง execution plan ได้ผ่าน requirement ID
  • ทุก task ใน execution plan มี acceptance criteria ที่ระบุวิธีตรวจสอบไว้อย่างชัดเจน
    • การทดสอบอัตโนมัติใช้ (TEST)
    • การตรวจสอบด้วยสายตาใช้ (BROWSER:DOM)
    • ใช้ (MANUAL) เฉพาะเมื่อไม่มีทางเลือกอื่น และถึงอย่างนั้นก็ยังพยายามสร้างการตรวจสอบอัตโนมัติด้วย curl หรือ bash ก่อนเสมอ
  • task ที่ไม่มี verification metadata ที่ชัดเจนจะถูก ทักษะ audit บล็อกก่อนเริ่มงาน

• AI Coding Toolkit (harness)

  • ทูลคิทที่ประกอบด้วยพรอมป์ต์ สกิล ฮุก และสคริปต์ จะจำกัดวิธีทำงานของเอเจนต์ และมี สกิลมากกว่า 35 รายการ พร้อมคำสั่งเอเจนต์แบบมีโครงสร้างและโครงสร้างพื้นฐานการตรวจสอบแบบลำดับชั้น
  • จัดการคำสั่งสำหรับเอเจนต์ในรูปของอินฟราสตรักเจอร์
    • AGENTS.md ทำหน้าที่เป็นชุดกฎหลัก: แก้ไขอย่างอนุรักษนิยม รักษาอินเทอร์เฟซเดิม ปฏิบัติตาม TDD ห้ามเดา ห้ามเขียนประวัติ git ใหม่
    • VISION.md กำหนดขอบเขตเชิงกลยุทธ์
  • มี ระบบตรวจสอบแบบลำดับชั้น
    • หลังจบแต่ละขั้น checkpoint skill จะรันเกตหลายชั้นที่รวม type checking, linting, testing, build, mutation testing และ security scan
    • หากใช้เครื่องมือเบราว์เซอร์ได้ ก็จะทำการตรวจสอบผ่านเบราว์เซอร์แบบอัตโนมัติ
    • ส่ง diff ที่เปลี่ยนแปลงไปให้ AI model อีกตัวหนึ่ง (Codex CLI) รีวิวเพื่อขอ second opinion
    • การตรวจสอบข้ามโมเดล ช่วยชดเชยจุดบอดของโมเดลเดียว
  • บางครั้งก็อ่านโค้ดโดยตรง แต่ จำกัดไว้เฉพาะกรณีพิเศษ
    • เมื่อการทดสอบทั้งหมดผ่านแล้ว แต่พฤติกรรมของผลิตภัณฑ์ยังรู้สึกแปลก
    • เมื่อต้องตัดสินใจด้านสถาปัตยกรรมที่สำคัญ
    • เมื่อกำลังดีบักปัญหาที่หลายเอเจนต์ยังแก้ไม่ได้
  • แม้ในกรณีเหล่านี้ เป้าหมายก็ไม่ใช่การวิเคราะห์ตัวโค้ดเอง แต่คือ หาช่องว่างใน harness ที่ปล่อยให้ปัญหาเกิดขึ้น เพื่อป้องกันไม่ให้เกิดซ้ำ

เมื่อใดที่ควรอ่านโค้ด

• ใน ระบบที่มีความปลอดภัยเกี่ยวข้องโดยตรง, บริการที่อ่อนไหวด้านความมั่นคงปลอดภัย, และ การตัดสินใจด้านสถาปัตยกรรมที่สำคัญ วิศวกรรมซอฟต์แวร์ก็คือวิศวกรรมจริง ๆ และในยุคที่โค้ดถูกสร้างเป็นจำนวนมากเช่นทุกวันนี้ ความสำคัญของมันกลับยิ่งเพิ่มขึ้น
• อุปมาจากวงการการบินเรื่อง "Children of the Magenta" ชี้ถึงปรากฏการณ์ที่นักบินพึ่งเส้นทางบินสีมาเจนตาบนหน้าจอนำร่องมากเกินไป
  • บทเรียนไม่ใช่ “อย่าใช้ออโตไพลอต” แต่คือ จงรักษาความสามารถในการเข้ามาแทรกแซงเมื่อจำเป็น
  • เมื่อเกิดปัญหา ต้องสามารถ ลดระดับอัตโนมัติแล้วกลับไปใช้พื้นฐานได้ แต่การเรียกร้องให้บินด้วยมือทุกเที่ยวบินตลอดเวลานั้นทั้งไม่มีประสิทธิภาพและเสี่ยงกว่า
  • หัวใจสำคัญคือการใช้ประโยชน์จากอัตโนมัติ โดยไม่สูญเสียความสามารถในการแทรกแซง

จงเดิมพันกับแนวโน้ม

• ทุกชั้นนามธรรมของคอมพิวติ้งเมื่อปรากฏขึ้นล้วนเจอแรงต้าน และกรณีตัวอย่างที่ชัดเจนคือ การที่ Dennis Ritchie และ Ken Thompson เขียน Unix ใหม่ด้วย C ในปี 1973
  • ดูบทความของ Cline เพิ่มเติมได้ที่ จากแอสเซมบลีสู่ AI: ทำไม 'vibe coding' จึงเป็นอีกบทหนึ่งของเรื่องราวนามธรรมของเรา
• ในตอนนั้นมีคำวิจารณ์ว่าจะช้าลง จะสูญเสียการควบคุมฮาร์ดแวร์ และความซับซ้อนจะทำให้การบำรุงรักษายากขึ้น แต่ชั้นนามธรรมของ C ทำให้ Unix ขยายตัวเป็น ระบบปฏิบัติการที่มีความสามารถในการพกพาและอิทธิพลสูง
• รูปแบบที่เกิดซ้ำคือ ผู้ที่มีความเชี่ยวชาญในชั้นที่ถูกทำให้เป็นนามธรรม มักย้ำความสำคัญของการเข้าใจชั้นนั้น ซึ่งมีเหตุผลในบางสถานการณ์ แต่โดยมากแล้วเวลาส่วนใหญ่จะถูกใช้ไปกับ การคิดและออกแบบบนชั้นนามธรรมที่สูงกว่า
• การเลือกไม่อ่านโค้ดไม่ใช่การประกาศว่าเครื่องมือสมบูรณ์แบบ แต่เป็น การตัดสินต่อกระแสที่ว่าในหลายกรณีมันใช้ได้ผลดีเพียงพอแล้ว และกำลังพัฒนาอย่างรวดเร็ว
• โค้ดไม่ได้หายไป แต่กำลังเคลื่อนสู่การเป็น รายละเอียดของการนำไปใช้งาน มากขึ้นเรื่อย ๆ ขณะที่ สเปก สถาปัตยกรรม และเลเยอร์การตรวจสอบ กำลังก้าวขึ้นมาเป็นผลลัพธ์หลัก

[foriequal0]

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

[sang459]

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

[chamchi]

กำลังสร้างไลบรารีด้วย AI อยู่ แต่ดูเหมือนว่าการรีแฟกเตอร์ การเพิ่มคุณภาพโค้ด และการตรวจเช็กข้อบกพร่องก็ควรให้ AI รันด้วยเหมือนกัน