Harness Engineering: ใช้งาน Codex ในโลกที่ให้เอเจนต์มาก่อน

• กรณีทดลองที่ทีมภายในของ OpenAI สร้างและเปิดตัว internal beta ของผลิตภัณฑ์ซอฟต์แวร์โดย ไม่เขียนโค้ดด้วยมือเป็นเวลา 5 เดือน โดยโค้ดทั้งหมดถูกสร้างโดยเอเจนต์ Codex
• เริ่มต้นด้วยวิศวกร 3 คน และจัดการโค้ดประมาณ 1 ล้านบรรทัด กับ pull request 1,500 รายการ โดยเฉลี่ยวิศวกร 1 คน merge PR ได้ 3.5 รายการต่อวัน
• บทบาทของวิศวกรเปลี่ยนจากการเขียนโค้ดโดยตรงไปเป็น การออกแบบสภาพแวดล้อม การระบุเจตนา และการสร้าง feedback loop โดยหัวใจสำคัญคือการสร้าง scaffolding ที่ทำให้เอเจนต์ทำงานได้อย่างเสถียร
• ใช้ AGENTS.md เป็น สารบัญ ไม่ใช่สารานุกรม และบังคับใช้ความสอดคล้องของสถาปัตยกรรมแบบเชิงกลผ่านเอกสารที่มีโครงสร้าง, linter และ structural tests
• ยิ่งเอเจนต์มีความเป็นอิสระสูงขึ้น ก็ยิ่งต้องมี การจัดการ entropy และการเก็บกวาดอย่างต่อเนื่องแบบ garbage collection โดยระเบียบวินัยของการสร้างซอฟต์แวร์กำลังย้ายจากตัวโค้ดไปอยู่ที่ scaffolding

---

การทดลองที่เริ่มจาก git repository ว่างเปล่า

• ปลายเดือนสิงหาคม 2025 มีการทำคอมมิตแรกใน repository ที่ว่างเปล่า โดย scaffolding เริ่มต้น (โครงสร้าง repository, การตั้งค่า CI, กฎการจัดรูปแบบ, การตั้งค่า package manager, application framework) ถูกสร้างใน Codex CLI โดยใช้ GPT-5 บนพื้นฐานของเทมเพลตที่มีอยู่เดิม
• ไฟล์ AGENTS.md เริ่มต้นที่ใช้บอกเอเจนต์ว่าจะทำงานกับ repository อย่างไรก็ถูก Codex เขียนขึ้นเองโดยตรง
• ตั้งแต่ต้น repository นี้ถูกก่อร่างโดยเอเจนต์ โดยไม่มีโค้ดเดิมที่มนุษย์เขียนไว้ก่อน
• หลังผ่านไป 5 เดือน มีโค้ดประมาณ 1 ล้านบรรทัด ครอบคลุม application logic, infrastructure, tooling, documentation และ internal developer utility
• ทีมขนาดเล็ก 3 คนเปิดและ merge pull request ราว 1,500 รายการ คิดเป็นอัตราเฉลี่ย 3.5 PR ต่อวันต่อวิศวกร 1 คน
• เมื่อทีมขยายเป็น 7 คน throughput กลับยิ่งเพิ่มขึ้น
• มีผู้ใช้หลายร้อยคนใช้งานภายในทุกวัน รวมถึงผู้ใช้ระดับ power user ภายในองค์กร
• ตลอดกระบวนการพัฒนา มนุษย์ไม่เคยมีส่วนร่วมกับโค้ดโดยตรง
• "ไม่มีโค้ดที่เขียนด้วยมือ" กลายเป็นปรัชญาหลักของทีม

นิยามบทบาทของวิศวกรใหม่

• เมื่อมนุษย์ไม่ได้เขียนโค้ดเองโดยตรง จึงต้องมีงานวิศวกรรมคนละแบบที่เน้น ระบบ, scaffolding และ leverage
• เหตุผลที่ช่วงแรกดำเนินไปช้ากว่าที่คาด ไม่ใช่เพราะ Codex ขาดความสามารถ แต่เพราะ สภาพแวดล้อมยังไม่พร้อม
  • เอเจนต์ยังขาดเครื่องมือ abstraction และโครงสร้างภายในที่จะช่วยให้บรรลุเป้าหมายระดับสูง
• งานหลักของทีมวิศวกรรมจึงเปลี่ยนไปเป็นการสนับสนุนให้เอเจนต์ทำงานที่มีประโยชน์ได้
• แยกเป้าหมายใหญ่ให้เป็น building block ขนาดเล็กกว่า (การออกแบบ, โค้ด, การรีวิว, การทดสอบ ฯลฯ) และให้เอเจนต์ประกอบบล็อกเหล่านี้ก่อนจะไปแก้งานที่ซับซ้อนขึ้น ในรูปแบบการทำงานแบบ depth-first
• เมื่อเกิดความล้มเหลว คำถามสำคัญไม่ใช่ "พยายามให้มากขึ้น" แต่คือ "มีความสามารถอะไรที่ยังขาดอยู่ และต้องทำอย่างไรให้เอเจนต์อ่านเข้าใจและลงมือทำได้"
• มนุษย์โต้ตอบกับระบบแทบทั้งหมดผ่าน prompt
  • สั่งอธิบายงาน, รันเอเจนต์, เปิด pull request เป็นต้น
• เพื่อให้ PR เสร็จสมบูรณ์ จะสั่งให้ Codex ตรวจทานการเปลี่ยนแปลงของตัวเองบนเครื่อง, ขอเพิ่ม agent review ทั้งใน local และ cloud, ตอบ feedback และวนซ้ำจนผู้รีวิวที่เป็นเอเจนต์ทั้งหมดพอใจ
  • โดยพื้นฐานคือแนวทางแบบ Ralph Wiggum Loop
• Codex ใช้เครื่องมือพัฒนามาตรฐานโดยตรง เช่น gh, local scripts และ skills ที่ฝังอยู่ใน repository เพื่อรวบรวม context
• มนุษย์ยังสามารถรีวิว pull request ได้ แต่ไม่ใช่สิ่งจำเป็น และเมื่อเวลาผ่านไป งานรีวิวเกือบทั้งหมดถูกเปลี่ยนเป็นการ ให้เอเจนต์รีวิวกันเอง

เพิ่มความสามารถในการอ่านแอปพลิเคชัน

• เมื่อ throughput ของโค้ดเพิ่มขึ้น ก็เกิดคอขวดที่ ความสามารถด้าน QA ของมนุษย์
• เนื่องจากเวลาและความสนใจของมนุษย์เป็นข้อจำกัดตายตัว ทีมจึงเพิ่มความสามารถให้เอเจนต์โดยทำให้ Codex อ่านและเข้าใจ UI ของแอป, logs, app metrics ฯลฯ ได้โดยตรง
• ด้วยความสามารถ บูตแอปแยกตาม git worktree ทำให้ Codex รันและควบคุมอินสแตนซ์แยกสำหรับแต่ละชุดการเปลี่ยนแปลงได้
• เชื่อม Chrome DevTools Protocol เข้ากับ agent runtime และสร้าง skills สำหรับ DOM snapshot, screenshots และงานนำทาง
  • ทำให้ Codex สามารถ reproduce บั๊ก, ตรวจยืนยันการแก้ไข และให้เหตุผลเกี่ยวกับพฤติกรรมของ UI ได้โดยตรง
• tooling ด้าน observability ก็ใช้แนวทางเดียวกัน
  • logs, metrics และ traces ถูกเปิดให้ Codex ใช้ผ่าน local observability stack ที่อยู่ชั่วคราวสำหรับแต่ละ worktree
  • เมื่องานเสร็จ logs และ metrics จะถูกลบ
  • เอเจนต์สามารถ query logs ด้วย LogQL และ query metrics ด้วย PromQL
• เมื่อมี context เหล่านี้ ก็จะจัดการ prompt อย่างเช่นให้ "service start เสร็จภายใน 800ms" หรือ "ไม่มี span ใดใน 4 user journey หลักเกิน 2 วินาที" ได้ง่ายขึ้น
• Codex หนึ่งครั้งสามารถทำงานเรื่องเดียวต่อเนื่องได้นานกว่า 6 ชั่วโมง (บ่อยครั้งระหว่างที่มนุษย์กำลังนอน)

ใช้ความรู้ใน repository เป็นระบบบันทึก

• การจัดการ context เป็นหนึ่งใน ความท้าทายใหญ่ที่สุด ที่ทำให้เอเจนต์ทำงานขนาดใหญ่และซับซ้อนได้อย่างมีประสิทธิภาพ
• บทเรียนช่วงแรกคือ ต้อง ให้แผนที่กับ Codex ไม่ใช่คู่มือ 1,000 หน้า
• พวกเขาเคยลองแนวทาง "AGENTS.md ไฟล์ใหญ่ไฟล์เดียว" แล้วล้มเหลวอย่างคาดเดาได้
  • context เป็นทรัพยากรที่มีจำกัด: ไฟล์คำสั่งขนาดใหญ่ทำให้งาน, โค้ด และเอกสารที่เกี่ยวข้องซับซ้อนขึ้น จนเอเจนต์พลาดข้อจำกัดสำคัญหรือไป optimize กับข้อจำกัดที่ผิด
  • ถ้าคำสั่งมีมากเกินไป มันก็ไม่ใช่คำสั่งอีกต่อไป: เมื่อทุกอย่าง "สำคัญ" ก็ไม่มีอะไรสำคัญ เอเจนต์จะทำ local pattern matching แทนการสำรวจอย่างมีเจตนา
  • พังอย่างรวดเร็ว: คู่มือใหญ่แบบเหมารวมจะกลายเป็นสุสานของกฎที่ล้าสมัย และเอเจนต์ไม่สามารถตัดสินได้ว่าอะไรยังใช้ได้อยู่
  • ตรวจสอบได้ยาก: blob เดียวไม่เหมาะกับการตรวจเชิงกล (coverage, freshness, ownership, cross-linking) ทำให้ drift เกิดขึ้นอย่างหลีกเลี่ยงไม่ได้
• วิธีแก้คือมอง AGENTS.md เป็น สารบัญ ไม่ใช่สารานุกรม
• ฐานความรู้ของ repository ถูกจัดการเป็น ระบบบันทึก ในไดเรกทอรี docs/ ที่มีโครงสร้าง
• AGENTS.md แบบสั้น (ประมาณ 100 บรรทัด) จะถูกใส่เข้า context เพื่อทำหน้าที่เป็นแผนที่และชี้ไปยังแหล่งข้อมูลที่ลึกกว่าและเชื่อถือได้กว่า
• เอกสารการออกแบบถูกจัดหมวดหมู่และทำดัชนี โดยมีความเชื่อหลักที่กำหนดสถานะการตรวจสอบและหลักการดำเนินงานแบบ agent-first
• เอกสารสถาปัตยกรรม ทำหน้าที่เป็นแผนที่ระดับบนสุดของโดเมนและการแบ่งชั้นของแพ็กเกจ
• เอกสารคุณภาพ ให้คะแนนแต่ละ product domain และ architecture layer พร้อมติดตามช่องว่างตามเวลา
• แผนงานถูกมองเป็น artifact ชั้นหนึ่ง
  • แผนชั่วคราวและเรียบง่ายใช้กับการเปลี่ยนแปลงเล็ก ๆ
  • งานที่ซับซ้อนจะถูกใส่ไว้ใน execution plan พร้อมความคืบหน้าและ decision log แล้วบันทึกไว้ใน repository
  • ทั้งแผนที่กำลังทำ แผนที่เสร็จแล้ว และหนี้ทางเทคนิคที่ทราบอยู่ จะถูกทำ version และวางไว้ในที่เดียวกัน
• แนวทางนี้ทำให้เกิด progressive disclosure: เอเจนต์เริ่มจากจุดเข้าใช้งานที่เล็กและเสถียรโดยไม่ต้องรับภาระมากเกินไปตั้งแต่แรก แล้วค่อยไปขั้นถัดไป
• การบังคับใช้แบบเชิงกล: linter เฉพาะทางและงาน CI จะตรวจสอบว่าฐานความรู้ยังเป็นปัจจุบัน, เชื่อมโยงข้ามกันครบ และจัดโครงสร้างถูกต้อง
• มี เอเจนต์ "doc-gardening" ที่รันซ้ำเป็นประจำ คอยตรวจเอกสารที่เก่าหรือไม่ถูกต้อง แล้วเปิด pull request เพื่อแก้ไข

เป้าหมายคือให้เอเจนต์อ่านง่าย

• เพราะ repository นี้ถูกสร้างโดยเอเจนต์ทั้งหมด จึงถูกปรับให้เหมาะกับ ความสามารถในการอ่านของ Codex เป็นอันดับแรก
• เป้าหมายของวิศวกรมนุษย์คือทำให้เอเจนต์สามารถให้เหตุผลเกี่ยวกับ business domain ทั้งหมดได้ จากใน repository เองโดยตรง
• จากมุมมองของเอเจนต์ สิ่งที่เข้าถึงไม่ได้ใน context ระหว่างรัน ก็แทบเท่ากับไม่มีอยู่จริง
  • ความรู้ใน Google Docs, เธรดแชต หรือในหัวของผู้คน เป็นสิ่งที่ระบบเข้าถึงไม่ได้
  • เข้าถึงได้เฉพาะ artifact ที่มีการจัดการเวอร์ชัน ใน repository (โค้ด, markdown, schema, execution plans)
• แม้รูปแบบสถาปัตยกรรมจะถูกตกลงกันใน Slack แต่ถ้าเอเจนต์ค้นหาไม่เจอ มันก็อ่านไม่ออก
• การให้ context กับ Codex มากขึ้นไม่ได้หมายถึงเพิ่มคำสั่งชั่วคราว แต่คือ จัดระเบียบและเปิดเผยข้อมูลที่ถูกต้องเพื่อให้เอเจนต์ใช้เหตุผลได้
• เมื่อนำเสนอข้อมูลแก่เอเจนต์เหมือนการ onboarding สมาชิกทีมใหม่ ไม่ว่าจะเป็น product principles, engineering norms หรือ team culture (รวมถึงความชอบเรื่องอีโมจิ) ก็จะได้ผลลัพธ์ที่ดีกว่า
• พวกเขาเลือกใช้ dependencies และ abstractions ที่สามารถ internalize ได้ทั้งหมดและให้เหตุผลได้จากภายใน repository
• เทคโนโลยีที่ "น่าเบื่อ" มักถูกเอเจนต์สร้างแบบจำลองได้ง่ายกว่า เพราะมีการ coupling, API stability และการนำเสนอใน training set ที่ดีกว่า
• ในบางกรณี การให้เอเจนต์ เขียนฟังก์ชันบางส่วนขึ้นใหม่เอง อาจถูกกว่าการพึ่งพาพฤติกรรม upstream ที่มืดทึบของ public library
  • ตัวอย่างเช่น สร้าง helper สำหรับ map-with-concurrency เองแทนแพ็กเกจสไตล์ p-limit แบบทั่วไป เพื่อให้ผสานกับ OpenTelemetry instrumentation ได้แน่นแฟ้น มี test coverage 100% และทำงานตรงตามที่ runtime คาดหวัง
• ยิ่งดึงระบบให้อยู่ในรูปที่เอเจนต์ตรวจสอบ, ยืนยัน และแก้ไขได้โดยตรงมากเท่าไร ก็ยิ่งเพิ่ม leverage ไม่เฉพาะกับ Codex แต่รวมถึงเอเจนต์อื่น ๆ (เช่น Aardvark) ด้วย

บังคับใช้สถาปัตยกรรมและรสนิยม

• แค่เอกสารอย่างเดียวไม่พอที่จะทำให้ codebase ที่เอเจนต์สร้างขึ้นคงความสอดคล้องอย่างสมบูรณ์
• พวกเขาจึงทำให้ฐานแข็งแรงและออกของได้เร็วด้วยการ บังคับใช้ invariant โดยไม่ไปควบคุมรายละเอียดการ implement
  • ตัวอย่างเช่น ต้องการให้ Codex parse รูปแบบข้อมูลตรง boundary แต่ไม่ได้ระบุวิธีที่ตายตัว (แม้โมเดลจะมีแนวโน้มชอบ Zod)
• เอเจนต์ทำงานได้ดีที่สุดในสภาพแวดล้อมที่มี ขอบเขตเข้มงวดและโครงสร้างที่คาดเดาได้
• แอปพลิเคชันถูกสร้างบนโมเดลสถาปัตยกรรมที่เข้มงวด
  • แต่ละ business domain ถูกแยกเป็น ชุดชั้นคงที่ โดยมีการตรวจสอบทิศทางของ dependency อย่างเข้มงวดและมีชุด edge ที่อนุญาตอย่างจำกัด
  • โค้ดไหลตามลำดับ Types → Config → Repo → Service → Runtime → UI
  • ประเด็น cross-cutting (authentication, connectors, telemetry, feature flags) จะเข้ามาผ่านอินเทอร์เฟซที่ชัดเจนเพียงตัวเดียวชื่อ Providers
  • นอกเหนือจากนี้จะไม่อนุญาต และถูกบังคับใช้ด้วยกลไกอัตโนมัติ
• ข้อจำกัดเหล่านี้ถูกบังคับใช้ผ่าน linter แบบกำหนดเองและ structural tests ที่ Codex สร้างขึ้น
• สถาปัตยกรรมระดับนี้มักถูกเลื่อนไปทำเมื่อองค์กรมีวิศวกรหลายร้อยคน แต่สำหรับ coding agent นี่คือ เงื่อนไขตั้งต้นตั้งแต่แรก
• custom lint ถูกใช้บังคับใช้ structured logging, naming conventions ของ schema และ type, ขนาดไฟล์สูงสุด และข้อกำหนดด้านความเสถียรตามแพลตฟอร์มแบบ static
  • เพราะ lint ถูกทำขึ้นเอง จึงสามารถเขียนข้อความ error เพื่อ ใส่คำแนะนำการแก้ไขเข้าไปใน context ของเอเจนต์ ได้
• ใน workflow ที่มนุษย์เป็นศูนย์กลาง กฎเหล่านี้อาจดูละเอียดหรือจำกัดเกินไป แต่เมื่อใช้กับเอเจนต์ ผลลัพธ์จะทวีคูณหลายเท่า
• ข้อจำกัดเหล่านี้ช่วยแยกให้ชัดว่าอะไรสำคัญและอะไรไม่สำคัญ
  • คล้ายกับการบริหารองค์กรแพลตฟอร์มวิศวกรรมขนาดใหญ่: กำหนดขอบเขตจากส่วนกลาง แต่เปิดให้มีอิสระในระดับท้องถิ่น
• โค้ดที่ได้อาจไม่ตรงกับรสนิยมด้านสไตล์ของมนุษย์เสมอไป แต่ถ้าผลลัพธ์ถูกต้อง ดูแลรักษาได้ และอ่านง่ายเวลาเอเจนต์รัน ก็ถือว่าผ่านเกณฑ์
• รสนิยมของมนุษย์จะถูกป้อนกลับเข้าสู่ระบบอย่างต่อเนื่อง
  • review comments, refactoring PR และบั๊กฝั่งผู้ใช้ จะถูกบันทึกเป็นการอัปเดตเอกสารหรือ encode ลงใน tooling โดยตรง
  • หากเอกสารไม่เพียงพอ ก็จะ ยกระดับกฎให้กลายเป็นโค้ด

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

• เมื่อ throughput ของ Codex เพิ่มขึ้น บรรทัดฐานทางวิศวกรรมแบบเดิมกลับให้ผลตรงกันข้าม
• repository นี้ทำงานด้วย merge gate ที่บล็อกให้น้อยที่สุด
• pull request มีอายุสั้น และปัญหาความไม่เสถียรของการทดสอบจะถูก ตามแก้ในรอบถัดไป แทนที่จะขัดขวางความคืบหน้าอย่างไม่มีกำหนด
• ในระบบที่ throughput ของเอเจนต์สูงเกินกว่าความสนใจของมนุษย์มาก ต้นทุนการแก้ไขนั้นถูก แต่ latency แพง
• แนวทางนี้อาจไม่เหมาะกับสภาพแวดล้อมที่มี throughput ต่ำกว่า และจำเป็นต้องหาจุดสมดุลที่เหมาะสม

ขอบเขตที่แท้จริงของคำว่า "agent-generated"

• เมื่อบอกว่า codebase นี้สร้างโดยเอเจนต์ Codex นั่นหมายถึง ทุกอย่าง ใน codebase
  • product code และ tests
  • การตั้งค่า CI และ release tooling
  • internal developer tools
  • เอกสารและประวัติการออกแบบ
  • evaluation harness
  • review comments และการตอบกลับ
  • scripts ที่ใช้ดูแล repository เอง
  • ไฟล์นิยาม production dashboard
• มนุษย์ยังอยู่ในลูปเสมอ แต่ทำงานอยู่บน ชั้น abstraction ที่ต่างจากเดิม
  • จัดลำดับความสำคัญของงาน, แปลง feedback จากผู้ใช้เป็น acceptance criteria และตรวจสอบผลลัพธ์
• เมื่อเอเจนต์ติดขัด พวกเขาจะมองว่านั่นเป็นสัญญาณให้หาว่าเครื่องมือ, guardrails หรือเอกสารอะไรที่ยังขาด และจะ ให้ Codex เขียนการแก้ไขนั้นเองเสมอ ก่อนนำกลับเข้า repository
• เอเจนต์สามารถดึง feedback จากการรีวิว, ตอบกลับแบบ inline, push อัปเดต และแม้กระทั่ง squash และ merge pull request ของตัวเองได้

ระดับความเป็นอิสระที่เพิ่มขึ้น

• เมื่อมีการ encode development loop มากขึ้นลงในระบบโดยตรง ทั้งการทดสอบ, การยืนยันผล, การรีวิว, การจัดการ feedback และการกู้คืน จึงมาถึง จุดวิกฤตสำคัญ
• สิ่งที่เอเจนต์ทำได้จาก prompt เดียวมีดังนี้:
  • ตรวจสอบสถานะปัจจุบันของ codebase
  • reproduce บั๊กที่มีรายงาน
  • บันทึกวิดีโอ แสดงสถานการณ์ที่ล้มเหลว
  • implement การแก้ไข
  • รันแอปพลิเคชันเพื่อตรวจยืนยันการแก้ไข
  • บันทึกวิดีโอชุดที่สองเพื่อแสดงวิธีแก้
  • เปิด pull request
  • ตอบ feedback จากทั้งเอเจนต์และมนุษย์
  • ตรวจจับและแก้ build failure
  • escalate ไปหามนุษย์เฉพาะเมื่อจำเป็นต้องใช้การตัดสินใจ
  • merge การเปลี่ยนแปลง
• ความสามารถเหล่านี้ขึ้นอยู่กับโครงสร้างและ tooling ของ repository นี้โดยเฉพาะอย่างมาก และไม่ควรสมมติว่าสามารถ generalized ได้หากไม่มีการลงทุนแบบเดียวกัน

Entropy และ garbage collection

• ความเป็นอิสระเต็มรูปแบบของเอเจนต์ก่อให้เกิดปัญหาใหม่: Codex จะทำซ้ำรูปแบบที่มีอยู่ใน repository (รวมถึงรูปแบบที่ไม่สม่ำเสมอหรือยังไม่เหมาะสม) ทำให้เกิด drift อย่างหลีกเลี่ยงไม่ได้เมื่อเวลาผ่านไป
• ในช่วงแรกมนุษย์รับมือด้วยมือ โดยใช้เวลาทุกวันศุกร์ (20% ของสัปดาห์) ไปกับการเก็บกวาด "AI slop"
  • และตามคาด มันไม่สามารถขยายได้
• ทางเลือกที่ใช้คือ encode "กฎทอง" ลงใน repository โดยตรง และสร้างกระบวนการทำความสะอาดเป็นประจำ
  • (1) เพื่อรวมศูนย์ invariant ให้เลือกใช้ shared utility package มากกว่า helper ที่เขียนเองกระจัดกระจาย
  • (2) อย่าสำรวจข้อมูลแบบ "YOLO-style" แต่ให้ตรวจสอบ boundary หรือพึ่งพา SDK ที่มีการกำหนด type เพื่อไม่ให้เอเจนต์ไปสร้างของผิดจากรูปแบบที่เดาเอา
• พวกเขารัน background jobs ของ Codex เพื่อตรวจความเบี่ยงเบน อัปเดตคะแนนคุณภาพ และสร้าง PR สำหรับ refactor เฉพาะจุดเป็นประจำ
  • ส่วนใหญ่รีวิวได้ภายใน 1 นาที และ merge อัตโนมัติ
• วิธีนี้ทำงานเหมือน garbage collection: หนี้เทคนิคก็เหมือนเงินกู้ดอกเบี้ยสูง ควรทยอยจ่ายน้อย ๆ อย่างสม่ำเสมอก่อนที่ดอกเบี้ยจะพอกพูน
• เมื่อจับรสนิยมของมนุษย์ได้แล้ว ก็สะท้อนไปยังทุกบรรทัดของโค้ดอย่างต่อเนื่อง และจับพร้อมแก้ pattern ที่ไม่ดีทุกวัน ไม่ปล่อยให้แพร่กระจายเป็นวันหรือเป็นสัปดาห์

สิ่งที่กำลังเรียนรู้ในตอนนี้และโจทย์ถัดไป

• กลยุทธ์นี้ใช้ได้ผลดีภายใน OpenAI จนถึงระดับการเปิดใช้งานภายในและการนำไปใช้จริง
• เป็นการยึดโยงการลงทุนเข้ากับความจริงด้วยการสร้างผลิตภัณฑ์จริงสำหรับผู้ใช้จริง และทำให้ดูแลรักษาได้ในระยะยาว
• สิ่งที่ยังไม่รู้คือ ในระบบที่สร้างโดยเอเจนต์อย่างเต็มรูปแบบ ความสอดคล้องของสถาปัตยกรรมจะวิวัฒน์อย่างไรในช่วงหลายปี
• พวกเขายังอยู่ระหว่างเรียนรู้ว่าจุดไหนที่การตัดสินใจของมนุษย์สร้างอิทธิพลได้มากที่สุด และจะ encode การตัดสินใจนั้นเพื่อนำไปใช้แบบทบต้นได้อย่างไร
• เมื่อความสามารถของโมเดลดีขึ้นอย่างต่อเนื่อง ทิศทางการพัฒนาของระบบนี้ก็ยังเป็นสิ่งที่ไม่แน่นอน
• การสร้างซอฟต์แวร์ยังคงต้องมี วินัย แต่ตอนนี้วินัยนั้นแสดงออกผ่าน scaffolding มากกว่าตัวโค้ด
• tooling, abstractions และ feedback loops ที่ช่วยรักษาความสอดคล้องของ codebase กำลังมีความสำคัญมากขึ้นเรื่อย ๆ
• ความท้าทายที่ยากที่สุดในตอนนี้คือการออกแบบสภาพแวดล้อม, feedback loops และ control systems ที่ช่วยให้เอเจนต์ สร้างและดูแลซอฟต์แวร์ที่ซับซ้อนและเสถียรในระดับใหญ่ ได้

[ragingwind]

40 วัน, 1 ล้านบรรทัด, 1.3 หมื่นล้านโทเค็น — สิ่งที่ ชินจองกยู CEO ของ Lablup ค้นพบเกี่ยวกับความเป็นจริงของเวิร์กโฟลว์แบบเอเจนติก - Silicon Valley ของ Park Jaehong - https://wikidocs.net/blog/@jaehong/8206/