Effectively using AI Assistants: ใช้ AI ช่วยพัฒนาซอฟต์แวร์ให้เร็วและได้มาตรฐาน (AWS Summit Bangkok 2026)

บทนำ (Introduction)

อีกหนึ่ง session ใน Track 4 ของงาน AWS Summit Bangkok 2026 คือ "Effectively using AI Assistants to accelerate development" (DVT307, Level 300) บรรยายโดยคุณวณิช เกียรติขจรเจริญ (Wanich Keatkajonjumroen) Solutions Architect จาก Amazon Web Services ร่วมกับคุณภูวดล โพธิทอง (Phuwadon Potithong) Chief Technology Officer จาก Wipay

สปีกเกอร์เปิดด้วยคำถามง่าย ๆ ว่า "มีใครในห้องที่วันนี้ยังไม่ได้ใช้ AI บ้าง?" — ไม่มีใครยกมือ ทุกคนใช้ AI ช่วยทำงานกันหมดแล้ว แต่ปัญหาที่ทุกคนเจอเหมือนกันคือ คำตอบที่ได้จาก AI มัก "ไม่ตรง" กับสิ่งที่เราต้องการ ต้องถามซ้ำหลายรอบ หรือ copy-paste โค้ดมาแล้วใช้ไม่ได้ บทความนี้จะสรุปแนวทางจาก session ว่าเราจะ "ถามครั้งเดียวให้ได้คำตอบที่ตรงที่สุด" และนำ AI มาใช้ในกระบวนการพัฒนาจริงระดับองค์กรได้อย่างไร

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

ขั้นที่ 1: Prompt ให้เป็น — ยิ่งให้ Context มาก ยิ่งได้คำตอบที่ดี

สปีกเกอร์ไล่ระดับวิธีการ prompt จากพื้นฐานไปสู่ขั้นสูง โดยเริ่มจาก Zero-shot ที่เราถามตรง ๆ เช่น "โค้ดส่วนนี้มี error นี้ แปลว่าอะไร แก้ยังไง" ซึ่งมักได้คำตอบกว้าง ๆ ที่ copy มาใช้แล้วเจอปัญหาอื่นต่อ

ระดับถัดมาคือ One-shot / Few-shot prompting คือการเพิ่มข้อมูลหรือตัวอย่าง (เช่น sample code หรือ guideline ว่าปกติทีมเราเขียนโค้ดอย่างไร) เพื่อสอนให้ AI "คิดแบบเรา" ตัวอย่างที่ยกคือ ถ้าถามลอย ๆ ว่า "ช่วยสร้าง script หา EC2 ที่มี tag นี้" จะได้ script ที่ใช้ได้แต่รองรับแค่ account เดียวหรือ region เดียว แต่ถ้าเพิ่ม context ว่า "ทีมของผมต้อง manage AWS account เป็นร้อย account ข้ามหลาย account และ tag จะเรียงตาม environment และ project ช่วยสร้าง script หา orphan resource จาก tag นี้" คุณภาพของคำตอบจะยกระดับขึ้นทันที

อีกเทคนิคคือการ กำหนด Persona ให้ AI เช่น "คุณคือ Senior Solutions Architect ช่วยสร้าง script นี้โดยใช้ best practice และอธิบายด้วยว่าทำไมถึงเลือกวิธีนี้" — การ assign บทบาทและขอเหตุผลประกอบ ทำให้ได้คำตอบที่มี quality สูงขึ้นชัดเจน

📎 Amazon Q Developer — Coding Assistant

ขั้นที่ 2: ชี้นำกระบวนการคิดของ AI (Guide the Thought Process)

เมื่อ feed context เป็นแล้ว ขั้นต่อไปคือการ "จูงวิธีคิด" ของ AI เพราะถ้าเราถามลอย ๆ AI ก็จะตอบมาแค่คำตอบเดียวเหมือนการ search Google สปีกเกอร์แนะนำเทคนิคดังนี้:

• Structured Reasoning / Decision-Making — สั่งให้ AI พิจารณาหลาย option พร้อมข้อดีข้อเสีย และที่สำคัญมากคือ บอกให้ AI alert กลับมาเมื่อข้อมูลที่เราให้ไม่เพียงพอ แล้วถามคำถามที่ต้องการเพิ่มเติมก่อนประมวลผลต่อ
• Tree of Thoughts (ToT) — ให้ AI แตกออกมาเป็น recommendation หลายแบบ ระบุข้อดีข้อเสียของแต่ละทาง แล้วค่อยเลือกอันที่เหมาะที่สุด ถ้าไม่ชอบคำตอบสุดท้ายก็ย้อนกลับไปดู option อื่นได้โดยไม่ต้องเริ่มใหม่
• Chain of Thought (CoT) — สอน AI ให้คิดเป็นขั้นตอน ตัวอย่างโจทย์ "optimize Lambda ให้ performance ดีขึ้น": (1) หา bottleneck ที่เป็นไปได้ เช่น cold start, memory, external call (2) หา solution ของแต่ละ bottleneck สัก 2-3 แบบ (3) ระบุข้อดีข้อเสียของแต่ละ solution (4) determine ว่าแบบไหนเหมาะกับปัญหาที่สุด — เป็นการบังคับให้ AI research แบบมนุษย์ก่อนตัดสินใจ
• Multi-Agent — เมื่อแตกงานออกเป็นหลายส่วนแล้ว AI ไม่จำเป็นต้องทำแบบ serial สามารถรัน parallel ด้วย multi-agent เพื่อทำงานได้มากขึ้น

จุดสำคัญที่สปีกเกอร์ย้ำคือ ต้องเขียนกติกาให้ชัดเจนและเด็ดขาด — ใช้คำว่า "ต้อง (must)" ไม่ใช่ "ควร (should)" เพราะถ้าเขียนกำกวม AI จะไม่มั่นใจและให้คำตอบแปลก ๆ ออกมา

ขั้นที่ 3: นำไปใช้จริงด้วย Workflow "Explore → Plan → Code → Commit"

การเอา AI มาใช้ใน workflow ประจำวันควรทำตามขั้นตอน Explore–Plan–Code–Commit:

1. Explore — สร้าง context ให้ AI อ่าน existing project ก่อน เพื่อให้เข้าใจว่าโปรเจกต์ของเราเป็นอย่างไร
2. Plan — ก่อนให้ AI เขียนโค้ดสักบรรทัด ให้วาง implementation plan ออกมาก่อน เพื่อตรวจสอบว่าแนวทางถูกต้องไหม
3. Code — ให้ AI เขียนโค้ดพร้อม generate documentation ให้ align กับ code standard ขององค์กร
4. Commit — ก่อน commit ต้อง review และตรวจให้ผ่าน best practice เสมอ

สปีกเกอร์เน้นแนวคิดสำคัญว่า ให้มองว่า AI คือ Junior Developer คนหนึ่ง — ไม่ว่า AI จะ generate โค้ดออกมามากแค่ไหน โค้ดนั้นก็ต้องผ่าน test และ quality check เหมือนกับโค้ดที่มนุษย์เขียน ไม่เช่นนั้นเราจะค่อย ๆ สะสม bug และมีโค้ดในระบบที่ไม่มีใครในทีมเข้าใจ

ขั้นที่ 4: ทำให้ใช้ซ้ำได้ทั้งองค์กรด้วย Agent SOP / Steering Files

ทั้งหมดนี้ implement ในองค์กรได้ผ่านการเขียน Agent SOP ในรูปแบบไฟล์ Markdown (.md) ที่เป็น reusable guide แชร์ให้คนทั้งทีมใช้ได้ และที่สำคัญคือต้อง ใส่ตัวอย่าง (encode examples) เข้าไปด้วย ไม่ใช่เขียนแค่กฎกติกาอย่างเดียว เพราะถ้ามีแต่กฎ output ที่ออกมาอาจเบี่ยงเบนได้ แต่ถ้ามีตัวอย่างประกอบจะบังคับสไตล์การเขียนได้แม่นยำกว่า ผลลัพธ์คือเราสามารถยกระดับพนักงานที่ยังใช้ AI ไม่เก่ง ด้วยการแชร์ SOP ของคนที่ทำเป็นให้ทั้งทีม

กรณีศึกษา: Wipay ให้ทีม non-developer สร้างฟีเจอร์ได้ตามมาตรฐาน

คุณภูวดล CTO ของ Wipay (หนึ่งใน Thai e-wallet ที่ให้ทั้งชาวต่างชาติสแกนจ่ายได้เหมือนคนในพื้นที่ และคนไทยใช้จ่ายได้) มาแชร์การนำแนวคิดนี้ไป implement จริง โดยเริ่มจากปัญหาคลาสสิกขององค์กร: มีโปรเจกต์ที่อยากทำเยอะมากแต่ไม่มีคนทำ พอลองให้ใช้ AI ครั้งแรก ผลคือในห้องประชุมเต็มไปด้วย comment, concern และ complaint จาก developer

สปีกเกอร์สรุปว่าเหตุที่ developer ใช้เวลานานมาจาก 3 เรื่อง คือ (1) Queue developer มีคิวงาน ทำพร้อมกันหลายอย่างไม่ได้, (2) Quality ให้ dev 4-5 คนเขียนโค้ดได้คุณภาพไม่เท่ากันเพราะแต่ละคนมีสไตล์ของตัวเอง แม้จะมี coding standard อยู่แล้ว และ (3) การนำของเข้า production ที่มักติด sprint ("ชั่วโมงเดียวเสร็จ แต่ทำเลยไม่ได้ ขอเข้า sprint ก่อน")

ทางออกของ Wipay คือกำหนดตัวละครหลัก 3 ตัว: Developer, Use case owner (QA), และ AI Agent โดยให้ developer นิยาม standard, QA แปลง standard เป็น instruction file แล้วใช้ AI Agent เป็น "ลูกน้อง" ที่ทำงานตาม instruction เหล่านั้น

โครงสร้าง Instruction / Steering Files

ทีม Wipay จัดการ instruction ผ่าน steering files (โครงสร้างที่ใช้ใน Kiro — agentic IDE ของ AWS) โดยสร้างโฟลเดอร์ .kiro/steering แล้ววางไฟล์ instruction แต่ละหมวดพร้อมกำหนด Inclusion Mode ว่าจะให้โหลด context เมื่อไร:

# Step 1 — สร้าง Steering Folder
mkdir -p .kiro/steering

แนวคิดคือ context ที่เป็น non-negotiable (security, PDPA, code style) จะถูกโหลด always ทุก session ส่วน context เฉพาะทางจะโหลดแบบ fileMatch หรือ manual เพื่อไม่ให้ context ยาวเกินจำเป็น

📎 Five ways to use Kiro and Amazon Q to strengthen your security posture — AWS Security Blog

Instruction ครอบคลุมอะไรบ้าง

instruction ของ Wipay ครอบคลุม 6 หมวดหลัก:

• Security — 7 non-negotiable rules, AES-256-GCM encryption, audit log ทุก action, JWT validation ทุก request
• PDPA Compliance — PII field classification table, data retention 3-10 ปี, breach notification ภายใน 72 ชั่วโมง, data subject rights & SLA
• API Design — 95 endpoints documented, response envelope format, error code ที่ไม่ leak ข้อมูลภายใน, role-based data exposure
• Testing Standards — coverage 100% บน auth/middleware, 90% บน service layer, mandatory audit log assertions, Playwright E2E checklist
• Observability — structured log format, PII-free logging, monitoring alarm thresholds, log retention ตาม data type
• Database — table & column naming rules, required columns, encrypted column patterns, migration workflow steps

The AI-Assisted Development Workflow

workflow ที่ Wipay ใช้มี 5 ขั้นตอน โดยกระจายบทบาทชัดเจน:

1. Developer Defines Standards — เขียนกฎชัดเจนว่าอะไรต้องมี อะไรห้าม พร้อมตัวอย่างโค้ดที่ถูกต้อง
2. QA Writes Instruction Files — แปลง standard เป็น Markdown ที่มีโครงสร้าง และทดสอบว่า AI produce output ตามกฎจริง
3. Team Member Requests a Feature — คน non-developer สั่ง AI agent ให้สร้างของ โดยให้แค่ business requirement
4. AI Generates Compliant Code — AI อ่าน instruction files แล้วสร้างโค้ดที่ผ่านกฎ security, compliance และ style โดยอัตโนมัติ
5. QA Reviews Output — QA ตรวจว่าโค้ดผ่านทุกมาตรฐาน ส่วน developer จะเข้ามาเฉพาะ decision เชิงสถาปัตยกรรมเท่านั้น

Best Practices ในการเขียน Instruction

สไลด์สรุป do/avoid ของการเขียน instruction ที่ดี:

• Be Specific, Not Vague — เขียน "Use AES-256-GCM. Encrypted format: enc:<iv>:<tag>:<ciphertext>" ไม่ใช่ "make sure data is secure"
• State Non-Negotiables Explicitly — ระบุกฎเด็ดขาดเป็นข้อ ๆ (Never... / Always...)
• Show Code Examples — ใส่ทั้งโค้ดที่ถูกและผิดเทียบกัน ไม่ใช่อธิบายด้วย prose อย่างเดียว เพราะ AI ตีความ prose แบบหลวม ๆ
• Version and Maintain — อัปเดตไฟล์เมื่อ standard เปลี่ยน และให้ QA เป็นเจ้าของใน version control อย่าเขียนทิ้งไว้ครั้งเดียว เพราะ instruction ที่ล้าสมัยจะผลิตโค้ดที่ล้าสมัย

ผลลัพธ์ (The Results)

ผลลัพธ์ที่องค์กรได้เมื่อทุกทีมสามารถเขียนโค้ดตาม standard เดียวกัน:

• 5x Faster Delivery — จากหน่วยสัปดาห์เหลือหน่วยวันสำหรับฟีเจอร์ใหม่ โดยไม่ต้องเพิ่มคน
• ∞ Scale — standard ของ developer คนเดียว serve ได้ทุกทีม ทุกโปรเจกต์ ตลอดไป
• 100% Compliance — กฎ security และ PDPA ถูก apply ทุกครั้งที่ generate โค้ด

สรุป (Conclusion)

Key takeaways ของ session นี้สรุปได้ 5 ข้อ: Prompt อย่างมีประสิทธิภาพและให้ context, ชี้นำกระบวนการคิดของ AI, ทำ Agent SOP เพื่อ reusability, อย่าประนีประนอมกับมาตรฐานของคุณ, และ ยกระดับทีมงานของคุณ

หัวใจสำคัญคือการมอง AI เป็น junior developer ที่ทรงพลังแต่ต้องมีกรอบกำกับ — เมื่อเราลงทุนเขียน instruction/steering files ที่ชัดเจน มีตัวอย่าง และดูแลให้ทันสมัย เราก็สามารถให้แม้แต่คน non-developer สร้างฟีเจอร์ที่ผ่านมาตรฐาน security และ compliance ได้ ดังที่ Wipay พิสูจน์ให้เห็นแล้วในการใช้งานจริง

อ้างอิง (References)

1. Amazon Q Developer — Coding Assistant
2. Introducing an agentic coding experience in your IDE — AWS DevOps & Developer Productivity Blog
3. Five ways to use Kiro and Amazon Q to strengthen your security posture — AWS Security Blog