ผมกำลังสร้างเอเจนต์ที่ทำงานตอนเราหลับอยู่

• เอเจนต์เขียนโค้ด AI สามารถสร้างโค้ดและนำการเปลี่ยนแปลงไปใส่ในบรันช์ได้แม้ตอนที่นักพัฒนากำลังหลับอยู่ แต่การ ตรวจสอบความถูกต้องและความน่าเชื่อถือของผลลัพธ์ ยังทำได้ยาก
• หากใช้ AI ตัวเดียวกันมาทดสอบโค้ดที่ AI เขียนเอง ก็จะกลายเป็น เครื่องแสดงความยินดีกับตัวเอง ที่ไม่สามารถจับความเข้าใจคลาดเคลื่อนจากเจตนาเดิมได้
• จึงนำ หลักการสำคัญของ TDD มาประยุกต์ โดย เขียนเกณฑ์การยอมรับก่อน ลงมือเขียนโค้ด แล้วให้เอเจนต์พัฒนาตามเกณฑ์นั้นก่อนทำการตรวจสอบแยกต่างหาก
• มีการสร้างไปป์ไลน์ 4 ขั้นตอนด้วยการผสาน headless mode ของ Claude Code (claude -p) เข้ากับ Playwright MCP โดยไม่ต้องมีแบ็กเอนด์แยก
• หากต้องการเชื่อถือผลงานของเอเจนต์ ต้องนิยามคำว่า "เสร็จสมบูรณ์" ให้ชัดเจนก่อนเริ่มงาน ซึ่งเป็น กระบวนการที่ยากกว่าการเขียนพรอมป์ต์ แต่จำเป็นอย่างยิ่ง

---

ปัญหาการตรวจสอบโค้ดของเอเจนต์อัตโนมัติ

• แม้จะใช้เครื่องมือ AI อย่าง Gastown ให้เอเจนต์เขียนโค้ดต่อเนื่องหลายชั่วโมงและนำการเปลี่ยนแปลงไปใส่ในบรันช์ได้ แต่ก็ยัง ไม่มีวิธีตรวจสอบที่เชื่อถือได้ ว่าผลลัพธ์นั้นถูกต้องจริงหรือไม่
• จากการจัดเวิร์กช็อป Claude Code ให้กับวิศวกรมากกว่า 100 คนในช่วง 6 เดือนที่ผ่านมา พบว่าทุกทีมเจอปัญหาเดียวกัน
• ทีมที่ใช้ Claude กับ PR ในงานประจำวันมี ปริมาณ PR ที่ merge ต่อสัปดาห์เพิ่มจาก 10 เป็น 40~50 รายการ ทำให้ต้องใช้เวลากับการรีวิวโค้ดมากขึ้นอย่างมาก
• ยิ่งระบบ ทำงานอัตโนมัติมากเท่าไร ปัญหาก็ยิ่งรุนแรงขึ้น — สุดท้ายจะกลายเป็นการปล่อยขึ้น production โดยไม่ได้รีวิว diff แค่หวังว่าจะไม่มีปัญหา และค่อยมาพบข้อผิดพลาดหลัง deploy แล้ว

ข้อจำกัดของแนวทางแก้เดิม

• วิธีอย่าง จ้างรีวิวเวอร์เพิ่ม ไม่ทันกับความเร็วที่เพิ่มขึ้น และการให้ วิศวกรอาวุโสนั่งอ่านโค้ดที่ AI สร้างทั้งวันก็ไม่มีประสิทธิภาพ
• ถ้าให้ Claude เขียนเทสต์สำหรับโค้ดที่ตัวเองเขียน โครงสร้างการตรวจสอบจะกลายเป็นการยืนยัน สิ่งที่ Claude คิดว่าผู้ใช้อยากได้ แทนที่จะเป็นสิ่งที่ผู้ใช้ต้องการจริงๆ
  • มันอาจจับ regression bug ได้ แต่จับ ความเข้าใจผิด (misunderstanding) ตั้งแต่ต้นไม่ได้
• เมื่อใช้ AI ตัวเดียวกันทั้งเขียนและตรวจสอบ ก็จะกลายเป็น "เครื่องแสดงความยินดีกับตัวเอง (self-congratulation machine)"
• จุดประสงค์แท้จริงของ code review คือการมี สายตาคู่ที่สอง ที่ไม่ใช่ผู้เขียนเดิม แต่การ cross-review กันระหว่าง AI ที่มาจากแหล่งเดียวกันก็มักพลาดเรื่องเดียวกัน

สิ่งสำคัญที่ TDD มองถูกต้อง

• หลักของ TDD คือ เขียนเทสต์ก่อน จากนั้นเขียนโค้ด และหยุดเมื่อเทสต์ผ่าน (ไม่เขียนเกินกว่านั้น)
• เหตุผลที่ทีมส่วนใหญ่ไม่ทำ TDD คือการต้อง คิดล่วงหน้าว่าโค้ดควรทำอะไร ซึ่งใช้เวลา
• แต่เมื่อ AI เข้ามาแก้ปัญหาเรื่องความเร็ว ข้ออ้างนี้ก็หายไป — ตอนนี้สิ่งที่ช้าคือ การตัดสินว่าโค้ดถูกต้องหรือไม่
• แทนที่จะใช้ unit test การ อธิบายว่าฟีเจอร์ควรทำอะไรด้วยภาษาธรรมดา กลับทำได้ง่ายกว่า
  • ตัวอย่าง: "ผู้ใช้ยืนยันตัวตนด้วยอีเมลและรหัสผ่าน หากข้อมูลรับรองผิดให้แสดง 'Invalid email or password' หากสำเร็จให้ย้ายไปที่ /dashboard และ session token จะหมดอายุหลัง 24 ชั่วโมง"
• สามารถเขียนเกณฑ์เหล่านี้ได้ก่อนเปิด code editor จากนั้นให้เอเจนต์ลงมือทำ และให้อีกสิ่งหนึ่งมาตรวจสอบ

ตัวอย่างการใช้งานจริง

• การเปลี่ยนแปลงฝั่งฟรอนต์เอนด์

  • สร้าง เกณฑ์การยอมรับ (Acceptance Criteria) จากไฟล์สเปก
    • AC-1: เมื่อเข้าถึง /login ด้วยข้อมูลรับรองที่ถูกต้อง ให้ redirect ไป /dashboard และตั้ง session cookie
    • AC-2: หากกรอกรหัสผ่านผิด ให้แสดงข้อความ "Invalid email or password" แบบตรงตัว และยังคงอยู่ที่หน้า /login
    • AC-3: หากเว้นฟิลด์ว่าง ให้ปุ่มส่งข้อมูลถูกปิดการใช้งานหรือแสดง inline error
    • AC-4: หากล้มเหลว 5 ครั้ง ให้บล็อกการเข้าสู่ระบบเป็นเวลา 60 วินาที พร้อมแสดงข้อความเวลารอ
  • แต่ละเกณฑ์สามารถตัดสินได้อย่างชัดเจนว่า ผ่าน หรือ ไม่ผ่าน
  • เมื่อเอเจนต์สร้างฟีเจอร์เสร็จแล้ว เอเจนต์เบราว์เซอร์ Playwright จะตรวจสอบแต่ละ AC, ถ่ายภาพหน้าจอ และสร้างรายงานผลแยกตามเกณฑ์
  • หากไม่ผ่าน ก็จะรู้ได้ชัดเจนว่าเกณฑ์ใดล้มเหลว และในเบราว์เซอร์เห็นอะไรเกิดขึ้น

• การเปลี่ยนแปลงฝั่งแบ็กเอนด์

  • ใช้แพตเทิร์นเดียวกันได้โดยไม่ต้องมีเบราว์เซอร์
  • ระบุพฤติกรรม API ที่สังเกตได้ เช่น status code, response header, error message แล้วตรวจสอบด้วย คำสั่ง curl

• ข้อจำกัด

  • มันไม่สามารถจับความเข้าใจผิดในตัวสเปกเองได้ — ถ้าสเปกผิดตั้งแต่แรก ต่อให้ตรวจสอบผ่าน ฟีเจอร์ก็อาจยังผิดอยู่
  • สิ่งที่ Playwright จับได้คือ ความล้มเหลวระดับการรวมระบบ, บั๊กการเรนเดอร์, และพฤติกรรมที่เสียในเบราว์เซอร์จริง
  • แม้จะเป็นข้ออ้างที่แคบกว่า "ความถูกต้องที่ได้รับการยืนยัน" แต่ก็ยังจับสิ่งต่างๆ ได้มากกว่าสิ่งที่ code review มักจับได้อย่างสม่ำเสมอ

• สรุปเวิร์กโฟลว์

  • เขียนเกณฑ์การยอมรับก่อนพรอมป์ต์ → เอเจนต์พัฒนาตามเกณฑ์ → รันการตรวจสอบ → รีวิวเฉพาะสิ่งที่ล้มเหลว (รีวิวความล้มเหลว ไม่ใช่รีวิว diff)

วิธีสร้าง: ไปป์ไลน์ 4 ขั้นตอน

• สร้างเป็น Claude Skill (github.com/opslane/verify) โดยใช้ claude -p (headless mode ของ Claude Code) และ Playwright MCP
• ไม่ต้องมี custom backend แยกหรือ API key เพิ่ม ใช้เพียง Claude OAuth token ที่มีอยู่แล้ว

• ขั้นที่ 1: Pre-flight

  • ใช้ bash ล้วน ไม่มีการเรียก LLM
  • ตรวจสอบว่า dev server รันอยู่หรือไม่, session ยืนยันตัวตนยังใช้ได้หรือไม่, และมีไฟล์สเปกหรือไม่
  • ทำให้ล้มเหลวได้อย่างรวดเร็วก่อนสิ้นเปลืองโทเคน

• ขั้นที่ 2: Planner

  • เรียก Opus หนึ่งครั้ง
  • อ่านสเปกและไฟล์ที่เปลี่ยน จากนั้นตัดสินว่าการตรวจสอบแต่ละรายการต้องใช้อะไรและควรรันอย่างไร
  • เพราะมันอ่านโค้ดเพื่อหา selector ที่ถูกต้อง จึงไม่ต้องเดาชื่อคลาส

• ขั้นที่ 3: Browser Agents

  • เรียก Sonnet หนึ่งครั้งต่อ AC และรันทั้งหมดแบบขนาน
  • ถ้ามี 5 AC ก็จะมี 5 เอเจนต์ที่นำทางและถ่ายภาพหน้าจออย่างอิสระ
  • Sonnet ถูกกว่า Opus 3~4 เท่า และให้ประสิทธิภาพเทียบเท่าในงานที่อิงการคลิก

• ขั้นที่ 4: Judge

  • เรียก Opus ปิดท้ายอีกหนึ่งครั้ง เพื่ออ่านหลักฐานทั้งหมดและคืนผลตัดสินรายเกณฑ์: pass, fail หรือ needs-human-review

• วิธีติดตั้ง

  • ติดตั้งได้เป็นปลั๊กอิน Claude Code: /plugin marketplace add opslane/verify
  • หรือจะ clone repo ไปปรับแต่งเองก็ได้ — แต่ละขั้นเป็นการเรียก claude -p เพียงครั้งเดียว โดยมีอินพุตชัดเจนและเอาต์พุตแบบมีโครงสร้าง
  • สามารถเปลี่ยนโมเดล เพิ่มขั้นตอน หรือเชื่อม CI ด้วยออปชัน --dangerously-skip-permissions

บทเรียนสำคัญ

• หัวใจสำคัญคือ "หากไม่ระบุคำนิยามของคำว่าเสร็จสมบูรณ์ไว้ล่วงหน้า คุณจะเชื่อถือผลลัพธ์ไม่ได้"
• การเขียนเกณฑ์การยอมรับยากกว่าการเขียนพรอมป์ต์ แต่ช่วยให้ คิดถึง edge case ล่วงหน้า และยกระดับคุณภาพได้
• วิศวกรต่อต้านเรื่องนี้ด้วยเหตุผลเดียวกับที่เคยปฏิเสธ TDD คือ มันให้ความรู้สึกว่าช้ากว่าในช่วงเริ่มต้น
  • หากไม่มีเกณฑ์การยอมรับ ก็ทำได้เพียงอ่านผลลัพธ์แล้วหวังว่ามันจะถูกต้อง
• นี่คือ ขั้นตอนจำเป็นในการสร้างความน่าเชื่อถือในสภาพแวดล้อมการพัฒนาที่ขับเคลื่อนด้วย AI

[github88]

ต่อให้ทำ TDD แค่ไหน ในระดับตอนนี้ที่ LLM ยังสามารถบิดเบือนการทดสอบให้ผ่านได้ การรีวิวโดยมนุษย์ก็ยังจำเป็นจริง ๆ..

[GN⁺]

ความคิดเห็นจาก Hacker News

• ช่วงนี้รู้สึกว่า LLM framework ที่ออกมากันกลับทำให้การพัฒนายากและแพงขึ้น
  แค่ตั้งค่าพื้นฐานก็น่าจะไปได้ไกลพออยู่แล้ว แต่ในสถานการณ์ที่โมเดลเปลี่ยนตลอด การสร้าง wrapper กับ harness มากมายดูไม่มีประสิทธิภาพ
  วิธีแบบปล่อยรันข้ามคืนแล้วเผาเงินแบบนี้ สุดท้ายคงกลายเป็นเรื่องขำขันเหมือน PHP meme

  • ถ้าอยู่ในฝั่ง คนขายเสียมขายจอบ ของกระแส AI เรื่องก็อีกแบบ
    ตามบทความบอกว่า “ในช่วง 6 เดือนที่ผ่านมาได้จัดเวิร์กช็อป Claude Code ให้กับวิศวกรมากกว่า 100 คน”
  • อยากให้คู่แข่งใช้ AI agent กับ codebase ให้เยอะที่สุดเท่าที่จะทำได้
    ปล่อยให้มันรันทั้งวันทั้งคืนจนสุดท้าย บริษัท AI ล้มละลาย แล้วเหลือไว้แค่สปาเกตตีโค้ดที่ AI เขียน 80% แล้วค่อยมาดูกันว่าใครจะหัวเราะทีหลัง
  • ไม่ควรเอา PHP มาล้อกัน ตอนนี้โปรเจกต์ที่ดีที่สุดบางส่วนของฉันก็ยังทำด้วย PHP
    รู้สึกว่า PHP เมื่อ 15 ปีก่อนยังดีกว่า สภาพแวดล้อม full-stack JS/TS ทุกวันนี้เสียอีก
  • ตอนนี้ยิ่งเห็นชัดว่า anti-PHP meme ในอดีตมันไร้สาระแค่ไหน
    PHP ยังอยู่และยังพัฒนาต่อไป ส่วน tooling ของ LLM ก็น่าจะลงเอยเป็นเครื่องมือพื้นฐานแบบนั้นเหมือนกัน
  • นี่ไม่ใช่แค่งานเพิ่มขึ้น แต่เป็น การหลอมรวมของบทบาท
    เส้นแบ่งระหว่าง BA, PO, QA, SWE กำลังเลือนลง ตอนนี้กำลังเกิด บทบาทลูกผสม ที่อยู่กึ่งกลางระหว่างธุรกิจกับการพัฒนา

• ทุกวันนี้เหมือนคนใช้ agent เพียงเพื่อจะได้บอกว่าใช้
  ฉันใช้แค่สองตัวสำหรับงานเขียนกับงานรีวิว แต่ก็เพิ่ม productivity ได้ 5~7 เท่า สบายๆ
  เลยเอาเวลาไปทบทวนสเปกมากขึ้น ส่วนงานเขียนโค้ด agent ใช้เวลาแค่ 10~30 นาที ก็ไม่มีอะไรต้องรีบ

  • ยังไม่เข้าใจแนวคิด “agent ที่รันข้ามคืน” เลย Claude ส่วนใหญ่จบใน 5~20 นาที
    พรุ่งนี้ก็ยังมีงานต่ออยู่ดี เลยไม่เห็นเหตุผลว่าทำไมต้องปล่อยรันทั้งคืน
  • ตอนแรกฉันก็เคยรันหลาย agent แบบขนานกัน แต่สุดท้ายพบว่าการ โฟกัสทีละไดเรกทอรี มีประสิทธิภาพกว่ามาก
  • งานจำนวนมากที่ SWE เคยทำ ตอนนี้ AI จัดการแบบ brute force ได้แล้ว
    จากมุมลูกค้า ไม่ได้ต่างกันมากนักหรอกว่าบั๊กจะมาจากอินเดีย ซานฟรานซิสโก หรือ AI
  • ฉันก็ใช้แค่ agent สองตัว และทำ fine-tuning เยอะมาก
    มันเป็นวิธีที่ควบคุมได้มากกว่ากระแส ‘agent orchestra’ ที่ฮิตกันตอนนี้มาก
  • มองว่าการตรวจสอบสเปกคือขั้นตอนที่สำคัญที่สุด
    เลยทำ verify skill ขึ้นมาเองเพื่อเช็กว่า Claude ทำตามสเปกได้ดีแค่ไหน

• ถ้าให้ Claude ใช้แพตเทิร์น red-green-refactor คุณภาพของเทสต์จะดีขึ้นอย่างชัดเจน
  ถ้าก้าวไปอีกขั้นด้วยการสร้าง sub-agent สำหรับ red/green/refactor ให้ตรวจสอบกันเอง ก็ทำงานได้ดีพอสมควร
  หัวใจสำคัญคืออย่าให้ context ปะปนกัน

  • แต่พอเริ่มรีแฟกเตอร์ เทสต์ก็มักหมดความหมายหรือหลุดหายไป
    reward hacking มีอยู่จริงและป้องกันได้ยาก
  • ต่อให้สั่งทำ red/green TDD ก็ยังเขียนเทสต์แบบไม่ทางล้มเหลว แล้วบอกว่า “แก้เสร็จแล้ว” ข้ามไปเลย
    ถึงจะอ้างอิง คู่มือนี้ ปัญหา bad test ก็ยังหนักเหมือนเดิม
  • ฉันนำ Outside-in TDD ไปใช้กับ Claude Code แบบเต็มรูปแบบแล้ว
    ผลลัพธ์ดีมาก เลยเผยแพร่ทั้ง หลักการและตัวอย่าง กับ starter repo
  • อยากรู้วิธีทำแพตเทิร์น green/red/refactor ให้ละเอียดกว่านี้ ถ้ามีเอกสารอ้างอิงก็น่าจะดี
  • วิธีนี้ใช้กับการรีวิว PR ก็ได้ผลเหมือนกัน
    การ แยกผู้เขียนกับผู้ตรวจสอบ สำคัญมาก ต่อให้ใช้โมเดลเดียวกัน ถ้าแยก context กันคุณภาพก็จะดีขึ้น

• ด้วย ข้อจำกัดด้าน context ของ LLM ในตอนนี้ agent ที่แท้จริงยังเป็นไปไม่ได้
  พอเกิน 500 บรรทัด ความผิดพลาดจะพุ่งขึ้นมาก และราว 200 บรรทัดก็คือขีดจำกัดแล้ว
  สุดท้าย LLM ก็เป็นแค่ เครื่องมือที่ต้องใช้ซ้ำๆ เหมือนเครื่องคิดเลข

• ฉันเรียกปรากฏการณ์นี้ว่า “Test Theatre”
  เขียนถึงเรื่องนี้ไว้ ที่นี่ และควรหลีกเลี่ยงอย่างจริงจัง

  • บางที agent เขียนโค้ด 100 บรรทัด แต่เขียนเทสต์ 600 บรรทัด ทว่าส่วนใหญ่เป็น เทสต์ที่ไม่มีความหมาย
    เทสต์ที่ดีควรตรวจสอบ design pattern กับ dependency และต้องช่วยตอนดีบักได้
  • ถ้าใช้ property testing จะได้ผลดีกว่ามาก
    อย่างเช่นใช้ Schemathesis ตรวจสอบสิทธิ์ผู้ใช้หรือการตอบกลับ 5xx แบบอัตโนมัติ
  • Test Theatre เป็นคำที่ตรงมาก ต่อให้เทสต์ผ่าน ก็ไม่ได้พิสูจน์อะไรจริงๆ
  • วิธีที่ดีที่สุดคือบังคับใช้ Outside-in TDD + mutation testing
    มี POC เกี่ยวกับเรื่องนี้อยู่ ที่นี่
  • จริงๆ แล้ว เทสต์เชิงพิธีกรรม แบบนี้มีมานานแล้ว ส่วนใหญ่ก็แค่ทดสอบตัว implementation เอง

• ช่วงนี้กำลังทดลอง agent orchestration อยู่
  แก่นสำคัญคือการลดการเรียก LLM แล้วเชื่อมต่อด้วย pipeline ของสคริปต์แบบกำหนดผลลัพธ์ได้
  รายละเอียดเขียนไว้ใน บทความนี้

  • ฉันก็ลองแนว orchestration ที่ยึดสคริปต์เป็นศูนย์กลาง คล้ายกัน
    เหมือนใน บันทึกการทดลองนี้ ที่สคริปต์สำคัญกว่า LLM

• ฉันใช้ agent สำหรับงานปฏิบัติการธุรกิจ อยู่ 6 ตัว
  ให้ทำหลายบทบาททั้งวิจัยตลาด เขียนคอนเทนต์ เขียนสคริปต์วิดีโอ ฯลฯ
  คำว่า “ปล่อยรันข้ามคืน” เป็นแนวคิดที่พูดเกินจริง และของจริงคือ เป้าหมายที่ชัดกับขอบเขตที่แคบ ให้ผลดีที่สุด
  คอขวดที่แท้จริงไม่ใช่การลงมือทำ แต่เป็น การจัดการ context

  • แนวทางน่าสนใจดี อยากรู้ว่าคุณกำลังสร้างผลิตภัณฑ์อะไรอยู่ และการทำรีเสิร์ชบน Reddit ยังเวิร์กอยู่ไหม

• ไม่รู้เลยว่าคนนี้จริงๆ แล้วกำลังสร้างอะไร
  ใน LinkedIn เห็นมีแต่ โพสต์เกี่ยวกับ Claude

  • การ deploy โค้ดที่ตัวเองยังตรวจสอบไม่ได้ถือเป็น ความเสี่ยงร้ายแรง
    ถ้าเป็นธุรกิจจริงจังคงนึกภาพไม่ออกว่าจะทำกันได้ยังไง
  • จากประสบการณ์ในวงการ 25 ปี ฉันไม่เคยเจอบริษัทที่ต้องการโค้ดเร็วขนาดนี้
    สุดท้ายโค้ดก็ถูกทิ้งไว้เฉยๆ เพราะมัวแต่คิดว่าจะขายยังไง

• มันเป็นปัญหาเดียวกับการจ้างคนที่เขียนแต่เทสต์
  ท้ายที่สุดก็แค่ยืนยันว่า “โค้ดทำงานตามแบบของโค้ด” เท่านั้น
  การกำหนด สเปกให้ชัดเจน สำคัญกว่ามาก

  • เทสต์หลังบ้านส่วนใหญ่เป็นแค่ การยืนยันแบบพูดซ้ำความเดิม
    น่าแปลกที่วิศวกรรมแขนงอื่นไม่ค่อยทำพลาดแบบนี้ซ้ำๆ แต่ซอฟต์แวร์กลับเป็นอยู่เรื่อยๆ
  • คุณค่าที่แท้จริงของเทสต์คือ การป้องกัน regression
    ต่อให้รีลีสแรกจะผิด ก็ยังช่วยรับประกันได้ว่าพฤติกรรมจะไม่เปลี่ยนไปในภายหลัง
  • จุดประสงค์ของเทสต์สุดท้ายก็คือ การตรวจสอบ mock
  • แก่นสำคัญคือกำหนดสเปกก่อน แล้วค่อยตรวจสอบให้ตรงตามนั้น
    บริษัทที่ปรึกษาหลายแห่งทำงานด้วย การตรวจสอบตาม acceptance criteria

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

  • ฉันจะไม่ deploy โค้ดที่ตัวเองไม่เข้าใจ เด็ดขาด
    ต่อให้ความเป็นอัตโนมัติจะต่ำกว่า ก็จะ merge เฉพาะโค้ดที่ตรวจสอบได้เท่านั้น
  • หรือไม่ก็ต้องไปในทางใช้เครื่องมืออย่าง formal methods เพื่อรับประกันความปลอดภัยของโค้ด