OpenAI Harness Engineering: สร้างผลิตภัณฑ์ด้วยโค้ด 0 บรรทัดจากมือคน

OpenAI เพิ่งเผยแพร่บทความจากทีมวิศวกรรมภายในที่น่าจับตามากที่สุดชิ้นหนึ่งของปีนี้ — ไม่ใช่เพราะเปิดตัวโมเดลใหม่ แต่เพราะมันเล่าประสบการณ์สร้างผลิตภัณฑ์จริงด้วยโค้ดที่เขียนด้วยมือคนทั้งหมดศูนย์บรรทัด

ทีมของ Ryan Lopopolo สร้างผลิตภัณฑ์ซอฟต์แวร์ตัวหนึ่งที่มีผู้ใช้งานภายใน OpenAI ใช้ทุกวัน และมี alpha tester ภายนอก โดยใช้เวลา 5 เดือน สร้างโค้ดรวมประมาณ 1 ล้านบรรทัด ผ่าน pull request กว่า 1,500 รายการ ทีม engineer เริ่มต้นแค่ 3 คน และตอนนี้ขยายเป็น 7 คน

ตัวเลขเหล่านี้น่าทึ่ง แต่สิ่งที่สำคัญกว่าคือสิ่งที่พวกเขาเรียนรู้เกี่ยวกับการทำงานในโลกที่ engineer ไม่ได้เขียนโค้ดอีกต่อไป

จาก “คนเขียนโค้ด” สู่ “คนออกแบบสภาพแวดล้อม”

ทีมนี้ตั้งกฎให้ตัวเองตั้งแต่วันแรก: ไม่มีโค้ดที่เขียนด้วยมือคน เลย

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

ผลที่ได้คืองานของ engineer เปลี่ยนไปอย่างสิ้นเชิง จากการเขียนโค้ด กลายเป็นการออกแบบสภาพแวดล้อม กำหนด intent และสร้าง feedback loop ที่ทำให้ Codex agent ทำงานได้อย่างน่าเชื่อถือ

ช่วงแรกความคืบหน้าช้ากว่าที่คิด ไม่ใช่เพราะ Codex ไม่เก่ง แต่เพราะสภาพแวดล้อมยังไม่ได้ถูกกำหนดอย่างละเอียดพอ Agent ขาดเครื่องมือ abstraction และโครงสร้างภายในที่จำเป็นต้องมีก่อนจะทำงานที่ซับซ้อนได้

วิธีแก้ไม่ใช่ “พยายามให้หนักขึ้น” แต่เป็นการถามว่า “ความสามารถอะไรขาดหายไป และเราจะทำให้ agent เข้าใจและปฏิบัติตามได้อย่างไร”

ทำให้ทุกอย่าง legible กับ agent

เมื่อปริมาณโค้ดเพิ่มขึ้น bottleneck กลายเป็น QA ที่ต้องใช้มนุษย์ตรวจสอบ ทีมจึงพยายามทำให้ตัวแอพเอง UI logs และ metrics สามารถอ่านและเข้าใจได้โดยตรงจาก Codex

พวกเขาทำให้แอพสามารถรันได้ในแต่ละ git worktree ดังนั้น Codex จึงเปิดและควบคุม instance ของแอพได้ทีละการเปลี่ยนแปลง พวกเขาเชื่อม Chrome DevTools Protocol เข้ากับ agent runtime และสร้าง skill สำหรับทำงานกับ DOM snapshots screenshots และ navigation

สิ่งนี้ทำให้ Codex สามารถ reproduce bug ตรวจสอบการแก้ไข และคิดเหตุผลเกี่ยวกับพฤติกรรมของ UI ได้โดยตรง

สำหรับ observability พวกเขาสร้าง local observability stack ที่ถูกสร้างและทำลายตามแต่ละ worktree Logs metrics และ traces เปิดให้ agent query ได้ผ่าน LogQL และ PromQL

พร้อม context นี้ prompt แบบ “ensure service startup completes in under 800ms” หรือ “no span in these four critical user journeys exceeds two seconds” กลายเป็นเรื่องที่ agent สามารถทำได้จริง

ทีมพบว่า Codex สามารถทำงานกับงานเดียวต่อเนื่องได้นานกว่า 6 ชั่วโมง บ่อยครั้งในขณะที่มนุษย์นอนหลับอยู่

Repository knowledge คือ system of record

หนึ่งในบทเรียนสำคัญที่สุดคือการจัดการ context พวกเขาลองใช้ AGENTS.md ยาวๆ แต่ล้มเหลวในทางที่คาดได้ — context มีจำกัด คู่มือยักษ์กลืนเนื้อที่ที่ควรจะเป็น task และโค้ด คำแนะนำที่มากเกินไปกลายเป็นคำแนะนำที่ไม่มีประโยชน์ และเอกสารยักษ์เน่าเสียเร็ว

แทนที่จะใช้ AGENTS.md เป็นสารานุกรม พวกเขาใช้มันเป็นสารบัญ ความรู้ทั้งหมดอยู่ในโครงสร้าง docs/ ที่เป็นระบบ โดยมี AGENTS.md สั้นๆ ประมาณ 100 บรรทัด ชี้ไปยังแหล่งข้อมูลที่ละเอียดกว่า

โครงสร้างประกอบด้วย:

• design-docs/ — เอกสารออกแบบที่มีการจัดทำดัชนีและตรวจสอบสถานะ
• exec-plans/ — แผนการดำเนินงานที่ versioned ทั้ง active completed และ technical debt
• product-specs/ — สเปกผลิตภัณฑ์
• references/ — เอกสารอ้างอิงสำหรับเทคโนโลยีต่างๆ
• เอกสารเฉพาะทาง: DESIGN.md FRONTEND.md PLANS.md PRODUCT_SENSE.md QUALITY_SCORE.md RELIABILITY.md SECURITY.md

สิ่งนี้ช่วยให้ agent เริ่มต้นจากจุดที่เล็กและมั่นคง แล้วค่อยๆ ค้นหาข้อมูลเพิ่มเติมตามต้องการ แทนที่จะถูกท่วมท้นตั้งแต่ต้น

พวกเขายัง enforce กลไกนี้ทางเทคนิค linter และ CI job ตรวจสอบว่าฐานความรู้ up-to-date cross-linked และมีโครงสร้างถูกต้อง agent ที่ทำหน้าที่ “doc-gardening” สแกนหาเอกสารที่ล้าสมัยและเปิด fix-up PR อัตโนมัติ

Agent legibility คือเป้าหมาย

เพราะ repo ทั้งหมดถูกสร้างโดย agent มันถูก optimize ให้ Codex อ่านเข้าใจได้ก่อน จากมุมมองของ agent สิ่งที่ไม่สามารถเข้าถึงได้ใน context ขณะทำงาน = ไม่มีอยู่จริง

ความรู้ที่อยู่ใน Google Docs chat threads หรือในหัวของคน ไม่สามารถเข้าถึงได้โดยระบบ สิ่งที่ agent เห็นได้มีแค่สิ่งที่อยู่ใน repo — code markdown schemas executable plans

การให้ Codex มี context มากขึ้นหมายถึงการจัดระเบียบและเปิดเผยข้อมูลที่ถูกต้อง เพื่อให้ agent สามารถคิดเหตุผลได้ ไม่ใช่การท่วมท้นด้วยคำสั่งแบบ ad-hoc

ทีมเลือกใช้เทคโนโลยีที่ agent สามารถ internalize และคิดเหตุผลได้ใน repo เทคโนโลยีที่ “ธรรมดา” มักจะง่ายต่อการ model โดย agent เนื่องจาก composability API stability และ representation ใน training set

ในบางกรณี การให้ agent implement ฟังก์ชันเองถูกกว่าการใช้ library ภายนอกที่มีพฤติกรรมที่ไม่โปร่งใส ตัวอย่างเช่น พวกเขา implement helper สำหรับ map-with-concurrency เองแทนที่จะใช้ p-limit จากภายนอก — เพราะ integrate กับ OpenTelemetry ได้ลึกกว่า มี test coverage 100% และมีพฤติกรรมตรงกับที่ runtime ต้องการ

Enforce architecture ไม่ใช่ micromanage

เอกสารอย่างเดียวไม่พอที่จะรักษาความสอดคล้องของ codebase ที่สร้างโดย agent ทั้งหมด ทีมจึง enforce invariant ไม่ใช่การควบคุมรายละเอียดของการ implement

ตัวอย่างเช่น พวกเขาบังคับให้ Codex parse data shapes ที่ boundary แต่ไม่บังคับว่าต้องใช้วิธีไหน (โมเดลดูจะชอบ Zod แต่พวกเขาไม่ได้ specify library นั้น)

Agent มีประสิทธิภาพสูงสุดในสภาพแวดล้อมที่มีขอบเขตชัดเจนและโครงสร้างคาดเดาได้ ทีมจึงสร้าง architectural model ที่ rigid แต่ละ business domain แบ่งเป็น layer คงที่ ด้วย dependency direction ที่ถูก validate อย่างเข้มงวดและชุด edge ที่อนุญาตอย่างจำกัด

กฎคือ: ภายในแต่ละ domain (เช่น App Settings) โค้ดสามารถพึ่งพาได้เฉพาะ “forward” ผ่าน layer คงที่เท่านั้น Types → Config → Repo → Service → Runtime → UI Cross-cutting concerns (auth connectors telemetry feature flags) เข้าทาง interface ที่ชัดเจนเพียงจุดเดียว: Providers สิ่งอื่นไม่ได้รับอนุญาตและถูก enforce ทางกลไก

นี่คือ architecture ที่ปกติทีมจะเลื่อนไปทำตอนมี engineer เป็นพัน แต่กับ coding agents มันเป็น prerequisite ตั้งแต่เนิ่นๆ — constraints คือสิ่งที่ทำให้ speed ไม่กลายเป็น decay หรือ architectural drift

การ enforce ใช้ custom linters และ structural tests รวมถึง “taste invariants” เช่น structured logging naming conventions file size limits และ platform-specific reliability requirements lint ที่ custom ถูกเขียนให้ error messages มี remediation instructions ที่ inject เข้าไปใน agent context ได้โดยตรง

ใน workflow ที่มนุษย์เป็นหลัก กฎเหล่านี้อาจดู pedantic แต่กับ agents มันกลายเป็นตัวคูณ — เมื่อ encode แล้วมันใช้ได้ทุกที่พร้อมกัน

Throughput เปลี่ยนปรัชญาการ merge

เมื่อ throughput ของ Codex เพิ่มขึ้น norm ของวิศวกรรมแบบเดิมกลับกลายเป็นสิ่งที่ counterproductive

Repo นี้ทำงานด้วย minimal blocking merge gates Pull requests มีอายุสั้น test flakes มักจะแก้ด้วย follow-up run แทนที่จะ block ไว้ตลอดกาล ในระบบที่ throughput ของ agent เกินกว่ามนุษย์จะตรวจสอบได้ การแก้ไขถูกกว่าการรอ

นี่จะเป็นการประมาทใน environment ที่ throughput ต่ำ แต่ที่นี่มักจะเป็น tradeoff ที่ถูกต้อง

Autonomy ที่เพิ่มขึ้น

เมื่อ development loop ถูก encode เข้าไปในระบบ — testing validation review feedback handling recovery — repo นี้ข้าม threshold ที่สำคัญ: Codex สามารถ drive feature ใหม่จากต้นจนจบได้

จาก prompt เดียว agent สามารถ:

• Validate state ของ codebase
• Reproduce bug ที่ถูก report
• บันทึก video แสดงความล้มเหลว
• Implement การแก้ไข
• Validate การแก้ไขโดยการควบคุมแอพ
• บันทึก video แสดงว่าแก้ได้
• เปิด pull request
• ตอบ feedback จาก agent และมนุษย์
• Detect และแก้ build failures
• Escalate ไปหามนุษย์เมื่อต้องการ judgment
• Merge การเปลี่ยนแปลง

พฤติกรรมนี้ขึ้นอยู่กับโครงสร้างและเครื่องมือเฉพาะของ repo นี้ และไม่ควรสมมติว่าจะ generalize ได้โดยไม่มีการลงทุนในระดับเดียวกัน — อย่างน้อยก็ยังไม่

Entropy และ garbage collection

ความเป็นอิสระของ agent นำปัญหาใหม่มาด้วย Codex จะ copy pattern ที่มีอยู่ใน repo แม้จะไม่สมบูรณ์หรือไม่ดีที่สุด ตามเวลา สิ่งนี้นำไปสู่ drift

ช่วงแรกทีมใช้เวลาทุกวันศุกร์ (20% ของสัปดาห์) ทำความสะอาด “AI slop” แน่นอนว่าวิธีนี้ไม่ scale

แทนที่จะทำเอง พวกเขา encode “golden principles” เข้าไปใน repo และสร้างกระบวนการ cleanup ที่เกิดขึ้นประจำ หลักการเหล่านี้เป็นกฎ mechanical ที่รักษาความสอดคล้องของ codebase ตัวอย่างเช่น:

1. ชอบ shared utility packages มากกว่า hand-rolled helpers เพื่อให้ invariant อยู่รวมกัน
2. ไม่ probe data “YOLO-style” — validate boundaries หรือพึ่ง typed SDKs เพื่อ agent ไม่สร้างบน guessed shapes โดยไม่ได้ตั้งใจ

เป็นประจำ background Codex tasks สแกนหา deviation อัปเดต quality grades และเปิด refactoring PR ที่ targeted ส่วนใหญ่สามารถ review ในเวลาน้อยกว่านาทีและ automerge ได้

นี่ทำงานเหมือน garbage collection technical debt เป็นเหมือนเงินก้อนดอกเบี้ยสูง — จ่ายทีละนิดต่อเนื่องดีกว่าปล่อยให้สะสมแล้วมาเจ็บตัวทีหลัง taste ของมนุษย์ถูก capture ครั้งเดียว แล้ว enforce อย่างต่อเนื่องในทุกบรรทัดโค้ด

สิ่งที่ยังไม่รู้

กลยุทธ์นี้ใช้ได้ดีจนถึง internal launch และ adoption ภายใน OpenAI การสร้างผลิตภัณฑ์จริงที่มีผู้ใช้งานจริงช่วย anchor การลงทุนให้สอดคล้องกับความเป็นจริงและนำทางไปสู่ maintainability ระยะยาว

สิ่งที่ยังไม่ทราบคือ:

• ความสอดคล้องของ architecture จะพัฒนาอย่างไรเมื่อเวลาผ่านไปหลายปีในระบบที่สร้างโดย agent ทั้งหมด
• Human judgment เพิ่ม leverage ได้มากที่สุดตรงไหน และจะ encode มันได้อย่างไร
• ระบบนี้จะพัฒนาอย่างไรเมื่อโมเดลมีความสามารถเพิ่มขึ้นเรื่อยๆ

สิ่งที่ชัดเจนแล้วคือ การสร้างซอฟต์แวร์ยังต้องการ discipline แต่ discipline นั้นแสดงออกในการออกแบบสภาพแวดล้อมที่ agent ทำงานได้ดี มากกว่าการเขียนโค้ดให้ดีด้วยตัวเอง

นี่หมายความว่าอย่างไรสำหรับทีมอื่น

ประสบการณ์ของ OpenAI ไม่ใช่ blueprint ที่ทีมอื่นสามารถ copy ได้ทันที แต่เป็นภาพต้นแบบของสิ่งที่อาจเกิดขึ้นในอีก 2-3 ปีข้างหน้า

สิ่งที่ทีมอื่นสามารถเริ่มทำได้ตั้งแต่ตอนนี้:

1) สร้าง repository knowledge ที่เป็นระบบ อย่าให้ความรู้อยู่กระจัดกระจายใน chat Google Docs หรือหัวของคนเก่งๆ แต่ละคน ให้ agent เข้าถึงได้

2) Enforce architecture ทางกลไก ไม่ใช่ด้วยคำสั่ง linter structural tests และ invariants ที่เขียนเป็น code จะ scale ได้ดีกว่าการ review ด้วยตา

3) ทำให้ทุกอย่าง legible กับ agent ถ้า agent ไม่สามารถอ่าน logs metrics หรือ UI ได้โดยตรง มันจะติด bottleneck ที่มนุษย์ตลอด

4) คิดใหม่เรื่อง merge philosophy ในโลกที่ agent สร้างโค้ดเร็วกว่ามนุษย์ตรวจสอบ การแก้ไขถูกกว่าการรอให้ perfect ก่อน merge

5) สร้าง garbage collection เป็นระบบ อย่ารอให้ technical debt สะสม แต่ให้ agent สแกนและแก้ไขอย่างต่อเนื่อง

นี่ไม่ใช่การทำนายว่า engineer จะหายไป แต่เป็นการบอกว่าบทบาทของ engineer กำลังเปลี่ยนไป — จากคนเขียนโค้ด สู่คนออกแบบระบบที่ agent ทำงานได้อย่างมีประสิทธิภาพ

และสำหรับทีมที่เคยทำ digital transformation หรือสร้าง data platform มาก่อน นี่อาจฟังคุ้นๆ — มันไม่ต่างจากการเปลี่ยนจาก “คนทำงาน manual” สู่ “คนออกแบบระบบที่ทำงานอัตโนมัติ” แค่ครั้งนี้งานที่ถูก automate คือการเขียนโค้ดเอง

FAQ

Q: นี่หมายความว่า engineer จะไม่ต้องเขียนโค้ดอีกต่อไปหรือไม่ A: ไม่ใช่ แต่บทบาทหลักเปลี่ยนจากการเขียนโค้ด เป็นการออกแบบสภาพแวดล้อม กำหนด intent และสร้าง feedback loop ให้ agent ทำงานได้อย่างน่าเชื่อถือ ในกรณีของ OpenAI ทีม 3-7 คนสร้างผลิตภัณฑ์ที่ต้องใช้ engineer หลายสิบคนถ้าทำแบบเดิม

Q: ทีมเล็กๆ สามารถทำแบบนี้ได้ไหม A: ได้บางส่วน แต่ต้องลงทุนใน infrastructure ที่ agent ต้องการ ไม่ใช่แค่ซื้อ subscription Codex แล้วหวังว่ามันจะทำทุกอย่างให้ สภาพแวดล้อมต้องถูกออกแบบมาเพื่อ agent

Q: คุณภาพโค้ดที่ agent สร้างเป็นอย่างไร A: ไม่ตรงกับ stylistic preference ของมนุษย์เสมอ แต่ถูกต้อง maintainable และ legible สำหรับ agent run ครั้งต่อไป ทีมยอมรับว่าผลลัพธ์ไม่ต้อง perfect แต่ต้อง correct และ maintainable

Q: อะไรคือ bottleneck ที่ยังเหลืออยู่ A: Human judgment และ QA capacity ยังเป็นทรัพยากรที่หายาก นอกจากนั้นยังไม่รู้ว่า architectural coherence จะเป็นยังไงเมื่อระบบมีอายุเป็นปี และยังไม่รู้ว่าจะ encode human judgment ได้ดีแค่ไหน

Q: มีอะไรที่ agent ยังทำไม่ได้ A: การตัดสินใจที่ต้องใช้ judgment ยังต้อง escalate ไปหามนุษย์ นอกจากนั้นการ generalize ประสบการณ์นี้ไปยัง repo อื่นต้องการการลงทุนในระดับเดียวกัน — อย่างน้อยก็ในตอนนี้