AI เขียนโค้ด 1 ล้านบรรทัดโดยมนุษย์ไม่แตะเลย ทีม OpenAI ทำได้อย่างไร?

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI · 18 ตุลาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ตัวเลขที่ทำให้ต้องหยุดอ่าน

ทีม OpenAI เขียนบทสรุปไว้เมื่อ 11 กุมภาพันธ์ 2026 [1] ว่าพวกเขาทดลองอะไรบางอย่างมาห้าเดือน

โปรเจกต์นั้นคือผลิตภัณฑ์ภายในที่ปล่อยให้ผู้ใช้จริงลอง

ทุกบรรทัดของมันเขียนโดย Codex ทั้งหมด

รวมแล้วราวหนึ่งล้านบรรทัด [1]

ทีมที่ขับเคลื่อนมีแค่สามวิศวกร

ระหว่างทางมี pull request เปิดและถูก merge ไปประมาณ 1,500 รายการ [1]

คิดเป็น 3.5 PR ต่อวิศวกรต่อวัน [1]

และน่าประหลาดที่อัตรานั้นเพิ่มขึ้น เมื่อทีมขยายเป็นเจ็ดคน

พวกเขาประเมินว่าใช้เวลาราวหนึ่งในสิบของการเขียนด้วยมือ [1]

ประโยคที่สรุปทุกอย่างไว้สั้น ๆ ในบทคือ "Humans steer. Agents execute."

ก่อนไปต่อ ผมขออธิบายคำว่า harness ก่อนสั้น ๆ

มันคือลูปของเอเจนต์และตรรกะที่อยู่ใต้ Codex ทุกหน้าจอ ตั้งแต่เว็บ CLI ส่วนขยาย IDE ไปจนถึงแอปบนเครื่อง [2]

พูดง่าย ๆ คือสิ่งที่เราเรียกกันว่าเอเจนต์นั้น ส่วนใหญ่ไม่ใช่ตัวโมเดล

ผมอ่านแล้วรู้สึกสองอย่างพร้อมกัน

อย่างแรกคือทึ่ง อย่างที่สองคือระแวง

และผมคิดว่าความระแวงนั้นมีเหตุผล

บทนี้ผมจะแยกให้ดูว่าอะไรคือบทเรียนที่หยิบไปใช้ได้จริง

และอะไรคือส่วนที่ยังไม่ควรเชื่อ

"Humans steer. Agents execute." แปลว่าอะไรจริง ๆ

คำนี้ฟังดูสวย แต่ถ้าไม่แยกให้ชัดจะเข้าใจผิดได้ง่าย

OpenAI อธิบายว่ามนุษย์ยังอยู่ในวงจรเสมอ [1]

แต่ย้ายไปทำงานคนละชั้นของนามธรรม

งานของคนคือจัดลำดับความสำคัญ แปลงเสียงผู้ใช้เป็นเกณฑ์ยอมรับ และตรวจผลลัพธ์

ส่วนงานเขียนโค้ด การทดสอบ การรีวิว และการแก้บั๊ก เป็นของเอเจนต์

จุดที่ผมคิดว่าสำคัญที่สุดคือประโยคนี้

เมื่อเอเจนต์ทำไม่ได้ ทีมเขามองว่านั่นคือ สัญญาณ ไม่ใช่ความล้มเหลว

คำถามที่ถามทันทีคือ "ความสามารถอะไรที่ยังขาด และจะทำให้มันชัดเจนพอให้เอเจนต์ทำตามได้อย่างไร"

แล้วคำตอบนั้นถูกป้อนกลับเข้าไปในระบบ โดยให้ Codex เขียนทางแก้เอง

นี่คือการย้ายงานจาก "เขียนโค้ด" ไปเป็น "ออกแบบสภาพแวดล้อมที่ทำให้เอเจนต์ทำงานได้"

บทเรียนที่หนึ่ง: AGENTS.md ต้องเป็นสารบัญ ไม่ใช่คู่มือ

นี่คือบทเรียนที่ผมคิดว่ามีค่าที่สุดของบท

ทีม OpenAI ลองวิธีที่หลายคนทำ คือยัดทุกอย่างลงในไฟล์ AGENTS.md ไฟล์เดียว [1][11]

มันล้มเหลวในแบบที่คาดเดาได้สี่ทาง

หนึ่ง บริบทเป็นทรัพยากรที่หายาก ไฟล์คำสั่งยักษ์ไปแย่งที่กับตัวงาน โค้ด และเอกสารที่เกี่ยวข้อง

ผลคือเอเจนต์มองข้ามข้อจำกัดสำคัญ หรือไปจูนกับข้อจำกัดผิดข้อ

สอง คำแนะนำที่มากเกินไปกลายเป็นไม่ใช่คำแนะนำ เมื่อทุกอย่างสำคัญ เท่ากับไม่มีอะไรสำคัญ

เอเจนต์จะเริ่มจับคู่รูปแบบเฉพาะหน้า แทนที่จะเดินตามแผนอย่างตั้งใจ

สาม มันเน่าแทบจะทันที คู่มือก้อนใหญ่กลายเป็นสุสานของกฎที่ล้าสมัย

เอเจนต์แยกไม่ออกว่าข้อไหนยังจริง คนก็เลิกดูแล แล้วไฟล์นั้นก็กลายเป็นกับดักที่รอคนมาเหยียบ

สี่ ตรวจด้วยเครื่องยาก ก้อนข้อความก้อนเดียวไม่เปิดทางให้ตรวจความครอบคลุม ความสดใหม่ หรือเจ้าของเนื้อหา

ทางออกของเขาคือเปลี่ยน AGENTS.md ให้เป็น สารบัญ [1] ยาวราว 100 บรรทัด

ชี้ไปที่โฟลเดอร์ docs/ ซึ่งเป็นแหล่งความจริงหลักของโปรเจกต์

แผนงานยังถูกยกให้เป็นชิ้นงานชั้นหนึ่งของโปรเจกต์

งานเล็กใช้แผนสั้น ๆ ที่ไม่ต้องเก็บไว้

แต่งานซับซ้อนจะถูกบันทึกเป็นแผนงานที่มีบันทึกความคืบหน้าและบันทึกการตัดสินใจ commit เข้า repo ด้วย [1][12]

เรียกว่า progressive disclosure คือให้เอเจนต์เริ่มจากจุดเข้าเล็ก ๆ ที่นิ่ง แล้วสอนว่าต่อไปควรไปดูที่ไหน

บทเรียนที่สอง: อะไรที่เอเจนต์เข้าไม่ถึง เท่ากับไม่มีอยู่จริง

หัวข้อนี้ในบทต้นทางชื่อว่า "Agent legibility is the goal" [1]

แนวคิดคือ เพราะ repo ทั้งหมดถูกสร้างโดยเอเจนต์ มันจึงถูกจัดให้เหมาะกับ การอ่านของเอเจนต์ ก่อน

เทียบได้กับการจัดโค้ดให้นักพัฒนาคนใหม่เข้าใจง่าย

แต่ต่างกันตรงที่เป้าหมายคือทำให้เอเจนต์เข้าใจโดเมนธุรกิจทั้งหมด จากตัว repo เองได้โดยตรง

ประโยคที่ผมต้องหยุดอ่านคือประโยคนี้

สิ่งที่เอเจนต์เข้าถึงไม่ได้ตอนรัน สำหรับมันแล้วเท่ากับไม่มีอยู่จริง

ความรู้ที่อยู่ใน Google Docs ในเธรดแชต หรือในหัวคน ไม่มีอยู่ในระบบของเอเจนต์

มีแต่ไฟล์ที่อยู่ใน repo และมีเวอร์ชันกำกับเท่านั้นที่มันเห็น

เขาจึงต้องดันบริบทเข้า repo มากขึ้นเรื่อย ๆ

ถ้าการคุยในแชตครั้งนั้นตกลงรูปแบบสถาปัตยกรรมกันไว้ แต่ไม่ได้เขียนลง repo

สำหรับเอเจนต์ก็เหมือนไม่เคยมีการคุยนั้น และในโค้ดเบสเดียวกันนั้นยังมีเอเจนต์ตัวอื่นอย่าง Aardvark ที่ทำงานด้วย [1][16]

ข้อสรุปนี้ทำให้ผมคิดถึงทีมตัวเองทันที

บทเรียนที่สาม: เลือกเทคโนโลยี "น่าเบื่อ" เพราะเอเจนต์อ่านง่ายกว่า

ข้อนี้ผมว่าฉลาดและดูขัดกับสัญชาตญาณ

ทีม OpenAI เลือกพึ่ง dependency และ abstraction ที่เอเจนต์สามารถ [1] เข้าใจได้ครบถ้วนจากใน repo

เทคโนโลยีที่คนเรียกว่า "น่าเบื่อ" มักจำลองง่ายกว่าสำหรับเอเจนต์

เพราะองค์ประกอบประกอบกันได้ดี API นิ่ง และมีอยู่ในข้อมูลที่โมเดลเคยเห็น

และมีตัวอย่างที่ผมชอบมาก [1]

แทนที่จะดึงแพ็กเกจช่วยจำกัด concurrency แบบสำเร็จรูป พวกเขาให้เอเจนต์เขียน helper ของตัวเองขึ้นมา

เหตุผลคือเวอร์ชันที่เขียนเองนั้นผูกกับระบบติดตามที่ทีมใช้อยู่แล้ว

มีเทสต์ครอบคลุมเต็ม และทำงานตรงตามที่รันไทม์คาดหวังเป๊ะ

บางครั้งการให้เอเจนต์เขียนของใหม่เอง ถูกกว่า การไปดัดกับไลบรารีที่เรามองไม่เห็นข้างใน

แต่ผมต้องเตือนตรงนี้ว่า วิธีคิดนี้จะอันตรายทันทีถ้าทีมคุณไม่มีเทสต์

บทเรียนที่สี่: บังคับสถาปัตยกรรมด้วย lint ที่เอเจนต์เขียนเอง

เอกสารอย่างเดียวไม่พอจะทำให้โค้ดที่เอเจนต์สร้างทั้งหมดสอดคล้องกัน

ทีม OpenAI จึงบังคับ ค่าคงที่ของระบบ [1][14] แทนการ micromanage วิธีเขียน

ตัวอย่างที่ยกมาคือ บังคับให้ Codex ตรวจรูปร่างข้อมูลที่ขอบระบบ

แต่ไม่กำหนดว่าจะทำอย่างไร หรือใช้ไลบรารีอะไร

โครงสร้างที่เขาสร้างคือ แบ่งแต่ละโดเมนธุรกิจออกเป็นชั้นตายตัว

และบังคับทิศทางการพึ่งพาระหว่างชั้นให้เดินได้ทางเดียว [13]

เรียงตามลำดับนี้

Types > Config > Repo > Service > Runtime > UI

ส่วนเรื่องที่ใช้ขวางทุกโดเมน เช่น การยืนยันตัวตน ตัวเชื่อมต่อ เทเลเมทรี และธงฟีเจอร์

ต้องเข้าทางประตูเดียวที่ประกาศไว้ชัด ชื่อ Providers

อย่างอื่นไม่อนุญาต และถูกบังคับด้วยเครื่อง

ผู้เขียนบทสรุปไว้ว่า นี่คือสถาปัตยกรรมแบบที่ปกติคุณจะรอไว้จนมีวิศวกรเป็นร้อยคน

แต่เมื่อมีเอเจนต์เขียนโค้ด มันต้องมีตั้งแต่ต้น

เพราะข้อจำกัดคือสิ่งที่ทำให้เร็วได้โดยไม่เน่า [15]

และมีรายละเอียดที่ผมว่าฉลาดมาก

lint เหล่านี้เอเจนต์เป็นคนเขียนเอง

และข้อความ error ถูกออกแบบให้ ใส่คำสั่งวิธีแก้กลับเข้าไปในบริบทของเอเจนต์ [1]

เมื่อเอเจนต์ทำผิด มันจะอ่านวิธีแก้จากข้อความ error นั้นแล้วแก้เอง

บทเรียนที่ห้า: ทิ้ง blocking merge gate

ข้อนี้คือส่วนที่จะทำให้หลายทีมไม่สบายใจ

เมื่อ throughput ของเอเจนต์สูงขึ้น บรรทัดฐานทางวิศวกรรมหลายข้อกลับกลายเป็นตัวถ่วง

ทีม OpenAI จึงลดด่านที่บล็อกการ merge ลงเหลือน้อยที่สุด [1]

ให้ pull request มีอายุสั้น

และเมื่อเทสต์ล้มแบบไม่แน่นอน เขามักสั่งรันใหม่แทนที่จะหยุดรอ

เหตุผลที่เขียนไว้คือ ในระบบที่เอเจนต์ผลิตเร็วกว่าความสนใจของมนุษย์มาก การแก้ไขถูกกว่าการรอ

และเขาก็ซื่อสัตย์พอจะเขียนกำกับว่า

วิธีนี้จะ ไม่รับผิดชอบ ถ้าอยู่ในสภาพแวดล้อมที่ throughput ต่ำ

บทเรียนที่หก: ขยะสะสมต้องเก็บเป็นงานประจำ

นี่คือส่วนที่ตรงกับประสบการณ์ของใครหลายคนที่สุด

เอเจนต์จะเลียนแบบรูปแบบที่มีอยู่แล้วใน repo แม้รูปแบบนั้นจะไม่ดี

พอนานเข้าจึงเกิดการเลื่อนไหลของมาตรฐาน

ช่วงแรกทีมใช้คนแก้

เขาเล่าไว้ว่าทุกวันศุกร์ ซึ่งคิดเป็น 20% ของสัปดาห์ หมดไปกับการเก็บกวาดสิ่งที่เรียกว่า AI slop [1]

และแน่นอนว่ามันขยายไม่ทัน

ทางออกคือเขียน golden principles ลงใน repo โดยตรง [1] แล้วสร้างงานเก็บกวาดเป็นรอบ

หลักการพวกนี้เป็นกฎเชิงกลที่ชัดเจน เช่น ให้ใช้ยูทิลิตีที่แชร์กันแทนการเขียนตัวช่วยเอง

และห้ามเดารูปร่างข้อมูล ให้ตรวจที่ขอบระบบหรือใช้ SDK ที่มีชนิดข้อมูลกำกับ

จากนั้นมีงานเบื้องหลังที่คอยสแกนหาสิ่งที่เบี่ยงออกจากหลัก

อัปเดตเกรดคุณภาพ และเปิด pull request สำหรับปรับโครงสร้าง [1]

ผู้เขียนเปรียบเทียบว่ามันทำงานเหมือนการเก็บขยะในหน่วยความจำ

หนี้ทางเทคนิคเปรียบได้กับเงินกู้ดอกเบี้ยสูง

จ่ายคืนทีละนิดเรื่อย ๆ ดีกว่าให้มันทบต้นแล้วค่อยไปจัดการทีหลังแบบเจ็บตัว

วงจรที่ครบแล้ว และคำเตือนที่ติดมา

ณ จุดหนึ่ง repo ข้ามเส้นที่มีความหมาย [1]

คือ Codex ขับเคลื่อนฟีเจอร์ใหม่ได้ครบวงจรจากคำสั่งเดียว

เริ่มจากตรวจสถานะโค้ดปัจจุบัน ทำซ้ำบั๊กที่รายงาน

อัดวิดีโอแสดงอาการพัง

แก้ แล้วอัดวิดีโอแสดงว่าหายแล้ว

เปิด pull request ตอบความเห็นของทั้งเอเจนต์และคน

ตรวจจับและซ่อม build ที่ล้ม

และส่งต่อให้คนเฉพาะเมื่อต้องใช้วิจารณญาณจริง ๆ

สุดท้ายคือ merge การเปลี่ยนแปลงนั้น

แต่ผู้เขียนกำกับไว้ชัดว่า พฤติกรรมนี้ขึ้นกับโครงสร้างและเครื่องมือของ repo นี้โดยเฉพาะ

และ ไม่ควรถือว่าทำได้เหมือนกัน ถ้าไม่ได้ลงทุนแบบเดียวกัน

อย่างน้อยก็ยังไม่ใช่ตอนนี้

ราคาที่ต้องรู้: สิ่งที่บท OpenAI ไม่ได้พูดในหัวข้อ

ถึงตรงนี้ทุกอย่างฟังดูดีเกินไป

และผมจะไม่ปล่อยให้คุณอ่านจบแบบนั้น

ชุมชนวิศวกรที่อ่านบทนี้ไม่ได้ซื้อทั้งหมด [3] และในเธรดของผู้ใช้ที่ลองสร้าง harness เอง มีคนตั้งข้อสังเกตว่าเรื่องแบบนี้มักฟังดูดีเกินจริง [17]

ข้อวิจารณ์ที่คมที่สุดคือ พวกเขาปฏิเสธ วิธีที่ OpenAI เลือกใช้พิสูจน์

หนึ่งล้านบรรทัดถูกอ่านเป็นคำเตือนเรื่องโค้ดซ้ำซ้อน [3] ความยาวเกินจำเป็น และภาระดูแลในอนาคต

ไม่ใช่หลักฐานเรื่องความสามารถ

หลายคนมองว่านั่นคือโชว์ขนาด ไม่ใช่โชว์คุณภาพ

และมีข้อเท็จจริงที่สำคัญมากโผล่ตามมาทีหลัง [3]

ผู้เขียนบทชี้แจงว่าโปรเจกต์ที่ซ่อนอยู่เป็น แอปเดสก์ท็อปแบบ Electron [3] ที่มีบริการหลังบ้านขนาดเล็ก

ไม่ใช่ระบบกระจายศูนย์ขนาดยักษ์อย่างที่หลายคนจินตนาการไปเอง [3]

และทีมใช้เวลาส่วนใหญ่ไปกับการปรับพรอมป์ ทักษะ และเอกสาร

พร้อมกับ ทิ้งงานของเอเจนต์มากกว่าครึ่ง ที่ไม่ผ่านเกณฑ์ [3]

ข้อเท็จจริงนี้ทำให้ข้ออ้างที่แข็งที่สุดแคบลงและน่าเชื่อถือขึ้น

คือถ้ามีโครงค้ำมากพอ เอเจนต์ทำความคืบหน้าในโค้ดเบสใหญ่ได้จริง

แต่มันไม่ได้ทำให้คนเชื่อว่าการพัฒนาแบบเอเจนต์เฟิร์สต์เป็นค่าตั้งต้นที่ดีสำหรับระบบที่จะอยู่นานแล้ว

และไม่ได้ทำให้ throughput ดิบกลายเป็นตัวชี้วัดคุณภาพสินค้า

อีกเรื่องที่ผมว่าสำคัญคือ อายุของคำว่า harness engineering เอง

คำนี้ไม่ได้เกิดจาก OpenAI

Mitchell Hashimoto ตั้งมันอย่างไม่เป็นทางการเมื่อ 5 กุมภาพันธ์ 2026 [4] ด้วยน้ำเสียงกึ่งขอโทษ

หกวันต่อมา OpenAI หยิบไปใช้เป็นชื่อบทสรุปใหญ่

จากนั้น Martin Fowler เขียนตามในอีกหกวัน

และในราวเจ็ดสัปดาห์ มันกลายเป็นหมวดหมู่ทางวิศวกรรมที่ถูกพูดถึงเป็นเรื่องปกติ

นักวิเคราะห์คนหนึ่งเขียนตรง ๆ ว่าไทม์ไลน์แบบนี้ [4] ควรทำให้คนอ่านสายเทคนิคระแวง

แต่เขาก็สรุปว่าการมองข้ามมันก็ผิด

คำถามที่ถูกไม่ใช่ "ของจริงหรือกระแส" แต่เป็น "หน้าต่างนี้เปิดอีกนานแค่ไหน"

คำตอบของเขาคือช่วงปี 2026 ถึง 2027 [4] ไม่ใช่คูน้ำที่ขุดไว้แล้วอยู่ตลอดไป

และที่สุด OpenAI เองก็ยอมรับไว้ในบท

เรายังไม่รู้ว่าความสอดคล้องทางสถาปัตยกรรมจะคลี่คลายอย่างไรในระยะหลายปีของระบบที่เอเจนต์สร้างทั้งหมด

ประโยคนี้สำคัญ เพราะมันคือคำถามที่ยังไม่มีคำตอบ

ของใหม่กว่าบอกอะไร (และมีชิ้นหนึ่งผมว่าน่าสนใจที่สุด)

ถ้าอ่านแค่บท OpenAI คุณจะเห็นภาพ ณ เดือนกุมภาพันธ์

แต่หลังจากนั้นมีงานอีกหลายชิ้นที่ต่อยอดและบางชิ้นก็หักล้าง

ชิ้นแรกคือ LangChain เมื่อ 17 กุมภาพันธ์ 2026 [5]

พวกเขารายงานว่าเอเจนต์ของตัวเองขยับจาก อันดับ 30 ขึ้นมาอยู่อันดับ 5 บน Terminal Bench 2.0

โดย แก้แค่ harness ไม่แตะโมเดลเลย

ชิ้นที่สองคือ Birgitta Böckeler [6] จาก Thoughtworks เขียนบนบล็อก Martin Fowler เมื่อ 2 เมษายน

เธอเสนอกรอบความคิดเรื่อง "ความเชื่อใจ" ที่ต้องสร้างกับโค้ดจาก AI

แยกเป็นสองทิศ คือการป้อนกฎล่วงหน้ากับการป้อนผลตอบกลับ

และแยกสองชนิด คือสิ่งที่ตรวจด้วยการคำนวณได้ กับสิ่งที่ต้องใช้การอนุมาน

ชิ้นที่สามคือ Addy Osmani เขียนบน O'Reilly Radar เมื่อ 15 พฤษภาคม [7]

นิยามของเขาสั้นและคมว่า เอเจนต์คือโมเดลบวกทุกอย่างที่คุณสร้างไว้รอบตัวมัน

ชิ้นที่สี่คือ Google Developers Blog เมื่อ 9 กันยายน [8]

วิศวกรของ Google สองคน คือ Principal Engineer และ Staff Software Engineer เขียนวิธีประเมิน กลั่นกรอง และเฝ้าเอเจนต์เขียนโค้ด

แต่ชิ้นที่ผมว่าน่าสนใจที่สุดคือ 13 ตุลาคม 2026

Naresh Jain เขียนบนบล็อก Martin Fowler ว่าเขาทดลอง [9] ให้เอเจนต์สร้าง API ตัวเดียวกันสองแบบ

แบบหนึ่งมี harness อีกแบบไม่มี

ผลคือโมเดลระดับแนวหน้า ผ่านทุกเกณฑ์ทั้งสองแบบ

แต่อีกโมเดลที่เน้นประหยัด สำเร็จแค่ 3 จาก 10 รอบ เมื่อไม่มี harness

พอใส่ harness เข้าไป สำเร็จ 10 จาก 10

และที่น่าสนใจคือรอบที่ใส่ harness นั้น ถูกกว่า 33% ต่อรอบ เมื่อเทียบกับโมเดลระดับแนวหน้าที่ทำได้เท่ากัน

นี่คือข้อสรุปที่ผมคิดว่ามีน้ำหนักที่สุดของทั้งวงการนี้

harness อาจเป็นทางให้ทีมคุณ ใช้โมเดลที่ถูกกว่า แทนที่จะไล่ซื้อโมเดลที่แพงกว่า

และชิ้นสุดท้ายคือ Anthropic เมื่อ 13 ตุลาคมเช่นกัน [10]

เขาเปิดว่าในเดือนพฤษภาคม 2026 บริษัทรวมโค้ดราว 2,500 ครั้งต่อวัน

พอถึงกันยายน ตัวเลขนั้นทะลุ 30,000 ครั้งต่อวัน

git กลายเป็นคอขวดจึงสร้างระบบควบคุมเวอร์ชันของตัวเองในห้าเดือน

อ่านรวมกันแล้วภาพที่ได้ชัดเจนขึ้น

ปัญหาไม่ได้อยู่ที่โมเดลอย่างเดียว และไม่ได้อยู่ที่ harness อย่างเดียว

แต่อยู่ที่ โครงสร้างพื้นฐานทั้งระบบ ที่ยังถูกออกแบบมาสำหรับมนุษย์

ถ้าคุณจะเริ่ม ห้าขั้นที่หยิบไปใช้ได้ทันที

ผมไม่แนะนำให้ใครลอกวิธี OpenAI ทั้งชุด

แต่มีห้าขั้นที่ทีมขนาดไหนก็เริ่มได้

ขั้นที่หนึ่ง: ย่อไฟล์คำสั่ง แล้วย้ายความรู้ไปไว้ในเอกสาร [13]

ลองตั้งเป้าว่าไฟล์ที่ฉีดเข้าบริบททุกครั้งควรอยู่ราวหนึ่งร้อยบรรทัด [18]

และทำหน้าที่เป็นแผนที่มากกว่าคู่มือ

ขั้นที่สอง: เขียนสิ่งที่ตกลงกันในแชตลง repo

ทุกครั้งที่ทีมตัดสินใจเรื่องสถาปัตยกรรม ให้ถามว่ามันจะอยู่ในสายตาของเอเจนต์ได้อย่างไร

ถ้าคำตอบคือ "อยู่ในหัวผม" แปลว่าเอเจนต์ไม่เห็น

ขั้นที่สาม: บังคับข้อจำกัดด้วย lint ไม่ใช่ด้วยเอกสาร

ตัวอย่างที่ทำได้ทันทีคือทิศทางการพึ่งพาระหว่างโมดูล ขนาดไฟล์สูงสุด และรูปแบบการบันทึก log

และทำให้ข้อความ error บอกวิธีแก้ด้วย ไม่ใช่แค่บอกว่าผิด

ขั้นที่สี่: ตั้งงานเก็บกวาดเป็นรอบ

คุณไม่ต้องรอให้มีทีมสิบคน เริ่มจากงานประจำสัปดาห์ที่ไล่หารูปแบบที่ไม่ควรมีแล้วเปิด PR แก้ [1]

จำไว้ว่าอย่าปล่อยให้หนี้ทางเทคนิคทบต้น

ขั้นที่ห้า: วัดสิ่งที่ควรวัด

OpenAI วัด PR ต่อคนต่อวัน แต่ชุมชนก็เตือนถูกว่าอย่าวัด throughput ดิบ [3]

ให้วัดสิ่งที่คุณจะต้องจ่ายจริง เช่น เวลาที่ใช้ทำความเข้าใจโค้ดเดิม และจำนวนครั้งที่แก้แล้วพังซ้ำ [3]

แล้วคำตอบของคำถามตั้งต้นคืออะไร

ทีม OpenAI ทำได้เพราะพวกเขา ไม่พยายามให้ AI เขียนโค้ด

พวกเขาสร้างระบบที่ทำให้การเขียนโค้ดเป็นงานที่เหลือน้อยที่สุด

ความพยายามทั้งหมดย้ายไปที่การออกแบบสภาพแวดล้อม เอกสาร และวงจรตอบกลับ

หนึ่งล้านบรรทัดไม่ใช่คำตอบ แต่เป็นผลพลอยได้

คำตอบจริงคือ ระบบที่ทำให้เอเจนต์ทำงานได้อย่างน่าเชื่อถือ

และผมคิดว่าคำถามที่คุณควรถามตัวเองไม่ใช่ "แชตบอตคุณเขียนโค้ดได้ไหม"

แต่คือ "ถ้าพรุ่งนี้คุณมีเอเจนต์สิบตัวมาช่วย ระบบของคุณพร้อมรับหรือยัง"

ถ้าคุณลองเริ่มจากห้าขั้นนี้ แล้วเจออุปสรรคหรือเจอวิธีที่ลื่นกว่าเดิม

เล่าให้ผมฟังได้เลยครับ ผมอยากรู้ว่าในบริบทของทีมคุณมันต่างจากนี้แค่ไหน

บทความหน้าผมจะพาไปดูฝั่งตรงข้ามบ้าง คือทีมที่ลองแล้วบอกว่า harness ไม่ได้ช่วยอะไร เพราะเรื่องนั้นก็มี และน่าสนใจพอ ๆ กัน

แหล่งอ้างอิง

[1] Ryan Lopopolo, "Harness engineering: leveraging Codex in an agent-first world" (OpenAI, 11 กุมภาพันธ์ 2026 · ทีมสามวิศวกร · หนึ่งล้านบรรทัด · 1,500 PR · 3.5 PR ต่อคนต่อวัน · เร็วเป็นหนึ่งในสิบของเวลา · AGENTS.md เป็นสารบัญ 100 บรรทัด · golden principles · คำยอมรับว่ายังไม่รู้เรื่องความสอดคล้องระยะยาว), เข้าถึง 18 ตุลาคม 2026. https://openai.com/index/harness-engineering/

[2] Celia Chen, "Unlocking the Codex harness: how we built the App Server" (OpenAI, 4 กุมภาพันธ์ 2026 · อธิบายว่า Codex ทุกหน้าจอใช้ harness ตัวเดียวกัน), เข้าถึง 18 ตุลาคม 2026. https://openai.com/index/unlocking-the-codex-harness/

[3] HN Debrief, "Harness engineering: Leveraging Codex in an agent-first world" (สรุปปฏิกิริยาชุมชนวิศวกร · วิจารณ์ว่าหนึ่งล้านบรรทัดถูกอ่านเป็นโชว์ขนาดไม่ใช่โชว์คุณภาพ · ระบุว่าโปรเจกต์จริงเป็นแอป Electron · ทีมทิ้งงานเอเจนต์มากกว่าครึ่ง), 7 มิถุนายน 2026. http://hndebrief.com/2026-06-07/harness-engineering-leveraging-codex-in-an-agent-first-world

[4] Bruce, "Harness Engineering: Window of Opportunity, Not a Forever Moat" (ไทม์ไลน์ของคำว่า harness engineering ตั้งแต่ Mitchell Hashimoto 5 กุมภาพันธ์ 2026 ถึง Anthropic 24 มีนาคม · ข้อสรุปว่าหน้าต่างเปิดปี 2026 ถึง 2027), 8 พฤษภาคม 2026. https://heyuan110.com/posts/ai/2026-05-08-harness-engineering-window-of-opportunity

[5] Vivek Trivedy, "Improving Deep Agents with harness engineering" (LangChain · เอเจนต์ขยับจากอันดับ 30 ขึ้นอันดับ 5 บน Terminal Bench 2.0 โดยแก้แค่ harness), 17 กุมภาพันธ์ 2026. https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering

[6] Birgitta Böckeler, "Harness engineering for coding agent users" (Martin Fowler บล็อก · กรอบความคิดเรื่องความเชื่อใจกับโค้ดจาก AI · การป้อนกฎล่วงหน้ากับผลตอบกลับ · สิ่งที่คำนวณได้กับสิ่งที่ต้องอนุมาน), 2 เมษายน 2026. https://www.martinfowler.com/articles/harness-engineering.html

[7] Addy Osmani, "Agent Harness Engineering" (O'Reilly Radar · นิยามว่าเอเจนต์คือโมเดลบวกทุกอย่างที่สร้างไว้รอบตัว), 15 พฤษภาคม 2026. https://www.oreilly.com/radar/agent-harness-engineering/

[8] Taylor Mullen และ Christian Gunderman, "The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents" (Google Developers Blog), 9 กันยายน 2026. https://developers.googleblog.com/the-anatomy-of-harness-engineering-how-to-evaluate-iterate-and-guard-ai-coding-agents/

[9] Naresh Jain, "Are Harnesses Worth the Cost?" (Martin Fowler บล็อก · ทดลอง API เดียวกันมีและไม่มี harness · โมเดลประหยัดสำเร็จ 3 จาก 10 รอบเมื่อไม่มี harness และ 10 จาก 10 เมื่อมี · ถูกกว่าราว 33% ต่อรอบ), 13 ตุลาคม 2026. https://martinfowler.com/articles/are-harnesses-worth-the-cost.html

[10] Anthropic Engineering, "Redesigning source control at Anthropic" (โค้ดที่รวมต่อวันจาก 2,500 ครั้งในเดือนพฤษภาคม เป็นมากกว่า 30,000 ครั้งในเดือนกันยายน · ย้ายมาระบบควบคุมเวอร์ชันของตัวเองในห้าเดือน), 13 ตุลาคม 2026. https://www.anthropic.com/engineering/redesigning-source-control

[11] agents.md, "AGENTS.md" (ฟอร์แมตเปิดสำหรับไฟล์คำสั่งของเอเจนต์ ที่ระบุว่ามีโปรเจกต์โอเพนซอร์สใช้อยู่กว่า 60,000 โปรเจกต์), เข้าถึง 18 ตุลาคม 2026. https://agents.md/

[12] Aaron Friel, "Using PLANS.md for multi-hour problem solving" (OpenAI Cookbook · แผนงานแบบมีบันทึกความคืบหน้าและบันทึกการตัดสินใจ · หน้าเขียนกำกับว่าเป็นสูตรที่เก็บเข้าคลัง), 7 ตุลาคม 2025. https://cookbook.openai.com/articles/codex_exec_plans

[13] Matklad, "ARCHITECTURE.md" (แนวคิดเอกสารแผนที่สถาปัตยกรรมระดับบนสุด), 6 กุมภาพันธ์ 2021. https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html

[14] Alexis King, "Parse, don't validate" (แนวคิดตรวจรูปร่างข้อมูลที่ขอบระบบซึ่งทีม OpenAI นำไปบังคับใช้), 5 พฤศจิกายน 2019. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

[15] Steve Krenzel, "AI is forcing us to write good code" (Bits of Logic · ข้อสังเกตว่าเอเจนต์ทำงานได้ดีที่สุดเมื่อสภาพแวดล้อมมีขอบเขตชัดเจนและโครงสร้างคาดเดาได้), 29 ธันวาคม 2025. https://bits.logic.inc/p/ai-is-forcing-us-to-write-good-code

[16] OpenAI, "Introducing Aardvark" (เอเจนต์ความปลอดภัยของ OpenAI ที่เชื่อมกับ Codex · ถ้อยเรื่องโค้ดเบสเดียวกันระบุใน [1] ไม่ได้อยู่ในหน้านี้), เข้าถึง 18 ตุลาคม 2026. https://openai.com/index/introducing-aardvark/

[17] สมาชิก r/ClaudeAI, "My wife kept nagging me so I built a harness to..." (บันทึกของผู้ใช้ที่สร้าง harness เอง และความเห็นที่ระแวงว่าเรื่องแบบนี้มักดีเกินจริง), 2026. https://www.reddit.com/r/ClaudeAI/comments/1rllmzu/my_wife_kept_nagging_me_so_i_built_a_harness_to/

[18] Ken Imoto, "OpenAI Codex Shipped 1M Lines From AGENTS.md: 3 Harness Lessons That Beat Model Swaps" (บันทึกของนักพัฒนาที่ลองใช้บทเรียนสามข้อจากบท OpenAI ในงานจริง · ลิงก์ต้นทางที่ kenimoto.dev ตอบ 404 ณ วันที่ตรวจ จึงใช้สำเนาของผู้เขียนเองบน dev.to), 21 กรกฎาคม 2026. https://dev.to/kenimo49/openai-codex-shipped-1m-lines-from-agentsmd-3-harness-lessons-that-beat-model-swaps-311m