นักพัฒนาส่วนใหญ่ประเมิน AI coding agents กันผิดวิธี พวกเขาติดตั้งเครื่องมือมาสามอย่าง เปิดเทอร์มินัล แล้วรันคำสั่งทดสอบแบบง่ายๆ (toy prompt) เหมือนกันหมด เช่น build me a landing page จากนั้นก็เลือกตัวที่ให้ผลลัพธ์ดูสวยที่สุด ซึ่งการทดสอบแบบนั้นแทบไม่ได้บอกอะไรเลยว่าระบบเหล่านี้จะทำงานอย่างไรเมื่ออยู่ในโค้ดเบส (codebase) ที่ใช้งานจริง

คำถามที่ดีกว่าไม่ใช่ว่าโมเดลไหนได้คะแนนสูงสุดในการทดสอบประสิทธิภาพการเขียนโค้ด (coding benchmark) แต่คือ ระบบ (system) ไหนที่สามารถนำความฉลาดดิบๆ มาประยุกต์ใช้กับโปรเจกต์ซอฟต์แวร์ที่มีความซับซ้อนและมีหลายไฟล์ได้อย่างแท้จริง ตัวโมเดลคือสมอง แต่ harness หรือระบบควบคุม—ซึ่งประกอบด้วยการจัดการบริบท (context management), การเข้าถึงเครื่องมือ, การจัดการข้อผิดพลาด และเลเยอร์การอนุญาตสิทธิ์—คือมือและดวงตา สมองที่อัจฉริยะแต่มาพร้อมกับมือที่เงอะงะจะทำให้โค้ดบน production ของคุณพังได้เร็วพอๆ กับสมองที่ระดับกลางๆ

และนี่คือสิ่งที่แยกเครื่องมือชั้นนำออกจากกัน เมื่อคุณก้าวข้ามผ่านการสาธิตความสามารถแปลกใหม่ (novelty demos) เข้าสู่การทำงานด้านวิศวกรรมจริงๆ

Harness คือหัวใจสำคัญของผลิตภัณฑ์

Agent harness เป็นตัวกำหนดว่าความฉลาดจะทำงานอย่างไรภายใน repository มันควบคุมว่าเอเจนต์จะจำบริบทได้มากแค่ไหน, ไฟล์ไหนที่มันสามารถแตะต้องได้, มันจะกู้คืนสถานการณ์อย่างไรเมื่อคำสั่งในเทอร์มินัลล้มเหลว และมันจะรู้ตัวหรือไม่ว่าควรหยุดก่อนที่จะลบไฟล์ .env ของคุณ เอเจนต์สองตัวอาจรันบนโมเดลที่มีคะแนน benchmark ใกล้เคียงกัน แต่ถ้าตัวหนึ่งสูญเสียความเข้าใจในความสัมพันธ์ระหว่างโมดูลหลังจากแก้ไขไฟล์ไปเพียงสามไฟล์ ในขณะที่อีกตัวยังคงรักษาแผนผังโครงสร้าง (architecture) ของคุณได้อย่างแม่นยำ ตัวที่สองจะทำการ refactor จนเสร็จ ในขณะที่ตัวแรกจะสร้างข้อผิดพลาดใหม่ (regressions) ขึ้นมาแทน

ลองคิดแบบนี้: โมเดลคือเครื่องยนต์ แต่ harness คือระบบกันสะเทือน เบรก และพวงมาลัย พลังขับเคลื่อนจะไม่มีความหมายเลยหากคุณไม่สามารถควบคุมรถให้อยู่บนถนนได้

Claude Code: การใช้เหตุผลเชิงลึกภายใน Repository

Claude Code โดดเด่นเมื่อคุณต้องการทำความเข้าใจโค้ดเบสที่ซับซ้อน มากกว่าแค่การเขียนโค้ดเพิ่มเข้าไป จุดแข็งของมันคือการรักษาโมเดลทางความคิด (mental model) เกี่ยวกับความสัมพันธ์ระหว่างโมดูลต่างๆ หากคุณกำลังไล่ตามบั๊กที่เริ่มจาก authentication middleware, ลามผ่าน database wrapper และไปปรากฏที่ validation utility ตัว Claude Code มักจะสามารถเกาะติดร่องรอยนั้นได้ มันมีประโยชน์อย่างยิ่งสำหรับการวางแผน refactor ขนาดใหญ่ที่คุณต้องเปลี่ยนชื่อ internal API, อัปเดตผู้ใช้งาน API ทุกจุด และปรับปรุงการทดสอบ โดยไม่ลืม shadowed import ในโฟลเดอร์ utility ที่ถูกลืมไป

วิธีปฏิบัติเพื่อให้ได้ประโยชน์สูงสุดคือการใช้ไฟล์ CLAUDE.md ไว้ที่ root ของโปรเจกต์ เอกสารนี้จะทำหน้าที่เป็นความจำขององค์กร (institutional memory) ที่คุณสามารถกำหนดเป็นกฎเกณฑ์ได้ คุณอาจระบุว่าการทำ logging ทั้งหมดต้องใช้ internal wrapper แทน console.log, การทำ database migrations ต้องอยู่ใน /infra/migrations เท่านั้น หรือทุกๆ React component ใหม่ต้องมีไฟล์ Storybook ที่สอดคล้องกัน หากไม่มีขอบเขต (guardrail) นี้ เอเจนต์ตัวไหนก็อาจจะทำงานออกนอกลู่นอกทางไปตามค่าเริ่มต้นจากการฝึกฝน (training defaults) ของมัน แต่ถ้ามีสิ่งนี้ Claude Code จะสามารถเคารพธรรมเนียมปฏิบัติที่ทีมของคุณใช้เวลาสร้างมานานหลายเดือนได้

เลือกใช้เครื่องมือนี้เมื่อการทำงานของคุณเป็นเชิงสำรวจและเชิงสถาปัตยกรรม หากคุณกำลังดีบั๊กตรรกะที่ซับซ้อนหรือกำลังจัดระเบียบความสัมพันธ์ระหว่างแพ็กเกจใน monorepo ความลึกในการจัดการบริบทของมันมักจะให้ผลลัพธ์ที่คุ้มค่า

OpenAI Codex: ระบบอัตโนมัติที่มีโครงสร้างชัดเจน

Codex ถูกสร้างขึ้นมาเพื่อทีมที่ต้องการผลลัพธ์ที่ทำซ้ำได้ในสเกลใหญ่ ในขณะที่ Claude Code เน้นไปที่การสำรวจ Codex จะเน้นไปที่ระบบอัตโนมัติ มันทำงานได้ดีที่สุดเมื่อคุณมีงานที่กำหนดขอบเขตไว้ชัดเจนและต้องการให้นำไปใส่ในระบบเดิมของทีมได้ เช่น การสร้าง boilerplate สำหรับ microservice ใหม่, การสร้างโครงสร้าง CRUD endpoints ด้วย middleware stack เฉพาะของคุณ หรือการอัปเดตไฟล์คอนฟิกูเรชันในกลุ่มของบริการต่างๆ

ข้อควรระวังคือคุณต้องมีความแม่นยำ หากเกณฑ์การยอมรับ (acceptance criteria) ของคุณคลุมเครือ Codex จะสร้างโค้ดที่ทำงานได้ในทางเทคนิค แต่อาจละเมิดธรรมเนียมปฏิบัติของคุณ คุณต้องกำหนดโครงสร้าง, กฎการตั้งชื่อ, รูปแบบการจัดการข้อผิดพลาด และความคาดหวังในการทดสอบไว้ล่วงหน้า ในสภาพแวดล้อมเช่นนั้น Codex จะทำหน้าที่เหมือนสายการผลิตที่เข้าใจคำสั่งภาษาธรรมชาติ มากกว่าที่จะเป็นคู่หูเขียนโปรแกรม (pair programmer) ซึ่งทำให้มันทรงพลังสำหรับเครื่องมือภายใน, เวิร์กโฟลว์ที่เกี่ยวข้องกับ CI และสถานการณ์ใดๆ ที่ความสม่ำเสมอสำคัญกว่าการแก้ปัญหาเชิงสร้างสรรค์

Gemini CLI: เวิร์กโฟลว์แบบเปิดที่เขียนสคริปต์ได้

Gemini CLI มีรูปแบบที่แตกต่างออกไปอย่างสิ้นเชิง มันไม่ใช่ผู้ช่วยเขียนโค้ดเชิงสนทนา แต่เป็นส่วนประกอบที่ขยายความสามารถได้ (extensible component) ภายในสภาพแวดล้อมเทอร์มินัลของคุณ มันสามารถเขียนสคริปต์ควบคุมได้สูง ซึ่งหมายความว่าคุณสามารถ pipe ข้อมูลเข้าสู่เวิร์กโฟลว์มาตรฐานของ Unix, เชื่อมต่อการทำงานกับ grep, awk หรือ jq และสร้าง toolchains เฉพาะตัวที่ไม่จำเป็นต้องคอยคัดลอกและวางระหว่างหน้าต่างแชท

ความเปิดกว้างนี้มีความสำคัญสำหรับวิศวกรที่ใช้เทอร์มินัลเป็นอินเทอร์เฟซหลัก คุณอาจใช้มันเพื่อสร้าง commit messages โดยอัตโนมัติจาก staged diffs, เขียน shell scripts รุ่นเก่าใหม่ด้วย Python พร้อมคำอธิบายแบบ inline, หรือสรุป log output จาก Kubernetes pod ที่ทำงานล้มเหลว โหมด non-interactive ของมันมีประโยชน์อย่างยิ่งสำหรับ CI pipelines คุณสามารถฝังมันไว้ใน GitHub Action หรือขั้นตอนใน Makefile เพื่อทำการแปลงโค้ดแบบเบาๆ, สร้าง documentation snippets จากซอร์สโค้ด, หรือทำความสะอาด error output ก่อนจะโพสต์ลงในช่อง Slack

หากเวิร์กโฟลว์ของคุณถูกสร้างขึ้นรอบๆ shell scripts และเครื่องมือแบบ composable อยู่แล้ว Gemini CLI ก็สามารถเข้ากับระบบของคุณได้โดยไม่ต้องขอให้คุณเปลี่ยนนิสัยการทำงาน

งานที่สำคัญจริงๆ

งานวิจัยเกี่ยวกับอัตราการยอมรับเอเจนต์ AI เผยให้เห็นรูปแบบที่จะไม่ทำให้วิศวกรที่มีประสบการณ์ประหลาดใจ: การเปลี่ยนแปลงเอกสาร (documentation) มักจะได้รับการอนุมัติบ่อยกว่าการพัฒนาฟีเจอร์ใหม่ การอัปเดต docstrings, การแก้ไขคอมเมนต์, หรือการขยายความ README เป็นสิ่งที่ดึงจุดแข็งของเอเจนต์ออกมาใช้ เพราะบริบทนั้นมีขอบเขตจำกัดและสไตล์การเขียนก็ถูกกำหนดไว้แล้วใน repository ส่วนการพัฒนาฟีเจอร์ใหม่นั้นต้องอาศัยการคิดค้น, การคาดการณ์ edge cases, และความเข้าใจในเจตนาของผู้ใช้ที่อาจไม่ได้ถูกเขียนไว้ที่ไหนเลย ไม่มีเครื่องมือใดเพียงเครื่องมือเดียวที่จะชนะได้ในทั้งสองหมวดหมู่ เพราะข้อกำหนดของระบบสนับสนุน (harness) นั้นแตกต่างกันอย่างสิ้นเชิง

นี่หมายความว่าการประเมินของคุณต้องตรงกับงานที่คุณทำจริงๆ หากคุณทดสอบเฉพาะงานที่มีข้อจำกัด เครื่องมือทุกตัวก็จะดูเหมือนอัจฉริยะไปเสียหมด

จุดที่เอเจนต์มักจะพัง

ความล้มเหลวส่วนใหญ่เกิดขึ้นใน execution layer ไม่ใช่ใน model layer โค้ดอาจจะสมบูรณ์แบบตามหลักไวยากรณ์ แต่เอเจนต์ก็ยังอาจล้มเหลวได้เนื่องจาก network timeout ไปยัง internal API, คำสั่ง sed ที่ทำงานได้บน macOS แต่ล้มเหลวบน GNU/Linux, หรือขอบเขตสิทธิ์ (permission boundary) ที่มันไม่รู้จัก เอเจนต์จะประสบปัญหาเมื่อ:

  • API ส่งคืน transient failure และลูปทำงานวนไปเรื่อยๆ แทนที่จะทำ backing off
  • เครื่องมือส่งคืน error stream ในรูปแบบที่เอเจนต์ตีความผิด
  • คำสั่งต้องการสิทธิ์ sudo ที่เอเจนต์ไม่มี นำไปสู่การค้างแบบเงียบๆ (silent hang)
  • การทดสอบที่สร้างขึ้นผ่านเมื่อรันแยกกัน แต่ล้มเหลวเมื่อรันร่วมกับฐานข้อมูลจริง เพราะระบบสนับสนุน (harness) ไม่ได้ดึง connection string ออกมาอย่างถูกต้อง

สิ่งเหล่านี้คือปัญหาด้านการรวมระบบ (integration problems) ซึ่งต้องใช้ระบบสนับสนุน (harness) ที่รู้วิธีอ่านข้อผิดพลาด, เคารพขอบเขต, และขอความช่วยเหลือจากมนุษย์ แทนที่จะดันทุรังทำต่อไปแบบผิดๆ

วิธีประเมินเครื่องมือเหล่านี้อย่างแท้จริง

เลิกทดสอบเอเจนต์ด้วยพรอมต์อย่าง build a landing page ได้แล้ว นั่นเป็นการวัดผลลัพธ์ทางภาพ ไม่ใช่ความสามารถทางวิศวกรรม แต่ควรนำเครื่องมือแต่ละตัวมาทดสอบผ่านบททดสอบที่ยากลำบากของงานจริงแทน:

  • แก้ไขบั๊กที่ครอบคลุมหลายไฟล์ โดยที่สาเหตุหลัก (root cause) และอาการ (symptom) อยู่คนละเลเยอร์ของ stack
  • ทำการ refactor โมดูลเพื่อลบ dependency ที่เลิกใช้แล้ว (deprecated) โดยไม่เปลี่ยนพฤติกรรมภายนอก จากนั้นตรวจสอบว่าชุดการทดสอบยังคงผ่านอยู่
  • อัปเดต mock fixture, type definition และ integration test ทุกตัว หลังจากที่ third-party API เปลี่ยนรูปแบบการตอบกลับ (response shape)
  • วินิจฉัยการ build ที่พังซึ่งเกิดจากความขัดแย้งของเวอร์ชัน (version conflict) และเสนอวิธีแก้ไขที่สามารถคอมไพล์ได้จริง

ติดตามตัวชี้วัดที่จับต้องได้ (hard metrics) ไม่ใช่แค่ความรู้สึก (vibes) นับอัตราการทำงานสำเร็จ (completion rate): เอเจนต์ทำงานจนจบหรือยอมแพ้กลางคัน? บันทึกว่าต้องมีการแก้ไขโดยมนุษย์กี่ครั้งก่อนที่โค้ดจะสามารถ merge ได้ ตรวจสอบว่าการทดสอบผ่านในการพยายามครั้งแรกหรือต้องมีการแก้ไขซ้ำหลายรอบ วัดเวลาที่วิศวกรอาวุโสใช้ในการรีวิวผลลัพธ์ เครื่องมือที่เขียนโค้ดที่ไร้ที่ติได้สองร้อยบรรทัดจะไม่มีค่าเลย หากคุณต้องใช้เวลาหนึ่งชั่วโมงเพื่อตรวจสอบว่ามันไม่ได้ไปแตะต้องไฟล์ที่ควรจะปล่อยทิ้งไว้เฉยๆ

บทสรุปที่แท้จริง

เครื่องมือที่ชนะไม่ใช่เครื่องมือที่สร้างตัวอักษรได้มากที่สุดหรือมีการสาธิตที่หวือหวาที่สุด แต่คือเครื่องมือที่สร้างโค้ดที่สามารถ merge ได้มากที่สุดโดยมีความยุ่งยากในการรีวิวน้อยที่สุด การแข่งขันในพื้นที่นี้กำลังเปลี่ยนจากการเน้นความฉลาดของโมเดลดิบๆ ไปสู่การเน้นระบบสนับสนุนทางวิศวกรรม (engineering harnesses) ที่เชื่อถือได้ จงเลือกเอเจนต์ที่การออกแบบระบบสอดคล้องกับลักษณะงานจริงของคุณ: การใช้เหตุผลเชิงลึกสำหรับการปรับโครงสร้างสถาปัตยกรรม (architectural surgery), ความแม่นยำที่มีโครงสร้างสำหรับการทำงานอัตโนมัติในทีม, หรือการขยายขีดความสามารถผ่านเทอร์มินัล (terminal extensibility) สำหรับเวิร์กโฟลว์ที่กำหนดเอง จากนั้นจึงทดสอบมันด้วยความล้มเหลวที่เกิดขึ้นจริง ไม่ใช่ปัญหาแบบของเล่น

การวิเคราะห์นี้อ้างอิงจากการเปรียบเทียบโดยตรงและการวิจัยพฤติกรรมของเอเจนต์ที่ระบุไว้ใน this detailed breakdown.

สำหรับการพูดคุยเพิ่มเติมเกี่ยวกับเครื่องมือทางวิศวกรรมและ AI workflows เข้าร่วมได้ที่ GyaanSetu learning community.