ใน repo ที่ทีมวิศวกรรมของ 10X บริษัทที่ปรึกษาและแล็บด้าน AI เรียกกันเองว่า "meta harness" ไม่มีโค้ดโปรแกรมอยู่เลยแม้แต่บรรทัดเดียว ทั้งที่ปกติ repo จะมีไว้เก็บโค้ด แต่ข้างในนี้กลับมีเพียงไฟล์ Markdown หรือไฟล์ข้อความธรรมดาที่จัดโครงสร้างหัวข้อไว้ ตอนที่ทีมงานเปิดให้ดู ภายในมีเอกสาร 3 กลุ่มหลัก คือ epics สำหรับคุมเป้าหมายใหญ่ 6 ชิ้น, specs สำหรับรายละเอียดทางเทคนิค 20 ชิ้น และ docs สำหรับข้อตกลงร่วมของทีมอีก 35 ชิ้น

Alex Lieberman ผู้ร่วมก่อตั้ง 10X เล่าว่า ถ้าต้องแกะรอยว่าคู่แข่งสร้างผลิตภัณฑ์ชิ้นหนึ่งขึ้นมาได้อย่างไร เขาอยากได้โฟลเดอร์เอกสารชุดนี้มากกว่าโฟลเดอร์โค้ดทั้งหมดเสียอีก เหตุผลนั้นตรงไปตรงมา เพราะโค้ดบอกได้แค่ว่า "ระบบมีอะไรอยู่บ้างในปัจจุบัน" แต่ไม่เคยบอกเลยว่า "ทำไมถึงต้องสร้างสิ่งเหล่านั้นขึ้นมา"

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

แยกเอกสารออกจากโค้ด แล้วจัดโครงสร้างให้เป็นระบบ

10X เลือกแยกโปรเจกต์ออกเป็น 2 repo ตั้งแต่แรก ฝั่งหนึ่งคือ repo สำหรับโค้ดจริง ส่วนอีกฝั่งคือ repo ที่รวบรวมเอกสารทั้งหมด โดยตั้งใจแยกสองส่วนนี้ออกจากกันอย่างเด็ดขาดไม่ให้ปะปนกัน

ในฝั่งเอกสาร ทุกไฟล์จะจัดแบ่งเป็น 3 หมวดหมู่ที่มีโครงสร้างชัดเจน ไม่ใช่กองเอกสารที่ปล่อยให้ใครอยากเขียนอะไรก็เขียน:

• epics ระบุภาพรวมว่าตอนนี้กำลังสร้างอะไร รวมถึงเป้าหมายและหมุดหมายสำคัญของโปรเจกต์
• specs เอกสารทางเทคนิคเชิงลึก ครอบคลุมทั้งงานสถาปัตยกรรมระบบและงานย่อยที่ต้องลงมือทำ
• docs แหล่งรวบรวมข้อมูลส่วนอื่นๆ ที่สำคัญ โดยเฉพาะ convention ที่เป็นข้อตกลงร่วมกันของทีมว่าต้องเขียนโค้ดรูปแบบไหน

ทีม 10X เรียกแนวคิดนี้ว่า context as code หมายถึงการดูแลบริบทหรือข้อมูลแวดล้อมของโปรเจกต์ให้เหมือนกับการดูแลโค้ด นั่นคือต้องจัดโครงสร้าง มีระบบคุมเวอร์ชัน และตรวจสอบความถูกต้องได้ ไม่ใช่แค่ไฟล์โน้ตที่เขียนทิ้งไว้แล้วไม่มีใครกลับมาดูอีก

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

ทุก session ของ agent เริ่มจากบริบทชุดเดียวกัน

ปัญหาคลาสสิกที่ทุกคนมักพบเมื่อทำงานกับ AI คือ agent จะไม่รู้ว่า session หรือรอบการทำงานก่อนหน้าทำอะไรไปแล้วบ้าง พอเปิดหน้าต่างแชตใหม่ ความเข้าใจเกี่ยวกับโปรเจกต์ก็กลับไปเริ่มต้นที่ศูนย์ ผู้ใช้จึงต้องคอยเล่าบริบทเดิมซ้ำๆ ทุกครั้ง

10X แก้ปัญหานี้ด้วยการใช้ hook ตอนเริ่ม session ที่เป็นกลไกแทรกคำสั่งอัตโนมัติก่อนที่ agent จะเริ่มทำงานจริง ทุกครั้งที่เปิด session ใหม่ ระบบจะป้อนบริบทสำคัญจาก repo เอกสารให้ agent ทันทีตั้งแต่ประโยคแรก ทีมงานแซวกันเองว่านี่คือ "prompt injection ฉบับหวังดี" เพราะเป็นการแอบส่งข้อมูลเข้าไปในบทสนทนาโดยที่ตัว agent เองไม่ได้ร้องขอ

ผลลัพธ์คือ agent ทุกตัวจะเริ่มต้นงานด้วยความพร้อมระดับเดียวกับวิศวกรที่อ่านเอกสารโปรเจกต์มาอย่างถี่ถ้วน ไม่ใช่คนแปลกหน้าที่เพิ่งเดินเข้าห้องประชุม ถ้าคุณเคยอ่านเรื่อง agent harness มาก่อน ส่วนนี้ก็คือชั้นบริบทของ harness ที่ทีมทุ่มเทพัฒนามากที่สุด

สิ่งที่ต้องแลกถ้ามองข้ามขั้นตอนนี้มักจะตามมาสร้างปัญหาให้ทีหลังเสมอ เพราะถ้าไม่มีระบบป้อนบริบทอัตโนมัติ เราจะต้องเสียเวลาพิมพ์อธิบายภาพรวมโปรเจกต์ใหม่ทุกเช้า และวันไหนที่อธิบายไม่ครบถ้วน agent ก็จะเริ่มเดา convention เอาเอง แล้วทิ้งโค้ดที่มีรูปแบบผิดเพี้ยนจากเดิมไว้ให้มนุษย์ตามล้างตามเช็ด ยิ่งในโปรเจกต์ขนาดใหญ่ที่มีไฟล์จำนวนมากจนบริบทล้นหน้าต่าง ปัญหา ขีดจำกัดของ context window หรือพื้นที่ความจำในแต่ละรอบของ AI ก็จะกลายเป็นอุปสรรคขัดขวางการทำงานอีกชั้นหนึ่งทันที

เอกสารก็เพี้ยนจากงานจริงได้เหมือนกัน

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

10X จึงพัฒนาเครื่องมือ CLI สำหรับใช้งานภายในขึ้นมา ซึ่งใช้ได้ทั้งคนและตัว agent เอง เช่น คำสั่ง 10x context ใช้สรุปสถานะของเอกสารทั้งหมดในระบบ หรือ 10x skills status ใช้รายงานว่าขณะนี้มีสกิลอะไรพร้อมให้ agent เรียกใช้บ้าง แต่คำสั่งที่น่าสนใจที่สุดคือ 10x validate

10x validate จะรันกฎกว่าร้อยข้อเพื่อไล่ตรวจว่าเอกสารแต่ละชิ้นเกิด documentation drift หรือคลาดเคลื่อนไปจากงานจริงแล้วหรือยัง Dan หัวหน้าฝ่ายวิศวกรรมของ 10X เปรียบเทียบการทำงานของมันว่าคล้ายกับโปรแกรมตรวจความเรียบร้อยอย่าง linter แต่เป็นการตรวจกระบวนการทำงานและเอกสารทั้งระบบ ไม่ใช่แค่ตรวจไวยากรณ์ของโค้ด

ตัวอย่างข้อผิดพลาดที่ระบบจับได้บ่อย เช่น ใน spec ระบุว่าฟีเจอร์นี้ทำเสร็จสมบูรณ์แล้ว แต่งานย่อยข้างในกลับยังค้างอยู่อีกหลายใบ ปัญหาลักษณะนี้แทบไม่มีทางมองเห็นได้ด้วยตาเปล่าถ้ามีเอกสารอยู่หลายสิบชิ้น และถ้าปล่อยทิ้งไว้ agent ก็จะอ่านแล้วเข้าใจผิดว่างานส่วนนั้นเสร็จแล้ว จนไปสร้างงานถัดไปทับลงบนสิ่งที่ยังสร้างไม่เสร็จจริง

วางแผนสี่ชั่วโมง แล้วพิมพ์คำสั่งบรรทัดเดียว

Dan เล่าถึงช่วงเวลาที่ระบบนี้เห็นผลชัดเจนที่สุด ตอนที่เขาใช้เวลาราว 4 ชั่วโมงวางแผนและออกแบบสถาปัตยกรรมอย่างละเอียด จากนั้นจึงพิมพ์คำสั่งเพียงบรรทัดเดียว แล้วปล่อยให้ agent ทำงานต่อเนื่องไปตลอดทั้งคืน:

/goal /10x-process/execute project-spec

เวลา 4 ชั่วโมงนั้นไม่ได้สูญเปล่า แต่เปลี่ยนเป็น spec คุณภาพสูงที่ agent หยิบไปลงมือทำต่อได้ทันทีโดยไม่ต้องวกกลับมาถามซ้ำอีก

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

นอกจากนี้ Dan ยังมีกฎเหล็กเรื่องการแบ่งงานที่ชัดเจนมาก คือให้ agent เขียนโค้ดเองให้ได้มากที่สุดเท่าที่จะทำได้ ส่วนงานที่ AI ยังทำแทนไม่ได้จริงๆ เช่น การเข้าไปตั้งค่าบนแดชบอร์ดของฐานข้อมูลภายนอกอย่าง Supabase ก็จะให้ agent สรุปขั้นตอนออกมาเป็นข้อๆ เพื่อให้มนุษย์เข้าไปตั้งค่าตามทีละขั้นตอน

ระบบเดียวกันนี้ Alex เอาไปทำคอนเทนต์

สิ่งที่ทำให้เรื่องนี้น่าสนใจเป็นพิเศษสำหรับคนที่ไม่ได้เขียนโค้ด คือ Alex นำโครงสร้างแบบเดียวกันนี้ไปประยุกต์สร้างระบบผลิตคอนเทนต์ส่วนตัว โดยแบ่งสถาปัตยกรรมออกเป็น 2 ชั้นที่ไม่ปะปนกัน:

• ชั้นกระบวนการ (Process Layer) เก็บไว้บน Git ซึ่งเป็นระบบคุมเวอร์ชันของทีม ทำหน้าที่เป็น pipeline หรือขั้นตอนการทำงานกลางแบบตายตัวที่ทุกคนหยิบไปใช้ร่วมกันได้
• ชั้นข้อมูลส่วนตัว (Personal Layer) เป็นไฟล์เฉพาะในเครื่องของแต่ละคน เก็บไฟล์ voice ที่บันทึกน้ำเสียงและสำนวนการเขียนเฉพาะตัว รวมถึงบทเรียนจากการทำงานรอบก่อนๆ ดังนั้น ใครจะหยิบ pipeline นี้ไปรันก็ได้ แต่ผลงานที่ได้จะยังคงเอกลักษณ์และสำนวนภาษาของเจ้าของเครื่องเสมอ

กระบวนการผลิตคอนเทนต์จะดำเนินไปตามลำดับขั้นตอน โดยแต่ละขั้นออกแบบมาเพื่อแก้ปัญหาเฉพาะทาง:

• เลือกผู้เขียน (Identity Selection): เลือกว่ากำลังจะผลิตคอนเทนต์ในนามของใคร เพื่อให้ระบบดึงไฟล์ voice และบทเรียนเฉพาะตัวของบุคคลนั้นมาใช้งานตลอดทั้งกระบวนการ
• ขั้นค้นหาไอเดีย (Idea Discovery): ระบบจะสแกนข้อมูลการทำงานรอบ 7 วันล่าสุดภายในบริษัทจาก Slack, Notion, Gmail, Linear และ Git พร้อมติดตามกระแสภายนอกจาก Reddit, X, YouTube และ Hacker News เพื่อค้นหาประเด็นที่คนพูดถึงมากผิดปกติ จากนั้นจะคัดกรองไอเดียเด่นๆ ราว 15 หัวข้อ แล้วเก็บไว้ในคลังข้อมูลกลางที่ทีมเรียกว่า "The Vault"
• ขั้นค้นคว้าข้อมูลเชิงลึก (Deep Research): สืบค้นงานวิจัยและเอกสารต้นฉบับ ติดตามความเคลื่อนไหวล่าสุด สำรวจว่าประเด็นไหนที่ตลาดพูดถึงไปจนช้ำแล้ว และยังมีคำถามสำคัญข้อไหนบ้างที่ยังไม่มีใครตอบ
• ขั้นสัมภาษณ์สกัดไอเดีย (Interview): ระบบจะสัมภาษณ์ผู้ใช้ผ่าน AI Personas 6 รูปแบบ ซึ่งเป็นบทบาทจำลองที่เลียนแบบสไตล์การถามของพิธีกรชื่อดังอย่าง Tim Ferriss หรือ Joe Rogan ผู้ใช้สามารถพิมพ์หรือพูดโต้ตอบผ่าน Claude Code ประมาณ 20 นาที ถ้าคำตอบดูกว้างหรือคลุมเครือเกินไป ระบบจะถามจี้เพื่อให้เจาะลึกในรายละเอียดทันที
• ขั้นร่างและขัดเกลา (Drafting): ระบุรูปแบบงานที่ต้องการ แล้วระบบจะดึงสกิลที่บันทึกสไตล์การเขียนของคนๆ นั้นในรูปแบบดังกล่าวมาช่วยเรียบเรียงให้ลื่นไหล โดยยังรักษาใจความและน้ำเสียงของเจ้าของเรื่องไว้อย่างครบถ้วน
• ขั้นตรวจประเมินคุณภาพ (Critique & Review): ส่งงานให้ Personas อีกชุดหนึ่งช่วยตรวจและให้คะแนน พร้อมใช้ตัวตรวจจับข้อความกลวงๆ สไตล์ AI หรือ AI fluff ถ้าคะแนนประเมินไม่ถึง 9 เต็ม 10 ระบบจะต้องวนกลับไปปรับแก้ใหม่
• ขั้นดัดแปลงคอนเทนต์ (Content Repurposing): นำเนื้อหายาว 1 ชิ้นมาดัดแปลงเป็นคอนเทนต์ย่อยรูปแบบต่างๆ ได้ราว 10 ชิ้น โดยชิ้นงานย่อยแต่ละชิ้นก็ต้องกลับไปผ่านขั้นตอนการตรวจประเมินคุณภาพรอบเดิมอีกครั้ง

แต่ขั้นตอนที่มีค่าที่สุดกลับเป็นขั้นตอนสุดท้ายที่ดูเรียบง่ายที่สุด เพราะหลังจากจบงานแต่ละรอบ ผู้ใช้จะให้ฟีดแบ็กกับระบบว่ามีจุดไหนที่ทำได้ดี และจุดไหนที่ยังไม่น่าพอใจ จากนั้นระบบจะบันทึกข้อสรุปกลับลงไปในไฟล์ contentlessons.md เพื่อนำมาตรวจเช็กก่อนเริ่มงานรอบถัดไปเสมอ นี่คือหัวใจของ ระบบที่ค่อยๆ ปรับตัวเองจากการใช้งานจริง ไม่ใช่ระบบที่ต้องสมบูรณ์แบบตั้งแต่วันแรก

เริ่มจากไฟล์เดียวก่อนก็ได้

ตัวเลขที่ Alex ยกมาอาจฟังดูไกลตัวสำหรับใครหลายคน เพราะเขามีคลังพอดแคสต์เก่าถึง 350 ตอน และโพสต์บนโซเชียลมีเดียอีกร่วม 10,000 ชิ้น ให้ระบบนำไปวิเคราะห์และถอดน้ำเสียงของตัวเอง แต่เขายืนยันว่าคนทั่วไปไม่จำเป็นต้องมีข้อมูลมหาศาลขนาดนั้นก็เริ่มต้นได้ทันที

สำหรับคนที่แทบไม่เคยโพสต์คอนเทนต์อะไรมาก่อนเลย เขาเสนอทางเลือก 3 ทางตามความสะดวก:

1. ให้ระบบสัมภาษณ์เราด้วยเสียง แล้วสรุปผลลัพธ์ออกมาเป็นไฟล์ voice
2. ป้อนข้อความเก่าๆ ที่เราเคยพิมพ์ เช่น แชตสนทนา อีเมล หรือข้อความในที่ทำงาน เพื่อให้ระบบช่วยถอดรูปแบบสำนวนออกมา
3. ยืมไฟล์ voice ของคนอื่นมาใช้เป็นร่างตั้งต้น แล้วค่อยๆ ป้อนฟีดแบ็กปรับแก้ไปเรื่อยๆ จนกลายเป็นสำนวนที่เป็นตัวเราเอง

ถ้าอยากเริ่มต้นในวันนี้ ไฟล์ 2 ไฟล์ที่คุ้มค่ากับการลงแรงมากที่สุด คือไฟล์ที่อธิบายว่า "งานลักษณะนี้ ที่นี่มีวิธีทำอย่างไร" หรือไฟล์กำหนดแนวทางปฏิบัติ และไฟล์ที่บันทึกว่า "รอบที่แล้ว เกิดข้อผิดพลาดตรงไหน" หรือไฟล์รวมบทเรียนที่ผ่านมา ทั้งสองไฟล์นี้ไม่ต้องพึ่งพาเครื่องมือไฮเทคใดๆ เป็นแค่ไฟล์ข้อความธรรมดา แต่กลับเป็นสิ่งที่ AI agent อ่านแล้วเปลี่ยนพฤติกรรมการทำงานได้ทันที

ข้อควรระวังที่ทีมงานย้ำเตือนไว้อย่างชัดเจนคือ ระบบเหล่านี้ไม่ได้เข้ามาแทนที่ทักษะพื้นฐานทางวิศวกรรมของมนุษย์ สำหรับคนที่พื้นฐานยังไม่แน่นแล้วหันมาพึ่งพา AI อย่างหนัก AI จะยิ่งขยายนิสัยการทำงานเดิมออกมาเป็นร้อยเท่า เพราะสุดท้ายแล้ว มนุษย์ยังต้องเป็นคนประเมินและตัดสินใจว่า แผนงานและสถาปัตยกรรมที่ agent เสนอขึ้นมานั้นถูกต้องและใช้การได้จริงหรือไม่

สิ่งที่ระบบนี้ขยายจริงๆ

ในยุคที่ใครๆ ก็คัดลอกโค้ดได้ง่ายกว่าที่เคย Alex มองว่าสิ่งที่มีค่าที่สุดและลอกเลียนแบบได้ยากเหลืออยู่เพียง 2 อย่าง คือ คนที่พร้อมลงมือทำสิ่งต่างๆ ด้วยตนเองโดยไม่ต้องรอคำสั่ง และ ความไว้วางใจจากกลุ่มคนที่ติดตามเราอยู่ และกองเอกสารที่จัดเรียงไว้อย่างสวยหรูก็ไม่ใช่ทั้งสองสิ่งนี้

เพราะเครื่องมือเหล่านี้ไม่ได้ช่วยคิดแทนใคร แต่ทำหน้าที่เร่งวิธีคิดที่เรามีอยู่เดิมให้ทำงานได้ไวขึ้นหลายเท่าตัว ทั้งในส่วนที่เราคิดมาอย่างรอบคอบแล้วและส่วนที่ยังคิดไม่ถี่ถ้วน คำถามสำคัญจึงไม่ใช่แค่ "เราจะวางระบบให้ AI agent ทำงานอย่างไร" แต่คือ "สิ่งที่เรากำลังจะบรรจงเขียนลงในไฟล์แรกนั้น มีค่ามากพอให้ระบบนำไปใช้ซ้ำแล้วซ้ำเล่าในทุกๆ วันหรือยัง"