สรุปจากคลิป ดูคลิปต้นฉบับ
มีบางไอเดียที่พอฟังจบแล้วทำให้เรารู้ทันทีว่า วิธีทำงานเดิมกำลังจะไม่เหมือนเดิมอีกต่อไป แนวคิดเรื่อง 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 เดือน เพื่อเสริมภาพว่าหลักคิดนี้นำไปใช้ได้กว้างแค่ไหน แต่สำหรับบทความนี้ ไม่มี