วิธีโอบรับอัจฉริยะที่คาดเดาไม่ได้

• เพื่อลดข้อผิดพลาดซ้ำ ๆ ในผลิตภัณฑ์ AI ที่ให้ผลลัพธ์ต่างกันแม้ใช้คำขอเดียวกัน ควรควบคุมด้วย โค้ดเชิงกำหนดแน่นอน ที่โมเดลฝ่าฝืนไม่ได้ แทนที่จะเพิ่มคำสั่งให้มากขึ้น
• โครงสร้างการควบคุมแบ่งเป็น 4 ชั้น ได้แก่ โมเดล, harness, เอกสาร และ hook โดยมีเพียง hook ที่ทำงานอย่างอิสระภายใต้เงื่อนไขเฉพาะเท่านั้นที่บังคับใช้กฎได้
• งานที่ตัดสินความถูกต้องได้ด้วยโค้ดสามารถรับประกันได้ แต่งานที่ต้องใช้วิจารณญาณ เช่น ข้อผิดพลาดเชิงวิเคราะห์ที่ละเอียดอ่อน ยังคงต้องพึ่งโมเดลอีกครั้ง ดังนั้นแม้โมเดลจะพัฒนาไป ช่องว่างของการตรวจสอบ ก็ไม่หายไป
• ผลิตภัณฑ์ AI ต้องมี harness engineering เพื่อแยกแยะว่าส่วนใดจะปล่อยให้โมเดลตัดสิน และส่วนใดต้องรับประกันด้วยโค้ด หากควบคุมน้อยไปก็ให้คำตอบผิด หากควบคุมมากไปก็กลายเป็นซอฟต์แวร์ทั่วไปที่มีราคาแพง
• หากทุกคนสามารถเช่าใช้โมเดลเดียวกันได้ ชั้นห่อหุ้ม (wrapper) ที่สะสมมาตรฐาน โค้ด ข้อมูล และสภาพแวดล้อมการเชื่อมต่อของแต่ละผลิตภัณฑ์ จะกลายเป็นความได้เปรียบในการแข่งขันที่ป้องกันได้ และการเติบโตของ Cursor แสดงให้เห็นสิ่งนี้

---

ย้ายกฎในเอกสารมาเป็นโค้ด

• แม้จะห้ามพฤติกรรมบางอย่างไว้ในไฟล์ที่ Claude Code อ่านทุกเซสชัน แต่บางครั้งมันก็เข้าใจและยอมรับเนื้อหาแล้วกลับทำพฤติกรรมเดิมซ้ำ
• เมื่อย้ายกฎมาเป็นโค้ดที่บล็อกคำสั่งทันทีเมื่อเงื่อนไขครบ พฤติกรรมต้องห้ามก็หยุดลงโดยไม่ขึ้นกับการตัดสินของโมเดล
• ต้นทุนการตรวจทานเอาต์พุต AI ที่ The Verification Tax กล่าวถึง สามารถลดลงได้ด้วยวิศวกรรมในขั้นต้นน้ำ แทนที่จะเพิ่มการตรวจทานภายหลัง
• แม้โครงสร้างควบคุมขั้นต่ำที่สร้างโดยคนคนเดียวและเครื่องมือส่วนตัว ก็มีรูปแบบเดียวกับปัญหาที่ผลิตภัณฑ์ AI ขนาดใหญ่ต้องแก้
• แนวทางปฏิบัติที่เชื่อมโยงประเภทความล้มเหลวกับชนิดของ hook และจัดระเบียบขอบเขตที่วัดได้ในแต่ละชั้น ดูได้ใน โพสต์ X แยกต่างหาก

สี่ชั้นที่ประกอบกันเป็นการควบคุม

• อำนาจการควบคุมประกอบด้วย สี่ชั้น ที่ยิ่งขึ้นไปด้านบนก็ยิ่งเข้มแข็งขึ้น
  • โมเดล: แม้จะเก่งอย่าง Claude Opus 4.8 หรือ GPT-5.5 ก็ยังอาจให้คำตอบต่างกันสำหรับคำขอเดียวกัน และไม่มีคำสั่งใดลบคุณสมบัตินี้ได้อย่างสมบูรณ์
  • Harness: เช่น Claude Code, Codex, OpenClaw ทำหน้าที่รันโมเดลและกำหนดว่าโมเดลจะเห็นอะไร แต่ทำได้เพียงชี้นำทิศทางใหญ่ ๆ
  • เอกสาร: CLAUDE.md และ AGENTS.md เก็บความชอบ บริบทโปรเจกต์ กฎ และการแก้ไขที่สะสมมา แต่โมเดลจะนำไปตัดสินร่วมกับข้อมูลอื่น จึงอาจไม่ปฏิบัติตาม
  • Hook: โค้ดที่เฝ้าดูสถานการณ์เฉพาะแล้วทำงานอย่างอิสระ โดยบล็อกคำสั่งต้องห้ามไม่ว่าโมเดลจะเห็นด้วยหรือไม่
• ในบรรดาสี่ชั้นนี้ มีเพียง hook ชั้นบนสุดเท่านั้นที่ไม่ต่อรอง
  • กฎที่ย้ายไปเป็น hook จะถูกโมเดลเลี่ยงไม่ได้ ทำให้ข้อผิดพลาดซ้ำหายไป และลดขอบเขตที่มนุษย์ต้องตรวจทาน

พื้นที่ของการตัดสินที่โค้ดรับประกันไม่ได้

• พื้นผิวที่ต้องควบคุมลดลงได้ แต่ปิดได้ไม่ทั้งหมด
  • เงื่อนไข “อย่ารันคำสั่งนี้” ตรวจสอบได้ด้วยโค้ด
  • เงื่อนไข “อย่าให้การวิเคราะห์ไหลไปในทิศทางที่ผิดอย่างละเอียดอ่อน” ต้องใช้วิจารณญาณ และโมเดลอีกตัวที่มาตัดสินก็มีความคาดเดาไม่ได้อีกเช่นกัน
• ระบบที่พิสูจน์เอาต์พุตได้จริงจะเปรียบเทียบเกณฑ์และผลลัพธ์ที่มนุษย์เขียนไว้ล่วงหน้าด้วยโค้ด และทำงานได้เฉพาะใน ขอบเขตที่นิยามคำตอบที่ถูกต้องได้อย่างแม่นยำ เท่านั้น
• แม้โมเดลจะอัปเกรด ปัญหาเรื่องการตัดสินก็ไม่หายไป ดังนั้นชั้นควบคุมที่ห่อหุ้มโมเดลยังคงจำเป็น

• การรับประกันบนฐานข้อกำหนดแบบเป็นทางการ

  • SEVerA สามารถรับประกันได้ว่าเอาต์พุตของเอเจนต์เป็นไปตามสัญญาแบบเป็นทางการ แต่ต้องเขียนสัญญาไว้ล่วงหน้าเป็น ตรรกะเชิงรูปแบบ และใช้ได้เฉพาะพื้นที่ที่ตรวจสอบแบบนี้ได้
  • VeriGuard เพิ่มความปลอดภัยที่ผ่านการตรวจสอบให้กับเอเจนต์ LLM แต่ผู้ใช้ยังคงต้องตรวจสอบด้วยตนเอง
  • ขั้นตอนที่ LLM แปลเจตนาของผู้ใช้เป็นกฎแบบเป็นทางการนั้นเองก็ยังคาดเดาไม่ได้
  • การรับประกันที่มีผลจริงจึงพึ่งพา การตรวจสอบแบบตายตัว ตามข้อกำหนดที่มนุษย์เขียนไว้ในท้ายที่สุด
  • “เอเจนต์ที่ปรับปรุงตัวเอง” ประเมินผลลัพธ์ที่เกิดขึ้นเพื่อปรับปรุงการทำงานครั้งต่อไป แต่ต่างจากวิธีพิสูจน์ว่าเอาต์พุตหนึ่ง ๆ ถูกต้อง

ห่อหุ้มเครื่องยนต์เชิงความน่าจะเป็นด้วยซอฟต์แวร์เชิงกำหนดแน่นอน

• การทดสอบซอฟต์แวร์แบบดั้งเดิมพัฒนามาจากการกำหนดเอาต์พุตที่ต้องการและคำตอบที่ถูกต้องหนึ่งเดียว แล้วตรวจสอบโค้ดที่คาดเดาได้
• ผลิตภัณฑ์ AI-native มี เครื่องยนต์เชิงความน่าจะเป็น ที่ให้ผลต่างกันแม้ใช้พรอมป์เดียวกันเป็นศูนย์กลาง จึงทำให้สมมติฐานของการทดสอบแบบเดิมพังลง
• อย่างที่ Hamel Husain ชี้ไว้ วินัยการทดสอบซอฟต์แวร์ที่สร้างกันมาหลายสิบปีตั้งอยู่บนสมมติฐานว่ามีคำตอบที่ถูกต้องหนึ่งเดียว แต่ใน AI คำตอบนั้นหายไปพอดี
• นักพัฒนาหลายคนกำลังมาบรรจบกันที่วิธีคงเครื่องยนต์ที่คาดเดาไม่ได้ไว้ แต่ห่อหุ้มด้วย โค้ดเชิงกำหนดแน่นอน ที่ทำงานเหมือนเดิมทุกครั้ง
  • 12-factor agents ของ Dex Horthy นิยามเอเจนต์ที่ดีว่าเป็นระบบที่ “ประกอบด้วยซอฟต์แวร์เป็นส่วนใหญ่”
  • building effective agents ของ Anthropic แนะนำให้รันงานผ่าน “เส้นทางโค้ดที่กำหนดไว้ล่วงหน้า” และเพิ่ม “การตรวจสอบแบบโปรแกรม”
• ใน Claude Code สามารถเลือกวิธีตรวจสอบเงื่อนไขได้
  • หากโค้ดตัดสินผ่านหรือไม่ผ่านอย่างอิสระ ก็จะได้ การรับประกัน
  • หากให้โมเดลตัดสินว่าเงื่อนไขครบหรือไม่ ก็จะได้เพียงผลการตัดสิน

• Skills และ /goal ของ Claude Code

  • Skills เป็นขั้นตอนที่มีโครงสร้างซึ่งเอเจนต์เรียกใช้ได้ แต่โมเดลเป็นผู้เลือกว่าจะรันหรือไม่และอาจออกนอกทางระหว่างทางได้ จึงอยู่ใน ชั้นเอกสาร
  • /goal ทำให้งานดำเนินต่อไปจนกว่าจะตรงตามเงื่อนไขที่ระบุ จึงใกล้เคียงกับชั้นบังคับ
  • อย่างไรก็ตาม หลังทุกเทิร์น โมเดลขนาดเล็กและรวดเร็วจะตัดสินว่าเงื่อนไขครบหรือไม่ จึงอาจตัดสินผิดได้เหมือนโมเดลอื่น
  • /goal เป็นฟีเจอร์ที่ห่อ Stop hook และใน Stop hook ที่เขียนเอง สคริปต์สามารถตัดสินผ่านหรือไม่ผ่านอย่างอิสระแทนโมเดลได้
  • เอกสาร Claude Code แยกสองวิธีไว้อย่างชัดเจน คือใช้ สคริปต์ สำหรับการตรวจสอบเชิงกำหนดแน่นอน และใช้โมเดลสำหรับการตรวจสอบที่ต้องใช้วิจารณญาณ

เมื่อการตั้งค่าส่วนบุคคลขยายสู่ระดับองค์กร

• ในสภาพแวดล้อมส่วนบุคคล หากเอเจนต์เพิกเฉยต่อกฎหนึ่งข้อ ก็อาจเสียเวลาเพียงไม่กี่นาที และกรณีสำคัญสามารถกันไว้ด้วย hook ส่วนตัว
• ใน บริษัทขนาด 200 คน ที่ใช้เอเจนต์เดียวกัน สมาชิกแต่ละคนไม่ได้มี hook ส่วนตัว และกฎอาจถูกรวมไว้ในไฟล์แชร์ไฟล์เดียว
• หากกฎที่แชร์ถูกเพิกเฉยหนึ่งครั้ง ปัญหาเดียวกันอาจปรากฏทุกที่ที่ไฟล์นั้นถูกเรียกใช้ และระดับการปกป้องขององค์กรจะถูกกำหนดโดยกฎที่เขียนไว้อย่างหลวมที่สุด
• โครงสร้างการควบคุมเหมือนกับการตั้งค่าส่วนบุคคล แต่เมื่อขนาดใหญ่ขึ้น ต้นทุนของข้อผิดพลาด ก็เปลี่ยนไป

อะไรควรรับประกัน และอะไรควรเปิดไว้

• คู่มือสถาปัตยกรรม agent-native ของ Every นิยามฟีเจอร์ไม่ใช่โค้ดที่ถูกเขียนขึ้น แต่เป็น “ผลลัพธ์ที่อธิบายไว้ ซึ่งเอเจนต์ที่ทำงานอยู่ในลูปทำให้สำเร็จ”
• แนวทางนี้ปล่อยให้โมเดลเคลื่อนไหวแบบฉับพลันและออกแบบผลิตภัณฑ์โดยยึดผลลัพธ์เป็นศูนย์กลาง แต่ในจุดที่ต้องควบคุม ก็ต้องกลับมาหาโค้ดอีกครั้ง
  • แนะนำให้ย้าย hot path ซึ่งเป็นเส้นทางที่เกิดบ่อยหรือสำคัญ ไปเป็นโค้ด
  • ยอมรับว่างานบางอย่างต้องมีการตรวจสอบที่ไม่ควรปล่อยให้เป็นการตัดสินของเอเจนต์
• การออกแบบผลิตภัณฑ์ที่มีโมเดลเป็นศูนย์กลางกับวิศวกรรมที่มีการควบคุมเป็นศูนย์กลางดูเหมือนตรงข้ามกัน แต่ทั้งคู่จัดการสถาปัตยกรรมเดียวกันจากคนละปลาย
• ในการออกแบบจริง ต้องตัดสินว่าจะตรึงจุดใดของผลิตภัณฑ์ไว้ด้วยโค้ด และตรึงถึงระดับใด
  • หากตรึงไว้น้อยเกินไป แม้แต่งานที่ต้องมีการรับประกัน โมเดลก็อาจตัดสินแบบฉับพลันและส่งคำตอบผิดที่ดูมั่นใจให้ลูกค้า
  • หากตรึงไว้มากเกินไป ทุกเส้นทางจะกลายเป็นซอฟต์แวร์ทั่วไปที่เขียนด้วยโค้ด และโมเดลก็ทำงานที่โค้ดเดิมทำอยู่แล้วในแบบที่ช้ากว่าและแพงกว่า
• Harness engineering ตามที่ทีม OpenAI เรียก คือการแบ่งสัดส่วนอย่างตั้งใจในแต่ละจุดของผลิตภัณฑ์ ว่าส่วนใดต้องใช้การตัดสินของโมเดล และส่วนใดต้องใช้การรับประกันจากโค้ด

ชั้นห่อหุ้มที่สะสมได้นานกว่าโมเดล

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

ชั้นควบคุมที่ Cursor สะสมไว้

• Cursor เครื่องมือเขียนโค้ดด้วย AI ไม่ได้สร้างโมเดลเอนกประสงค์ของตัวเอง แต่ส่งคำขอไปมาระหว่าง Claude, GPT, Gemini และ Grok โดยมองโมเดลเหมือนสินค้าที่เช่าใช้ได้
• แม้ Claude Code ของ Anthropic จะเข้าถึงโมเดลชั้นยอดก่อน ก็ไม่สามารถแทนที่ Cursor ได้
• รายได้ของ Cursor เพิ่มจากประมาณ 1 พันล้านดอลลาร์ เมื่อเดือนพฤศจิกายนปีที่แล้ว เป็นประมาณ 4 พันล้านดอลลาร์ในเดือนมิถุนายน
• SpaceX ใช้ออปชันที่ได้มาในเดือนเมษายนเมื่อสัปดาห์ที่แล้ว และตกลงซื้อ Cursor ในราคา 60 พันล้านดอลลาร์ ซึ่งเป็นดีลซื้อกิจการสตาร์ทอัพที่มีเงินลงทุนจาก VC มูลค่าสูงที่สุดเป็นประวัติการณ์
• สิ่งที่ Cursor สะสมไว้ไม่ใช่โมเดลเอนกประสงค์ที่ดีกว่า แต่เป็นชั้นที่ห่อหุ้มผลิตภัณฑ์
  • ดัชนี codebase ที่ซิงก์ที่เก็บโค้ดทั้งหมดและคงให้อยู่ในสถานะค้นหาได้
  • โมเดล autocomplete ของตนเองที่เรียนรู้จากการแก้ไขหลายร้อยล้านครั้งต่อวัน ว่านักพัฒนายอมรับหรือปฏิเสธข้อเสนอแบบใด
  • สภาพแวดล้อมการเชื่อมต่อระดับองค์กรที่ฝังตัวอยู่ในบริษัท Fortune 500 ส่วนใหญ่
• แม้บริษัทโมเดลจะมีโมเดลที่ดีกว่า ก็ไม่ได้เป็นเจ้าของเอดิเตอร์ ดัชนี และ พฤติกรรมการใช้งาน ของนักพัฒนา

คำถามที่ตัดสินความยั่งยืนของผลิตภัณฑ์ AI-native

• กรณีที่สร้างชั้นควบคุมอย่าง Cursor ยังมีไม่มาก และคนส่วนใหญ่ที่ใช้ AI ในงานยังไม่ได้สร้างชั้นห่อหุ้มแบบนี้ หรือไม่รู้ด้วยซ้ำว่ามีอยู่
• ในระดับบริษัท วิธีสร้างชั้นนี้คือสิ่งที่แยกผลิตภัณฑ์ AI-native ที่ทนต่อการใช้งานจริง ออกจากเดโมน่าประทับใจบนโมเดลที่ใครก็เช่าใช้ได้
• แม้ foundation model จะกลายเป็นของฟรี คำถามว่าอะไรยังคงเหลืออยู่ จะเป็นตัวตัดสิน สินทรัพย์ที่ยั่งยืน ของผลิตภัณฑ์