Software Engineering กับ Harness Engineering: 10x หรือ Technical Debt

ลองนึกภาพร้านก๋วยเตี๋ยวเจ้าเก่าที่ขายดีมา 20 ปี วันดีคืนดีพี่มาวินมารีวิวลง TikTok แล้วลูกค้าทะลักเข้ามา 10 เท่า เตาเดิม หม้อเดิม พนักงานเท่าเดิม แต่ Order เพิ่มเป็น 10 เท่า

หัวข้อ Software Engineering at the Tipping Point ของ Adam Bender ที่พูดในงาน Google I/O คือการลองเปลี่ยนจากร้านก๋วยเตี๋ยวเป็น Developer Ecosystem ถ้า AI Agents ทำให้งาน Software Engineering เพิ่มขึ้น 10–15 เท่าในอีก 18 เดือน คุณรู้ไหมว่าอะไรจะพังก่อน?

ในเวลาเดียวกัน OpenAI และ Anthropic ก็พยายามแก้ปัญหานี้ด้วยสิ่งที่เรียกว่า Harness Engineering

Software Ecology

แนวคิดเรื่อง Software Ecology มอง Developer Environment ขององค์กรเป็น Socio-Technical Ecosystem คำนี้สื่อว่าการทำ Software ไม่ใช่แค่เรื่องของคอมพิวเตอร์ แต่ประกอบด้วย 2 ส่วนที่แยกจากกันไม่ได้:

• Socio : มนุษย์และกระบวนการ ตัวคุณ เพื่อนร่วมทีม ผู้บริหาร วัฒนธรรมองค์กร รูปแบบการทำงาน (เช่น Agile, Scrum) ตลอดจนวิธีที่คนในทีมสื่อสารและมีปฏิสัมพันธ์ร่วมกัน
• Technical: เครื่องไม้เครื่องมือต่าง ๆ ชุดโค้ดที่เขียน Programming Languages ระบบ Cloud หรือแม้แต่เทคโนโลยี AI ที่นำมาประยุกต์ใช้

ใครสนใจลองไปฟังพี่รูฟอธิบายเรื่อง Socio-Technical Architecture ได้นะ สนุกดี

10x Moment

มีคำกล่าวว่าโลกของ Software คือ Trade-off ทุกการตัดสินใจเมื่อได้ 1 สิ่ง จะต้องแลกมากับ 1 อย่างเสมอ บ่อยครั้ง 1 อย่างที่ว่า เปลี่ยนแปลงไปเป็นหนี้ทางเทคนิคหรือที่เรียกว่า Technical Debt ก่อนไปต่ออยากให้เข้าใจ 4 คำนี้ก่อน

• Deploy: กระบวนการนำ Code ที่เสร็จแล้วขึ้นไปบน Environment ต่างๆ เช่น DEV, UAT หรือ PROD
• Release: การเปิดให้ End-user เข้าถึง Feature บน Production Environment
• Output: สิ่งที่ทำเสร็จและส่งมอบเรียบร้อยแล้ว เช่น เขียน API เสร็จ 10 เส้น, เพิ่ม Feature ใหม่ๆ
• Outcome: ความเปลี่ยนแปลงที่เกิดขึ้นตามมาจาก Output เช่น System ประมวลผลเร็วขึ้น 50%, User เพิ่มขึ้น 30% หลังจากปล่อย UI ใหม่

สมมติว่าพรุ่งนี้บริษัทตัดสินใจนำ AI มาช่วยเขียน Code สิ่งที่จะเกิดขึ้นคือ ทีมพัฒนาจะ Generate Code และ Feature ได้เยอะขึ้น 10x คำถามต่อมาคือเราเอา 10x นั่นไปอยู่ตรงไหน

Adam Bender ถามใน Talk ว่า คุณ Release บ่อยแค่ไหน? สมมุติ หากทีมของคุณสามารถ Release ได้รายวัน ถือว่าทำได้ดีในระดับมาตรฐานอุตสาหกรรม Software แล้ว ความท้าทายในยุคที่ AI ช่วยเขียนโค้ดได้เร็วขึ้น 10x หากคุณยังคงรอบการ Release เท่าเดิม จะทำให้ปริมาณการ เปลี่ยนแปลง (Change set) ต่อการ Release หนึ่งครั้งมีขนาดใหญ่ขึ้น

ตัวอย่างเช่น เรา Release เดือนละครั้ง สิ่งที่หลีกเลี่ยงไม่ได้คือการดอง Code 10x จำนวนมหาศาล ระดับ Super Extra Large Changes และหากเกิด Bug ระหว่าง Deploy การหา Root Cause จะทำได้ยากมาก และนี่คือจุดเริ่มต้นของการต้องเปิด War Room นั่นหมายความว่าตรงนี้คือ 10x ของทีมคุณ

Release แบบรายอาทิตย์ ปัญหา Code ก้อนใหญ่จะลดลง แต่จะเจอคอขวดใหม่เรื่อง Cost และ Build Time แทน เพราะทุกครั้งต้องเสียเวลา Setup Environment และ Run Automated Test ซึ่งในแต่ละ Level จะยิ่งทวีคูณ ตั้งแต่ Unit Test, Integration Test, E2E Test เวลาที่ใช้รอตั้งแต่สั่ง Build จน Test ผ่านครบทุกด่านจะนานขึ้นเรื่อย ๆ จนเราต้องมานั่ง Optimize Pipeline กันอย่างหนัก ท้ายที่สุดเพื่อลดคอขวดเรื่องเวลา ก็อาจต้องแก้ปัญหาด้วยการ Scale Resource ทั้งการเพิ่มสเปก Build Server และเปิด Test Environment คู่ขนานกันหลายตัว

สำหรับทีมที่สามารถขยับความถี่มาถึง Stage ที่ Release ได้มากกว่า 1 ครั้งต่ออาทิตย์ แปลว่าสามารถก้าวข้าม Limitation ด้าน Risk และ Infrastructure มาได้แล้ว (มั้ง)

โจทย์ใน Stage นี้จึงไม่ใช่ Speed ในการเอา Code ขึ้น Server แต่คือการตั้งคำถามว่าควร Release Feature ไหนให้ User ใช้งานดี วัดผลอย่างไร จะเปลี่ยนผ่านจาก Output หรือ Task ที่ Deliver ในระดับ 10x ไปสู่ Outcome หรือ Business Impact ได้ยังไง เราต้องหันมา Focus ว่า Feature ที่ทำออกไปช่วยแก้ Pain Point ให้ User ได้จริงหรือไม่ เพิ่มยอด Conversion Rate ได้แค่ไหน หรือลด Operation Time ของทีมได้กี่ชั่วโมง เพื่อให้แน่ใจว่างานที่ทำไปสร้าง Impact ได้อย่างแท้จริง

ใช่ครับ ที่เล่ามาทั้งหมดคือมุมมองแบบ Cross-functional team แต่หากองค์กรยังมีโครงสร้างแบบแยก Role ของ Dev, QA DevOps และ Designer ชัดเจน การเพิ่มความเร็วฝั่ง Technical น่าจะส่งผลประมาณนี้มั้ง (ผมแอบคิดไปเอง):

• Dev: ใช้ AI ผลิต Code ได้เร็วขึ้น 10 เท่า กลายเป็นการสร้างงานส่วนเกินที่ Focus แค่ Output แล้วผลักภาระคิวงานไปขั้นตอนถัดไป
• QA: ศักยภาพและ Process การทดสอบยังใช้ความเร็วเท่าเดิม งานปริมาณมหาศาลจึงไปกระจุกตัวสะสม กลายเป็นคอขวดที่ทำให้ภาพรวมสะดุด และเสี่ยงที่บั๊กจะหลุดรอดเพราะต้องเร่งระบายคิว
• DevOps: กระบวนการจัดการ Pipeline และ Environment ยังมีขีดจำกัดเท่าเดิม โค้ดที่รอต่อคิวจำนวนมากจึงนำไปสู่ปัญหา Code Conflict บ่อยขึ้น และไม่สามารถดันงานขึ้น Production ได้ทัน
• Designer: ผลิต Requirement และออกแบบ UI/UX ไม่ทันความเร็วของ Dev ทำให้เกิดภาวะคอขวดตั้งแต่ต้นน้ำ หรือจำใจส่งสเปกที่ยังไม่สมบูรณ์ให้ Dev ทำจนเกิดการรื้อแก้ซ้ำซาก

จุดนี้สอดคล้องกับ Conway’s Law ใน Team Topologies ที่ว่าโครงสร้าง Software ที่องค์กรสร้างขึ้น มักจะสะท้อนรูปแบบการสื่อสารและโครงสร้างของคนในองค์กรนั้น ๆ

มาดูมุมมองอีกฝั่งที่มี Unlimited AI Tokens และมองว่าบทบาทของมนุษย์ต้องเปลี่ยนจาก Coder ไปเป็น Architect กัน

Harness Engineering

หาก Software Engineering คือศาสตร์แห่งการออกแบบและสร้างระบบซอฟต์แวร์ที่เชื่อถือได้ Harness Engineering ก็คือศาสตร์แห่งการวางระบบที่ควบคุมให้ AI Agent ผลิตโค้ดที่ถูกต้องออกมาได้อย่างต่อเนื่อง โดยลดภาระการทำ Code Review ของมนุษย์ให้เหลือน้อยที่สุด

Philipp Schmid จาก Hugging Face เปรียบเทียบระบบของ AI Agent ว่าเหมือนกับสถาปัตยกรรมคอมพิวเตอร์

ลองจินตนาการว่า Model ของ AI คือ CPU ที่มีพลังประมวลผลสูง และมี Context Window เป็นเหมือน RAM โดยมีตัว Agent เป็นเหมือน Application ที่รันขึ้นมาเพื่อทำงานเฉพาะทางให้เรา แต่ระบบทั้งหมดนี้จะทำงานไม่ได้เลย หากขาด Harness ซึ่งทำหน้าที่เปรียบเสมือน OS คอยกำหนด Policy ควบคุมให้ CPU และ RAM ให้ทำงานร่วมกัน

Harness Engineering ถูกพูดถึงครั้งแรกโดย Mitchell Hashimoto, co-founder ของ HashiCorp ตอนนั้นเขาไม่แน่ใจด้วยซ้ำว่ามีคำศัพท์ที่เรียกกันในวงการหรือยัง?

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

หลังจากนั้น 6 วัน (วันที่ 11 กุมภาพันธ์ 2026) ทาง OpenAI (เอาอีกแล้ว) ก็เป็นผู้จุดประกายคำนี้อย่างเป็นทางการผ่านบล็อกโพสต์ชื่อ “Harness Engineering” โดยเล่าเบื้องหลังที่ทีม Codex ปล่อยโค้ดขึ้น Production กว่า 1 ล้านบรรทัดโดยที่มนุษย์ไม่ได้เขียนเอง ด้วยกระบอกเสียงของ OpenAI ที่ดังกว่าใครเพื่อน จุดนี้เลยกลายเป็นจุดเริ่มต้นแห่งความสนุก

ผมจะใช้ Use Case จาก OpenAI และ Anthropic ในการอธิบายแนวคิดนี้ ประการแรกเลย อยากให้ทุกคนเข้าใจว่า 2 บริษัทนี้เป็นบริษัทพัฒนา AI และแน่นอนว่าพวกเขามี Resource มหาศาล (อย่างน้อยตอนนี้ก็มี)

OpenAI สร้างโปรเจกต์แอปพลิเคชัน เช่น แอป Sora บน Android โดยให้ AI เขียนโค้ดแบบ 100% ปัญหาคือเมื่อ Code ไปแตะระดับ 1 ล้านบรรทัด ส่งผลให้กระบวนการทำงานแบบเดิมใช้ไม่ได้ ไม่มี Engineering คนไหนสามารถนั่งทำ Code Review ในโค้ดหลักล้านบรรทัดเพื่อหา Bug ได้ และอีกปัญหาที่เจอคือ หากป้อน Prompt ยาวๆ เป็นคู่มือ 1,000 หน้า AI จะลืม Context และเริ่มมั่ว มันจะเริ่มเรียกใช้ API ที่ไม่มีอยู่จริง หรือสร้างไฟล์ผิดที่ผิดทาง

OpenAI เสนอแนวคิด Environment-First Harness ดังนี้

• Distributed Context: แทนที่จะโยน Requirement ก้อนใหญ่ให้ AI ทีเดียวจนหลุด Focus เขาใช้วิธีสร้างไฟล์ AGENT.md, SKILL.md ฝังกระจายไว้ในทุก Module บังคับให้ AI ต้องอ่านเพื่อทำความเข้าใจ Context, Architecture และ Status งานปัจจุบันก่อนเริ่มเขียน Code ทุกครั้ง เสมือนการทำ Onboarding ให้ AI รู้ว่าตัวเองอยู่ตรงไหนของ System
• Strict Dependency Flows: ป้องกันปัญหา AI เขียน Code ข้ามขั้นตอนจน Structure พัง จึงมี Step แบบตายตัวคือ Types ➔ Config ➔ Repo ➔ Service ➔ Runtime ➔ UI เพื่อบังคับให้ AI สร้าง Infrastructure ให้เสร็จก่อนจะ Jump ไปทำส่วน UI
• CI/CD (Automated Feedback): เลิกใช้คนมานั่งทำ Code Review เพราะ Volume โค้ดของ AI มหาศาลเกินไป แต่ใช้ระบบ CI/CD เข้ามา Run Test ทันทีที่ AI เขียน Code เสร็จ ถ้าพัง ระบบจะโยน Error กลับไปสั่งให้ AI แก้ไขเองวนไปจนกว่าจะผ่าน

หลังจาก OpenAI ปล่อยบทความได้ไม่กี่สัปดาห์ Anthropic ก็ตีปล่อย Paper ออกมารวดเดียว 3 ฉบับ (เกี่ยวกับ Effective harnesses, Harness design และ Managed agents) ปัญหาของ Anthropic เมื่อสั่งให้ AI ตรวจโค้ดที่ตัวเองเพิ่งเขียน มันจะเข้าข้างตัวเองและรายงานว่างานสมบูรณ์แบบเสมอ ทั้งที่ความจริงโค้ดพังและแอปใช้งานไม่ได้

Anthropic นำเสนอแนวคิดการทำงานเป็น Multi-Agent 3 ตัว โดยแตกฟังก์ชันออกเป็น 3 Components ที่ทำงานแยกขาดจากกัน

1. Planner Agent: รับ Requirement มาซอยเป็น Tasks ย่อย
2. Generator Agent: ทำหน้าที่เป็น Worker เขียนโค้ดตาม Implementation Tasks
3. Evaluator Agent: ทำหน้าที่เป็น Black-box Testing รันสคริปต์ยิงผ่าน Browser หรือ API เพื่อจับผิดตัว Generator โดยเฉพาะ ถ้าคิดภาพไม่ออกให้นึก E2E Testing Tools เช่น playwright, cypress

การทำ Decoupling แยกตัวเขียนโค้ดกับตัวตรวจโค้ดออกจากกัน แก้ปัญหา AI เข้าข้างตัวเองได้จริง แต่ Trade-off ที่หลีกเลี่ยงไม่ได้คือ Cost ที่พุ่งกระฉูดและเกิดความซับซ้อนในการทำ Orchestration ระหว่าง Agent ตามมา

ในทางทฤษฎี Harness Engineering เหมือนจะเป็นตัวจบที่เข้ามาช่วยคุม AI ให้ผลิตโค้ดได้อย่างมีประสิทธิภาพ แต่พอเอามา Implement จริงในสเกล Enterprise มันกลับมีราคาที่ต้องจ่าย และสร้าง Pain point ใหม่ๆ ให้ทีม Dev ไม่น้อย

Cost & Latency

Anthropic ลองทำท่า Multi-Agent (ใช้ AI 3 ตัวคุยและตรวจงานกันเอง) ผลคือ Cost พุ่งจาก $9 เป็น $200 แถมใช้เวลาปาไป 6 ชั่วโมง บางที Agent ตีกันเอง เผา Token ทิ้งฟรี ๆ สุดท้าย Dev ก็ต้องเหนื่อยมาเขียน Code เพื่อทำ Orchestration คิวงานให้อยู่ดี

**The Test-Passing Illusion **OpenAI ลองใช้ CI/CD มารัน Automated Test ดักไว้ สิ่งนี้บอกได้แค่ว่า Code ไม่พัง แต่ไม่ได้แปลว่า Architecture ดี งานอาจจะรันผ่านฉลุย แต่ Maintain ต่อไม่ได้ ยิ่งถ้าเป็น Greenfield Project ที่ยังไม่สรุปสถาปัตยกรรม การไปตั้ง Rule ก็ไม่ต่างจากการนั่งเทียนเขียน

**ตลกร้ายที่เรียกว่า Harness Decay **มันคือสภาวะที่ Harness กลายเป็น Technical Debt ทันทีที่ AI อัปเกรดตัวเองจนฉลาดขึ้น โค้ดที่เราเคยเขียนเพื่ออุดช่องโหว่เก่า ๆ กลับกลายมาเป็นตัวถ่วงที่ทำให้ System ช้าและเปลือง Cost ฟรี ตัวอย่างเช่น

Anthropic:

• Opus 4.5: AI ยังหลงทางง่าย ต้องสร้าง System แบ่ง Tasks ย่อยมาคุม
• Opus 4.6: AI เริ่มมอง Context รวมเก่งขึ้น Dev เลยต้องลบ System ที่ทำหน้าที่แบ่ง Task ทิ้งไป เพราะถ้าไม่ลบจะทำให้เสีย Cost ไป 40% ฟรีๆ
• Opus 4.7: ระบบที่ Self-evaluate เขียน Code ไว้ซับซ้อนเพื่อคอยตรวจจับข้อผิดพลาด (ใน Opus 4.5) พอมาถึง Opus 4.7 ที่โมเดลตรวจงานตัวเองได้ (Self-evaluate) ตัว Agent ตรวจงานที่แยกไว้ต่างหากนี้ไม่ได้ช่วยเพิ่ม Quality อะไรให้ระบบ แต่กลับคอยสูบ Token และทำให้ระบบทำงานช้าลง

Manus / LangChain: AI โตไวมาก Manus ต้องรื้อ System ใหม่ 5 รอบใน 6 เดือน ส่วน LangChain รื้อ 3 รอบใน 1 ปี เพราะว่าองค์กรก็ต้องรับกรรมกับการจ่ายค่า Token ฟรีแถม System อืด เนื่องจาก AI Model มีการอัปเดต

Vercel: ทีมลองลบ Tools ของ AI ทิ้งถึง 80% ผลคือ AI ทำงานได้แม่นขึ้น เพราะพอ AI ฉลาดแล้ว การยัดเยียด Rule หรือ Tool เยอะไปยิ่งทำให้ AI มันสับสน

A Decision Framework

แนวทางเลือกใช้ให้เหมาะกับสเกลและสถานการณ์ของคุณ

• Solo Dev หรือทีมเล็กๆ : เริ่มที่ท่าง่าย ๆ เน้นความคล่องตัว ลองใช้แนวทางของ OpenAI ด้วยการเพิ่มไฟล์ AGENT.md หรือ CLAUDE.md ไว้ใน Repo เพื่อใช้เป็นไกด์คอยคุม Context ให้ AI ทำงานได้ตรงจุดมากขึ้น
• Enterprise หรือมีหลายทีม: พอคนเยอะและต้องทำงานข้ามทีม เลิกมองการแก้ปัญหาเป็นรายโปรเจกต์ได้เลยครับ ให้มองภาพใหญ่ระดับ Infrastructure แทน แนะนำให้เริ่มจากระบบที่มีอยู่แล้วอย่าง Linters, Tests, CI และนำแนวคิด Architecture Fitness Harness เข้ามาช่วยหาช่องโหว่ ส่วนตัวผมยังไม่ค่อยเชื่อเรื่องการให้ AI ช่วยรีวิวโค้ดแบบ 100% แต่ถ้าบริษัทคุณมี Budget และปริมาณโค้ดมันมหาศาลจนใช้คนรีวิวไม่ไหวแล้วจริง ๆ ค่อยเริ่มนำ Evaluation Loop (Post-build review) มาใช้ ให้ AI ตัวหนึ่งเขียนโค้ด แล้วใช้อีกตัวมาทำ Code Review เพื่อดักจับ Bug อย่าลืมระวังเรื่อง AI Edit War ด้วย เพราะ Token ที่มันเถียงกันคือเงินเรา สิ่งนี้จะช่วยอุดช่องโหว่ที่ Automated Test ทั่วไปอาจมองข้าม
• Finance, Healthcare ฯลฯ: ในจุดนี้ Harness จะมีสถานะเทียบเท่ากับ Control Framework ให้คิดเผื่อ Auditor ไว้ล่วงหน้าเลย การใช้สถาปัตยกรรมที่เก็บ Log แบบแก้ไขไม่ได้ (Append-only event log) ไม่ว่าคุณจะวางกลยุทธ์เก็บ Log แยกตามแต่ละ Domain หรือจะรวบศูนย์เป็น Centralized Audit Service ก็ตาม (ผมเองก็ยังไม่เคยทำจริงจังนะครับ อาศัยอ่านและศึกษามาอีกที)

เรากำลังอยู่ในช่วงรอยต่อที่สำคัญ การตัดสินใจว่าอะไรคือ Technical Debt นั่นอยู่ที่ตัวคุณ ทีมคุณและวัฒนธรรมองค์กรคุณ ส่วนตัวผมชอบแนวทางที่ Adam Bender ที่ฝากไว้ในช่วงท้ายของ Talk

• Own Your Agency: คุณคือ Architect of Change ที่มีอำนาจตัดสินใจว่าจะวางรากฐานทางวิศวกรรมขององค์กรไปในทิศทางใด
• Radical Mentorship: ในยุคที่ความรู้ใหม่เกิดขึ้นทุกวัน การก้าวไปข้างหน้าคนเดียวไม่มีความหมาย จงเปลี่ยนความเชี่ยวชาญส่วนตัวให้เป็นมาตรฐานของทีม แบ่งปัน Workflow ที่เวิร์ก เพื่อให้ทุกคนก้าวผ่านขีดจำกัดเดิมไปด้วยกัน
• Systems Thinking: เลิกโฟกัสแค่การปั่นงานรายชิ้นให้เสร็จทีละอย่าง เพราะงานในยุคนี้ทุกส่วนเชื่อมโยงกันหมด หากจะสร้างระบบที่แข็งแรง คุณต้องมองให้ออกว่าการเปลี่ยนจุดหนึ่งจะส่งผลกระทบไปถึงไหน

AI เป็นเพียง เครื่องขยายสัญญาณ (Amplifier) หากพื้นฐานการทำงานหรือวัฒนธรรมองค์กรของคุณไม่ดีพอ AI ก็จะขยายความผิดพลาดให้ใหญ่ขึ้นตามไปด้วย ดังนั้นก่อนจะวิ่งให้เร็วขึ้น 10x ต้องมั่นใจก่อนว่า ทิศทาง และ รากฐาน ของเราแข็งแรงพอ — Adam Bender

Conclusion

เมื่อก้าวเข้าสู่ยุคที่ AI Agents ทำให้เกิด 10x Moment ในโลกของการพัฒนาซอฟต์แวร์ แนวคิดอย่าง Software Ecology และ Harness Engineering แท้จริงแล้วทั้ง 2 วิธีนี้ไม่ได้แก้ปัญหาที่เกิดขึ้น แต่พูดถึงเรื่องเดียวกันในมุมมองที่ต่างกัน

Software Ecology มองผ่านเลนส์ของ Socio-Technical Ecosystem ที่เชื่อมโยงฝั่ง คน และ เครื่องมือ เข้าด้วยกัน มุมมองนี้เน้นย้ำว่าการเร่งสร้าง Output ให้เร็วขึ้น 10 เท่าด้วย AI อาจยิ่งทวีคูณ Technical Debt หากกระบวนการ Deploy, Release หรือโครงสร้างของ Cross-functional team ไม่พร้อมรองรับปริมาณงานที่ทะลักเข้ามา

ในขณะที่ Harness Engineering มองผ่านเลนส์ของ System Architecture โดยมุ่งเน้นไปที่การสร้าง Environment หรือวาง Framework (เช่น CI/CD, Distributed Context หรือ Multi-Agent) เพื่อตีกรอบให้ AI เขียน Code ได้ถูกต้องและทำงานแทนมนุษย์ได้มากที่สุด แม้จะต้องเผชิญกับ Trade-off ด้าน Cost, Latency หรือความเสี่ยงที่ Framework เหล่านั้นจะกลายเป็น Harness Decay เมื่อ AI อัปเกรดตัวเองจนฉลาดขึ้นก็ตาม

Refs

• https://ai.gopubby.com/harness-engineering-what-every-ai-engineer-needs-to-know-in-2026-0ab649e5686a
• https://www.youtube.com/watch?v=2n41YjR5QfU&list=PLOU2XLYxmsIJp39MsvkeWYYNwMso-HeNT&index=2&t=1920s