ใช้ AI Coding Agent เขียนโค้ดยังไง ให้เร็วขึ้นแต่ Developer ไม่กากลง

AI เขียนโค้ดเร็วจริง…แล้วเรายังต้องเก่งอยู่ไหม?

ช่วงนี้เปิด IDE มาก็เจอ AI ปิด IDE หนีไปนอนก็ยังฝันว่า AI ตามมา Review Code ให้ 🤣 ตั้งแต่ช่วยเติมโค้ด ตอบคำถาม ไปจนถึง Coding Agent ที่อ่านไฟล์ แก้โค้ด รันคำสั่ง และทดสอบงานต่อให้ได้เป็นชุด ดูแล้วเหมือนชีวิต Developer จะสบายขึ้นเยอะ

แต่ความเร็วไม่ได้แปลว่าถูกต้องเสมอไปครับ

AI อาจสร้างโค้ดที่ Build ผ่าน เขียน Test ให้ตัวเองผ่าน และสรุปอย่างมั่นใจว่า “เสร็จเรียบร้อย” ทั้งที่ Requirement หลุดไปคนละจังหวัด หรือเผลอแก้ Business Logic เดิมจนพังแบบเนียน ๆ ก็ได้ ฮ่าๆ

คำถามสำคัญจึงไม่ใช่ “AI เขียนโค้ดแทนเราได้ไหม?” แต่คือ:

เราจะทำงานร่วมกับ AI ยังไง ให้ได้ทั้งความเร็ว คุณภาพ และยังเข้าใจระบบที่ตัวเองต้องรับผิดชอบ?

บทความนี้ไม่มีคาถา Prompt เดียวแล้วสร้างระบบพันล้านนะครับ เพราะยังไม่มี 🤣 แต่มี Workflow ที่นำไปปรับใช้กับงานจริงได้ ตั้งแต่รับโจทย์จนถึงตรวจหลักฐานก่อนส่งงาน

สรุปสั้น ๆ สำหรับคนรีบ

ถ้าจำได้แค่เรื่องเดียว ให้จำประโยคนี้ไว้:

AI เป็นคนช่วยทำงาน แต่ Developer ยังเป็นคนตัดสินใจและรับผิดชอบผลลัพธ์

ก่อนให้ Agent ทำอะไร ต้องตอบให้ได้ว่าเรากำลังทำอะไร ผลลัพธ์ที่ต้องการคืออะไร ห้ามแตะอะไร และจะใช้อะไรพิสูจน์ว่างานเสร็จ จากนั้นอ่านแผน ดู Diff และตรวจพฤติกรรมจริง อย่ารับงานเพียงเพราะ AI พิมพ์ว่า “All tests passed” ตัวโต ๆ แล้วใส่อีโมจิเขียวมาให้ครับ 😂

Coding Agent ต่างจาก Chatbot ยังไง?

คำว่า AI สำหรับเขียนโค้ดมีหลายแบบ แต่ละเครื่องมือทำได้ไม่เท่ากัน แบ่งภาพรวมง่าย ๆ ได้แบบนี้ครับ

Autocomplete

ช่วยเติมโค้ดต่อจากตำแหน่งที่กำลังพิมพ์ เหมาะกับ Mapping, Validation หรือ Test Case พื้นฐาน เราเป็นคนควบคุมทีละบรรทัดมากที่สุด

Chat Assistant

เราเอาโค้ดหรือปัญหาไปถาม แล้ว AI อธิบายหรือเสนอ Code Snippet กลับมา เหมาะกับการเรียนรู้ เปรียบเทียบแนวทาง และช่วยคิดตอนติดปัญหา

Coding Agent

Agent สามารถทำงานหลายขั้นต่อกันได้ เช่น สำรวจ Repository หาไฟล์ที่เกี่ยวข้อง แก้โค้ด รัน Test อ่าน Error แล้วปรับงานอีกรอบ ขอบเขตจริงขึ้นอยู่กับเครื่องมือและ Permission ที่เราให้

จุดนี้แหละครับที่ทั้งทรงพลังและน่ากลัว เพราะยิ่ง Agent ลงมือได้มาก เราก็ยิ่งต้องกำหนด Boundary ให้ชัด

ถ้าจะมองให้เห็นภาพ Coding Agent ก็คล้ายเพื่อนร่วมทีมที่ทำงานเร็วและอ่านเร็วมาก แต่ยังไม่รู้บริบทธุรกิจทั้งหมด แถมบางครั้งยังมั่นใจเกินเหตุได้ด้วย ถ้ามอบ Ticket สั้น ๆ ว่า “แก้ Login ให้หน่อย” แล้วหวังว่าจะออกมาถูกทุกอย่าง ก็ไม่ต่างจากเรียกเด็กฝึกงานวันแรกมาแล้วบอกว่า “ระบบอยู่ใน Git นะ ฝากขึ้น Production ด้วย” บันเทิงแน่นอนครับพี่น้องครับ 🤣

งานแบบไหนเหมาะกับ AI Coding Agent?

งานที่ให้ AI ช่วยได้เต็มที่

• สำรวจ Codebase และสรุป Flow ที่เกี่ยวข้อง
• สร้าง Test จากพฤติกรรมที่กำหนดไว้ชัดเจน
• แก้ Bug ที่มีขั้นตอนทำซ้ำและ Expected Result
• ทำ Refactor ขนาดเล็กที่ไม่เปลี่ยน Behavior
• เขียน Boilerplate, Validation หรือ Type ที่ซ้ำกัน
• อธิบาย Error, Stack Trace และความสัมพันธ์ระหว่างไฟล์
• ตรวจ Diff เพื่อหาความเสี่ยงหรือ Test Case ที่ตกหล่น
• ร่าง Documentation จากโค้ดที่ตรวจสอบแล้ว

งานที่ AI ช่วยได้มาก แต่คนต้องรับผิดชอบการตัดสินใจ

• Product หรือ Business Rule ที่ Requirement ยังไม่ชัด
• Authentication และ Authorization
• Migration ที่แก้ข้อมูลจริงหรือย้อนกลับยาก
• Payment, Billing หรือการคำนวณเงิน
• การจัดการข้อมูลส่วนบุคคลและ Secret
• การ Deploy หรือแก้ระบบ Production
• การลบข้อมูลหรือเปลี่ยนโครงสร้างระบบครั้งใหญ่

AI ช่วยงาน Security ได้เยอะครับ ตั้งแต่ไล่ Permission Matrix, หา Denied Path, คิด Threat Scenario, เขียน Security Test ไปจนถึง Review Diff จุดแบ่งไม่ใช่ “AI ทำได้หรือไม่ได้” แต่คือ “ควรให้อิสระมันได้แค่ไหน และใครรับผิดชอบความเสี่ยงที่เหลือ” Policy กับการยอมรับ Residual Risk ยังต้องมีคนเป็นเจ้าของ

Workflow 5 ขั้น: จากโจทย์ถึงโค้ดที่เชื่อถือได้

ขั้นที่ 1: เขียน Outcome แล้วให้ Agent สำรวจก่อน

อย่าเริ่มด้วย “ทำหน้า Login ให้ดีขึ้น” เพราะคำว่า ดีขึ้น ของเรา ของผู้ใช้ และของ AI อาจเป็นคนละโลกกันเลยก็ได้นะจ้ะ

เขียนให้เป็นพฤติกรรมที่ตรวจได้ เช่น:

• เมื่อกรอกรหัสผ่านผิด ระบบแสดงข้อความโดยไม่เปิดเผยว่ามีอีเมลนี้หรือไม่
• ปุ่ม Login กดซ้ำไม่ได้ระหว่างส่ง Request
• ถ้า API ตอบสำเร็จ ผู้ใช้ถูกพาไปหน้า Dashboard
• พฤติกรรม Login เดิมส่วนอื่นต้องไม่เปลี่ยน

จากนั้นให้ Agent อ่าน Repository Instructions, Flow, Test เดิม และไฟล์ที่เกี่ยวข้องก่อนลงมือ

สำรวจ flow การ Login ในโปรเจกต์นี้ก่อน โดยยังไม่แก้ไฟล์

ช่วยสรุป:
1. จุดเริ่มต้นของ request
2. ไฟล์และ component ที่เกี่ยวข้อง
3. validation และ error handling ปัจจุบัน
4. test ที่ครอบคลุมอยู่แล้ว
5. ความเสี่ยงถ้าเปลี่ยน behavior นี้

ถ้าข้อมูลไม่พอ ให้บอกสิ่งที่ยังไม่รู้ ห้ามเดาเป็นข้อเท็จจริง

คำว่า “ยังไม่แก้ไฟล์” สำคัญนะครับ โดยเฉพาะตอนที่เรายังไม่แน่ใจว่า Agent เข้าใจระบบถูกหรือเปล่า ไม่งั้นมันอาจขยันเกินหน้าเกินตาแล้วแก้ให้ครึ่ง Repository ฮ่าๆ

ขั้นที่ 2: ตกลงแผนและ Boundary

เมื่อเข้าใจ Flow แล้ว ให้ Agent เสนอแผน รายชื่อไฟล์ที่จะเปลี่ยน เหตุผล และวิธีทดสอบก่อนทำ

Prompt ไม่ต้องมีสูตรลับหรือชื่อย่อเท่ ๆ ครับ แค่บอก 4 เรื่องให้ครบ:

Context:
- โปรเจกต์นี้คือ ...
- flow และไฟล์ที่เกี่ยวข้องคือ ...

Goal:
- ผู้ใช้ต้องสามารถ ...
- เมื่อเกิด ... ระบบต้อง ...

Constraints:
- รักษา behavior เดิมของ ...
- ห้ามเพิ่ม dependency หรือแก้ส่วนที่ไม่เกี่ยวข้อง
- ห้าม deploy, ลบข้อมูล หรือใช้ secret จริง
- ถ้าต้องเปลี่ยน API หรือ schema ให้หยุดอธิบายก่อน

Evidence:
- เพิ่ม test ที่แสดงปัญหาเดิมและยืนยัน behavior ใหม่
- รัน test, typecheck และ build ที่เกี่ยวข้อง
- ตรวจ diff และรายงานสิ่งที่ยังไม่ได้พิสูจน์

ก่อนลงมือ ให้เสนอแผนสั้น ๆ พร้อมรายชื่อไฟล์

นี่ไม่ใช่การจู้จี้ครับ แต่เป็นการบอกให้ชัดว่า ชนะเมื่อไร ห้ามวิ่งออกนอกสนามตรงไหน และเมื่อไรต้องกลับมาถามคน

ขั้นที่ 3: ให้ Test อธิบาย Behavior

ถ้าเป็น Bug ที่ทำซ้ำได้ ให้เริ่มจาก Test ที่ Fail เพราะสาเหตุที่เราต้องการแก้ แล้วค่อยเปลี่ยน Production Code จน Test ผ่าน

ลำดับที่น่าเชื่อถือคือ:

1. ทำให้เห็นปัญหาเดิม
2. เพิ่มหรือปรับ Test ให้จับปัญหานั้นได้
3. ยืนยันว่า Test Fail ด้วยเหตุผลที่ถูกต้อง
4. แก้โค้ดเท่าที่จำเป็น
5. ยืนยันว่า Test ใหม่และ Test เดิมผ่าน

ถ้า Agent เขียนทั้ง Test และ Implementation พร้อมกัน แล้วทุกอย่างเขียวตั้งแต่ครั้งแรก เรายังไม่รู้ว่า Test นั้นเคยจับ Bug ได้จริงไหม เดี๋ยวไปหน้าแตกตอน UAT แล้วจะบันเทิงครับ 🤣

ขั้นที่ 4: อ่าน Diff และแยกหลักฐานแต่ละชั้น

Summary ของ Agent มีไว้ช่วยนำทาง ไม่ใช่หลักฐานสุดท้าย เปิด Diff แล้วดูว่าไฟล์ไหนถูกแก้ Business Logic เดิมเปลี่ยนไหม Error ถูกกลืนหรือเปล่า มี Secret หลุดเข้ามาไหม และ Test ตรวจผลลัพธ์จริงหรือแค่ตรวจว่า Function ถูกเรียก

ถ้าอ่านส่วนไหนไม่เข้าใจ ให้ Agent อธิบายทีละส่วนหรือย่อการเปลี่ยนแปลงให้เล็กลงก่อน

โค้ดที่เราอธิบายไม่ได้ คือโค้ดที่เรายังไม่ควรอนุมัติ

จากนั้นค่อยตรวจหลายชั้นตามความเสี่ยง:

• Static Check: Format, Lint และ Type Check
• Automated Test: Unit, Integration หรือ End-to-End
• Build: สร้าง Artifact ได้จริง
• Behavior Check: ลอง Happy Path กับ Edge Case สำคัญ
• Runtime Check: Environment เป้าหมายทำงานตรงกับสิ่งที่ตรวจใน Local

Test ผ่านในเครื่องไม่ได้แปลว่า Production ใช้งานได้แล้ว และ Health Check เขียวก็ไม่ได้พิสูจน์ว่า Business Flow ใหม่ถูกต้อง อย่ารวมทุกด่านให้กลายเป็นคำว่า “Done” คำเดียวครับ

ขั้นที่ 5: ให้มนุษย์เป็นคนตัดสินใจ

Agent ช่วยเสนอทางเลือก ลงมือ และรวบรวมหลักฐานได้ แต่คนควรเป็นผู้ตัดสินใจเรื่องที่มีผลกระทบสูง เช่น Requirement ตรงกับสิ่งที่ผู้ใช้ต้องการจริงไหม ความเสี่ยงที่เหลือยอมรับได้หรือไม่ Migration พร้อมกับข้อมูลจริงหรือยัง และควร Merge, Deploy หรือ Rollback เมื่อไร

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

4 หลุมพรางที่ทำให้ใช้ AI แล้วงานพังกว่าเดิม

1. ให้โจทย์คลุมเครือแล้วหวังว่า AI จะอ่านใจ

AI เก่งเรื่องเติมช่องว่าง และนั่นคือปัญหาเมื่อช่องว่างนั้นเป็น Business Rule ถ้ายังไม่รู้ Requirement ให้ใช้ AI ช่วยตั้งคำถามก่อน อย่าให้มันเลือกคำตอบแทน Stakeholder

2. เชื่อเพราะ Test เขียวหรือเพราะคำอธิบายดูดี

Test อาจตรวจผิดเรื่อง Mock ทุกอย่างจนไม่เหลือของจริง หรือถูกเขียนตาม Implementation ที่ผิดตั้งแต่ต้น ต้องอ่าน Assertion และดูว่า Test เคย Fail ด้วยเหตุผลที่ต้องการหรือไม่ เช่นเดียวกับโค้ด ถ้า Agent อธิบายแล้วเรายังไม่เข้าใจ อย่าเพิ่ง Merge

3. ปล่อยให้ Refactor ทั้งโลก

Agent มักมองเห็นโอกาส “ปรับปรุง” เพิ่มเติม บางอย่างก็ดีครับ แต่ยิ่ง Diff ใหญ่ ยิ่ง Review ยาก และยิ่งซ่อน Regression ได้ง่าย งานหนึ่งควรแก้ปัญหาหนึ่งให้ชัดก่อน อย่าให้แก้ปุ่มเดียวแล้วกลับมาพร้อม Design System ใหม่ทั้งชุด ฮ่าๆ

4. ให้ข้อมูล สิทธิ์ หรืออำนาจตัดสินใจมากเกินจำเป็น

อย่าวาง API Key, Token, Password, ข้อมูลลูกค้า หรือ Production Payload ลงไปเพียงเพื่อให้ Debug ง่ายขึ้น ใช้ข้อมูลจำลอง ปิดบังค่าที่อ่อนไหว และทำตามนโยบายขององค์กรเสมอ

ถ้างานต้องอ่านโค้ด ก็ไม่จำเป็นต้องมีสิทธิ์ Deploy ถ้างานต้องวิเคราะห์ Migration ก็ไม่จำเป็นต้องเขียนฐานข้อมูลจริง เริ่มจากสิทธิ์น้อยที่สุดแล้วเพิ่มเฉพาะเมื่อจำเป็น โดยเฉพาะงานเงิน ข้อมูลจริง และสิ่งที่ย้อนกลับยาก จุดอนุมัติต้องชัดเจน

ก่อนเออ ออ ห่อหมก รับงานจาก AI

• ☐ Outcome และ Behavior ที่ต้องการชัดเจน
• ☐ ขอบเขตไฟล์ สิ่งที่ห้ามแตะ และจุดหยุดขออนุมัติชัดเจน
• ☐ อ่าน Diff ทุกส่วนและไม่มี Secret หรือข้อมูลจริงหลุดเข้ามา
• ☐ Test จับพฤติกรรม และมีหลักฐานตามความเสี่ยงของงาน
• ☐ เราอธิบายโค้ดที่เปลี่ยนได้ รวมถึงสิ่งที่ยังไม่ได้พิสูจน์
• ☐ การตัดสินใจสำคัญยังมีมนุษย์เป็นเจ้าของ

สรุป: อย่าแข่งพิมพ์โค้ดกับ AI

Coding Agent พิมพ์เร็วกว่า อ่านหลายไฟล์เร็วกว่า และไม่บ่นตอนให้แก้ Test รอบที่สิบ เราไม่จำเป็นต้องแข่งกับมันในสนามนั้นครับ 🤣

สิ่งที่ Developer ต้องเก่งขึ้นคือการเปลี่ยนปัญหาคลุมเครือให้เป็นโจทย์ที่ตรวจสอบได้ เข้าใจผลกระทบ ตั้ง Boundary แยกคำกล่าวอ้างออกจากหลักฐาน และรับผิดชอบสิ่งที่ส่งถึงผู้ใช้จริง

AI ที่ดีไม่ได้ทำให้เราไม่ต้องคิด แต่มันช่วยคืนเวลาให้เราไปคิดเรื่องที่สำคัญกว่าเดิม ใช้มันให้เหมือนเพื่อนร่วมทีมที่เก่งและเร็ว ให้ Context ที่พอเหมาะ และตรวจงานอย่างจริงจัง

เราอาจให้ AI กด Merge ให้ได้ แต่ความรับผิดชอบต่อสิ่งนั้นยังเป็นของเราอยู่ดีครับพี่น้องครับ 🤘