Harness Engineering เมื่อมนุษย์เป็นคนบังคับทิศ และ AI Agent เป็นคนลงมือเขียนซอฟต์แวร์

สรุปจากคลิป ดูคลิปต้นฉบับ

มีบางไอเดียที่พอฟังจบแล้วทําให้เรารู้ทันทีว่า วิธีทํางานเดิมกําลังจะไม่เหมือนเดิมอีกต่อไป แนวคิดเรื่อง Harness Engineering ของ Ryan Lopopolo เป็นหนึ่งในนั้น เพราะมันไม่ได้พูดแค่ว่า AI ช่วยเขียนโค้ดได้ดีขึ้น แต่กําลังเสนอภาพใหม่ของงานวิศวกรรมซอฟต์แวร์ทั้งระบบ ว่าจากนี้ไปมนุษย์อาจไม่ใช่ “คนพิมพ์โค้ด” เป็นหลักอีกแล้ว เรากลายเป็นคนกําหนดงาน วางข้อจํากัด ตั้งมาตรฐาน และออกแบบสภาพแวดล้อมให้ agent ทํางานแทนเราได้ยาวๆ

จุดที่ทําให้แนวคิดนี้ทรงพลัง ไม่ใช่คําโฆษณาเรื่อง productivity แต่คือการย้ายคําถามสําคัญจาก “จะเขียนโค้ดอย่างไร” ไปเป็น “จะสร้างระบบอย่างไรให้ agent เขียนโค้ดได้ดีพอที่จะเชื่อใจ” ฟังดูเหมือนแค่เปลี่ยนเครื่องมือ แต่จริงๆ แล้วมันคือการเปลี่ยนบทบาทของวิศวกรไปอีกขั้น

บทความนี้สรุปและวิเคราะห์แนวคิดทั้งหมดของ Harness Engineering ตั้งแต่มุมมองเรื่อง “code is free” ไปจนถึงวิธีสร้าง guardrails, review agents, test structure, การออกแบบ repository ให้เหมาะกับ model context และภาพระยะถัดไปที่มนุษย์เป็นคน steer ส่วน agents เป็นคน execute อย่างเต็มตัว

เมื่อโค้ดไม่ใช่ทรัพยากรที่หายากอีกต่อไป

ประโยคที่กระแทกที่สุดประโยคหนึ่งคือ “Code is free” หรือโค้ดผลิตได้แทบไม่จํากัด ถ้ามองด้วยสายตาแบบวิศวกรรมดั้งเดิม ประโยคนี้อาจฟังขัดใจ เพราะโค้ดมีต้นทุนดูแล มีภาระบํารุงรักษา และมีความเสี่ยงสะสมเสมอ แต่ Ryan กําลังชี้ให้เห็นความจริงอีกแบบว่า ต้นทุนการ “สร้าง” โค้ดในโลกที่มี coding agents เก่งพอ ไม่ใช่คอขวดอีกแล้ว

ถ้าเมื่อก่อนข้อจํากัดคือจํานวนคนที่นั่งหน้าคีย์บอร์ด วันนี้ข้อจํากัดเริ่มย้ายไปอยู่ที่ GPU capacity, token budget, human attention และ context window แทน ความหมายของเรื่องนี้ใหญ่กว่าที่เห็น เพราะเมื่อ implementation ไม่ใช่ส่วนที่แพงที่สุดอีกต่อไป ทักษะที่มีค่าก็เปลี่ยนตามทันที

เราเริ่มเห็นชัดว่าบทบาทวิศวกรซอฟต์แวร์กําลังขยับไปทาง systems thinking, system design, delegation และ specification มากขึ้น คนที่ได้เปรียบไม่ใช่คนพิมพ์เร็วที่สุด แต่เป็นคนที่กําหนดปัญหาได้คม วางระบบได้ดี และถ่ายทอด “นิยามของงานที่ดี” ให้เครื่องทําต่อได้โดยไม่หลุดมาตรฐาน

มุมนี้น่าสนใจมาก เพราะมันไม่ใช่การลดความสําคัญของวิศวกร แต่เป็นการปรับงานวิศวกรรมให้เข้าใกล้งานออกแบบระบบจริงๆ มากขึ้น ถ้าแต่ก่อนเราใช้เวลาส่วนมากไปกับการลงแรงทํา ตอนนี้เราอาจต้องใช้เวลาส่วนมากไปกับการออกแบบวิธีให้แรงงานอัตโนมัติทําแทนได้

ทรัพยากรที่หายากจริงๆ ในยุค AI coding agents

Ryan เสนอกรอบคิดที่เรียบง่ายแต่คมมากว่า ในโลกใหม่ของการสร้างซอฟต์แวร์ สิ่งที่หายากมีอยู่แค่ไม่กี่อย่าง

• เวลาของมนุษย์
• attention ของมนุษย์และของโมเดล
• context window ของโมเดล

กรอบนี้ช่วยให้เราจัดลําดับการลงทุนได้ชัดขึ้นมาก ถ้าเวลาคนแพงที่สุด เราไม่ควรเอาเวลาไปไล่แก้ข้อผิดพลาดเดิมซ้ําๆ ถ้า attention จํากัด เราไม่ควรปล่อยให้ทั้งคนและ agent ต้องคอยจํากติกาแบบกระจัดกระจาย และถ้า context window คือข้อจํากัดสําคัญ เราต้องออกแบบ codebase, docs, tests และ feedback loop ให้ประหยัด context มากที่สุด

นี่คือแก่นของ Harness Engineering เลยก็ว่าได้ มันไม่ใช่แค่ prompt engineering ที่เขียนคําสั่งให้ดีขึ้น แต่คือการสร้าง โครงสร้างแวดล้อมรอบโมเดล ที่ช่วยให้โมเดลใช้ context อย่างคุ้มค่า ตัดสินใจได้ใกล้เคียงมาตรฐานทีม และเดินงานระยะยาวได้โดยไม่ต้องให้มนุษย์คอยพิมพ์ “continue” อยู่เรื่อยๆ

“ทุกคนคือ staff engineer” และต้องคิดแบบคนขับทีม agent

อีกแนวคิดที่ชวนคิดมากคือ Ryan มองว่าในยุคนี้ วิศวกรทุกคนควรคิดกับตัวเองว่าเป็น staff engineer ที่มีทีมย่อยจํานวนมากรอรับมอบหมายงานตลอดเวลา เพียงแต่ทีมเหล่านั้นไม่ใช่มนุษย์ทั้งหมด แต่เป็น agents ที่พร้อมทํางาน 24 ชั่วโมงถ้ามี token และมีกรอบงานที่ดีพอ

พอมองแบบนี้ เราจะหยุดคิดเรื่อง productivity ในระดับ “คนหนึ่งคนทําได้เร็วขึ้นแค่ไหน” แล้วเปลี่ยนเป็น “คนหนึ่งคนขับ execution capacity ได้มากแค่ไหน” แทน

ประเด็นนี้พลิกวิธีวางแผนงานทันที งานที่เคยถูกจัดเป็น P3 แล้วไม่มีวันได้ทํา เพราะไม่มีคนพอ อาจกลายเป็นงานที่สามารถปล่อย agents ไปลองหลายแนวทางพร้อมกันได้เลย อย่างเช่น refactor หลายทาง ทํา prototype หลายแบบ หรือเพิ่ม localization ตั้งแต่วันแรกโดยไม่ต้องแย่งเวลาทีมหลัก

ตัวอย่างเรื่อง localization ที่เขายกมาน่าสนใจมาก เมื่อโค้ดผลิตได้ง่าย ฟีเจอร์ภายในองค์กรก็สามารถรองรับหลายภาษาได้ตั้งแต่ต้น ซึ่งในโลกเก่ามักถูกเลื่อนไปทีหลังเสมอเพราะไม่มี capacity พอ นี่คือภาพชัดของโลกที่ “ของดี” ไม่จําเป็นต้องถูกจํากัดไว้เฉพาะงานสําคัญที่สุดอีกแล้ว

สิ่งที่สําคัญไม่ใช่โค้ด แต่คือ prompt และ guardrails ที่พาไปถึงโค้ดนั้น

ถ้าตัวโค้ดไม่ใช่สินทรัพย์หายาก คําถามต่อไปคืออะไรที่สําคัญกว่า คําตอบของ Ryan ชัดมาก นั่นคือ prompt, guardrails, documentation และร่องรอยการตัดสินใจของทีม

ในโลกนี้ ไฟล์อย่าง ADRs, docs, playbook, logs ของ tickets, code reviews และ persona-based guidance ไม่ใช่เอกสารประกอบอีกต่อไป แต่มันคือ “โครงสร้างความคิดของทีม” ที่ต้องทําให้ model เข้าถึงและใช้ได้จริง

นี่เป็นจุดที่หลายทีมมักพลาด เราอยากให้ agent ทํางานเหมือน senior engineer แต่ไม่ได้ให้มันเห็นสิ่งที่ทําให้ senior engineer ตัดสินใจได้ดี เช่น มาตรฐานเรื่อง reliability, แนวทางออกแบบ API, ความคาดหวังด้าน security, รูปแบบ QA plan ที่ถือว่าผ่าน หรือแม้แต่หลักง่ายๆ อย่างระบบนี้ parse ที่ edge แล้วไม่ validate ซ้ํากลางทาง

ถ้า agent ทํางานได้ไม่ดี ปัญหาหลายครั้งจึงไม่ใช่เพราะโมเดล “ไม่เก่งพอ” แต่เป็นเพราะองค์กรยังไม่ได้แปลง tacit knowledge ของทีมให้เป็นข้อความที่ค้นเจอ ใช้งานได้ และถูก inject ในจังหวะที่ถูกต้อง

งานของทีมคือการทําให้ “นิยามของงานที่ดี” ชัดพอสําหรับ agent

ซอฟต์แวร์ที่ดีไม่ได้มาจาก requirement เชิงฟังก์ชันอย่างเดียว มันเกิดจากการตัดสินใจเล็กๆ นับร้อยเรื่องที่มักไม่ถูกเขียนลงไปตรงๆ อย่างเช่น

• ควรแยก component มากแค่ไหน
• network call ทุกจุดต้องมี retry และ timeout หรือไม่
• API แบบไหนถือว่าใช้ยากเกินไป
• ไฟล์ยาวเท่าไรถึงเริ่มทําให้ context ของโมเดลเสียเปล่า
• ควรใช้ utility กลางหรือปล่อยให้แต่ละ package เขียนเอง

Ryan อธิบายได้คมมากว่า การทํา patch เล็กๆ ให้ดีจริง อาจต้องอาศัยการตัดสินใจย่อยหลายร้อยครั้ง และโมเดลเคยเห็นโค้ดหลากหลายรูปแบบมามหาศาลอยู่แล้ว งานของเราจึงไม่ใช่สอนมันเขียน syntax แต่ต้อง ระบุ non-functional requirements ให้ชัด

พูดอีกแบบคือ ถ้าเราอยากได้โค้ดที่ maintainable, secure, observable และ consistent เราต้องเขียนสิ่งเหล่านี้ออกมาให้เป็นกฎ เป็น docs เป็น test หรือเป็น review comments อัตโนมัติ ไม่ใช่หวังว่ามนุษย์จะจําได้ทุกครั้ง

ตรงนี้มีความคิดที่น่าเอาไปใช้มาก คือเขามอง feedback จาก code review ไม่ใช่เป็นเรื่องเฉพาะหน้า แต่เป็นสัญญาณว่าระบบยัง encode ความรู้ไม่พอ ถ้า reviewer ต้องคอมเมนต์เรื่องเดิมทุกสัปดาห์ แปลว่าทีมยังไม่ได้ทําให้ความรู้นั้น durable

Prompt มีได้ทุกที่ ไม่ได้อยู่แค่ในช่องพิมพ์คําสั่ง

หนึ่งในส่วนที่น่าสนใจที่สุดคือการขยายความหมายของคําว่า prompt ให้กว้างกว่าที่เราคุ้นกันมาก Ryan มองว่าแทบทุกอย่างที่ส่งผลต่อพฤติกรรมของ agent คือ prompt ทั้งหมด

• prompt ตรงๆ ที่พิมพ์ใส่ model
• rules files
• skills
• ข้อความ error จาก lint
• ข้อคิดเห็นจาก reviewer agents
• test failures ที่บอกวิธีแก้
• โครงสร้างไฟล์และความสม่ําเสมอของ codebase

มุมนี้สําคัญ เพราะมันช่วยให้ทีมเลิกยึดติดกับการ “เขียน prompt ให้เทพ” แบบจุดเดียว แล้วหันมาคิดเชิงระบบแทนว่ามีจุดไหนบ้างใน pipeline ที่สามารถส่งคําชี้แนะกลับไปหา agent ได้

ตัวอย่างที่ทรงพลังมากคือ lint หรือ test failure ไม่ควรบอกแค่ว่า “ผิด” แต่ควรบอก วิธีแก้ที่สอดคล้องกับหลักของทีม เช่น แทนที่จะแจ้งว่า type ไม่ถูกต้อง ก็ควรบอกเลยว่าโค้ดส่วนนี้ไม่ควรมี unknown เพราะทีมใช้แนวทาง parse ที่ edge และ derive type จาก schema อยู่แล้ว

เมื่อ error message กลายเป็น remediation prompt มันก็ไม่ได้เป็นแค่เครื่องมือจับผิด แต่เป็นเครื่องมือสอน agent แบบ just-in-time ซึ่งดูจะได้ผลดีกว่าการยัดกฎทั้งหมดใส่ตอนต้นเสียอีก

Harness ที่ดีไม่ใช่ระบบซับซ้อน แต่คือระบบที่ส่ง context ถูกเวลา

ในช่วงถามตอบมีประเด็นหนึ่งที่ตอบได้ชัดมากว่า เราควรระวังไม่ให้ over-engineer harness ของตัวเองจนกลายเป็นภาระ เขาเสนอหลักง่ายๆ ว่า harness ที่ดีควรทําหน้าที่แค่ surface instructions at the right time

นี่เป็นหลักคิดที่น่าจํามาก เพราะหลายทีมเวลาเริ่มจริงจังกับ agent มักรีบสร้าง framework รอบตัวมันมากเกินไป สุดท้ายบํารุงรักษายาก แถมบางส่วนถูก model capability รุ่นใหม่ทําให้ล้าสมัยเร็ว

Ryan เลือกเน้นสิ่งที่ไม่น่าจะล้าสมัยง่าย นั่นคือการจัดการ context และ timing ของคําแนะนํา เช่น บางกฎไม่จําเป็นต้องบอกตั้งแต่ต้น ให้ agent ลองสร้าง UI ก่อน แล้วค่อยบังคับเรื่อง component decomposition ตอน lint หรือ test phase แบบนี้ช่วยลดการ overload context ตอนเริ่มงาน และยังทําให้คําแนะนําปรากฏในจังหวะที่เกี่ยวข้องจริง

เรามองว่านี่คือความต่างระหว่าง harness ที่ฉลาด กับ harness ที่ใหญ่ ระบบที่ดีไม่จําเป็นต้องมี layer เยอะ แต่ต้องรู้ว่าควรเตือนอะไร เมื่อไร และเตือนผ่านช่องทางไหน

วิธีจัด workflow ให้ agent เป็นจุดเริ่มต้นของการพัฒนา

อีกส่วนที่ชัดเจนมากคือ workflow ที่ให้ Codex หรือ coding agent เป็น entry point ของ dev process ไม่ใช่เครื่องมือพ่วงท้าย editor ของมนุษย์

งานเริ่มจาก ticket จากนั้นมอบให้ agent พร้อม skills ที่จําเป็นต่อการทํางาน เช่น วิธี launch app, วิธีเปิด local observability stack, วิธีต่อกับ Chrome DevTools และวิธีรันเครื่องมือเฉพาะใน repository นั้นๆ

แนวคิดนี้ต่างจากการสร้าง shell ขึ้นมาให้ agent อยู่ข้างใน แต่เป็นการทําให้ repository และ local dev tools ถูกออกแบบมาเพื่อให้ agent เรียกใช้ก่อน วิธีคิดแบบนี้ทําให้ทีมสามารถซ่อนความเปลี่ยนแปลงภายในไว้หลัง skills ชุดเล็กๆ ได้ มนุษย์ไม่จําเป็นต้องตามรู้ทุกการเปลี่ยนแปลงของ tooling ก็ยังขับ agent ได้ต่อเนื่อง

จุดนี้มีบทเรียนที่นําไปใช้ได้ดีมาก คือแทนที่จะมี skills จํานวนมหาศาล เขาเลือกโฟกัสแค่ประมาณ 5 ถึง 10 skills แล้วทําให้มันดีขึ้นเรื่อยๆ เพราะ infra ภายใน repository เปลี่ยนบ่อย ถ้า skills กระจัดกระจายเกินไป ต้นทุนดูแลจะกลับมาหามนุษย์อีกครั้ง

ทํา code review แบบใหม่ ด้วย reviewer agents และวันเก็บกวาด slop

ปัญหาสําคัญของทีมที่ผลิต PR ได้เร็วมาก ไม่ใช่การเขียนโค้ด แต่คือการ merge ให้ทัน ถ้าแต่ละคนปล่อย PR ออกมา 3 ถึง 5 ชิ้นต่อวัน merge conflict จะเริ่มรุนแรงทันที และ code review ของมนุษย์จะกลายเป็นคอขวด

วิธีแก้ของทีมนี้น่าสนใจมาก เขาใช้วิธีให้วิศวกรแต่ละคนมีวันศุกร์เป็น garbage collection day เป้าหมายไม่ใช่ทําฟีเจอร์ใหม่ แต่เก็บทุกชนิดของ slop หรือข้อผิดพลาดซ้ําๆ ที่ทําให้ PR merge ยาก แล้วเปลี่ยนมันให้กลายเป็นกฎถาวรของระบบ

นี่คือ feedback loop ที่แข็งแรงมาก

• มนุษย์เจอปัญหาใน PR
• จัดหมวดว่าปัญหานั้นเป็นเรื่องของ persona ไหน เช่น front-end architect หรือ reliability engineer
• เขียน docs ว่า “งานที่ดี” ใน persona นั้นหน้าตาเป็นอย่างไร
• สร้าง reviewer agent ให้ตรวจตาม docs นี้ทุกครั้งที่มี push
• ลด feedback เดิมซ้ําๆ ลงเรื่อยๆ

ฟังดูเรียบง่าย แต่สะท้อนแนวคิดลึกมาก คือเราไม่ได้ต้องการ reviewer ที่เก่งเฉพาะหน้า เราต้องการระบบที่แปลงการรีวิวที่ดีให้กลายเป็นส่วนหนึ่งของ pipeline ไปเลย

Ryan ยังพูดชัดว่าถ้ามนุษย์ต้องคอยพิมพ์ “continue” หรือคอยแก้ทิศทางบ่อยเกินไป นั่นคือความล้มเหลวของ harness เพราะระบบยังให้ context ไม่พอ ประโยคนี้แรง แต่ก็น่าจะจริงในเชิงออกแบบระบบ

ออกแบบ codebase ให้เหมาะกับ agent ไม่ใช่แค่เหมาะกับคน

อีกประเด็นที่สะกิดหลายทีมได้มากคือ เรามักออกแบบ codebase โดยคิดถึงมนุษย์เป็นหลัก แต่ถ้า agent จะเป็นคนทํางานจํานวนมาก เราต้องเริ่มคิดถึง agent-native architecture ด้วย

Ryan เล่าว่าโปรเจกต์เริ่มต้นแบบ repository ว่างๆ แล้วค่อยๆ โต จนสุดท้ายกลายเป็นกองความซับซ้อนที่ไม่มี package privacy ไม่มี boundary ชัด และ agent มองไม่ออกว่า domain ไหนแยกจากกันอย่างไร สุดท้ายทีมต้องจัดระเบียบครั้งใหญ่ แยก workspace เป็นจํานวนมากตาม business domain และ layer ของระบบ

สาระสําคัญไม่ใช่ว่าทุกคนต้องมี 750 packages แต่คือ โครงสร้าง repository ต้องช่วยให้ agent จํากัดพื้นที่คิดได้ ถ้าส่วนใหญ่ของงานแก้ไขได้ภายใน subtree ที่เล็กลง โมเดลก็ใช้ context ได้คุ้มขึ้นและเดาผลลัพธ์ได้แม่นขึ้น

เขายังเสนอแนวทางที่ดูเคร่งแต่สมเหตุสมผลมาก เช่น

• ควรมีวิธีเดียวในการทํา bounded concurrency
• ควรมีวิธีเดียวในการสร้าง side effectful command ที่มี observability
• ควรมี ORM เดียว
• ควรมีภาษาเดียวหรือแนวทางหลักเดียว
• ควรมีรูปแบบเดียวในการเขียน CI scripts และ lint rules

แก่นของเรื่องนี้คือ ความสม่ําเสมอช่วยให้ token ที่โมเดลต้องทํานายง่ายขึ้น พูดอีกแบบคือ code standard ไม่ได้มีไว้เพื่อความสวยอย่างเดียว แต่มีไว้เพื่อลด entropy ของระบบด้วย

ทดสอบไม่ใช่แค่ behavior แต่ทดสอบ “โครงสร้างของซอร์สโค้ด” ด้วย

จุดที่เฉียบมากอีกเรื่องคือแนวคิดการเขียน tests ที่ตรวจ source code structure แยกจาก lints อย่างเช่น ตั้งข้อกําหนดว่าไฟล์ไม่ควรยาวเกิน 350 บรรทัด เพื่อบังคับให้ codebase เหมาะกับข้อจํากัดด้าน context ของโมเดล

นี่เป็นแนวคิดที่ทีมพัฒนาส่วนใหญ่แทบไม่เคยคิด เพราะเราคุ้นกับการใช้ test เพื่อตรวจ behavior ของโปรแกรม แต่โลกของ agents ทําให้เราต้องเพิ่มอีกชั้นหนึ่ง คือทดสอบว่าโค้ดของเรามี “รูปร่าง” ที่เหมาะกับผู้ช่วยอัตโนมัติหรือไม่

ในทางปฏิบัติ มันอาจรวมถึงการตรวจ dependency edges, package privacy, การ deduplicate schema, หรือการห้ามมี implementation utility ซ้ําหลายชุดในคนละ package จุดเหล่านี้ช่วยลดพฤติกรรมที่ agent มัก optimize แบบ local coherence คือเขียนของใหม่ให้จบตรงหน้า แทนที่จะ reuse ของกลางของทีม

ถ้าเพิ่งเริ่มใช้ coding agents ควรเริ่มตรงไหน

ช่วงถามตอบมีคําแนะนําที่จับต้องได้มากสําหรับทีมที่ยังอยู่ในช่วงเปลี่ยนผ่าน เขาเสนอไว้สองทางหลัก

ทางแรกคือใช้ agent เพื่อ เพิ่มความมั่นใจใน codebase ปัจจุบัน โดยเฉพาะการเขียน tests ให้ครอบคลุมพฤติกรรมที่มีอยู่แล้ว นี่เป็นจุดเริ่มต้นที่ดีเพราะได้ทั้งคุณภาพซอฟต์แวร์และทําให้ agent เดินใน codebase ได้มั่นใจขึ้น

ทางที่สองคือสํารวจว่าเวลาของทีมหมดไปกับอะไร แล้วค่อยใช้ agent เข้าไปลดจุดติดขัดเหล่านั้น เช่น รอ CI นานเกินไป ต้องไล่แก้ flaky tests เสียเวลามาก หรือเสียเวลาทํางานซ้ําใน code review ถ้าเริ่มจาก pain point จริง เราจะเห็น ROI ของ agent ชัดกว่าเริ่มจาก use case ที่ดูหวือหวาแต่ไม่ใช่คอขวดของทีม

คําแนะนํานี้ฟังดูธรรมดา แต่ดีตรงที่ไม่บังคับให้ทุกทีมต้องกระโดดไปสู่ fully autonomous coding ทันที เราสามารถเดินเป็นขั้น เริ่มจากงานที่วัดผลได้ก่อน แล้วค่อยขยายไปสู่งานที่ agent รับผิดชอบมากขึ้น

โค้ดอาจกลายเป็น build artifact แบบใหม่

หนึ่งในช่วงที่ชวนคิดไกลที่สุดคือคําถามว่า โค้ดเป็นเพียง disposable build artifact หรือเปล่า และคําตอบของ Ryan คือ “ใช่”

แนวคิดนี้แรงมาก เพราะมันทําให้เราเปลี่ยนสถานะของโค้ดจาก “ทรัพย์สินหลัก” ไปเป็น “ผลลัพธ์ที่คอมไพล์ออกมาจากข้อกําหนดและข้อจํากัด” คล้ายกับการมอง LLM เป็น fuzzy compiler ที่รับ spec, constraints, docs, tests, lints และ review rules แล้วสร้างโค้ดที่ยอมรับได้ออกมา

ถ้ามองแบบนี้ สิ่งที่มีค่ามากกว่าตัวโค้ดคือระบบรอบโค้ดทั้งหมด รวมถึงกฎที่ทําให้โค้ดนั้นถูกสร้าง แก้ เปลี่ยน หรือทิ้งได้โดยไม่กระทบคุณภาพ นี่น่าจะเป็นหนึ่งในมุมมองที่มีผลต่อทิศทางที่สุดของยุค AI software engineering

ระยะถัดไปของซอฟต์แวร์ เมื่อมนุษย์ถือ token budget และกําหนดทิศทาง

ภาพปลายทางที่ Ryan วาดไว้ชัดมาก เขาอยากไปสู่โลกที่มนุษย์ถือแค่ token budget, ลําดับความสําคัญของงาน, ตัวชี้วัดความสําเร็จ และเกณฑ์ด้าน reliability จากนั้นปล่อยให้เครื่องจักรทํางานต่อเนื่องเป็นไตรมาสหรือเป็นปี โดยแทบไม่ต้องจับพวงมาลัยเองตลอดเวลา

ฟังแล้วอาจดูสุดโต่ง แต่ถ้ามองจากแนวโน้มปัจจุบัน มันไม่ใช่ภาพเพ้อฝันเสียทีเดียว เพราะสิ่งที่ยังขาดอยู่หลายส่วนไม่ได้เป็นเรื่อง model capability เพียงอย่างเดียว แต่เป็นเรื่อง process formalization เราต้องเขียนขั้นตอนการทํางานที่เคยอยู่ในหัวคนให้ออกมาเป็นระบบ เช่น QA smoke testing, runbooks ฝ่าย support, การ triage user feedback, การตรวจ PII leakage ใน logs หรือแม้แต่การติดตาม sentiment จากผู้ใช้

นั่นทําให้เห็นชัดว่าซอฟต์แวร์ยุคถัดไปอาจไม่ได้แข่งขันกันแค่ model ไหนเก่งกว่า แต่แข่งขันกันที่ทีมไหน แปลงความรู้ปฏิบัติขององค์กรให้กลายเป็น machine-readable process ได้เร็วและแม่นกว่า

คําศัพท์เฉพาะทางเพิ่มเติม

• Harness Engineering คือแนวทางออกแบบสภาพแวดล้อม เครื่องมือ กฎ และ workflow รอบ AI agent เพื่อให้มันทํางานได้ใกล้มาตรฐานทีมที่สุด ไม่ใช่แค่พิมพ์ prompt ให้ดีครั้งเดียว
• Context Window คือปริมาณข้อมูลที่โมเดลรับรู้ได้ในช่วงเวลาหนึ่ง ถ้าข้อมูลเยอะเกินไป สิ่งสําคัญอาจหลุดออกจากบริบทที่โมเดลใช้อ้างอิง
• Guardrails คือข้อจํากัดหรือกติกาที่คอยกันไม่ให้ agent ออกนอกทาง อย่างเช่น lint rules, test rules, reviewer agents หรือ policy docs
• Non-functional Requirements คือข้อกําหนดที่ไม่ใช่ฟีเจอร์ตรงๆ แต่มีผลต่อคุณภาพของระบบ เช่น reliability, security, maintainability, observability
• Reviewer Agent คือ agent ที่ไม่ได้เขียนโค้ดหลัก แต่ถูกตั้งให้ตรวจงานผ่านมุมมองเฉพาะ เช่น security, reliability หรือ front-end architecture
• Parse, Don’t Validate แนวคิดการจัดการข้อมูลเข้าระบบ โดยแปลงข้อมูลให้เป็น type ที่เชื่อถือได้ตั้งแต่ขอบระบบ แทนที่จะปล่อยข้อมูลไม่ชัดเจนเข้ามาแล้วค่อยตรวจภายหลัง

สิ่งที่แนวคิดนี้บอกเราจริงๆ เกี่ยวกับระยะถัดไปของงานวิศวกรรม

ถ้ามองให้ลึก Harness Engineering ไม่ได้บอกว่า “AI จะมาแทนคนเขียนโค้ด” แบบผิวเผิน แต่มันกําลังบอกว่า มูลค่าของวิศวกรกําลังเลื่อนระดับขึ้น เราไม่จําเป็นต้องวัดตัวเองจากจํานวนบรรทัดโค้ดอีกต่อไป แต่จากความสามารถในการสร้างระบบที่ทําให้ execution scale ได้โดยไม่เพิ่มภาระ cognitive load ของคน

และเรื่องนี้ไม่ได้มีผลเฉพาะทีมใหญ่ด้วย ทีมเล็กยิ่งได้ประโยชน์ เพราะถ้าคนไม่มากอยู่แล้ว การมี agents ที่ทํางานเป็นกองหนุนตลอดเวลาอาจทําให้ทีมเล็กแข่งขันกับทีมใหญ่ได้ดีขึ้นมาก ตราบใดที่รู้วิธีเขียนมาตรฐาน เขียน docs และปั้น feedback loop ให้แน่นพอ

มุมที่เรารู้สึกว่าน่าคิดที่สุดคือ ความเป็น “senior” ในอีก 6-12 เดือนอาจไม่ได้วัดจากการรีวิวโค้ดเก่งอย่างเดียว แต่วัดจากการทําให้ทีมไม่ต้องรีวิวเรื่องเดิมซ้ําอีกเลยต่างหาก คนที่เก่งจริงจะเป็นคนเปลี่ยน judgment ส่วนตัวให้กลายเป็นระบบที่ใช้ซ้ําได้

บทสรุปส่งท้ายจากทีมงาน Insiderly

• โลกของ software engineering กําลังเปลี่ยนจุดศูนย์กลาง จากการผลิตโค้ด ไปสู่การออกแบบระบบที่ทําให้ agent ผลิตโค้ดได้ดีพอจะใช้งานจริง
• คําว่า “code is free” ไม่ได้แปลว่าโค้ดไม่มีค่า แต่แปลว่าต้นทุนการสร้างโค้ดลดลงจนไม่ใช่คอขวดหลักอีกต่อไป
• สิ่งที่มีค่ามากขึ้นคือ context และมาตรฐานทีม ยิ่งทีมไหนเขียนความรู้ tacit ออกมาเป็น docs, tests, lints และ reviewer workflows ได้ดี ทีมยิ่งได้เปรียบ
• Prompt ที่ทรงพลังที่สุดไม่ได้อยู่แค่ในช่องแชต มันซ่อนอยู่ใน error messages, code structure, review comments และเครื่องมือทุกชิ้นใน pipeline
• code review แบบใหม่คือการแปลง feedback ซ้ําๆ ให้กลายเป็นระบบอัตโนมัติ ไม่ใช่ปล่อยให้ senior engineer เหนื่อยกับเรื่องเดิมทุกสัปดาห์
• ระยะถัดไปของวิศวกรน่าจะคล้ายคนขับองค์กรย่อส่วน ถือ token budget, จัดลําดับงาน, ตั้ง acceptance criteria แล้วปล่อย agents ลงมือแทนในวงกว้าง
• ถ้าจะเริ่มวันนี้ จุดเริ่มที่ดีคือเพิ่ม tests และลด pain point ของทีมทีละจุด ไม่จําเป็นต้องกระโดดไปสู่ autonomous software factory ตั้งแต่วันแรก

Meta Description

วิเคราะห์แนวคิด Harness Engineering ของ Ryan Lopopolo ว่าทีมซอฟต์แวร์ควรทํางานอย่างไร เมื่อมนุษย์เป็นคนกําหนดทิศ และ AI agent เป็นคนลงมือเขียนโค้ด

Keywords

Harness Engineering, AI coding agents, Ryan Lopopolo, OpenAI, วิศวกรรมซอฟต์แวร์ AI, context engineering, code review automation

Slug

harness-engineering-humans-steer-agents-execute

การประเมินและข้อเสนอแนะ

• อ่านเข้าใจง่ายเพียงใด: 9/10
• ยืดยาวหรือกระชับเหมาะสม: 8/10
• อ่านแล้วเหมือน AI หรือมนุษย์เขียน: 9/10
• ใช้คําซ้ําหรือรูปแบบประโยคซ้ําหรือไม่: 8/10
• มีการเปิด-ปิดประโยคหลากหลายหรือไม่: 9/10
• ความน่าเชื่อถือของเนื้อหา: 9/10

ข้อเสนอแนะ: อาจเพิ่มกรณีศึกษาเชิงเปรียบเทียบจากทีมพัฒนาอื่นหรือเอกสารภายนอกในอีก 6-12 เดือน เพื่อเสริมภาพว่าหลักคิดนี้นําไปใช้ได้กว้างแค่ไหน แต่สําหรับบทความนี้ ไม่มี