Tackling Anti-patterns ด้วย AI-Driven Development Lifecycle (AI-DLC): บทเรียนจาก AWS Summit Bangkok 2026

บทนำ (Introduction)

ในงาน AWS Summit Bangkok 2026 มี session ระดับ Level 300 ที่น่าสนใจในหัวข้อ "Tackling Anti-patterns with AI-Driven Development Lifecycle (AI-DLC)" (รหัส DVT304) บรรยายโดยคุณ Sawit Meekwamdee, Solutions Architect จาก AWS ร่วมกับคุณ Anan Phupengjai, Expert QA Engineer จาก AXONS / CP Foods

ประเด็นหลักของ session นี้เริ่มจากคำถามเล่นๆ บนเวทีว่า "ปี 2026 แล้ว ยังมีใครเขียนโค้ดเองอยู่บ้าง?" สะท้อนว่าวันนี้นักพัฒนาเกือบทุกคนมี AI assistant เป็นเหมือนเพื่อนคู่คิด แต่ความสัมพันธ์นั้นก็เหมือน love-leadership relationship บางทีก็ดีจนใจหาย บางทีก็ทำอะไรออกมาไม่รู้เรื่อง คำถามจริงๆ จึงไม่ใช่ว่าจะใช้ AI ดีไหม แต่คือ เราจะใช้ AI อย่างไรให้ได้ผลลัพธ์ที่คาดเดาได้และมีคุณภาพระดับ production

Session นี้แบ่งเนื้อหาออกเป็น 4 ส่วน ได้แก่ AI กำลัง disrupt การพัฒนาซอฟต์แวร์อย่างไร, anti-patterns ที่พบบ่อยพร้อมแนวทางแก้, แนวคิด AI-Driven Development Lifecycle (AI-DLC) และสุดท้ายคือเคสจริงของ AXONS ที่นำ Kiro มาเร่งงาน UI testing

เนื้อหาหลัก (Main Content)

AI กำลัง disrupt การพัฒนาซอฟต์แวร์ และ "Productivity Paradox"

จากการที่ AWS ได้พูดคุยกับลูกค้าหลายราย ทีมงานพบว่ามี 3 คำถามที่ทุกคนพูดถึงตรงกันเมื่อพูดถึง AI กับ software development lifecycle: หนึ่ง "การเปลี่ยนแปลงครั้งใหญ่นี้มาเร็วมาก เราจะเตรียมตัวอย่างไร ต้อง upskill อะไรบ้าง?" สอง "เราลองประเมินเครื่องมือ AI มาหลายตัวแล้ว แต่ก็ยังไม่เห็น acceleration อย่างที่ถูกสัญญาไว้" และสาม "จะทำให้นักพัฒนาหลักร้อยหลักพันคนกลายเป็น AI-native ได้อย่างไร?"

ความคาดหวังของหลายองค์กรคือ AI น่าจะช่วยงานได้อย่างน้อย 50–60% แต่ความจริงในช่วงปีที่ผ่านมากลับต่างออกไป

ผู้บรรยายยกงานวิจัยจาก METR ("Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity") ที่ทำ randomized controlled trial กับนักพัฒนาที่มีประสบการณ์เฉลี่ย 5 ปี จำนวน 16 คน ทำงานราว 246 งานบนโปรเจกต์ขนาดใหญ่ ผลที่ออกมา ขัดกับความรู้สึกของทุกฝ่าย: นักพัฒนา รู้สึกว่า productivity เพิ่มขึ้นราว 20% แต่เมื่อวัดจริงกลับพบว่าการใช้เครื่องมือ AI ทำให้พวกเขาใช้เวลานานขึ้น 19% สวนทางทั้งกับการคาดการณ์ของผู้เชี่ยวชาญด้านเศรษฐศาสตร์ (คาดว่าจะเร็วขึ้น 39%) และ ML (คาดว่าเร็วขึ้น 38%)

ทำไมถึงเป็นเช่นนั้น? คำตอบจากเวทีตรงไปตรงมาว่า AWS เองก็ยังไม่รู้คำตอบที่แน่ชัด นี่เป็นปัญหาที่ทุกคนต้องเรียนรู้ไปด้วยกัน แต่สิ่งที่ AWS ทำได้คือไปสังเกต anti-patterns ที่เกิดซ้ำๆ เมื่อทีมนำ AI เข้ามาในงานพัฒนา

AI ช่วยให้นักพัฒนาสร้าง generative AI application และเร่งกระบวนการพัฒนาได้ แต่ต้องใช้อย่างถูกวิธี — ดูแนวทางการเร่ง SDLC ด้วย generative AI ได้จาก AWS Prescriptive Guidance
📎 Accelerating software development lifecycles on AWS with generative AI — AWS Prescriptive Guidance

Anti-patterns ที่พบบ่อย และวิธีแก้

ผู้บรรยายเรียก session ช่วงนี้ติดตลกว่าเป็น "session สารภาพบาป" เพราะหลายข้อเป็นสิ่งที่นักพัฒนาเกือบทุกคนเคยทำ

1. หลีกเลี่ยง "vibe coding" ในงาน production
Vibe coding ไม่ได้แย่เสมอไป มันเหมาะกับงานบางประเภท แต่สำหรับงานระดับ production ที่ต้องการความ predictable การปล่อยให้ AI generate โค้ดโดยที่เราไม่เข้าใจว่ามันทำงานอย่างไรถือเป็น anti-pattern ทุกครั้งที่ทำงานควรถามตัวเองว่า "เรา debug โค้ดทุกบรรทัดได้ไหม?" และ "เราเข้าใจโค้ดนี้แบบ end-to-end หรือเปล่า?" ถ้าตอบได้ การใช้ AI ช่วยเขียนก็เป็นเรื่องที่ทำได้

2. ให้ AI ทำงานเล็กและง่าย ไม่ใช่งานซับซ้อนก้อนเดียว
Anti-pattern ที่พบบ่อยคือการโยนงาน complex ทั้งก้อนให้ AI ทำ บางครั้งก็สำเร็จ บางครั้งก็ไม่สำเร็จ ซึ่งคือความ "คาดเดาไม่ได้" สิ่งที่ควรทำคือ หยุด ให้งานซับซ้อนที่ "อาจจะ" สำเร็จ เริ่ม สร้าง simple tasks ที่สำเร็จเสมอ และ แตกงาน ออกเป็น function, ไฟล์ หรือ flow ที่ชัดเจน เราสามารถให้ AI ช่วยแตกงานจากโค้ดที่มีอยู่แล้วให้เราเป็นคน review ก่อนได้ ผลคือได้ผลลัพธ์ที่ชัดเจนและคาดเดาได้

3. จัดการ context window อย่างระมัดระวัง
หลายคนเชื่อว่ายิ่ง context ใหญ่ AI ยิ่งฉลาด ซึ่งจริงเฉพาะเมื่อ context นั้น ตรงประเด็นและสอดคล้อง กับงาน แต่ถ้า context ซับซ้อนหรือขัดแย้งกันเอง ผลลัพธ์จะออกมาไม่ตรงความคาดหวัง เหมือนคนที่ได้ข้อมูลเยอะแต่ข้อมูลขัดแย้งกันก็ยิ่งสับสน แนวทางคือให้เฉพาะ context ที่เกี่ยวข้องกับงานนั้น และ reset context ทุกครั้งที่เปลี่ยนงานหรือเริ่ม issue ใหม่ สองคำถามที่ควรถามตัวเองคือ "เรามีข้อมูลที่ไม่เกี่ยวข้องค้างอยู่ใน context มากแค่ไหน?" และ "ครั้งล่าสุดที่ reset context คือเมื่อไหร่?"

4. สร้าง unit test ให้ครอบคลุมเพื่อให้ AI ตรวจงานตัวเองได้
เมื่อเขียนโค้ดเร็วขึ้นด้วย AI หลายทีมกลับลืมเขียน unit test ทำให้ test coverage ลดลงและคุณภาพแอปพลิเคชันแย่ลง ที่สำคัญคือเมื่อ test ไม่ครบ AI จะไม่สามารถตรวจสอบงานที่มัน generate ออกมาเองได้ แนวทางคือเปิด AI อีกชุดให้ช่วยจับ requirement มาเขียน unit test ให้ครอบคลุม เพื่อให้ตัว coding agent มีกลไก validate งานของตัวเอง

5. กระจายการใช้ AI ให้ทั่วทุกจุดของ lifecycle
แม้จะมี test เยอะ แต่ถ้า deploy ลง environment ช้า หรือมี environment ไม่ครบ การทดสอบก็จะติดขัด เพราะ จุดที่ช้าที่สุดคือตัวกำหนดความเร็วโดยรวม สิ่งที่ควรทำคือมี end-to-end environment ที่ใช้งานได้จริง และ CI/CD pipeline ที่เร็วพอจะ report ผลและรัน test ได้ทัน รวมถึงต้องกระจายการใช้ AI ไปทุกขั้นตอนของ software development lifecycle

6. จัดการ Brownfield (โค้ดเดิม) อย่างระมัดระวัง
ความเชื่อเก่าๆ ว่า AI เก่งเฉพาะงาน greenfield ไม่จริงอีกต่อไป เพราะ AI agent ปัจจุบันทำงานกับ codebase เดิมได้ดีขึ้นมาก สิ่งที่ ไม่ควร ทำคือเปิดทั้ง repository ขนาดใหญ่แล้วสั่งให้ AI ไปอ่านทั้งหมดก่อนเพิ่มฟีเจอร์ เพราะ context จะเต็มและ AI ต้อง summarize จนทำงานได้ไม่ดี สามแนวทางบนสไลด์คือ หยุดป้อน codebase ขนาดใหญ่เป็น input ตรงๆ, สร้าง semantic-rich context ขึ้นมาก่อน และ ใช้เทคนิค decomposition ขั้นสูงสำหรับ codebase ที่ใหญ่มาก แนวทางปฏิบัติคือให้ AI ไปอ่านแล้วสรุปลงไฟล์ก่อน เวลาจะแก้อะไรก็อ้างอิงจุดนั้น

วิธีหนึ่งในการเสริม context ให้ AI คือการต่อ external tool ผ่าน Model Context Protocol (MCP) ซึ่ง Amazon Q Developer รองรับแล้ว
📎 Using MCP with Amazon Q Developer — Official Docs

7. อย่าเชื่อ AI เท่ากับที่เชื่อ Senior Engineer
ยิ่งใช้ AI นานยิ่งรู้สึกสนิทและเชื่อใจจนบางทีกด pass-all โดยไม่ตรวจ ผู้บรรยายแนะนำให้มอง AI เหมือน intern ที่เก่งและรอบรู้มาก แต่ยังมีโอกาสพลาด ไม่ใช่ senior engineer จุดที่ต้องระวังคือ AI มักจะ overthink, ตั้งสมมติฐานเอง (makes assumptions) และต้องมี "เจ้าของ" (needs an owner) เสมอ แนวทางคือ ให้คำสั่งและเป้าหมายที่ชัดเจน, สั่งให้ถามกลับเมื่อไม่แน่ใจแทนที่จะ assume เอง และที่สำคัญที่สุด เราคือเจ้าของโค้ดทุกบรรทัดที่ AI generate ออกมา จึงต้อง review เสมอ

AI-Driven Development Lifecycle (AI-DLC) คืออะไร

จาก anti-patterns เหล่านี้ AWS จึงพัฒนา methodology ที่ชื่อ AI-Driven Development Lifecycle (AI-DLC) ขึ้น โดยไม่ได้เกิดขึ้นลอยๆ แต่มาจากการนำโจทย์จริงทั้งภายใน AWS เองและจากลูกค้าหลายราย มาทดลองใช้หลาย methodology แล้วปรับปรุงจาก feedback อย่างต่อเนื่อง จนออกมาเป็น white paper ให้ทุกคนนำไปใช้ได้

หลักการง่ายๆ ของ AI-DLC คือ ถ้าอยากได้อะไรให้บอก AI แล้วให้ AI เป็นคน generate ส่วนมนุษย์เป็นคน verify โดย operating model คือ เมื่อเราบอกความต้องการ AI จะเขียน plan ออกมาก่อนว่าจาก requirement นั้นต้องทำอะไร 1-2-3-4 จากนั้นมนุษย์ review แผน ถ้าไม่ตรงก็คุยปรับกับ AI ได้ (เพราะแผนคือสิ่งที่เราควบคุม) เมื่อแผนตรงความต้องการแล้วจึงให้ AI สร้างโค้ด และมนุษย์กลับมา review ผลลัพธ์อีกครั้ง

AI-DLC แบ่งเป็น 3 เฟสที่ build context ส่งต่อกันไปเรื่อยๆ:

• Inception (Mob Elaboration): build context จากโค้ดเดิม, elaborate intent ด้วย user stories และวางแผนเป็น units of work — AI จะ validate สิ่งที่เราส่งไป ถามกลับเมื่อเจอข้อมูลขัดแย้งหรือไม่พอ
• Construction (Mob Construction): สร้าง domain/component model, generate code & test, เพิ่ม architectural components และ deploy ด้วย IaC พร้อม test ลง development environment
• Operation: deploy ขึ้น production ด้วย IaC และจัดการ incident โดยอาศัย business context และ lessons learned จากเฟสก่อนหน้า

จุดเด่นคือแต่ละเฟส build richer context ให้เฟสถัดไป และ stage มีลักษณะ "adaptive" ปรับตาม intent เมื่อต้องตัดสินใจ เช่นตอนเกิด incident ในเฟส Operation เราสามารถย้อนกลับไปดู context และเหตุผลของการตัดสินใจในเฟสก่อนหน้าได้ ทำให้ตัดสินใจได้แม่นยำกว่าการมองแค่ปัญหาเฉพาะหน้า

AI-DLC เป็น methodology ที่ AI agent orchestrate ทั้งกระบวนการ generate plan, code, test และ infra config โดยมนุษย์ verify ก่อนดำเนินการต่อ
📎 AI-Driven Development Life Cycle: Reimagining Software Engineering — AWS DevOps Blog
📎 Open-Sourcing Adaptive Workflows for AI-DLC — AWS DevOps Blog

Showcase: AXONS เร่ง UI Testing ด้วย Kiro

คุณ Anan Phupengjai จาก AXONS มาแชร์ประสบการณ์จริง AXONS เป็นผู้นำด้าน agricultural technology ที่พัฒนาระบบดิจิทัลให้ธุรกิจเกษตรอุตสาหกรรมและอาหาร ดูแลซอฟต์แวร์ให้ CPF และกลุ่ม CP กว่า 250 บริษัทใน 22 ประเทศ มีทั้ง web, mobile และ enterprise app โดยมีทีม QA Engineer มากกว่า 90 คน เมื่อสเกลใหญ่ระดับนี้ คุณภาพและความเร็วต้องไปด้วยกัน

คุณ Anan ชี้ว่าปัญหาของ AXONS ไม่ได้อยู่ที่ตอนรัน test แต่อยู่ที่ตอนเริ่มต้นงาน QA ทั้งการสร้าง test case ที่ใช้เวลา, การทำ automation script ที่ช้าและขึ้นกับประสบการณ์คน และ UI changes ที่ทำให้ script เปราะและต้อง maintain สูง ตามที่สไลด์สรุปไว้ว่า "Our problem isn't at 'run test'. It's at beginning QA work."

Action #1: สร้าง test case จาก PBI
เดิมที QA เริ่มจากการกาง requirement แล้วใช้ template เปล่าสร้าง test case แต่ AXONS เปลี่ยนมาให้ Kiro + MCP ดึง context จาก PBI board มาสร้าง draft test case ที่เป็นไปตาม format และ structure ของทีม โดยมี QA review ตั้งแต่วันแรก เพื่อตรวจความครบถ้วน ถูกต้อง และสอดคล้องกับมาตรฐาน แนวคิดคือ "Start from a structured draft, not a blank page."

ในเดโม Kiro อ่าน requirement จาก board แล้วสร้าง test case ตาม instruction file ที่กำหนด naming convention, format และ structure ไว้ ทำให้ QA ได้ test case ที่พร้อม review และนำไปใช้ได้โดยใช้เวลาไม่นาน หลังจากนั้น AXONS นำ test case มาเป็นสารตั้งต้นให้ Kiro ช่วยสร้าง automation test ต่อ ทั้งฝั่ง API (เริ่มจาก API test case) และฝั่ง web/mobile (ใช้ร่วมกับ Playwright) โดย QA ยังมีหน้าที่ตรวจสอบ test ก่อน merge เข้า pipeline

สำหรับ mobile automation จากเดิมที่ QA ต้องเขียน test เองราว 30 นาที เมื่อให้ Kiro ช่วยสร้าง QA ได้ test suite ที่พร้อมใช้งานในเวลา ไม่ถึง 10 นาที และผลลัพธ์ที่ชัดที่สุดคือจำนวน automated test case ที่เคยทำเป็น script ได้ 949 เคส เพิ่มขึ้นเป็น 3,227 เคส (ราว 3 เท่า) สะท้อนว่าเมื่อ QA เริ่มงานได้เร็วขึ้น ก็สเกล automation ได้มากขึ้นและส่ง feedback กลับทีมได้เร็วขึ้น

สิ่งที่ทำให้ได้ผล (What worked): หนึ่ง มี instruction.md ที่ชัดเจนเป็นตัวกำหนดวิธีคิด output format และ structure, สอง MCP ขยายความสามารถของ Kiro ด้วย working context จริง และสาม QA review ยังเป็นสิ่งสำคัญ AI ช่วยร่าง แต่ QA ต้องตรวจสอบและตัดสินใจ

สิ่งที่จะทำต่อ (What's next): พัฒนา skills.md และ QA-specific agent สำหรับ enterprise adoption, วัด time-saved metrics ที่ชัดเจน และเชื่อม workflow เข้ากับ CI/CD และ test management system ให้ลึกขึ้น

AXONS ใช้ความสามารถ Model Context Protocol (MCP) เพื่อให้ coding agent เข้าถึง context จาก PBI board และเครื่องมือภายนอกได้
📎 Use Model Context Protocol with Amazon Q Developer for context-aware IDE workflows — AWS DevOps Blog

สรุป (Conclusion)

บทสรุปของ session คือ AI-DLC ยังไม่มี gold standard เป็นมาตรฐานตายตัว แต่ละองค์กรต้องปรับใช้ตามบริบทของตัวเอง และค่อยๆ กระจายไปในแต่ละภาคส่วน สิ่งที่ทุกคนควรทำคือ ทดลอง AI-DLC ในโปรเจกต์ pilot, วัด end-to-end productivity ไม่ใช่จำนวนบรรทัดโค้ด (LOC), สร้าง AI-native practice ของทีม และแชร์สิ่งที่เรียนรู้ทั่วทั้งองค์กร

ประโยคที่ผู้บรรยายทิ้งท้ายสรุปทุกอย่างได้ดี: "Learning to work with AI requires hands-on experience, just like learning to code requires writing code" — การจะใช้ AI ให้เป็นต้องลงมือทำจริง ไม่อย่างนั้นเราจะไม่มีวันเข้าใจสิ่งที่เราทำ และเคสของ AXONS ก็พิสูจน์ว่าเมื่อใช้ถูกวิธี ตั้งแต่ instruction ที่ชัดเจน, MCP ที่เสริม context จริง ไปจนถึง QA review ที่ยังขาดไม่ได้ AI ก็ช่วยให้ทีมเริ่มงานได้เร็วขึ้นและยกระดับคุณภาพซอฟต์แวร์ได้จริง

อ้างอิง (References)

1. AI-Driven Development Life Cycle: Reimagining Software Engineering — AWS DevOps & Developer Productivity Blog
2. Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC) — AWS DevOps & Developer Productivity Blog
3. Building with AI-DLC using Amazon Q Developer — AWS DevOps & Developer Productivity Blog
4. Accelerating software development lifecycles on AWS with generative AI — AWS Prescriptive Guidance
5. Using MCP with Amazon Q Developer — Amazon Q Developer Docs
6. Use Model Context Protocol with Amazon Q Developer for context-aware IDE workflows — AWS DevOps & Developer Productivity Blog
7. MCP overview — Amazon Q Developer Docs