วิศวกรรมฮาร์เนส: ยุคที่การออกแบบสภาพแวดล้อมการทำงานสำคัญกว่าตัวโมเดล

นี่คือบทวิเคราะห์เกี่ยวกับ “วิศวกรรมฮาร์เนส (Harness Engineering)” ที่ Addy Osmani สรุปไว้ เขาวินิจฉัยว่าตลอด 2 ปีที่ผ่านมา ความสนใจของอุตสาหกรรมพุ่งไปที่คำถามว่า “โมเดล AI ตัวไหนฉลาดกว่า” เพียงอย่างเดียว มีการเปรียบเทียบกันไม่รู้จบว่า GPT เขียนโค้ดได้สะอาดกว่าหรือไม่ หรือ Claude มีอาการหลอนน้อยกว่าหรือเปล่า แต่ข้อโต้แย้งของเขาคือ ผลลัพธ์ของ AI สำหรับการเขียนโค้ดในโลกจริงนั้นไม่ได้ถูกกำหนดโดยตัวโมเดลเพียงอย่างเดียว หากแต่ถูกกำหนดโดยฮาร์เนสที่ล้อมรอบโมเดลนั้นเสียมากกว่า คำว่าฮาร์เนสหมายถึงทุกอย่างยกเว้นตัวโมเดล ครอบคลุมทั้ง system prompt ที่ใช้สั่งงาน AI, เครื่องมือและเซิร์ฟเวอร์ภายนอกที่ใช้งานได้, นโยบายการจัดการคอนเท็กซ์, อุปกรณ์ตรวจสอบที่แทรกเข้ามาอัตโนมัติระหว่างการทำงาน (hook), พื้นที่รันที่ปลอดภัย (sandbox), AI ผู้ช่วย (sub-agent), วงจรป้อนกลับ (feedback loop) ไปจนถึงกระบวนการกู้คืนเมื่อการทำงานติดขัด Viv Trivedy ได้ทำให้แนวคิดนี้เป็นทางการด้วยประโยคสั้น ๆ ว่า “AI agent = model + harness” และคนอย่างทีมวิศวกรรมของ Anthropic, HumanLayer, และ Simon Willison ก็กำลังขัดเกลาแนวทางนี้ให้ประณีตยิ่งขึ้น Osmani มองว่ากระแสนี้ได้ตั้งหลักเป็นสาขาวิศวกรรมแขนงหนึ่งแล้ว

เมื่อคลี่ประเด็นสำคัญออกมา จะได้ดังนี้

• ฮาร์เนสคืออะไร AI ไม่อาจกลายเป็นระบบที่ทำงานให้เสร็จได้ด้วยโมเดลเพียงอย่างเดียว ต้องมีทั้งโค้ดและการตั้งค่าที่ช่วยให้มันจำความคืบหน้าได้, เรียกใช้เครื่องมือได้, ดูผลลัพธ์แล้วตัดสินใจใหม่ได้, และป้องกันสิ่งที่ไม่ควรทำได้ จึงจะกลายเป็น “AI ที่ทำงานเป็น” ได้ ผลิตภัณฑ์อย่าง Claude Code, Cursor, Codex, Aider, และ Cline ล้วนเป็นฮาร์เนส และแม้จะใช้โมเดลเดียวกัน พฤติกรรมที่ผู้ใช้สัมผัสได้ก็ยังขึ้นอยู่กับฮาร์เนส Simon Willison อธิบายว่า AI agent คือ “ระบบที่เรียกใช้เครื่องมือซ้ำ ๆ เพื่อให้บรรลุเป้าหมาย” และแก่นของความสามารถก็คือการออกแบบเครื่องมือและโครงสร้างการทำซ้ำเหล่านั้นอย่างไร

• มุมมองที่ว่าไม่ใช่ความผิดของโมเดล แต่เป็นความผิดของการตั้งค่า เมื่อ AI ทำสิ่งแปลก ๆ วิศวกรมักโทษโมเดลและสรุปว่า “รอเวอร์ชันถัดไปเถอะ” แต่วิศวกรรมฮาร์เนสปฏิเสธปฏิกิริยาแบบนี้ หากยืมคำของ HumanLayer มาก็คือ “นี่ไม่ใช่ปัญหาของโมเดล แต่เป็นปัญหาของการตั้งค่า (skill issue)” แม้จะใช้ Claude Opus 4.6 โมเดลเดียวกัน ถ้าอยู่ในฮาร์เนสมาตรฐานอย่าง Claude Code ก็อาจอยู่แถวล่างของ Terminal Bench 2.0 แต่เมื่อย้ายไปใช้ฮาร์เนสที่ปรับแต่งเอง กลับกระโดดขึ้นไปอยู่หัวตารางได้ ทีมของ Viv ก็เคยยกระดับโมเดลเดียวกันจากประมาณอันดับ 30 ขึ้นมาเป็นระดับท็อป 5 ได้เพียงแค่เปลี่ยนฮาร์เนส นั่นหมายความว่าศักยภาพของโมเดลมักถูกฮาร์เนสลดทอนอยู่ไม่น้อย

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

• ออกแบบย้อนกลับจากพฤติกรรมที่ต้องการ วิธีคิดที่มีประโยชน์ที่สุดอย่างหนึ่งที่ Viv เสนอคือ ออกแบบย้อนกลับในลำดับ “เราต้องการพฤติกรรมแบบนี้ → ชิ้นส่วนฮาร์เนสใดที่ทำให้พฤติกรรมนั้นเกิดขึ้นได้” ถ้าไม่สามารถอธิบายได้ในหนึ่งบรรทัดว่าชิ้นส่วนใดมีไว้เพื่อพฤติกรรมอะไร ก็ควรถอดมันออกจะดีกว่า เมื่อลงรายละเอียด ระบบไฟล์และ Git มีไว้เพื่อเก็บรักษางานและย้อนกลับได้ในระยะยาว, bash และการรันโค้ดคือเครื่องมืออเนกประสงค์สำหรับลองทำทุกอย่าง, sandbox คือพื้นที่รันที่ปลอดภัยซึ่งต่อให้พังก็ไม่กระทบตัวระบบหลัก, ไฟล์หน่วยความจำรวมถึงเว็บเสิร์ชและเครื่องมือ MCP คือช่องทางสะสมความรู้ใหม่, การบีบอัดด้วยสรุปและการแยกผลลัพธ์จากเครื่องมือรวมถึงฟังก์ชัน skill คือกลไกขยายข้อจำกัดด้านความจำของ AI, และ Ralph loop กับสถาปัตยกรรมแยก planner / evaluator คือวิธีพางานยาวหลายวันไปจนจบ

• ปัญหา context rot AI มีข้อจำกัดเรื่องปริมาณข้อความที่อ่านได้ในครั้งเดียว และยิ่งเข้าใกล้ขีดจำกัดนั้น ความสามารถในการตัดสินใจก็ยิ่งลดลงอย่างเห็นได้ชัด เพราะฉะนั้นฮาร์เนสจึงเป็นชุดกลไกสำหรับใช้พื้นที่จำกัดนี้ให้คุ้มค่าที่สุดด้วย ประการแรก เมื่อใกล้เต็มขีดจำกัด ก็ต้องสรุปและบีบอัดเนื้อหาเก่าอย่างชาญฉลาด ประการที่สอง สำหรับผลลัพธ์ขนาดใหญ่ เช่น log ยาว 2,000 บรรทัด ให้เก็บไว้เฉพาะหัวกับท้าย แล้วแยกเนื้อหากลางไปไว้ในไฟล์เพื่อค่อยอ่านกลับมาเมื่อจำเป็น ประการที่สาม อย่าแสดงเครื่องมือและคำสั่งทั้งหมดตั้งแต่แรก แต่ใช้วิธี “เปิดเผยแบบค่อยเป็นค่อยไป” โดยแสดงเฉพาะตอนที่งานนั้นจำเป็นจริง ๆ สำหรับงานที่ยาวมาก บางครั้งก็ต้องเริ่มใหม่ในหน้าต่างใหม่โดยถือเอกสารส่งต่องานที่จัดโครงสร้างไว้ Anthropic ชี้ว่า “สำหรับงานยาว การบีบอัดด้วยสรุปอย่างเดียวไม่พอ และอาจมีช่วงที่ต้องเริ่มใหม่ด้วยเอกสารส่งต่องานแบบมีโครงสร้าง” ซึ่งก็คล้ายกับเวลาคนส่งต่องานให้พนักงานใหม่พร้อมเอกสารที่จัดไว้ดีแล้ว

• แพตเทิร์นสำหรับพางานยาวไปต่อ จุดอ่อนอย่างหนึ่งของโมเดลในปัจจุบันคือชอบจบงานเร็วเกินไป, ไม่เก่งในการแตกปัญหาใหญ่ให้เป็นส่วนย่อย, และเมื่อหน้าต่างคอนเท็กซ์เปลี่ยน การไหลของงานก็มักขาดตอน ฮาร์เนสจึงต้องเข้ามาชดเชยจุดอ่อนนี้ Ralph loop เป็นเทคนิคเรียบง่ายที่ hook จะคอยดักทุกครั้งที่โมเดลพยายามจบงาน แล้วฉีดเป้าหมายเดิมกลับเข้าไปในหน้าต่างคอนเท็กซ์ใหม่เพื่อให้ทำงานต่อได้ แต่ละรอบเริ่มจากสถานะสะอาด ทว่าผลลัพธ์ของรอบก่อนยังส่งต่อกันผ่านระบบไฟล์ ขณะเดียวกัน Anthropic เน้นว่าควรแยก “ผู้สร้าง” กับ “ผู้ประเมิน” ออกเป็น AI คนละตัว เพราะถ้าให้ AI ประเมินผลงานของตัวเอง มันมักให้คะแนนตัวเองสูงเกินจริง นอกจากนี้ยังมีแพตเทิร์น “sprint contract” ที่ตกลงกันล่วงหน้าตั้งแต่ก่อนเริ่มงานว่า “เสร็จ” หมายถึงสถานะใด เพื่อกันไม่ให้เป้าหมายค่อย ๆ บวมระหว่างทาง

• บทบาทของ hook “บอก AI ไว้ว่าให้ทำแบบนั้น” กับ “ให้ระบบบังคับให้ทำแบบนั้น” เป็นคนละเรื่องกัน hook คือกลไกอัตโนมัติที่เข้ามาอุดช่องว่างนี้ โดยจะแทรกตัวทำงานในจังหวะอย่างก่อนใช้เครื่องมือ, หลังแก้ไฟล์, ก่อน commit, หรือเมื่อเริ่ม session เช่น รัน syntax check, lint, และ test อัตโนมัติทุกครั้งที่มีการแก้โค้ด, บล็อกคำสั่งเสี่ยงอย่าง rm -rf หรือ git push --force, หรือบังคับให้ขออนุมัติจากมนุษย์ก่อนเปิด PR หลักการคือ “สำเร็จให้เงียบ ล้มเหลวให้ดัง” ถ้าการตรวจผ่าน AI จะไม่ได้ยินอะไรเลย แต่ถ้าล้มเหลว ข้อความ error จะถูกฉีดกลับเข้าไปในโฟลว์ทันทีเพื่อให้มันแก้เองได้ เป็นโครงสร้างที่แทบไม่มีต้นทุนในเวลาปกติ แต่ช่วยได้ตรงจุดเมื่อเกิดปัญหาจริง

• เอกสารกฎและการเลือกเครื่องมือควรสั้นและชัดเจน AGENTS.md ที่วางไว้ใน root ของโปรเจกต์คือไฟล์ตั้งค่าที่ทรงอิทธิพลที่สุด เพราะมันจะถูกใส่เข้าไปใน system prompt ทุกเทิร์น HumanLayer แนะนำให้คงเอกสารนี้ไว้ไม่เกิน 60 บรรทัด ยิ่งยาว น้ำหนักของแต่ละบรรทัดยิ่งจางลง จึงไม่ควรใช้เป็นคู่มือบอกสไตล์ทั่วไป แต่ควรเหลือไว้เฉพาะสิ่งจำเป็นจริง ๆ เหมือนเช็กลิสต์ของนักบิน เช่นเดียวกับเครื่องมือ ชื่อ คำอธิบาย และสคีมาจะถูกฝังเข้าไปในพรอมป์ต์ทุกครั้งที่ร้องขอ ดังนั้นเครื่องมือที่ขัดเกลาดี 10 ตัวจึงดีกว่าเครื่องมือคล้าย ๆ กัน 50 ตัว HumanLayer ยังชี้ประเด็นด้านความปลอดภัยด้วย เพราะคำอธิบายของเครื่องมือก็คือข้อความที่ AI จะอ่าน การต่อ MCP server ภายนอกที่ยังไม่ผ่านการตรวจสอบ จึงอาจกลายเป็นช่องทางให้ใครบางคนแอบฉีดคำสั่งที่เขียนไว้ล่วงหน้าเข้าไปใน AI ได้

ส่วนที่นับเป็นข้อดีได้มีดังนี้

• ชี้ชัดว่าควรลงแรงตรงไหน ข้อมูล benchmark แสดงให้เห็นว่าต่อให้ไม่เปลี่ยนโมเดล ก็ยังยกระดับพฤติกรรมได้มากผ่านฮาร์เนส นั่นหมายความว่าแทนที่จะหวังลอย ๆ ว่า “รอโมเดลตัวถัดไป” ก็มีพื้นที่เฉพาะเจาะจงที่ลงมือปรับได้ทันที
• เป็นโครงสร้างที่สะสมความรู้ได้ วิธีแบบ ratchet ที่เปลี่ยนความผิดพลาดให้เป็นกฎ ทำให้บทเรียนที่เคยเจอครั้งหนึ่งกลายเป็นทรัพย์สินของทีม แม้คนจะเปลี่ยน เอกสารกฎและ hook ก็ยังอยู่เพื่อปกป้องคนถัดไป
• การเกิดขึ้นของฮาร์เนสสำเร็จรูป (HaaS) กระแสที่ Viv เรียกว่า “Harness-as-a-Service” กำลังตั้งหลักอย่างรวดเร็ว ผลิตภัณฑ์อย่าง Claude Agent SDK, Codex SDK, และ OpenAI Agents SDK เริ่มรวมทั้ง work loop, เครื่องมือ, การจัดการคอนเท็กซ์, hook, และ sandbox ไว้ให้ล่วงหน้า ทำให้ไม่ต้องสร้างทุกอย่างเองตั้งแต่ต้น และหันไปโฟกัสที่ความรู้เฉพาะโดเมนของตัวเองได้

แต่ก็มีส่วนที่น่าหนักใจอยู่เช่นกัน

• ขอบเขตที่ต้องดูแลกว้างมาก ทั้งคำสั่ง, เครื่องมือ, พื้นที่รันที่ปลอดภัย, การตรวจสอบอัตโนมัติ, และการสังเกต log ล้วนต้องรับผิดชอบเองทั้งหมด แก่นสำคัญคือมันไม่ใช่พื้นที่ที่ผู้ให้บริการโมเดลจะจัดการให้เอง
• ความเสี่ยงจากการจับคู่กันของโมเดลกับฮาร์เนส โมเดลในปัจจุบันถูกฝึกแบบมี post-processing ภายในฮาร์เนสบางแบบ เมื่อนำไปย้ายฮาร์เนส ประสิทธิภาพจึงอาจตกฮวบได้ทันที แค่เปลี่ยนชื่อเครื่องมือหนึ่งชื่อ หรือรูปแบบอาร์กิวเมนต์เพียงแบบเดียว ผลลัพธ์ก็อาจสั่นคลอน โมเดลที่เป็นสากลจริงไม่ควรถูกกระทบจากชื่อเครื่องมือ แต่เพราะมันถูกฝึกร่วมกับโครงสร้างแวดล้อมเฉพาะ จึงเกิดอาการคล้าย overfitting
• ความเสี่ยงด้านความปลอดภัยของเครื่องมือภายนอก เนื่องจาก AI อ่านคำอธิบายของ MCP server โดยตรง ทันทีที่เชื่อมต่อเครื่องมือที่ยังไม่ผ่านการตรวจสอบ ข้อความจากภายนอกก็เริ่มมีอิทธิพลต่อ AI ได้ตั้งแต่ก่อนที่ผู้ใช้จะพิมพ์อะไรแม้แต่ตัวเดียว

มุมมองที่ทำให้เรื่องนี้แตกต่างคือ

• ถอยห่างจากวาทกรรมที่ยึดโมเดลเป็นศูนย์กลาง แทนที่จะรอ GPT ที่ฉลาดกว่า ก็เสนอแนวทางเชิงวิศวกรรมเพื่อดันขีดจำกัดของโมเดลที่มีอยู่ตอนนี้ให้ไปไกลที่สุด การวินิจฉัยคือ ช่องว่างระหว่างข้อจำกัดของ AI ที่เราเห็นในวันนี้กับความสามารถจริงของโมเดลนั้น ส่วนใหญ่มักเป็น “ช่องว่างของฮาร์เนส”
• ฮาร์เนสไม่ได้หายไป แต่ย้ายตำแหน่ง เมื่อโมเดลดีขึ้น ชิ้นส่วนฮาร์เนสบางอย่างก็หมดความจำเป็น ตัวอย่างเช่น Opus 4.6 แทบลบอาการรีบร้อนแบบ “คอนเท็กซ์ใกล้หมดแล้ว ต้องรีบปิดงาน” ที่พบได้บ่อยใน Claude Sonnet 4.5 ไปได้ ทำให้อุปกรณ์ช่วยพยุงความมั่นใจบางอย่างที่เคยใช้กลายเป็น dead code ไปทั้งชุด แต่ในพื้นที่ใหม่ที่โมเดลเข้าไปแตะได้ ก็จะมีจุดอ่อนใหม่เกิดขึ้น และต้องมีฮาร์เนสใหม่เข้ามาอุดช่องว่างนั้นอีก คำของ Anthropic ที่ว่า “ทุกชิ้นส่วนของฮาร์เนสล้วนแฝงสมมติฐานว่ามีอะไรบ้างที่โมเดลยังทำเองไม่ได้” จึงเข้ากันได้ดีมาก
• วงจรการเรียนรู้ระหว่างโมเดลกับฮาร์เนส อีกกระแสหนึ่งที่ Viv ชี้คือวงจรป้อนกลับระหว่างการออกแบบฮาร์เนสกับการฝึกโมเดล เมื่อพบแพตเทิร์นที่มีประโยชน์ในฮาร์เนส มันจะถูกทำให้เป็นมาตรฐาน จากนั้นโมเดลรุ่นถัดไปก็ถูกฝึกบนมาตรฐานนั้น และบนโมเดลใหม่ก็จะเกิดแพตเทิร์นฮาร์เนสใหม่อีกครั้ง ดังนั้นข้อสรุปก็คือ “ฮาร์เนสที่ดี” ไม่ใช่ฮาร์เนสที่โมเดลถูกฝึกมาด้วย แต่คือฮาร์เนสที่ถูกนำมาขัดเกลาใหม่ให้เข้ากับงานของตนเอง
• อุตสาหกรรมกำลังค่อย ๆ ลู่เข้าหากัน Coding AI อย่าง Claude Code, Cursor, Codex, Aider, และ Cline แม้จะมีโมเดลภายในต่างกัน แต่รูปร่างของฮาร์เนสกลับค่อย ๆ คล้ายกันมากขึ้น ข้อเท็จจริงที่ว่าโมเดลต่างกันแต่ฮาร์เนสเริ่มเหมือนกัน เป็นสัญญาณให้เห็นว่าสาขานี้กำลังลงหลักอยู่ตรงไหน

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

[kimjoin2]

รู้สึกเหมือนมีแต่คำศัพท์การตลาดเพิ่มขึ้นเรื่อย ๆ แบบมหาศาลเลยนะ

[jimmy2056]

ถ้าโมเดลดี ภาระในการออกแบบฮาร์เนสก็จะลดลงด้วย

[akapwhd]

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

[dongho42]

แต่ถ้าพูดในพรอมป์ต์ว่าให้ทำ A และอย่าทำ B แล้วมันเข้าใจได้ดีจริง ๆ วิธีแบบนี้ก็น่าจะใช้ได้ แต่ถ้าการทำตามพรอมป์ต์ของ AI เป็นไปแบบมีความน่าจะเป็นตามสถานะของเซิร์ฟเวอร์ AI วิธีแบบนี้จะยังใช้ได้ผลไหม?

[dongho42]

เมื่อก่อนแม้จะเขียนในพรอมป์ชัดเจนว่าให้ทำ A แต่ก็ยังมีโอกาสอยู่เรื่อย ๆ ที่มันจะไม่ทำตาม เลยลองสารพัดวิธี ทั้งเน้นด้วยตัวหนาแบบ mrkdwn เขียนซ้ำสองรอบ เขียนเป็นภาษาอังกฤษ เขียนแบบรับต้นส่งท้าย เขียนเป็น xml แต่สุดท้ายมันก็ยังเมินพรอมป์อยู่เป็นระยะ ๆ...

[kurthong]

ผมก็ยัดทุกอย่างคล้าย ๆ กับที่ Osmani พูดเหมือนกัน
ตอนที่กำลังทำแอปอยู่ แล้วประเด็นนี้ก็โผล่ขึ้นมา เลยรีบพูดหน่อย
Osmani เองก็อย่าพูดอย่างเดียวเลย
ผมว่าถ้าเอาสิ่งที่ตัวเองพูดไปใส่ไว้ใน Google Anti-Gravity ด้วยก็น่าจะดีกว่าไหม
Karpathy ก็เหมือนกัน ตอนนี้เหมือนไม่คิดจะลงมือทำแล้ว เอาแต่โยนบทความออกมานิด ๆ หน่อย ๆ เฉย ๆ แบบนี้ก็ไม่ค่อยไหร่นะ! ครับ

https://github.com/hang-in/tunaFlow

[blackfabric]

สรุป 3 บรรทัด

• ระบบ (harness) สำคัญกว่าตัวโมเดลในการตัดสินความสำเร็จหรือความล้มเหลว: ประสิทธิภาพของ AI ไม่ได้ขึ้นอยู่กับตัวโมเดลอย่าง GPT หรือ Claude เพียงอย่างเดียว แต่ถูกกำหนดโดยการออกแบบสภาพแวดล้อมการทำงานที่ล้อมรอบมัน เช่น พรอมป์ต์ เครื่องมือ แซนด์บ็อกซ์ และลูปฟีดแบ็ก ซึ่งเรียกรวมว่า harness
• หลักการ 'Ratchet' ที่เปลี่ยนความผิดพลาดให้กลายเป็นกฎ: ไม่ควรมองความผิดพลาดของ AI เป็นแค่อุบัติเหตุชั่วคราว แต่ต้องสะท้อนกลับเข้าไปในเอกสารกฎ (เช่น AGENTS.md) หรือฮุกทันที เพื่อให้ระบบแข็งแรงขึ้นเรื่อย ๆ ตามกาลเวลา
• ปัญหาไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่การตั้งค่า (Skill): บ่อยครั้งที่ AI ทำงานได้ไม่ดี ไม่ใช่เพราะสติปัญญาของโมเดลไม่พอ แต่เพราะการออกแบบ harness ไม่ดีพอ และจำเป็นต้องใช้แนวทางเชิงวิศวกรรมโดยออกแบบส่วนประกอบและข้อจำกัดที่ต้องมี ไล่ย้อนกลับมาจากผลลัพธ์ที่ต้องการ

[yungoun]

แต่ก็แปลกนะ จนถึงแค่สัปดาห์ก่อน Harness ยังขายหนักมากอยู่เลย แต่พอเริ่มสัปดาห์นี้กลับเงียบไปเลย.. ไม่แน่ใจว่าเป็นเพราะ Anthropic ทำพลาดเองกับ Codex 5.5 ที่ทำได้โดดเด่นกว่าด้วยหรือเปล่า........

[click]

อะไรอย่าง SDD นี่กระแส hype ตายไปนานแล้ว ดูเหมือนตอนนี้จะเป็นยุคของ harness แทน
ส่วนที่ค่อนข้างน่าทึ่งของ harness คือ ทั้งที่ในข้อมูลฝึกชัดเจนว่าไม่มี แต่โมเดลกลับเข้าใจแนวคิดที่เรียกว่า harness ได้อย่างรวดเร็ว
ไม่แน่ใจว่าเพราะมันใช้ความหมายเดิมของคำที่มีอยู่แล้วหรือเปล่า ทั้งที่ยังไม่ได้พูดถึงเลย แต่มันก็พูดขึ้นมาก่อนเองประมาณว่าให้ไปอัปเดต harness ก่อน

[kurthong]

นี่เป็นเนื้อหาที่ถึงขั้นวิเคราะห์บทความของนักพัฒนาระดับสูงที่พูดเรื่องไม่ค่อยมีแก่นสารแต่ทำให้ดูน่าเชื่อถือเลยนะครับ (ขออภัยด้วยที่ส่วนตัวผมไม่ค่อยชอบ Google) แน่นอนว่าการพยายามเข้าถึงเพื่อทำความเข้าใจปรากฏการณ์นี้ ผมมองว่าเป็นความพยายามที่ดีครับ