- กรณีทดลองสร้างผลิตภัณฑ์ซอฟต์แวร์เบต้าภายในโดยกำหนดข้อจำกัดตายตัวว่า ไม่มีโค้ดที่เขียนด้วยมือเลยแม้แต่บรรทัดเดียว และให้ Codex เขียนตั้งแต่ตรรกะแอปพลิเคชัน, การทดสอบ, การตั้งค่า CI, เอกสาร, ระบบสังเกตการณ์ ไปจนถึงเครื่องมือภายใน
- โค้ดเบสที่เริ่มจาก git repository ว่างเปล่า เติบโตเป็นราว 1 ล้านบรรทัดในเวลาประมาณ 5 เดือน และมีวิศวกร 3 คนที่ขับเคลื่อน Codex เพื่อเปิดและรวม PR ราว 1,500 รายการ เป็นระดับ PR throughput
- งานหลักของวิศวกรเปลี่ยนจากการเขียนโค้ดไปเป็นการ ออกแบบสภาพแวดล้อม, การระบุเจตนา, และการสร้าง feedback loop เพื่อทำให้เอเจนต์ทำงานได้อย่างน่าเชื่อถือ
- ความรู้ของ repository ถูกดูแลผ่าน
AGENTS.mdแบบสั้น,docs/ที่มีโครงสร้าง, execution plan, linter และ CI ขณะที่ UI, log, metric และ trace ถูกเปลี่ยนให้เป็น ความสามารถในการอ่านแอปพลิเคชัน ที่ Codex สามารถอ่านและตรวจสอบได้โดยตรง - เมื่อ throughput เพิ่มขึ้น การลด merge gate ให้เหลือน้อยที่สุดและแก้ไขผ่านการรันต่อเนื่องภายหลังกลายเป็นทางเลือกที่ใช้ได้จริง แต่ ความสม่ำเสมอด้านสถาปัตยกรรม ระยะยาวและการเข้ารหัสวิจารณญาณของมนุษย์ยังคงเป็นเรื่องที่ต้องเรียนรู้
เบต้าภายในที่สร้างโดยไม่มีโค้ดเขียนด้วยมือเลย
- ในช่วง 5 เดือนที่ผ่านมา มีการทดลองสร้างและเปิดตัวผลิตภัณฑ์ซอฟต์แวร์เบต้าภายในโดยมีข้อกำหนดว่า ไม่มีโค้ดที่เขียนด้วยมือเลยแม้แต่บรรทัดเดียว
- ผลิตภัณฑ์นี้มีทั้งผู้ใช้ภายในที่ใช้งานทุกวันและผู้ทดสอบอัลฟ่าภายนอก และอยู่ในสภาพที่ผ่านวงจรการเปิดตัว, deploy, incident และการแก้ไขจริง
- ทุกบรรทัดของโค้ดตั้งแต่ตรรกะแอปพลิเคชัน, การทดสอบ, การตั้งค่า CI, เอกสาร, ระบบสังเกตการณ์ ไปจนถึงเครื่องมือภายใน เขียนโดย Codex ทั้งหมด และประเมินว่าสร้างได้ในเวลาประมาณ 1/10 เมื่อเทียบกับการเขียนโค้ดด้วยมือ
- มนุษย์เป็นผู้ควบคุม ส่วนเอเจนต์เป็นผู้ลงมือทำ
- ภายในไม่กี่สัปดาห์ต้องปล่อยผลลัพธ์ที่ท้ายที่สุดมีขนาดถึง 1 ล้านบรรทัด จึงทำให้งานหลักของทีมวิศวกรรมย้ายจากการเขียนโค้ดไปเป็นการออกแบบสภาพแวดล้อม, ระบุเจตนา และสร้าง feedback loop
เริ่มจาก git repository ว่างเปล่า
- commit แรกของ repository ว่างเกิดขึ้นปลายเดือนสิงหาคม 2025
- โครงเริ่มต้นอย่างโครงสร้าง repository, การตั้งค่า CI, กฎการ format, การตั้งค่า package manager และ application framework ถูกสร้างโดย Codex CLI ที่ใช้ GPT-5 โดยอาศัยคำแนะนำจาก template เดิมบางส่วน
- ไฟล์
AGENTS.mdเริ่มต้นที่ใช้บอกแนวทางให้เอเจนต์ทำงานใน repository ก็เขียนโดย Codex เช่นกัน - ไม่มีโค้ดเดิมที่มนุษย์เขียนไว้เพื่อรองรับระบบนี้ และ repository ถูกก่อรูปโดยเอเจนต์ตั้งแต่ต้น
- ผ่านไป 5 เดือน repository เติบโตเป็นราว 1 ล้านบรรทัด ครอบคลุมตรรกะแอปพลิเคชัน, infrastructure, เครื่องมือ, เอกสาร และ utility ภายในสำหรับนักพัฒนา
- วิศวกร 3 คนขับเคลื่อน Codex เพื่อเปิดและรวม PR ราว 1,500 รายการ คิดเป็น throughput เฉลี่ย 3.5 PR ต่อวันต่อวิศวกร 1 คน
- หลังจากทีมขยายเป็นวิศวกร 7 คน throughput ก็ยังเพิ่มขึ้นต่อเนื่อง
- ผลลัพธ์นี้ไม่ใช่เพียงการสร้าง output เพื่อโชว์ output และตัวผลิตภัณฑ์ก็มีผู้ใช้ภายในหลายร้อยคนรวมถึง power user ภายในใช้งานจริง
- ตลอดกระบวนการพัฒนา มนุษย์ไม่ได้มีส่วนเขียนโค้ดโดยตรง และ ไม่มีโค้ดที่เขียนด้วยมือ คือปรัชญาหลักของทีม
นิยามบทบาทวิศวกรใหม่
- ข้อจำกัดที่มนุษย์ไม่เขียนโค้ดโดยตรงทำให้งานวิศวกรรมเปลี่ยนไปสู่การโฟกัสที่ระบบ, scaffolding และ leverage
- ความคืบหน้าในช่วงแรกช้ากว่าที่คาด แต่ไม่ใช่เพราะ Codex ขาดความสามารถ หากเป็นเพราะสภาพแวดล้อมยังถูกระบุไม่ชัดเจนพอ
- เอเจนต์ยังขาดเครื่องมือ, abstraction และโครงสร้างภายในที่จำเป็นต่อการเดินหน้าไปสู่เป้าหมายระดับสูง
- งานหลักของทีมวิศวกรรมคือทำให้เอเจนต์สามารถทำงานที่มีประโยชน์ได้
- งานจริงจึงเป็นการแตกเป้าหมายใหญ่ให้เป็นบล็อกเล็กลง เช่น การออกแบบ, โค้ด, รีวิว, การทดสอบ แล้ว prompt ให้เอเจนต์สร้างบล็อกเหล่านั้นก่อนนำไปต่อยอดเป็นงานที่ซับซ้อนกว่า ในลักษณะ depth-first
- เมื่อเกิดความล้มเหลว วิธีแก้ไม่ใช่ “พยายามให้มากขึ้น” แต่คือค้นหาว่าความสามารถใดที่ยังขาดเพื่อให้ Codex ทำงานได้ แล้วทำสิ่งนั้นให้อยู่ในรูปที่เอเจนต์อ่านและปฏิบัติตามได้
- มนุษย์โต้ตอบกับระบบเป็นหลักผ่าน prompt โดยวิศวกรอธิบายงาน, รันเอเจนต์ แล้วให้มันเปิด PR
- ในกระบวนการทำ PR ให้เสร็จ Codex จะรีวิวการเปลี่ยนแปลงของตัวเองในเครื่อง, ขอ agent review เพิ่มทั้งใน local และ cloud, ตอบรับ feedback จากมนุษย์หรือเอเจนต์ และวนซ้ำจน reviewer ที่เป็นเอเจนต์ทุกตัวพอใจ ในลักษณะใกล้เคียง Ralph Wiggum Loop
- Codex ใช้เครื่องมือพัฒนามาตรฐานอย่าง
gh, local script และ skill ที่ฝังใน repository โดยตรงเพื่อรวบรวมบริบทโดยไม่ต้องให้มนุษย์คอยคัดลอกและวาง - มนุษย์ยังสามารถรีวิว PR ได้ แต่ไม่ใช่ข้อบังคับ และเมื่อเวลาผ่านไป งานรีวิวเกือบทั้งหมดก็ย้ายไปเป็นการประมวลผลระหว่างเอเจนต์
ทำให้แอปพลิเคชันอ่านได้มากขึ้น
- เมื่อ throughput ของโค้ดเพิ่มขึ้น คอขวดก็ย้ายไปอยู่ที่ศักยภาพ QA ของมนุษย์
- เนื่องจากข้อจำกัดตายตัวคือเวลาและความใส่ใจของมนุษย์ จึงขยายความสามารถของเอเจนต์ด้วยการทำให้ UI, log และ metric ของแอปพลิเคชันสามารถถูกอ่านโดย Codex ได้โดยตรง
- แอปพลิเคชันถูกจัดให้บูตได้แยกตาม git worktree เพื่อให้ Codex สามารถรันและควบคุม instance หนึ่งชุดต่อการเปลี่ยนแปลงแต่ละครั้ง
- มีการเชื่อม Chrome DevTools Protocol เข้ากับ agent runtime และสร้าง skill สำหรับ snapshot ของ DOM, screenshot และงานนำทาง
- ด้วยสิ่งนี้ Codex จึงสามารถทำซ้ำบั๊ก, ตรวจสอบการแก้ไข และอนุมานพฤติกรรมของ UI ได้โดยตรง
- log, metric และ trace ถูกเปิดให้ Codex เข้าถึงผ่าน local observability stack แบบชั่วคราวที่มีอยู่สำหรับ worktree นั้นโดยเฉพาะ
- Codex ทำงานบนเวอร์ชันของแอปที่แยกขาดจากกันโดยสมบูรณ์ รวมถึง log และ metric ด้วย และเมื่อจบงาน log กับ metric ที่เกี่ยวข้องก็จะถูกลบออก
- เอเจนต์ query log ด้วย LogQL และ query metric ด้วย PromQL
- prompt อย่าง “รับประกันว่าการเริ่มต้น service จะเสร็จภายใน 800ms” หรือ “รับประกันว่าไม่มี span ใดใน 4 user journey หลักเกิน 2 วินาที” สามารถแปลงเป็นงานที่ลงมือทำได้
- เป็นเรื่องปกติที่การรัน Codex หนึ่งครั้งจะทำงานเดียวนานเกิน 6 ชั่วโมง และเวลานั้นมักเป็นช่วงที่มนุษย์กำลังนอน
เปลี่ยนความรู้ของ repository ให้เป็น system of record
- หนึ่งในโจทย์สำคัญในการทำให้เอเจนต์มีประสิทธิภาพกับงานขนาดใหญ่และซับซ้อนคือการจัดการบริบท
- สิ่งที่ Codex ต้องการไม่ใช่คู่มือยาว 1,000 หน้า แต่คือแผนที่
- บริบทเป็นทรัพยากรที่หายาก และไฟล์คำสั่งขนาดมหึมาจะเบียดพื้นที่ของงาน, โค้ด และเอกสารที่เกี่ยวข้อง ทำให้เอเจนต์พลาดข้อจำกัดสำคัญหรือไป optimize กับข้อจำกัดที่ผิด
- คำแนะนำที่มากเกินไปจะไม่ใช่คำแนะนำอีกต่อไป เพราะเมื่อทุกอย่างสำคัญ ก็จะไม่มีอะไรสำคัญ ทำให้เอเจนต์ติดอยู่กับการจับคู่แพตเทิร์นเฉพาะหน้าแทนการสำรวจอย่างมีเจตนา
- คู่มือก้อนเดียวขนาดใหญ่จะล้าสมัยทันที เสี่ยงจะกลายเป็นสุสานของกฎเก่า และเป็นสิ่งรบกวนที่ดูน่าเชื่อถือแต่ไม่มีใครดูแล
- ไฟล์ก้อนเดียวทำให้ตรวจสอบเชิงกลไกได้ยาก ทั้งในเรื่อง coverage, ความทันสมัย, ownership และ cross-link จึงหลีกเลี่ยง drift ได้ยาก
AGENTS.mdถูกมองเป็น สารบัญ ไม่ใช่สารานุกรม- knowledge base ของ repository อยู่ในไดเรกทอรี
docs/ที่มีโครงสร้างและถูกมองเป็น system of record AGENTS.mdแบบสั้นราว 100 บรรทัดถูก inject เข้าไปเป็นบริบทและทำหน้าที่เป็นแผนที่ที่ชี้ไปยังแหล่งความจริงที่ลึกกว่า- เอกสารการออกแบบถูกจัดทำเป็น catalog และทำดัชนีพร้อมชุดความเชื่อหลักที่นิยามสถานะการตรวจสอบและหลักการดำเนินงานแบบ agent-first
- เอกสารสถาปัตยกรรม ให้แผนที่ระดับบนสุดของโดเมนและชั้นของ package
- เอกสารคุณภาพทำการจัดระดับแต่ละ product domain และชั้นสถาปัตยกรรม พร้อมติดตามช่องว่างตามกาลเวลา
- แผนถูกมองเป็นผลลัพธ์ชั้นหนึ่ง โดยการเปลี่ยนแปลงเล็กใช้แผนชั่วคราวแบบเบา ส่วนงานซับซ้อนจะถูก commit ลง repository เป็น execution plan ที่มีทั้งความคืบหน้าและ decision log
- ทั้งแผนที่กำลังใช้งาน, แผนที่เสร็จแล้ว และหนี้เทคนิคที่ทราบอยู่ ล้วนอยู่ภายใต้ version control และวางไว้ร่วมกัน ทำให้เอเจนต์ทำงานได้โดยไม่ต้องพึ่งบริบทภายนอก
- โครงสร้างนี้เปิดทางให้เกิด progressive disclosure โดยเอเจนต์เริ่มจากจุดเข้าที่เล็กและเสถียรแทนที่จะถูกถล่มด้วยข้อมูลตั้งแต่แรก แล้วค่อยเรียนรู้ว่าควรดูอะไรต่อ
- linter เฉพาะทางและ CI job ใช้ตรวจสอบความทันสมัย, cross-link และความถูกต้องของโครงสร้างใน knowledge base
- เอเจนต์ดูแลเอกสารที่รันซ้ำเป็นประจำจะค้นหาเอกสารเก่าหรือล้าสมัยที่ไม่สะท้อนพฤติกรรมจริงของโค้ด แล้วสร้าง PR เพื่อแก้ไข
เป้าหมายคือความสามารถในการอ่านของเอเจนต์
- เนื่องจากทั้งโค้ดเบสเป็นผลผลิตที่เอเจนต์สร้าง เป้าหมายการ optimize สูงสุดจึงเป็นความสามารถในการอ่านของ Codex
- เหมือนกับที่ทำให้วิศวกรใหม่สำรวจโค้ดได้ง่าย เป้าหมายของวิศวกรมนุษย์คือทำให้เอเจนต์สามารถอนุมาน business domain ทั้งหมดได้จาก repository โดยตรง
- จากมุมมองของเอเจนต์ สิ่งใดที่เข้าถึงไม่ได้ในบริบทขณะรัน ก็แทบเท่ากับไม่มีอยู่จริง
- ความรู้ที่อยู่ใน Google Docs, thread แชต หรือในหัวของคน ไม่ใช่สิ่งที่ระบบเข้าถึงได้ และสิ่งที่เอเจนต์มองเห็นมีเพียงโค้ด, Markdown, schema และ execution plan ที่เป็นผลลัพธ์ใน repository แบบ local และอยู่ภายใต้ version control
- ต่อให้ทีมตกลงรูปแบบสถาปัตยกรรมกันใน Slack หากเอเจนต์ค้นพบไม่ได้ ก็มีสถานะไม่ต่างจากความรู้ที่พนักงานใหม่ซึ่งเข้ามาอีก 3 เดือนข้างหน้าไม่อาจรับรู้
- การให้บริบทกับ Codex มากขึ้นไม่ใช่การเทคำสั่งแบบสุ่มใส่เข้าไป แต่คือการจัดระเบียบและเปิดเผยข้อมูลที่ถูกต้องเพื่อให้เอเจนต์ใช้เหตุผลได้
- เหมือนการ onboarding สมาชิกทีมใหม่ด้วยหลักการของผลิตภัณฑ์, บรรทัดฐานทางวิศวกรรม, วัฒนธรรมทีม ไปจนถึงความชอบเรื่องอีโมจิ หากให้ข้อมูลเหล่านี้กับเอเจนต์ด้วย ก็จะนำไปสู่ output ที่สอดคล้องมากขึ้น
- dependencies และ abstraction ถูกเลือกให้ฝังอยู่ภายใน repository และสามารถอนุมานได้ครบถ้วนให้มากที่สุด
- เทคโนโลยีที่มักถูกมองว่า “น่าเบื่อ” กลับมีแนวโน้มที่เอเจนต์จะสร้างแบบจำลองได้ง่ายกว่า เพราะมี composability, API ที่เสถียร และการมีตัวแทนอยู่ในข้อมูลฝึก
- ในบางกรณี การให้เอเจนต์ reimplement บางฟังก์ชันเองอาจถูกกว่าการอ้อมผ่านพฤติกรรมระดับสูงที่ทึบของ public library
- แทนที่จะดึงแพ็กเกจสไตล์
p-limitแบบทั่วไปเข้ามา ทีมเลือกสร้าง helper map-with-concurrency เอง ซึ่งผสานกับ OpenTelemetry instrumentation อย่างแน่นแฟ้น มี test coverage 100% และพฤติกรรมตรงกับความคาดหวังของ runtime แบบพอดี - ยิ่งดึงระบบเข้ามาอยู่ในรูปที่เอเจนต์ตรวจสอบ, ยืนยัน และแก้ไขได้โดยตรงมากเท่าไร ก็ยิ่งเพิ่ม leverage ไม่เฉพาะกับ Codex แต่รวมถึงเอเจนต์อื่นอย่าง Aardvark ที่ทำงานบนโค้ดเบสเดียวกันด้วย
บังคับใช้สถาปัตยกรรมและรสนิยม
- เอกสารเพียงอย่างเดียวไม่พอสำหรับรักษาความสม่ำเสมอของโค้ดเบสที่สร้างโดยเอเจนต์ทั้งหมด
- โครงสร้างที่ต้องการคือการบังคับใช้ invariant โดยไม่ต้องคุมรายละเอียด implementation ทุกจุด เพื่อให้เอเจนต์ปล่อยงานได้เร็วโดยไม่บ่อนทำลายฐานราก
- วิธีที่ใช้กับ Codex คือกำหนดให้ parse รูปทรงข้อมูลที่ boundary แต่ไม่ได้บังคับวิธีทำในรายละเอียด
- เอเจนต์ทำงานได้ดีที่สุดในสภาพแวดล้อมที่มี boundary เข้มงวดและโครงสร้างที่คาดเดาได้ ดังนั้นแอปพลิเคชันจึงถูกจัดรอบโมเดลสถาปัตยกรรมที่แข็งแรง
- แต่ละ business domain ถูกแบ่งเป็นชุดชั้นคงที่ และมีการตรวจสอบอย่างเข้มงวดทั้งทิศทางของ dependency และการเชื่อมต่อที่อนุญาต
- ข้อจำกัดเหล่านี้ถูกบังคับใช้เชิงกลไกด้วย custom linter และ structural test ที่ Codex สร้างขึ้น
- ภายในแต่ละ business domain โค้ดสามารถพึ่งพาได้เฉพาะไปข้างหน้าตามชั้นคงที่
Types → Config → Repo → Service → Runtime → UI - cross-cutting concern เช่น authentication, connector, telemetry และ feature flag สามารถเข้าสู่ระบบได้ผ่าน interface ที่ชัดเจนเพียงหนึ่งเดียวชื่อ
Providersเท่านั้น - dependency อื่นนอกเหนือจากนี้ไม่อนุญาตและถูกบล็อกด้วยกลไกอัตโนมัติ
- สถาปัตยกรรมแบบนี้ปกติมักถูกเลื่อนไปจนกว่าจะมีวิศวกรหลายร้อยคน แต่ในสภาพแวดล้อมที่มี coding agent นี่คือเงื่อนไขตั้งต้นตั้งแต่เนิ่น ๆ เพื่อรักษาความเร็วพร้อมป้องกันการเสื่อมและ architectural drift
- ในการปฏิบัติจริง กฎเหล่านี้ถูกบังคับใช้ด้วย custom linter, structural test และชุด “taste invariant” ขนาดเล็ก
- มีการบังคับใช้แบบ static ผ่าน custom lint สำหรับ structured logging, กฎการตั้งชื่อ schema และ type, ข้อจำกัดขนาดไฟล์ และข้อกำหนดด้านความน่าเชื่อถือแยกตามแพลตฟอร์ม
- ข้อความ error ของ custom lint ถูกเขียนให้ inject แนวทางการแก้เข้าไปในบริบทของเอเจนต์
- ใน workflow ที่มนุษย์เป็นศูนย์กลาง กฎเหล่านี้อาจดูจุกจิกหรือจำกัดเกินไป แต่ในสภาพแวดล้อมของเอเจนต์ กฎที่เข้ารหัสไว้ครั้งเดียวจะทำงานเป็นตัวคูณกับทั้งระบบในคราวเดียว
- ส่วนกลางจึงควบคุม boundary, correctness และ reproducibility อย่างเข้มงวด ขณะที่ภายในนั้นทีมหรือเอเจนต์ยังมีอิสระสูงในการเลือกรูปแบบการแก้ปัญหา
- โค้ดที่ได้อาจไม่ได้ตรงกับความชอบเชิงสไตล์ของมนุษย์เสมอไป แต่ถ้ามันถูกต้อง, ดูแลต่อได้ และอ่านได้สำหรับการรันของเอเจนต์ในอนาคต ก็ถือว่าผ่านเกณฑ์
- รสนิยมของมนุษย์ยังคงย้อนกลับเข้าสู่ระบบอย่างต่อเนื่องผ่าน review comment, PR รีแฟกเตอร์ และบั๊กที่ผู้ใช้เผชิญ จนนำไปสู่การอัปเดตเอกสารหรือเครื่องมือ
- หากเอกสารยังไม่พอ กฎก็จะถูกยกระดับไปเป็นโค้ด
ปรัชญาการ merge ที่เปลี่ยนไปเพราะ throughput
- เมื่อ throughput ของ Codex เพิ่มขึ้น บรรทัดฐานทางวิศวกรรมเดิมจำนวนมากกลับให้ผลตรงกันข้าม
- repository ถูกดำเนินการด้วย merge gate แบบบล็อกน้อยที่สุด
- PR ถูกทำให้สั้น
- test flake มักถูกจัดการด้วยการรันติดตามภายหลัง แทนที่จะปล่อยให้มันบล็อกความคืบหน้าอย่างไม่มีกำหนด
- ในระบบที่ throughput ของเอเจนต์สูงเกินความสนใจของมนุษย์มาก ต้นทุนการแก้ไขจะต่ำ แต่ต้นทุนของการรอจะสูง
- แม้แนวทางนี้อาจดูไม่รับผิดชอบในสภาพแวดล้อมที่ throughput ต่ำ แต่ในบริบทนี้ มันมักเป็น trade-off ที่ถูกต้อง
ขอบเขตจริงของคำว่า “สร้างโดยเอเจนต์”
- การบอกว่าโค้ดเบสถูกสร้างโดยเอเจนต์ Codex หมายถึงทุกสิ่งทุกอย่างภายในโค้ดเบสนั้น
- สิ่งที่เอเจนต์สร้างได้แก่
- product code และ test
- การตั้งค่า CI และเครื่องมือ release
- เครื่องมือภายในสำหรับนักพัฒนา
- เอกสารและประวัติการออกแบบ
- evaluation harness
- review comment และคำตอบ
- script ที่ใช้ดูแล repository เอง
- ไฟล์นิยาม production dashboard
- มนุษย์ยังอยู่ในวงจรเสมอ แต่ทำงานบนชั้น abstraction ที่สูงกว่าเดิมมาก
- มนุษย์เป็นผู้จัดลำดับความสำคัญของงาน, แปลง feedback จากผู้ใช้ให้เป็น acceptance criteria และตรวจสอบผลลัพธ์
- เมื่อเอเจนต์ติดขัด จะถูกมองเป็นสัญญาณว่าขาดอะไรบางอย่างในเครื่องมือ, guardrail หรือเอกสาร และการแก้ไขนั้นก็จะถูกป้อนกลับเข้า repository โดยให้ Codex เป็นผู้เขียนเช่นกัน
- เอเจนต์ใช้เครื่องมือพัฒนามาตรฐานโดยตรง ดึง review feedback มา, ตอบ inline, push อัปเดต และบ่อยครั้งก็ squash แล้ว merge PR ของตัวเอง
เพิ่มระดับความเป็นอิสระ
- เมื่อมีการเข้ารหัสการทดสอบ, การตรวจสอบ, การรีวิว, การจัดการ feedback และการกู้คืนเข้าไปในระบบมากขึ้น Codex ก็เพิ่งผ่านจุดวิกฤตที่สามารถผลักดันฟีเจอร์ใหม่แบบ end-to-end ได้ด้วยตัวเอง
- งานที่เอเจนต์ทำได้จาก prompt เดียว ได้แก่
- ตรวจสอบสถานะปัจจุบันของโค้ดเบส
- ทำซ้ำบั๊กที่มีการรายงาน
- บันทึกวิดีโอที่แสดงความล้มเหลว
- ลงมือแก้ไข
- ควบคุมแอปพลิเคชันโดยตรงเพื่อตรวจสอบการแก้
- บันทึกวิดีโอชุดที่สองเพื่อแสดงการแก้สำเร็จ
- เปิด PR
- ตอบรับ feedback จากเอเจนต์และมนุษย์
- ตรวจจับและแก้ build failure
- escalate ไปหามนุษย์เฉพาะเมื่อจำเป็นต้องใช้วิจารณญาณ
- merge การเปลี่ยนแปลง
- พฤติกรรมนี้พึ่งพาโครงสร้างและเครื่องมือเฉพาะของ repository นั้นอย่างมาก และไม่ควรสมมติว่าสามารถทำให้เป็นเรื่องทั่วไปได้หากไม่มีการลงทุนแบบใกล้เคียงกัน
เอนโทรปีและ garbage collection
- ความเป็นอิสระเต็มรูปแบบของเอเจนต์นำปัญหาใหม่เข้ามาด้วย
- Codex มีแนวโน้มจะคัดลอกแพตเทิร์นที่มีอยู่แล้วใน repository แม้แพตเทิร์นนั้นจะไม่สม่ำเสมอหรือไม่เหมาะที่สุดก็ตาม
- เมื่อเวลาผ่านไป การทำซ้ำเช่นนี้จะนำไปสู่ drift
- ในช่วงแรก มนุษย์รับมือสิ่งนี้ด้วยแรงงานตรง และทีมใช้ทุกวันศุกร์ หรือ 20% ของเวลาต่อสัปดาห์ ไปกับการเก็บกวาด “AI slop”
- วิธีนี้ขยายต่อไม่ได้ จึงมีการเข้ารหัส “golden principle” ลงใน repository โดยตรงและสร้างกระบวนการเก็บกวาดแบบวนซ้ำ
- golden principle คือกฎเชิงกลไกที่มีความเห็นชัดเจน ซึ่งทำให้โค้ดเบสอ่านง่ายและสม่ำเสมอสำหรับการรันของเอเจนต์ในอนาคต
- ตัวอย่างหลักการคือการเลือกใช้ shared utility package แทน helper ที่ทำขึ้นเฉพาะกิจ เพื่อรวม invariant ไว้ส่วนกลาง
- อีกตัวอย่างคือการตรวจสอบ boundary หรือพึ่ง type SDK แทนการไล่สำรวจข้อมูลแบบ “YOLO” เพื่อไม่ให้เอเจนต์สร้างสิ่งต่อบนรูปทรงข้อมูลที่เดามาโดยบังเอิญ
- มีงาน Codex เบื้องหลังที่รันเป็นประจำเพื่อสแกนหาความคลาดเคลื่อน, อัปเดตระดับคุณภาพ และสร้าง PR รีแฟกเตอร์แบบเจาะจงเป้าหมาย
- PR รีแฟกเตอร์ส่วนใหญ่ใช้เวลารีวิวไม่ถึง 1 นาทีและสามารถ auto-merge ได้
- กระบวนการนี้ทำงานคล้าย garbage collection
- หนี้เทคนิคก็เหมือนเงินกู้ดอกเบี้ยสูง และแทบจะดีกว่าเสมอที่จะทยอยจ่ายคืนเป็นหน่วยเล็ก ๆ อย่างต่อเนื่อง แทนที่จะปล่อยสะสมแล้วค่อยมาเจ็บหนักทีเดียว
- รสนิยมของมนุษย์เมื่อถูกจับได้แล้วจะถูกบังคับใช้อย่างต่อเนื่องกับทุกบรรทัดของโค้ด
- แพตเทิร์นที่ไม่ดีสามารถถูกจับและแก้ได้ทุกวัน ก่อนจะแพร่ไปทั่วโค้ดเบสเป็นเวลาหลายวันหรือหลายสัปดาห์
ยังอยู่ระหว่างการเรียนรู้
- กลยุทธ์นี้จนถึงตอนนี้ทำงานได้ดีกับการเปิดตัวและการนำไปใช้ภายใน OpenAI
- การสร้างผลิตภัณฑ์จริงสำหรับผู้ใช้จริงช่วยยึดการลงทุนไว้กับความเป็นจริง และผลักดันไปสู่การบำรุงรักษาระยะยาว
- ยังไม่รู้ชัดว่าความสม่ำเสมอด้านสถาปัตยกรรมในระบบที่สร้างโดยเอเจนต์ทั้งหมดจะเปลี่ยนไปอย่างไรตลอดหลายปี
- ทีมยังคงเรียนรู้อยู่ต่อไปว่าจุดไหนที่วิจารณญาณของมนุษย์สร้าง leverage ได้มากที่สุด และจะเข้ารหัสวิจารณญาณนั้นอย่างไรให้เกิดผลสะสม
- ยังไม่มีคำตอบชัดว่าระบบนี้จะพัฒนาไปอย่างไรเมื่อโมเดลมีความสามารถสูงขึ้นตามเวลา
- สิ่งที่ชัดเจนขึ้นคือ การสร้างซอฟต์แวร์ยังต้องการวินัย แต่ตอนนี้วินัยนั้นปรากฏชัดใน scaffolding มากกว่าในตัวโค้ด
- ความสำคัญของเครื่องมือ, abstraction และ feedback loop ที่ช่วยรักษาความสม่ำเสมอของโค้ดเบสยังคงเพิ่มขึ้นเรื่อย ๆ
- โจทย์ที่ยากที่สุดในตอนนี้คือการออกแบบสภาพแวดล้อม, feedback loop และระบบควบคุมที่ช่วยให้เอเจนต์สร้างและดูแลซอฟต์แวร์ที่ซับซ้อนและเชื่อถือได้ในระดับขนาดใหญ่
- ยิ่งเอเจนต์อย่าง Codex รับหน้าที่ในวงจรชีวิตซอฟต์แวร์มากขึ้นเพียงใด คำถามเหล่านี้ยิ่งมีความสำคัญมากขึ้นเท่านั้น
- บทเรียนช่วงต้นช่วยชี้ว่าเราควรลงทุนแรงไปที่ตรงไหนเพื่อจะตัดสินได้ว่า สามารถสร้างบางอย่างขึ้นมาได้เลย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ปริมาณงาน สูงแบบเหลือเชื่อเลย สงสัยว่าควรใช้ค่าอ้างอิงอะไร ก่อนยุค agent coding ปกติคาดหวังให้วิศวกรส่ง PR ได้เท่าไรกัน? วันละราว 2~10 อันหรือเปล่า?
ก็สงสัยเหมือนกันว่าตลอด 6 เดือนที่ผ่านมา ซอฟต์แวร์ดีขึ้นจริงไหม ถ้าจำนวนวิศวกรพอๆ กัน วงจรการพัฒนาแอปซอฟต์แวร์หลักๆ ก็น่าจะเร็วขึ้นสัก 5 เท่า แต่ดูเหมือนจะไม่เป็นแบบนั้น แอป AI เปลี่ยนเร็วมาก แต่ก็เป็นสาขาใหม่เลยพอคาดได้ นอกเหนือจากนั้นยังไม่ค่อยรู้สึก
ในที่นี้ 1,500 PR ต่อ 1 ล้านบรรทัด เท่ากับเพิ่มสุทธิประมาณ 650 บรรทัดต่อ PR ไม่ได้แปลว่า PR ทั้งอันมี 650 บรรทัด แต่หมายถึงยอดสุทธิหลังหักบรรทัดที่ลบแล้วเป็น +650 บรรทัด
สำหรับผู้อ่านสายละเอียด มีคำถามน่าคิดอยู่บ้าง โปรเจ็กต์ที่เพิ่มจำนวนบรรทัดเท่ากับโค้ดเบสของ Firefox ปีละหนึ่งก้อน อีก 10 ปีจะหน้าตาเป็นอย่างไร? จำนวนบรรทัดบอกอะไรเกี่ยวกับความฟุ่มเฟือยของเครื่องมือได้บ้าง และการที่ไม่ได้เปิดเผยเป้าหมายของโปรเจ็กต์อย่างชัดเจนบอกอะไรเกี่ยวกับผลลัพธ์ได้บ้าง? ในโลกที่มนุษย์ไม่ได้เขียนโค้ดเองแล้ว เรายังควรสนใจจำนวนบรรทัดอยู่ไหม? ถ้าโค้ดเบสใหญ่ขึ้นมาก การใช้โทเค็นจะเป็นอย่างไร? ถ้ายืนยันได้ว่าการใช้ LLM ทำให้จำนวนบรรทัดพุ่งกระฉูด นั่นจะมีความหมายอย่างไรกับโค้ดเบสที่ใช้มันไปไม่กี่เดือนแล้วอยากกลับไปเขียนโค้ดเองเพราะค่าใช้จ่าย?
แปลกดีที่การใช้งาน “agent” ส่วนใหญ่กลับเป็นการเอาไปสร้างผลิตภัณฑ์ AI อีกที เป็นโครงสร้างเต่าซ้อนเต่าไม่รู้จบ บางทีสิ่งนี้อาจบอกอะไรเกี่ยวกับวงการของ Harness มากกว่าพลังของ “agent” ก็ได้
ดู MS Office ช่วงนี้จะเห็นการเปลี่ยนแปลงเล็กๆ เยอะมาก แต่ส่วนใหญ่ชวนหงุดหงิด เช่น เวลา @แท็กเพื่อนร่วมงานในคอมเมนต์ของ Word แล้วโฟกัสหายไป หรือเวลาจะพิมพ์ในช่องค้นหาของ Outlook ต้องคลิกสองครั้ง หรือเหมือนกับว่า date picker บน Outlook มือถือทำฟีเจอร์ที่เคยแสดงเวลาว่างของฉันกับของผู้เข้าร่วมหายไป
ดังนั้นปริมาณงานอาจดูเยอะ แต่ที่น่าเสียดายคือมันกำลังทำฟังก์ชันที่เคยใช้ได้ดีให้พัง หรือไม่ก็เอาเวลาไปใช้กับเรื่องไม่สำคัญ อย่างแถบสถานะการค้นหาของ OneDrive ที่หมุนวนรอบช่องพิมพ์
คือให้โค้ดส่วนใหญ่ยังอยู่ภายใต้การควบคุมของฉันในฐานะคนขับ ส่วน AI ใช้เพื่อเสริมภาวะลื่นไหลและกำจัดจุดที่ติดขัด อยากให้เครื่องมือสร้างโค้ดจริงๆ ให้น้อยที่สุด
ตลอด 5 เดือนที่ผ่านมา ฉันทำการทดลองแบบเดียวกันที่ tsz[1] และได้ข้อสรุปคล้ายกันมาก ต้องมี Harness เยอะพอสมควรเพื่อบังคับให้เกิด การแยกสถาปัตยกรรม ที่ดี และต้องมีทั้งเทสต์กับ CI เยอะๆ ด้วย
จุดประสงค์ของการสร้าง tsz คือเพื่อเรียนรู้วิธีทำโปรเจ็กต์ขนาดใหญ่มากด้วย AI ท้ายที่สุด workflow และแนวคิดแบบเดียวกันนี้ก็นำไปใช้สร้างแอปผลิตภัณฑ์สำหรับลูกค้าที่มี UI ได้เช่นกัน ดูเหมือนว่า OpenAI จะใช้ทั้ง automated browser test และวิดีโอเป็นส่วนหนึ่งของ workflow ด้วย เมื่อโมเดลดีขึ้น แนวทางการสร้างซอฟต์แวร์แบบนี้ก็น่าจะสมเหตุสมผลในที่สุด แต่ผมคิดว่ายังไปไม่ถึงจุดนั้น อย่างน้อยต่างจากคำกล่าวอ้างกำกวมของ OpenAI ตรงที่เราแชร์ผลลัพธ์ให้ดูได้โดยตรง
โซลูชันอย่าง Lovable ที่ให้ระบบอัตโนมัติระดับสูงมากนั้นดูมองโลกในแง่ดีเกินไปหน่อย และไม่ได้ผูกเข้ากับ automated test จำนวนมากอย่างแนบแน่น
[1] https://github.com/tsz-org/tsz
ตรงกับวิธีที่ฉันทำอยู่เป๊ะเลย Claude/Codex ให้เครื่องมือสำหรับตรวจสอบงานของตัวเองได้ ไม่ว่าจะเป็นเบราว์เซอร์, smoke test, end-to-end test, หรือ local environment ที่มี fidelity สูง
ฉันเก็บบริบททั้งหมดไว้ในรีโพซิทอรี ไม่ว่าจะเป็น issue tracking, เอกสาร, ไอเดีย, แผน, บันทึกงาน (https://github.com/shepherdjerred/monorepo/tree/main/package...)
ฉันให้ Claude/Codex เข้าถึง เครื่องมือ observability อย่าง Grafana, Prometheus, Tempo, PagerDuty และให้มันทำตามแนวปฏิบัติทางวิศวกรรมที่ดี เช่น fail fast, type safety, และการ parsing ที่ขอบเขตของระบบ
แต่ใน homelab ก็ยังไปไม่ถึงระดับอัตโนมัติเต็มตัวเพราะต้นทุนกับภาระของ CI
เมื่อไม่นานมานี้ฉันดูวิดีโอคนงานโรงงานบุหรี่ไฟฟ้า เขาหยิบมัดบุหรี่ไฟฟ้าจากสายพาน เอาเข้าปากแล้วสูบแรงๆ สัก 5 วินาที จากนั้นก็ไปทดสอบมัดถัดไป การที่มนุษย์ต้องรีวิว PR ที่ AI เขียนซึ่งเปลี่ยนไปหลายร้อยบรรทัดก็ไม่ต่างกันมากนัก
แต่ PR ไม่เป็นแบบนั้น PR แย่ๆ แค่อันเดียวอาจร้ายแรงต่อธุรกิจได้ แต่บุหรี่ไฟฟ้าเสียแค่อันเดียวปกติไม่ถึงขั้นนั้น
อีกอย่าง หากวิศวกรซอฟต์แวร์ลองสุ่มตรวจผลลัพธ์จาก AI จะพบว่าคุณภาพตอนนี้ยังไม่ผ่านเกณฑ์ที่อยากได้สำหรับผลิตภัณฑ์อย่างสม่ำเสมอ จึงต้องรีวิวทุก PR และแก้จำนวนมากด้วย
ถ้าจำกัดขอบเขตผลกระทบของการเปลี่ยนแปลงได้ และผลลัพธ์โดยรวมดีพอที่จะยอมรับได้โดยแทบไม่ต้องกำกับ เหลือแค่ตรวจซ้ำว่าไม่มี regression ระดับโรงงาน วิธีแบบสุ่มตัวอย่างก็น่าจะใช้ได้
ฉันเป็นหนึ่งในวิศวกรสามคนที่เขียนบทความนี้ ถ้ามีคำถามก็ตอบได้
ฉันไม่ใช่พวกไม่เชื่อ AI แต่เจตนาของบทความนี้ชวนให้สงสัย มันยก agent-first engineering ขึ้นมาอ้างใหญ่โตโดยอิงจากผลิตภัณฑ์จริง ผู้ใช้จริง และทีมจริงที่กำลังเติบโต แล้วทำให้ดูเหมือนเป็นกรณีศึกษาจริง แต่กลับไม่บอกหรือโชว์เลยว่ากำลังสร้างอะไร เหมือนบทความปั่นกระแส AI อื่น ๆ ทุกอย่าง
สิ่งนี้จะใช้ได้ก็ต่อเมื่อมี ทรัพยากรคอมพิวต์ไม่จำกัด และโทเค็นไม่จำกัดเท่านั้น
จากมุมของคนที่เคยใช้แพลน $20 วิธีแบบ agent ล้วน ๆ แบบนี้เป็นไปไม่ได้เลย เดี๋ยวก็ชนลิมิตเร็วมากและผลงานก็ได้น้อยกว่า
สิ่งที่เวิร์กมากคือให้โค้ดที่มนุษย์เขียนเป็นข้อมูลอ้างอิงแล้วสั่งให้มันขยายต่อ วางโครงสร้างโดยรวม ออกแบบสถาปัตยกรรม และเขียนโค้ดตัวอย่างไว้สักไม่กี่ส่วน เช่น controller, service, model, component, database schema, วิธีทำ auth เพื่อให้ LLM มีฐานให้เริ่มโฟกัสได้
ปกติฉันจะเขียน stub ที่อธิบายวิธี implement ค่อนข้างละเอียด มันเหมือน pseudocode ในระดับ abstraction ที่สูงกว่า จากนั้นค่อยให้ LLM ไปลงมือ implement
ถ้าล้มเหลว หลายครั้งจะดีกว่าถ้าย้อนทุกการเปลี่ยนแปลง แล้วปรับ stub ให้จับความล้มเหลวเดิมได้ก่อนลองใหม่
หรือไม่ก็ commit การเปลี่ยนแปลงไปเลย แล้วให้มันจัดการเฉพาะส่วนที่ผิดในบริบทใหม่
ถ้าเริ่มต้นแบบ agent ตั้งแต่แรก ฉันผิดหวังตลอดทั้งเรื่องผลลัพธ์และลิมิต บางทีก็ชนลิมิตก่อนครบชั่วโมงด้วยซ้ำ
ถ้าอัปเกรดเป็น $200 ต่อเดือนก็ใช้ได้มากขึ้น แต่สำหรับคนใช้หนักแบบฉัน ปริมาณที่ใช้ได้ก็ยังไม่เคยพออยู่ดี
ยังอิจฉาคนที่ได้ usage 200x แค่เพราะตอบรับ RSVP ไปงานปาร์ตี้ของ OpenAI
นี่ก็เป็นอีกบทความขายของแบบหอบแฮก ๆ ขายเสียมให้คนขุดแร่ แล้วทองอยู่ไหน? ผลิตภัณฑ์สุดมหัศจรรย์ที่ สร้างขึ้นจริง จากแชตบอตที่คุยกันบน Git แล้วปั่นโค้ดออกมาเป็นกองอยู่ที่ไหน? มองไม่เห็นเลย
อยากให้โพสต์บล็อกที่ตื่นเต้นแบบนี้ ให้ความรู้ มากกว่านี้
อย่างเช่นช่วยแสดงทีละขั้นว่าต้องตั้งค่า workflow ที่อ้างว่าแรงมากนั้นอย่างไร และสาธิตแบบเป็นรูปธรรม
ฉันไม่ใช่พวกไม่เชื่อ AI ตรงกันข้าม ถ้ามันมีพลังวิเศษจริง ฉันก็ไม่อยากพลาด
สำหรับฟีเจอร์ใหม่จะเขียน feature spec แบบ Gherkin สำหรับการปรับปรุงก็อัปเดตมัน และสำหรับการรีแฟกเตอร์จะไม่แตะต้องมัน ใน PR จะติดป้ายด้วยคำนามพวกนี้
ใช้ pre-push hook รัน type check, lint, unit test และการตรวจสอบอื่น ๆ ที่เร็วและสคริปต์ได้
สร้าง VitePress subsite ไว้ใน repo แล้วให้เอเจนต์เป็นคนดูแล เอกสารหลักการสำคัญ สถาปัตยกรรม ฯลฯ ไว้ในนั้น
สร้างคำสั่ง CLI ที่ลิสต์ทุกหน้าและคำอธิบาย YAML frontmatter เพื่อให้เอเจนต์เลือกอ่านได้โดยไม่ทำให้ context window ระเบิด
ใช้ domain-driven design และ monorepo เขียน logic ไว้ในชั้น headless แล้วค่อยประกอบชั้นต่าง ๆ เป็นแอป เอเจนต์ไล่สำรวจชั้นพวกนี้ได้ดีมาก
ใช้ zod หรือเครื่องมือเทียบเท่าในภาษานั้น ๆ และทำ contract-first API development ส่วนตัวฉันชอบจุดนี้ที่สุด และใช้ orpc
สร้างสกิลเดียวชื่อ “code” แล้วอธิบาย lifecycle ไว้ เปิด worktree ตั้งค่า .env เพื่อไม่ให้ชนกับเอเจนต์ตัวอื่น เลือกพอร์ตที่ยังไม่ใช้ ซึ่ง Docker ช่วยเรื่องนี้ได้ดี เขียนหรืออัปเดตไฟล์ฟีเจอร์ ตกลงสเปกกันตรงนี้ แล้วค่อย implement ตรวจสอบด้วยของอย่าง playwright mcp รันการตรวจสอบก่อน push รอรีวิวหลัง push เก็บกวาด แล้ว fast-forward merge เข้า main
testcontainers ดีมากสำหรับการรับประกันว่าเอเจนต์หลายตัวจะรันเทสต์ได้โดยไม่ชนกัน
เอาจริง ๆ มีสกิลแค่อย่างเดียว ที่เหลือทั้งหมดอยู่ในเอกสาร มันให้ความรู้สึกว่าผลิตภาพสูงมาก ในความหมายของ “สร้างซอฟต์แวร์ที่ดี” ไม่ใช่ในความหมายของจำนวนบรรทัดโค้ด
เพื่อทำแบบนั้น ทุกครั้งที่เอเจนต์เจอปัญหา ฉันจะถามว่าจะใช้เครื่องมือตรวจสอบหรือสคริปต์อะไรแก้ได้บ้าง ระหว่างกระบวนการ audit ก็ให้มันเขียนเครื่องมือพวกนั้นเองด้วย ผลคือทุกวันนี้มี rule สำหรับตรวจ commit มากกว่า 30 ข้อแล้ว[2] และทำงานได้ค่อนข้างดี
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (“โหมดเดโม” จะเห็นได้ถ้าปล่อยไว้จนตัวจับเวลาหมด)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
ตอนแรกก็เคยลองทำแบบนี้ ใช้ ChatGPT เป็น “ผู้จัดการโครงการ” ให้ตั้งค่า harness ทั้งหมดก่อนจะเขียนโค้ด ผ่านไปหนึ่งสัปดาห์ ได้เอกสารกฎ สถาปัตยกรรม และเฟรมเวิร์กออกมามากกว่า 140 ฉบับ แต่จำนวนบรรทัดโค้ดคือ 0 บรรทัด
ต่อมาพอให้เครื่องมืออื่นช่วยตรวจทาน คำตัดสินคือ “ตู้เซฟเปล่าที่ปลอดภัยสมบูรณ์แบบ”
harness ไร้ที่ติ แต่ข้างในไม่มีอะไรเลย
harness สำคัญก็จริง แต่ถ้าไม่ทำควบคู่ไปกับการปล่อยโค้ด ก็เท่ากับว่าแค่เขียน เรื่องแต่ง เท่านั้น