ความเป็นมา
จุดเริ่มต้นของเรื่องนี้มาจากการประชุมแบบตัวต่อตัวหลายครั้งกับหัวหน้าทีมของผม เขาสนใจว่าผมใช้เครื่องมือ AI อย่างไร สร้าง Harness ส่วนตัวแบบไหน และจัดโครงสร้าง workflow การเขียนโค้ดด้วย AI ของผมอย่างไร เหตุผลหลักคือผมส่งมอบงานตาม requirement ได้เร็วและมีคุณภาพ จนตอนนี้ได้เป็นเจ้าของหลัก (primary owner) ของบางโปรเจกต์ไปแล้ว ผมจึงถือโอกาสนี้จัดระเบียบ workflow การใช้ AI ในแต่ละวันของตัวเอง ปัจจุบันหน้าที่หลักของผมในทีมคือการพัฒนา Agent พร้อมกับดูแล business logic ของ backend ที่มีอยู่เดิมไปด้วย
ก่อนหน้านี้ ผมเคยแชร์ workflow ที่เกี่ยวข้องไว้บน Xiaohongshu บริบทในตอนนั้นคือ GPT-5.4 และ Opus 4.6 สามารถทำงานได้สมบูรณ์แล้วหากเราให้ context ที่แม่นยำและ constraint ที่สมเหตุสมผล การเติบโตของ Harness Engineering ทำให้ทุกคนตระหนักว่า: คุณสามารถควบคุมโมเดลที่ทรงพลังได้ดีขึ้นด้วยการเพิ่ม constraint เข้าไป
ยกตัวอย่างเช่น Skills อย่าง Superpowers ที่มีการ implement แบบค่อนข้างหนัก โดยเน้นไปที่ Spec และ TDD เป็นหลัก ช่วยให้คนจัดระเบียบและขับเคลื่อนงานได้ง่ายขึ้น
แต่การทำแบบนี้ก็มีข้อเสียอยู่ ความรู้สึกที่ชัดเจนที่สุดคือ: Token ถูกใช้หมดไปเร็วมาก Skills อย่าง Superpowers มี Workflow จำนวนมากที่ใช้เพื่อจำกัดการกระทำถัดไปของโมเดล แม้ในมุมมองภาพรวม ขั้นตอนบางอย่างจะไม่จำเป็นแล้วก็ตาม เช่น context ครบถ้วนพอที่จะเริ่ม implement ได้เลย แต่โมเดลก็อาจจะยังรันไปตาม process ที่กำหนดไว้ล่วงหน้าอยู่ดี
หลังจากที่โมเดลใหม่ ๆ ปล่อยออกมา ผมเห็นนักพัฒนาหลายคนเริ่มแชร์ว่าพวกเขาแทบไม่ได้ใช้ Skills ที่หนักหน่วงพวกนี้แล้ว สาเหตุหลักคือเมื่อความสามารถของโมเดลสูงขึ้น constraint และ process บางอย่างที่เราเคยคิดว่ามีประโยชน์ กลับกลายเป็น noise สำหรับโมเดลไปซะงั้น ตัวอย่างเช่น ตอนที่ OpenAI ปล่อย Astra ออกมา พวกเขาเขียนบล็อกโพสต์แนะนำวิธีลบ Skills และ system prompt ที่ไม่จำเป็นออก เพื่อปรับปรุงประสบการณ์การใช้งานโมเดลโดยเฉพาะ
ดังนั้น บทความนี้จะรวบรวมจากสิ่งที่ผมลงมือทำจริงในช่วงไม่กี่เดือนที่ผ่านมา เพื่อแชร์วิธีการที่ยังใช้ได้ผลกับผมในปัจจุบัน และพูดคุยถึงวิธีใช้ Agent ต่าง ๆ ให้ดีขึ้นเพื่อยกระดับประสิทธิภาพการพัฒนาซอฟต์แวร์ในแต่ละวัน
1. Skills และ Prompts ที่ผมใช้บ่อย
การแบ่งเครื่องมือที่ผมใช้อยู่ตอนนี้:
ปัจจุบันผมใช้ Codex + GPT-5.6 Sol สำหรับการ implement โค้ดเป็นหลัก และใช้ Astra สำหรับการวางแผน ก่อนที่ Astra จะปล่อยออกมา งานวางแผนส่วนใหญ่จะโยนให้ GPT-5.6 Sol Max ดูแล
สำหรับ requirement ง่าย ๆ ผมจะใช้ pi + DeepSeek V4 Flash ในการ implement ส่วนการ review แบบ adversarial และการทำ Code Review จะให้ Claude 5 Fable เป็นคนจัดการเป็นหลัก ในโปรเจกต์ส่วนตัว ผมยังใช้ GPT-6 Pro บนเว็บสำหรับการออกแบบ solution หลักด้วย
Skills ที่ผมใช้บ่อย
- think: Skill ของ tw93 ใช้สำหรับการปรับจูน solution ให้ตรงกันและ brainstorming เป็นหลัก
- grill me / grill with docs: ใช้สำหรับการเคลียร์ requirement เป็นหลัก ด้วยการตั้งคำถามอย่างต่อเนื่องเพื่อทำให้เป้าหมาย, constraint และ trade-off ชัดเจน จากนั้นบันทึกผลลัพธ์ลงใน ADR หรือ CONTEXT.md ตามความเหมาะสมของกระบวนการพัฒนา มันช่วยให้ผมขุดเจอปัญหาที่ไม่ได้นึกถึงตอนคุยกันช่วงแรกได้
- implement: ใช้คู่กับ grill เป็นส่วนหนึ่งของชุด Skills ของ Matt Pocock ใช้สำหรับ implement แผนหรือ Issue ที่นิยามไว้อย่างชัดเจนแล้ว
- ponytail: ใช้สำหรับจัดการ over-design ของ AI ช่วยลดความยากในการ Review ผมใช้ตัวนี้บ่อยมากเพราะ GPT-5.6 Sol มักจะ over-design อยู่เสมอ
- handoff: จัดระเบียบ context ปัจจุบันให้อยู่ในรูปแบบไฟล์ เพื่อให้ทำงานต่อใน session ใหม่ได้ง่ายขึ้น ปกติผมใช้มันเพื่อส่งต่องานจาก Codex ไปยัง Claude Code หรือ pi agent
- check: ใช้สำหรับ code review โดยทั่วไปจะใช้ตอน submit MR
- Skills ที่ตกผลึกมาจากการทำงานและโปรเจกต์ส่วนตัว: ส่วนใหญ่เป็น SOP ของกระบวนการที่นำกลับมาใช้ซ้ำได้ เช่น end-to-end testing คำแนะนำของผมคือ ในการทำงานประจำวัน ถ้ากระบวนการไหนต้องทำซ้ำเกินสามครั้ง ลองให้ Codex ช่วยจัดระเบียบมันให้เป็น Skill เพื่อหยิบมาใช้ซ้ำได้เลยในภายหลัง
Prompts ที่ผมใช้บ่อย
ทุกวันนี้ผมไม่ค่อยนั่งเขียน Prompt ยาว ๆ ด้วยตัวเองแล้ว เวลาต้องใช้ ผมมักจะให้ Codex ช่วยเรียบเรียงให้แทน เช่น หลังจากถกกันหลายรอบ ถ้าผมต้องการส่ง context ปัจจุบันไปให้ GPT Pro ออกแบบ solution ผมจะให้ Codex สร้าง handoff Prompt ฉบับสมบูรณ์ขึ้นมาก่อน
นอกจากนี้ ผมยังใช้ Prompt สั้น ๆ ประเภทต่อไปนี้บ่อยมาก
บางครั้งมันให้ผลลัพธ์แบบ "ประโยคเดียวคุ้มกว่าพันคำ" ผมมองว่ามันเป็นเหมือน "ทางลัดในการคิด" ของโมเดล
พวกมันไม่ใช่คาถาวิเศษ แต่เป็น methodology ที่ถูกทำให้เป็นมาตรฐานสูงมากในองค์ความรู้ของมนุษย์ ระหว่างการเทรน โมเดลได้เห็น paper, โค้ด, design document และบทสนทนาที่เกี่ยวข้องมามหาศาล ดังนั้นบ่อยครั้งเราไม่ต้องมานั่งเขียน Workflow หลายร้อยบรรทัดเอง แค่บอกมันว่าจะให้ใช้วิธีคิดแบบไหนก็พอ นี่คือ prompts บางส่วนที่ผมพบว่าได้ผลดีมากจากการใช้งานจริง:
- First Principles: อย่าเพิ่ง optimize ต่อจาก solution ที่มีอยู่ ให้กลับไปถามใหม่ว่าปัญหานี้ควรแก้ยังไงกันแน่ ตัวอย่างเช่น ถ้า interface ทำงานช้า คุณอาจบอกว่า:
อย่าออกแบบต่อจาก solution เดิมที่ตั้งไว้ว่า "เพิ่ม Redis cache" ให้วิเคราะห์จาก first principles ว่าทำไม interface นี้ถึงช้า และ solution ขั้นต่ำที่จำเป็นจริง ๆ คืออะไร
โฟกัสของโมเดลจะเปลี่ยนจาก "ควรออกแบบ Redis ยังไง" ไปเป็น:
คอขวดอยู่ที่ SQL, network, serialization, lock contention หรือการคำนวณซ้ำ? ถ้าเพิ่ม index ใน SQL แล้วแก้ปัญหาได้ จะดึง Redis เข้ามาทำไม?
Prompt ประเภทนี้เหมาะมากเวลาที่คุณสงสัยว่า "ตัวคำถามเองอาจจะผิดตั้งแต่แรก"
- Adversarial Review: อย่าหาเหตุผลมาสนับสนุน solution ของผม ให้พยายามพิสูจน์ว่ามันผิด
วิธีถามแบบธรรมดา ๆ คือ:
ช่วยดูหน่อยว่า technical solution นี้มีปัญหาอะไรไหม
สามารถเปลี่ยนเป็น:
ทำ adversarial review กับ solution นี้ โดยให้ความสำคัญกับการหา counter-example ที่จะล้ม core assumptions ให้ได้ก่อน
สมมติว่า solution ของคุณคือ "การใช้ distributed locks เพื่อแก้ปัญหาคำขอซ้ำ" โมเดลจะไม่แค่บอกวิธีตั้งค่า lock timeout อีกต่อไป แต่จะเริ่มตั้งคำถามว่า:
คำขอซ้ำจำเป็นต้องทำ mutual exclusion จริงเหรอ? ใช้ interface idempotency แก้ได้ไหม? ถ้า lock service ล่มล่ะ? ถ้า lock หมดอายุแต่ business ยังรันไม่เสร็จล่ะ? เรากำลังสร้าง distributed failure point ใหม่ขึ้นมาเพื่อแก้ปัญหา local อยู่หรือเปล่า?
Prompt ประเภทนี้เหมาะกับ solution review และ Code Review เป็นพิเศษ
- Ablation Experiments: ระบบที่ดีขึ้น ไม่ได้แปลว่าทุกอย่างที่คุณเพิ่มเข้าไปจะมีประโยชน์
ตัวอย่างเช่น คุณทำการ optimize สามอย่างพร้อมกัน:
หลังจากเพิ่ม indexes, Redis cache และ batch queries แล้ว latency ของ interface ลดลงจาก 800ms เหลือ 100ms
ณ จุดนี้ คุณสามารถถามตรง ๆ ได้เลยว่า:
ออกแบบ ablation experiments สำหรับการ optimize ทั้งสามอย่างนี้ เพื่อดูว่าประโยชน์ที่แท้จริงมาจากส่วนไหน
โมเดลจะออกแบบ control group รอบ ๆ การจัดกลุ่มที่แตกต่างกัน เริ่มจาก Baseline เปรียบเทียบการเพิ่มแค่ indexes, indexes + cache, indexes + cache + batch queries ฯลฯ
สุดท้าย มันอาจจะพบว่า:
แค่เพิ่ม indexes อย่างเดียวก็ลด latency จาก 800ms เหลือ 120ms แล้ว ส่วนอีกสอง solution ที่ซับซ้อนช่วยได้แค่ 20ms เท่านั้น
แค่นี้คุณก็จะรู้ชัดขึ้นว่าโค้ดส่วนไหนควรเก็บไว้ และความซับซ้อนส่วนไหนอาจจะไม่จำเป็น
- Occam's Razor: เมื่อผลลัพธ์ใกล้เคียงกัน ให้เลือก solution ที่มี assumption น้อยกว่าและซับซ้อนน้อยกว่า
ตัวอย่างเช่น Agent ออกแบบ solution มาแบบนี้:
Kafka + Redis + Distributed Lock + State Machine + Timed Compensation
คุณสามารถเติมประโยคนี้เข้าไป:
ลอง review ดีไซน์นี้ใหม่โดยใช้ Occam's Razor ลบกลไกที่ไม่จำเป็นทั้งหมดออก ภายใต้เงื่อนไขว่ายังตอบโจทย์ requirement ได้ครบ
บ่อยครั้งที่สุดท้ายมันจะพบว่า:
สถานการณ์ปัจจุบันมีการเขียนข้อมูลลงฐานข้อมูลเดียว แค่ transaction บวก unique index ก็เพียงพอแล้ว
ประโยคนี้มีประโยชน์มากสำหรับ Coding Agents ในปัจจุบัน เพราะโมเดลมักจะ over-design ง่าย ๆ เพียงเพื่อความ "ครบถ้วน"
- High Cohesion, Low Coupling: ตรวจสอบ responsibility และขอบเขตของโค้ดอีกครั้ง
ตัวอย่างเช่น ถ้าคุณพบว่า OrderService มีโค้ดยาวถึง 2000 บรรทัดแล้ว คุณสามารถถามว่า:
Review ขอบเขตความรับผิดชอบของ OrderService ตามหลักการ high cohesion และ low coupling อย่าแยกเพียงเพื่อจะแยก
ปกติโมเดลจะเริ่มตรวจสอบว่า:
ทำไม order service ถึงต้องจัดการทั้ง inventory, coupons, SMS, payment และ reports พร้อมกัน? logic ไหนเป็นของ order domain จริง ๆ และอันไหนควรมอบให้ module อื่นผ่าน interface ที่เสถียร?
มันไม่ได้แค่กระตุ้นให้เกิด "การแยกไฟล์" ง่าย ๆ แต่เป็นการเปิดใช้ชุดการตัดสินใจทั้งหมดเกี่ยวกับ modularization, information hiding, ทิศทางของ dependency และการแบ่งความรับผิดชอบ
ดังนั้น ผมจึงแทบจะไม่ค่อยเขียนแบบนี้อีกแล้ว:
ขั้นตอนที่ 1 วิเคราะห์ requirement, ขั้นตอนที่ 2 ตรวจสอบ assumption, ขั้นตอนที่ 3 หาทางเลือกอื่น, ขั้นตอนที่ 4...
methodology ที่成熟จำนวนมาก โมเดลเรียนรู้มาแล้ว ผมชอบบอกมันตรง ๆ มากกว่าว่า:
วิเคราะห์ใหม่จาก first principles, ทำ adversarial review กับ solution ปัจจุบัน; กลไกหลักต้องได้รับการยืนยันผ่าน ablation experiments; solution ต้องเป็นไปตาม Occam's Razor, โค้ดต้องรักษา high cohesion และ low coupling
เบื้องหลังข้อความไม่กี่สิบคำนี้ จริง ๆ แล้วเรากำลังระบุ cognitive action ที่แตกต่างกันถึงห้าอย่าง:
นิยามปัญหาใหม่ → โจมตี assumption → ยืนยัน contribution → ลบความซับซ้อน → จัดระเบียบขอบเขตระบบ
นี่คือสิ่งที่ผมเข้าใจว่าเป็นการเปลี่ยนแปลงของ Prompt Engineering ในยุคโมเดลใหม่: แทนที่จะเขียนกระบวนการคิดแบบตายตัวฉบับสมบูรณ์ให้โมเดล สู้ใช้ methodology ที่แม่นยำเพื่อบอกมันว่า "ให้คิดด้วยวิธีไหน" แล้วค่อยเสริม constraint ที่จำเป็นจริง ๆ สำหรับงานนั้นจะดีกว่า
2. Workflow การพัฒนาในแต่ละวันของผม
หลังจากได้รับ requirement ปกติผมจะส่ง context ที่เกี่ยวข้องให้ Agent ก่อน เช่น PRD, บันทึกการประชุม, แชท, และ feedback จากผู้ใช้ จากนั้นใช้ grill เพื่อปรับ requirement ให้ตรงกันกับมัน
เอกสารพวกนี้มักไม่ใช่ requirement ที่สมบูรณ์และสอดคล้องกัน PRD อาจยังไม่อัปเดต ข้อจำกัดบางอย่างอาจถูกเพิ่มเข้ามาตอนประชุม ลำดับความสำคัญอาจถูกปรับในแชท ความเข้าใจ requirement ของผมเองก็อาจมี assumption ที่ไม่ได้พูดออกไปรวมอยู่ด้วย
ผมปล่อยให้ Agent ทำความเข้าใจเอกสารเหล่านี้ร่วมกับ Wiki ของทีมและโค้ดที่มีอยู่ จากนั้นค่อย ๆ เคลียร์เป้าหมาย ขอบเขต และ trade-off ที่ส่งผลต่อการ implement ผ่านการตั้งคำถามอย่างต่อเนื่อง คำถามบางส่วนผมตอบได้ทันที แต่บางข้อก็ต้องกลับไปคอนเฟิร์มกับฝั่ง product หรือเพื่อนร่วมงานที่เกี่ยวข้อง
ตรงนี้ผมจะคุมสเกลไว้: เมื่อคำถามที่เหลืออยู่จะไม่ทำให้ทิศทางการ implement และผลการ acceptance เปลี่ยนแปลงอย่างมีนัยสำคัญอีกแล้ว เราก็เริ่มพัฒนาได้เลย
ผมไม่ได้บังคับให้มันวางแผนรายละเอียดการ implement ล่วงหน้าทั้งหมด ไม่เช่นนั้นแค่การ align requirement ก็จะกลายเป็นกระบวนการที่หนักเกินไป
ข้อสรุปหลังจาก align กันแล้วจะถูกบันทึกลงใน Spec หรือ CONTEXT.md โดยเน้นบันทึกปัญหาที่ต้องแก้ในครั้งนี้ ขอบเขต การตัดสินใจสำคัญ และเกณฑ์การ acceptance ซึ่งช่วยให้ Agent ตัวถัดไปที่รับผิดชอบการ implement และ review มี context เดียวกันได้ โดยไม่ต้องกลับไปอ่านบทสนทนาก่อนหน้าทั้งหมดใหม่
พอ solution ตกผลึกแล้ว ผมจะให้ Agent หลักเป็นคนตัดสินใจว่าจะ execute ยังไงโดยดูจากความซับซ้อนของงาน requirement ง่าย ๆ ก็ implement ไปเลย ส่วนที่ซับซ้อนจะถูกซอยเป็น Issue ที่มีขอบเขตชัดเจนและ acceptance แยกกันได้ เฉพาะส่วนที่รันอิสระได้เท่านั้นที่จะถูกส่งให้ subagent พัฒนาแบบขนานกันใน worktree ที่ต่างกัน แล้วสุดท้ายค่อยให้ Agent หลักมารวมเข้าด้วยกัน
coding Agent จะทำ test ให้เสร็จก่อน พอคิดว่าพร้อมส่งมอบแล้ว ผมจะดึง Agent ตัวอื่นเข้ามาทำ cross-adversarial review ตามระดับความซับซ้อนของงาน ปัญหาที่พบจะถูกส่งกลับไปยัง coding Agent หลัก (ก็คือ Codex) แบบรวมศูนย์ เพื่อให้มันแก้ไขและ verify ใหม่
ก่อนที่ผมจะ Review ด้วยตัวเอง ผมจะทำ end-to-end testing ด้วย
ปัจจุบันผมไม่ได้อ่านโค้ดที่ถูก generate มาทีละบรรทัดทั้งหมดแล้ว แต่จะดูที่ผล test และ core business logic เป็นหลัก ตรงนี้มี prerequisite สำคัญอยู่ข้อหนึ่ง: ขอบเขตของแต่ละ MR ต้องเล็กพอ และ business path ที่สมบูรณ์จะถูก verify ทีละขั้นไปพร้อมกับการพัฒนา
MR ที่เล็กช่วยให้การเปลี่ยนแปลงที่ต้องทำความเข้าใจและตัดสินอยู่ในขอบเขตที่ควบคุมได้ในแต่ละครั้ง ส่วน end-to-end tests จะช่วยเช็คว่าการเปลี่ยนแปลงเหล่านี้รอดไหมเมื่อนำไปวางใน business process จริง ตอน manual Review ผมจะโฟกัสที่การยืนยัน business logic และดูว่าผล test ที่มีอยู่เพียงพอต่อการรองรับการส่งมอบครั้งนี้หรือไม่
3. วิธีสร้าง End-to-End Testing ที่เป็นมิตรกับ Agent
AI เก่งเรื่องการเขียน test case มากแล้ว บ่อยครั้งที่เขียน test หลายร้อยบรรทัดเพื่อ Bugfix หนึ่งตัว (โดยเฉพาะ 5.6 sol) การเขียน test เยอะขึ้นในตัวมันเองมักไม่ใช่ปัญหา แต่หลัง deploy และ launch ไปแล้ว เราก็ยังเจอ error ที่คาดไม่ถึงอยู่ดี
จากการลงมือทำของผม ปัญหาหลักคือ: เราไม่ได้เตรียม end-to-end testing environment ให้ Agent เพื่อให้มันมีโอกาสค้นพบปัญหาเหล่านี้ระหว่างขั้นตอนการ coding และ self-testing
ถ้าเราสร้าง environment แบบนี้ได้ ให้ Agent รัน task จาก entry point จริงของ test environment ได้อย่างสะดวก และเช็คไปได้เรื่อย ๆ จนถึงผลลัพธ์ที่ user ต้องการ เราก็จะมั่นใจได้ว่าโค้ดที่ AI เขียนจะทำงานในระบบจริงได้อย่างปลอดภัย
ในการพัฒนาจริง ผมได้สร้างชุด end-to-end development testing environment สำหรับธุรกิจของเราขึ้นมา Agent สามารถ query ตารางฐานข้อมูล, logs และเชื่อมต่อเข้าเครื่องเพื่อ troubleshoot ปัญหาได้อย่างสะดวก
กระบวนการสร้างทั้งหมดนี้ แท้จริงแล้วคือการให้ Agent ดึงเอาขั้นตอน self-test ในแต่ละวันของผมออกมา แล้วรวมเครื่องมือและความสามารถที่กระจัดกระจายเข้าด้วยกัน: อะไรที่ทำเป็นเครื่องมือได้ก็จับยัดใส่ MCP หรือ CLI; กระบวนการไหนใช้ซ้ำได้ก็เขียนเป็น Skills
แน่นอนว่ามันต้องออกแรงพอสมควรในช่วงแรก แต่อย่ากลัวความยุ่งยาก พอมันเสร็จแล้ว มันจะช่วยเร่งความเร็วการพัฒนาได้อย่างมาก ลดโอกาสเกิด rework และปัญหาบน production แถมคุณยังไม่ต้องมานั่งกังวลทั้งวันว่าโค้ดที่ AI เขียนจะทำให้เกิดอุบัติเหตุหรือเปล่า
ในเรื่อง end-to-end testing ที่เป็นมิตรกับ Agent ผมทำหลัก ๆ อยู่ 4 อย่าง:
- ให้ Agent คุ้นเคยกับ environment: เช่น รองรับการ start test environment แบบคลิกเดียว, สร้าง test data, ทำให้ version ปัจจุบัน, test account และ permission ชัดเจน รวมถึงมีฟีเจอร์ cleanup และ reset ไว้ให้
- ให้ Agent ควบคุม business systems: รัน business process จริงผ่าน browser, API หรือ CLI
- ให้ Agent query ตารางฐานข้อมูลและ logs ได้สะดวก: ยืนยันผลการจัดเก็บข้อมูลผ่าน database MCP แบบ read-only, ค้นหาปัญหาผ่าน log system Skills และการ query Trace
- นำกระบวนการที่จุกจิกแต่เสถียรมากลับใช้ซ้ำ: เขียน operation ที่เสถียรลง script, จัดระเบียบ entry point และวิธี troubleshoot ให้อยู่ใน Skills เพื่อลดการแทรกแซงด้วยมือและการคุยโต้ตอบซ้ำ ๆ
จากงานเหล่านี้ นี่คือวิธีการที่ผมพบว่าได้ผลดีในปัจจุบัน:
- Browser Automation: เมื่อ business systems ต้องใช้งานผ่าน browser ผมแนะนำ browser โอเพนซอร์ส ego lite ใช้งานง่ายและเร็ว เมื่อจับคู่กับ pi agent + DeepSeek V4 Flash จะทำ test เสร็จได้ค่อนข้างไว ช่วยลดเวลาทดสอบลงได้
- รวม Operations ไว้ใน CLI: รวม Skills ที่ใช้ซ้ำได้, MCP ที่ config ไว้ และ script ที่เขียนขึ้น เข้ามาเป็น unified test CLI ตัวเดียว ที่มีความสามารถทั้งเช็ค environment, เตรียม data, รัน scenario, query ผลลัพธ์ และ cleanup ซึ่งมันยังสามารถกลายเป็น internal efficiency tool ได้อีกด้วย ตอนนี้ผมทำชุดนี้เป็น CLI เรียบร้อยแล้ว และมันก็สะดวกมากเวลาต้อง troubleshoot ปัญหา
- ให้ Tools รับใช้ Acceptance โดยตรง: DB queries ใช้ยืนยันสถานะ, logs และ Traces ใช้อธิบายความล้มเหลว แต่ผลลัพธ์ที่คาดหวังยังคงต้องมาจาก business contract อย่าปล่อยให้ Agent คิดเอาเองว่าอะไรถูกเพียงเพราะมันเห็นว่าระบบ return อะไรออกมา ภายใต้ business logic ที่ซับซ้อน ระบบอาจ return ผลลัพธ์ที่ดูสมเหตุสมผลแต่จริง ๆ ไม่ตรง spec ออกมาทั้งหมดก็ได้ เครื่องมือช่วยให้เราได้หลักฐาน ไม่ใช่มาช่วยนิยามคำตอบที่ถูกต้องให้เรา
- ถ้า Product เป็น Agent อยู่แล้ว ต้องเช็คคุณภาพของคำตอบด้วย: ถ้า product ที่กำลังทดสอบเป็น Agent นอกจาก business process จะรันผ่านแล้ว คุณภาพของคำตอบก็ต้องนำมาพิจารณาด้วย นี่คือสิ่งที่เรามักเรียกว่า Agent Eval ซึ่งจะไม่ขอขยายความในที่นี้
4. วิธี Review โค้ดที่ AI เขียน
หัวข้อก่อนหน้าได้แชร์วิธีทำให้ AI เขียนโค้ดคุณภาพสูงแล้ว แต่ท้ายที่สุด นักพัฒนาก็ยังคงเป็นผู้รับผิดชอบหลักของ business requirement อยู่ดี
ถ้าไม่มี Review ระบบขนาดใหญ่ก็เจอปัญหาได้ง่าย ๆ
และคุณก็คงไม่อยากถูกปลุกมา On-call กลางดึก แล้วพบว่าต้นเหตุคือโค้ดที่ AI เขียนไว้หรอกนะ
เรื่อง Review ปัจจุบันผมมีแนวทางปฏิบัติหลัก ๆ ดังนี้:
- ดูเกณฑ์ acceptance ก่อน แล้วค่อยดูผล test: เช็คเกณฑ์ acceptance ที่ Agent ให้มาก่อน จากนั้นนำไปเทียบกับผล end-to-end test ก่อนหน้านี้ เพื่อยืนยันว่าตรงตามที่คาดหวังไหมและมีอะไรหลุดไปหรือเปล่า อย่าดูแค่ว่า test ผ่านไปกี่เคส แต่ต้องดูด้วยว่า test พวกนี้ verify สิ่งที่ requirement นี้ใส่ใจจริง ๆ หรือเปล่า
- ไล่ดู implementation ตาม business path โฟกัสพลังงานไปที่ส่วนที่มีความเสี่ยงสูง: ผมจะเช็คเรื่อง permissions, state changes, concurrency, retries, data consistency และส่วนที่มีความเสี่ยงสูงอย่าง migration กับ rollback เป็นหลัก สำหรับ CRUD ที่เป็น pattern เสถียรแล้ว ใช้เวลากับมันน้อยลงได้—บางส่วนผมแทบไม่ได้ดูแล้วด้วยซ้ำ
- เช็ค abstraction และ mechanism ที่เพิ่มเข้ามาใหม่เป็นพิเศษ: สำหรับ abstraction และ mechanism ใหม่ ๆ ผมจะใช้แนวคิดอย่าง Occam's Razor ให้ AI review อีกครั้งว่า: มันจำเป็นจริงไหม มีวิธี implement ที่ง่ายกว่านี้หรือเปล่า มันเพิ่มความซับซ้อนมากเกินไปเพื่อแก้ปัญหาเฉพาะจุดหรือไม่?
- ลองสร้าง Review Bot เฉพาะทางเมื่อมี MR จำนวนมาก: ถ้าในทีมมี MR เยอะ เราสามารถออกแบบ Review Bot เฉพาะทางมาจัดการ cross-review ได้ ซึ่งจะต่างจากการเรียก pi agent / Claude Code มาทำ adversarial review ตรง ๆ ที่พูดถึงก่อนหน้านี้ ตรงที่มันจะเน้นการนำข้อมูลการเปลี่ยนแปลงจาก Git มารวมกับ review process ที่ออกแบบไว้ล่วงหน้า กลายเป็นความสามารถในการ review ที่ทำซ้ำได้และรับใช้ MR โดยเฉพาะ
5. สรุปและข้อคิดบางส่วน
คอขวดที่ชัดเจนที่สุดในการพัฒนาของผมตอนนี้คือความเร็วในการ Review
Agent สามารถดันงานหลายชิ้นไปพร้อมกันได้ แต่ความเร็วในการทำความเข้าใจธุรกิจ ตัดสินใจเรื่อง solution และยืนยันการส่งมอบของผมไม่ได้เพิ่มขึ้นตามสัดส่วนนั้น ถ้าคุณปล่อยให้มันเขียนเยอะขึ้นอย่างเดียว สิ่งที่น่าจะเกิดขึ้นคือคุณแค่สะสมโค้ดที่รอ review มากขึ้นเรื่อย ๆ
ดังนั้น สิ่งต่อไปที่ผมอยากปรับปรุงคือการทำให้งานซ้ำซากถูกค้นพบและแก้ไขก่อนที่มันจะมาถึงมือผม
ปัญหาที่เจอได้ผ่าน type checking, tests และ business assertions ควรให้ Agent จัดการเองให้ได้มากที่สุดระหว่างการพัฒนา ส่วนเรื่องที่ต้องใช้วิจารณญาณของผม จะถูกโฟกัสไปที่ว่าเข้าใจ requirement ถูกต้องไหม, key business logic รอดไหม, และยังมี risk อะไรที่ยังไม่ได้ verify ในการเปลี่ยนแปลงครั้งนี้
Review Bot เฉพาะทางช่วยทำสิ่งเหล่านี้ได้ แต่มูลค่าของมันขึ้นอยู่กับว่ามันช่วยลดการตกหล่นของปัญหาที่สำคัญและลดภาระงาน manual ได้หรือไม่ ไม่ใช่แค่ดูว่ามันคอมเมนต์ได้กี่รายการ
สิ่งนี้ยังทำให้ความเข้าใจของผมเกี่ยวกับ Harness ค่อย ๆ เป็นรูปธรรมมากขึ้น: นอกจากการให้ context ที่ถูกต้องแก่ Agent แล้ว พวกมันยังต้องการ environment ที่สามารถ execute task ได้จริง และมีฐานในการตัดสินผลลัพธ์ด้วย
ผมจัดระเบียบ operations ที่ทำซ้ำ ๆ ในการ self-test แต่ละวันให้อยู่ใน CLIs, scripts และ Skills เพื่อให้มันรันระบบ เช็คผลลัพธ์ และหาหลักฐานความล้มเหลวด้วยตัวเอง ในงานที่คล้ายคลึงกันในอนาคต ความสามารถเหล่านี้ก็ยังถูกนำมาใช้ต่อได้ และค่อย ๆ ส่งต่อให้เพื่อนร่วมงานคนอื่นนำไปใช้ซ้ำได้ด้วย
ในขณะเดียวกัน workflow นี้ก็ต้องหมั่น "ลบออก" เป็นประจำด้วย
บางขั้นตอนมีไว้เพื่อชดเชยจุดอ่อนของโมเดลรุ่นใดรุ่นหนึ่ง เมื่อโมเดลเปลี่ยนไป ประโยชน์ของขั้นตอนเหล่านี้ก็ควรถูกประเมินใหม่ งานง่าย ๆ ก็ทำตรง ๆ งานซับซ้อนค่อยเพิ่มการวางแผน การซอยงาน และการ cross-review ตัวอย่างเช่น หลัง Astra อัปเดต ผมก็ลบ constraint ที่เข้มงวดเกินไปบางตัวใน AGENTS.md ออก โมเดลมีการ iterate workflow ของเราก็ต้อง iterate ตามไปด้วย
แน่นอนว่าการ testing และ Review ช่วยลดความไม่แน่นอนได้ แต่มนุษย์ก็ยังคงต้องให้เกณฑ์ acceptance ที่ถูกต้อง แม้ว่าโค้ดและ test จะสอดคล้องกัน แต่ทั้งสองอย่างก็อาจจะเข้าใจ requirement ผิดไปด้วยกันก็ได้ End-to-end tests ครอบคลุมแค่พฤติกรรมใน environment และ scenario ที่เลือกมาเท่านั้น ส่วน traffic, concurrency และการกระจายตัวของข้อมูลใน production environment ก็ยังอาจนำมาซึ่งปัญหาใหม่ ๆ ได้
สำหรับนักพัฒนาที่เพิ่งเริ่มทำงานอย่างผม ผมยังคงหวังว่าจะได้เรียนรู้ความรู้เชิงวิชาชีพในสายนี้เพิ่มเติมผ่านการทำงาน อย่างไรก็ตาม AI ก็ได้ลดโอกาสที่เราจะได้ "ลงหลุม" ด้วยตัวเองไปบ้าง ประสบการณ์ล้ำค่าบางอย่างที่เคยได้มาจากการเจอปัญหาและสืบหาสาเหตุ ตอนนี้กลับกลายเป็นแค่ AI พูดว่า:
"ผมผิดเอง กำลังแก้ไขเดี๋ยวนี้ครับ"
ดังนั้น
ตอนนี้ผมจึงกันเวลาส่วนหนึ่งของการพัฒนาในแต่ละวันไว้สำหรับการเรียนรู้และทบทวน พร้อมกับคิดอยู่เสมอว่า: ความสามารถอะไรที่เพื่อนร่วมงานสาย R&D จำเป็นต้องมีจริง ๆ ในยุค AI
บทความนี้บันทึกชุดวิธีการที่ผมค่อย ๆ คลำทางเจอในงานของตัวเองในช่วงไม่กี่เดือนแรกที่เริ่มทำงาน ส่วนขอบเขตการนำไปใช้และจุดที่ยังขาดตกบกพร่อง ผมยังคงค้นหาต่อไป
ทุกคนสามารถเริ่มจากการเลือกเส้นทางการ self-test ที่ทำเป็นประจำมาสักหนึ่งเส้น ลองให้ Agent รันมันด้วยตัวเอง เก็บหลักฐานไว้ แล้วค่อยตกผลึกขั้นตอนที่ได้ผลออกมา
เนื่องจากข้อกำหนดด้านความลับของบริษัท รายละเอียดหลายอย่างจึงไม่สามารถนำมาใส่ในบทความนี้ได้ หวังว่าบทความนี้จะเป็นการ "ปาอิฐเพื่อดึงหยก" (จุดประกายไอเดีย) และผมยินดีมากที่จะได้ฟังแนวปฏิบัติดี ๆ จากทุกคนในการพัฒนาจริงนะครับ~
