มุมมองการใช้ Self Coding Agents จากทีมพัฒนา Agent เขียนโค้ดที่มาแรงที่สุดในโลกตอนนี้ เมื่อโค้ดเขียนโค้ดเองได้ อนาคตจะเป็นอย่างไร

ความน่ากลัวอย่างหนึ่งของโลก AGI คือ AI เก่งกว่ามนุษย์ในทุก ๆ ด้าน ซึ่งเรื่องนี้เกิดขึ้นแล้วในห้องทดลองลือว่างั้นนะครับ แต่เมื่อ AGI หรือ ASI เกิดขึ้นแล้ว เรื่องโปรแกรมมิ่ง หรือโค้ด AI สามารถเขียน โค้ดได้เก่งกว่า แน่นอนว่า AI จะไม่ต้องการความไม่สมบูรณ์แบบของมนุษย์ มาปรับแก้ไขสิ่งที่สมบูรณ์แบบคือ โค้ดที่ AI เขียนหรือพัฒนาจนสมบูรณ์ เมื่อถึงจุดนั้นจะเกิดเหตุการณ์ที่ AGI Coding ความสามารถของตัวเองเพิ่มขึ้น แล้วทิ้งมนุษย์ไว้ข้างหลัง มนุษย์ควบคุมอะไร AI ไม่ได้อีกต่อไป พล๊อตเหมือนหนัง อนาคต ที่เราเคยดูกัน

บทความนี้ผมสรุปมาจากมุมของคุณ Colin Flaherty จาก Augment Code ซึ่งถือว่าเป็นอีกหนึ่ง Startup ดาวรุ่งด้าน AI Self Coding Agents ทีมนี้สร้าง แพลตฟอร์ม AI Self Coding Agents สำหรับวิศวกรซอฟต์แวร์มืออาชีพ AI ผู้ช่วยเขียนโค้ด ให้ทำงานกับโค้ดเบสขนาดใหญ่ได้เหมือนผู้เชี่ยวชาญภายในทีม อนาคตทีมเดฟ ในบริษัทก็จะมี AI Agent เป็นส่วนหนึ่งของทีม แต่จะทำยังไงให้สำเร็จ รายละเอียดผมขยายความไว้ให้แล้วในบทความครับ

สิ่งที่โดดเด่นของ Augment Code คือ สร้าง Self Coding Agents ฉลาดที่สุดสามารถแก้ไขโจทย์การเขียนโปรแกรมที่ยาก ๆ เป็นอันดับหนึ่งของ SWE-Bench¹ มาตรฐานกลางวัดความสามารถ AI ในการเขียนโค้ด ชนะ Google DeepSeekR1 และ OpenAI (ณ ​เวลาที่ผมเขียนบทความนี้นะครับ อันดับเปลี่ยนตลอดทุก ๆ Quarter หรืออาจจะรายเดือน)

Self Coding Agents คืออะไร

AI Coding Agents หรือ “AI ผู้ช่วยในการเขียนโค้ด (Self Coding Agents)” กำลังเปลี่ยนโฉมหน้าวิศวกรรมซอฟต์แวร์ จากเดิมที่เราใช้ autocomplete และ chat models ในการช่วยเขียนโค้ด ก้าวไปสู่ยุคที่ AI สามารถ “เขียนโค้ดเอง” ได้ แต่อยู่ภายใต้การดูแลของมนุษย์เพียงเล็กน้อยเท่านั้น

ช่วงที่ผ่านมา มีคำว่า VIBE Coding เกิดขึ้นมาในโลกนักพัฒนา เพราะการเขียนโค้ดที่มี AI ช่วยเปลี่ยนความรู้สึกในการทำงานโค้ดดิ้ง ไปมาก ถาม AI-> ช่วยปรับโค้ด เขียนให้ใหม่ -> เอาโค้ดมาใช้ แล้วก็เขียนเพิ่ม มันเกิดสภาวะ Flow ลื่นไหลในการทำงานไปเรื่อย ได้ Code และงานคืบหน้าอย่างมากโดยที่เขียนโค้ดน้อยลงมาก เพราะ AI มาช่วยเขียน นักพัฒนาแค่ตรวจสอบโค้ดและกำกับมัน เป็นความรู้สึกเสมือนการเขียนโค้ดน้อยลงแต่การทำงานคืบหน้าไปอย่างมาก ด้วยการช่วยเหลือของ AI

พลังของ Self-Coding Agents ได้เกิดขึ้นแล้ว

อ้างอิงจากคุณกระทิง ให้สัมภาษณ์รายการ The Standard ว่าภายใน KBTG ปี 2024 ทีมงานใช้ AI ช่วยในการเขียนโค้ดไปแล้ว 400,000 บรรทัด และปีล่าสุดเขียนโค้ดเพิ่มขึ้นเป็น 30 ล้านบรรทัด เพิ่มขึ้น 75 เท่า

และเคสที่ Colin Flaherty นำมาเล่าให้ฟัง ในโครงการพัฒนา AI เขียนโค้ดของ Augment Code พวกเขาได้สร้าง Agent ขึ้นมา และโค้ดทั้งหมด ~20,000 บรรทัด มีมากกว่า 90% เขียนโดยตัวแทน AI ภายใต้การควบคุมของทีมมนุษย์ แสดงให้เห็นว่า AI ไม่ได้ช่วยแค่ “เติมโค้ดเล็กๆ” แต่สามารถสร้างฟีเจอร์หลักของระบบได้จริง (feature‑scale code)

20,000 บรรทัด มี 90% เขียนโดย Agent ซึ่งรวมทั้งการเพิ่ม integration เขียน tests และการ optimize performance — ภายใต้การดูแลของทีมมนุษย์

พวกเขาเพิ่ม third‑party integration ให้ Agent เพื่อให้ Agent สามารถทำงานได้เหมือนทีมโค้ดดิ้งจริง ๆ​ โดยเชื่อม Slack, Linear, Jira, Notion, Google Search ที่น่าตกใจกว่านั้น ทีมงานได้สั่งให้มัน ‘เพิ่ม Google Search integration’ Agent ก็ไปค้นหาไฟล์โค้ด เลือก interface ที่ถูกต้อง แล้วเขียนโค้ดส่วนเชื่อมต่อนั้นให้เอง” หลายๆ การเขียนโค้ดเพิ่มเติมตามคำสั่ง Agent ไปค้นหา Google และสร้างโค้ดเชื่อม API Integrate ได้เองจากแค่คำสั่ง

โค้ดทั้งหมด 20,000 บรรทัด ที่มี 90% เขียนโดย Agent ซึ่งรวมทั้งการเพิ่ม integration เขียน tests และการ optimize performance — ทั้งหมดอยู่ ภายใต้การดูแลของทีมมนุษย์

จากเคส ความน่าสนใจ จากสิ่งที่เกิดขึ้นจากการสร้าง Coding Agent และการให้ agent เข้ามาร่วมพัฒนาโค้ด

• การ onboard Agent ค่อนข้างสำคัญเช่นกัน ก็เหมือนการ onboarding ทีมงานวิศวกรใหม่ ต้องมี docs, knowledge base เตรียมไว้ให้ AI เรียนรู้และถาม ไม่ใช่ปล่อย AI ให้ดู code เองเฉย ๆ
• เมื่อต้องสร้าง third‑party integrations หลายตัว เราสามารถให้ Agent สร้างพร้อมกันได้ทั้งหมด ทำให้ product management เปลี่ยน bottleneck ไม่ใช่ชั่วโมงเขียนโค้ด แต่มาจากไอเดียและการออกแบบ

• เมื่อต้องสร้าง third‑party integrations หลายตัว เราสามารถให้ Agent สร้างพร้อมกันได้ทั้งหมด ทำให้ product management เปลี่ยน — bottleneck ไม่ใช่ชั่วโมงเขียนโค้ด แต่มาจากไอเดียและการออกแบบ ผมยกตัวอย่างให้เห็นภาพมากขึ้น
  • สมมติทีมอยากเชื่อม Slack, Jira, Google Calendar และ Notion เข้ากับระบบ CRM
    • เดิม (มนุษย์เขียนโค้ด): รวม 8 วัน
      • วิศวกร A เขียน Slack integration (2 วัน)
      • วิศวกร B เขียน Jira integration (2 วัน)
      • วิศวกร C เขียน Google Calendar (2 วัน)
      • วิศวกร D เขียน Notion (2 วัน)
    • ใหม่ (AI Agent ช่วย): ทั้งหมดรวมแค่ 1 วัน
      • ให้ Agent รับคำสั่ง “สร้าง Slack, Jira, Google Calendar, Notion integrations
      • Agent สร้างโค้ดพื้นฐานทั้ง 4 ตัวพร้อม unit tests (ภายใน 4 ชั่วโมง)
      • วิศวกรทดสอบ ปรับดีไซน์ API และ business logic (4–6 ชั่วโมง)
    • Bottleneck ไม่ใช่เวลาตัวเขียนโค้ด เพราะความเร็วของการเขียนโค้ดต่างกันมากเหมือนในตัวอย่าง แต่กลายเป็นการตัดสินใจว่า “เราจะออกแบบ UX/flow ของ integrations ยังไง” และ “เลือก use‑cases ไหนก่อน” จะกลายเป็นเรื่องที่ต้องคิดและใช้เวลามากกว่า
      
• อีกอย่างที่ Agent ช่วยได้มาก มีการเขียนคำสั่งให้ Agent ดู PR(Pull Request) ล่าสุด สร้าง announcement แล้วโพสต์ใน Slack AI ทำได้เพราะมี Slack integration และ context engine ที่เข้าใจ code base เปรียบเทียบให้เห็นภาพ เดิม และการใช้ Agent

เมื่อเราสั่งให้ AI Agent “ดู PR ล่าสุด สร้าง announcement แล้วโพสต์ใน Slack” สิ่งที่ได้คือ:

• ประโยชน์สำคัญสำหรับคนไม่ใช่ Dev
  • ข้อมูลสื่อสารทันใจ ไม่ต้องรอวิศวกรสรุป PR ด้วยตนเอง ทีมอื่นก็รู้ความคืบหน้าเร็วขึ้น
  • ลดความผิดพลาด ข้อความประกาศมาจาก AI ที่ดึงข้อมูลตรงจากระบบ โอกาสพิมพ์ผิดหรือลืมข้อมูลสำคัญต่ำ
  • ประหยัดเวลา ขั้นตอนที่เคยหลายขั้นกลายเป็นคำสั่งเดียว ทีม Dev ใช้เวลาไปกับการพัฒนาฟีเจอร์แทน
  • สอดคล้องเป็นมาตรฐาน รูปแบบประกาศใน Slack จะเหมือนกันทุกครั้ง ดูเป็นมืออาชีพ และติดตามง่าย
• พูดง่ายๆ คือ AI Agent ช่วย “อัตโนมัติขั้นตอนที่ซ้ำซาก” ทำให้ทั้งทีมรับข่าวสารได้เร็ว แม่นยำ และ Dev มีเวลาทุ่มเทกับงานที่สร้างมูลค่ามากขึ้นครับ

• สำหรับเรื่อง testing: Agent เขียนฟังก์ชัน save cache แบบมี lock แต่ลืม read‑modify‑write จึงเกิด race condition เราเรียนรู้ว่าต้องมี test harness ครอบ parallel edge cases
  
• ห้ามมอง Agent เป็นคน : ไม่ควรเปรียบคุณสมบัติของวิศวกรที่ยังเพิ่งเริ่มต้น กับ Agent ระดับเพิ่งเริ่มต้นไม่ได้ เพราะ Skill ศักยภาพไม่เหมือนกัน
  
  Agent อาจทำ math ไม่ได้แต่เขียนฟีเจอร์ frontend ได้เร็วกว่ามนุษย์มาก ซึ่งหมายถึงคือ อย่าไปตีกรอบคุณสมบัติของ AI Agents ให้เหมือนกับวิศวกรมนุษย์ เพราะจุดแข็งและจุดอ่อน ต่างกันอย่างสิ้นเชิง

ทำไมห้ามเทียบตรงๆ Coding Agent กับ โปรแกรมเมอร์ตรงๆ

ทำไม “Context Engine” ในกระบวนการใช้ AI Coding Agent จึงสำคัญ

สิ่งที่สำคัญจากโครงการที่ คุณ Colin Flaherty อธิบายมาทั้งหมด ความสำคัญเรื่องนึงที่จะทำให้ Coding Agent ประสบความสำเร็จในการทำงานร่วมกับทีม คือการวางพื้นฐานของ “Context Engine”

Context Engine คือ ระบบรวบรวมและจัดระเบียบข้อมูลทุกแหล่ง (โค้ดเบส, เอกสาร, logs, chat history) ให้ AI Agents เข้าถึงบริบทครบถ้วนแบบเรียลไทม์ การมี Context Engine จะทำให้ AI คัดสรรข้อมูลที่เกี่ยวข้องมายัดใน prompt อัตโนมัติ ช่วยลดข้อผิดพลาดและทำให้โค้ดที่สร้างตรงตามมาตรฐานองค์กร และออกแบบให้ขยายตัว Scale ได้ง่าย รองรับงานระดับ Enterprise ที่มีโค้ดเบสขนาดใหญ่และผู้ใช้จำนวนมาก

เช่น ในกระบวนการใช้ AI Coding Agent ถ้าทีมมี ทีมมีโค้ดเบส 200K บรรทัด กระจายหลาย repo และ มี Slack, Jira, Notion เป็นเครื่องมือสื่อสาร เมื่อสั่ง Agent “เพิ่มฟีเจอร์ X” Context Engine จะรวบรวม โค้ดที่เกี่ยวข้องกับฟีเจอร์ X, เทมเพลตการเขียนขององค์กร (style guide) , ประวัติ discussion ใน Jira/Slack ที่เกี่ยวข้อง, ตัวอย่าง unit tests ที่มีโครงสร้างคล้ายกัน ซึ่งทั้งหมดนี้ ทำให้ Agent จึงสร้างโค้ดฟีเจอร์ X ได้ตรงตามมาตรฐานองค์กร เสร็จเร็ว และผ่านการทดสอบอัตโนมัติ

สรุป คือ “Context Engine” ในกระบวนการใช้ AI Coding Agent จึงสำคัญ

• ช่วยให้ AI เข้าใจโปรเจกต์ขนาดใหญ่ โปรเจกต์จริงมีหลายไฟล์ หลายทีม หลายเครื่องมือ Context Engine รวบรวมทุกแหล่งให้ AI เห็นภาพรวม
• ช่วยให้สื่อสารกับ Agent ดีขึ้น เมื่อ Agent ได้รับ prompt มันจะใช้ Context Engine ดึงข้อมูลที่เกี่ยวข้อง (เช่น ฟังก์ชันที่เกี่ยวข้อง, API docs, การตั้งค่า credentials) มาใส่ใน prompt โดยอัตโนมัติ
• ลดข้อผิดพลาด ช่วยให้ Agent ไม่ “หลงทาง” ในโค้ดเบส ช่วยลดบั๊กที่เกิดจากการขาดบริบท
• รองรับองค์กร ต้องรับโหลดคำขอจำนวนมาก รักษาความปลอดภัยของข้อมูลภายในองค์กร และขยายตัวเมื่อทีมใหญ่ขึ้น

“Context Engine นี่คือฐานรากที่มั่นคงและยืดหยุ่น ให้ AI Agents ทำงานกับโปรเจกต์ขนาดใหญ่ได้อย่างแม่นยำและปลอดภัยในระดับองค์กร” ครับ

บทสรุป & แนวโน้มอนาคต

อนาคต software engineering ในยุค Agents: โค้ดยังสำคัญ แต่ความสัมพันธ์กับโค้ดเปลี่ยนไป good test harnesses และ product/design thinking จะเป็นหัวใจ เพราะ code becomes cheap to write

จากทั้งหมดแสดงให้เห็นว่า การทำงานการ Coding ของทีมงงานจะมีประสิทธิภาพมากขึ้นเรื่อย ๆ ผมมองงว่าหลาย ๆ บริษัท ที่บอกว่าบริษัทตัวเองไม่ใช่ Tech และไม่ได้อยากมีทีม Tech เพราะเป็นการลงทุนที่ไม่ใช่ Core Competentcy ของตนเอง น่าจะต้องลองเปลี่ยนมุมมองดูนะครับ เพราะว่าอนาคตการพัฒนาโค้ด ไม่ใช่เรื่องที่ยากขนาดนั้นแล้ว อาจมีทีมงานเล็ก ๆ 2-3 คนกำกับดูแลการเขียนโค้ดกับ Agent ก็สามารถสร้าง Software SOlutions ไว้ช้ในองค์กรได้ลดการใช้ Software ภายนอกที่อาจไม่ตรงต่อความต้องการทั้งหมดและแพง

การสามารถสร้าง Solutions ได้ช่วยทีมได้มากและเร็วเพิ่ม Prosuctivity ให้ภายในได้รวดเร็วกว่า ความยืดหยุ่นสูงกส่า

สิ่งเหล่านี้ทำให้เห็นครับว่า โค้ด “ถูกลง” และถูกยิ่งขึ้น: การเขียนโค้ดพื้นฐานจะเกือบเป็นอัตโนมัติ จึงเหลือเวลาทีมงานโฟกัสที่การออกแบบสถาปัตยกรรม, UX และกลยุทธ์ผลิตภัณฑ์

โดยสรุป

• อนาคต software engineering ในยุค Agents: โค้ดยังสำคัญ แต่ความสัมพันธ์กับโค้ดเปลี่ยนไป good test harnesses และ product/design thinking จะเป็นหัวใจ เพราะ code becomes cheap to write
• Product‑First Mindset: Bottleneck การพัฒนาจะเลื่อนไปที่ “ไอเดีย” และ “การตัดสินใจเชิงผลิตภัณฑ์” มากกว่า “จำนวนบรรทัดโค้ด”
• Multi‑Agent Collaboration: ทีมจะใช้หลาย Agent ทำงานพร้อมกันในหน้าที่เฉพาะ (testing agent, security agent, doc‑writer agent) แล้ว orchestrate ผลลัพธ์ร่วมกัน
• Continuous Learning Loop: Agents จะเรียนรู้จากการโต้ตอบจริง เก็บ memory และปรับปรุงตัวเองแบบทวีคูณ
• ขยายไปยัง Domain อื่น: เกินขอบเขตซอฟต์แวร์ ไปสู่ data pipelines, infra automation, DevOps orchestration

เราเองก็กำลังเริ่มต้นเรื่องนี้และปรับแผนภายในเพื่อค่อย ๆ นำเรื่องนี้มาใช้ ใครทำแล้วประสบความสำเร็จก่อน มาแชร์กันด้วยนะครับ แล้วติดตามความคืบหน้าเรื่องนี้ในบริษัท Digithun ในบทความถัด ๆ ไป

FYI : ในวิธีโอมีการให้ Idea ของการวางแนวคิดการการพัฒนาโค้ดให้เป็น ‘ระดับความซับซ้อน’ ของงานแต่ละชิ้น’ แทนที่การแบ่งตามหมวด (categories) ซึ่งผมไม่ได้ขยายความเรื่องนี้ใครสนใจดูได้จาก Video “Self Coding Agents — Colin Flaherty, Augment Code” เพิ่มเติมช่วงนาที 8.34 นะครับ

ดู Video ต้นฉบับที่นี่

1. SWE-bench เป็นเบนช์มาร์กสำหรับวัดความสามารถของ AI ในการแก้ไขปัญหาซอฟต์แวร์จากกรณีจริงบน GitHub ซึ่งแตกต่างจากโจทย์โค้ดดิ้งทั่วไปที่มักเป็นฟังก์ชันเล็กๆ หรือ LeetCode-style โดย SWE-bench ใหญ่ขึ้นทั้งด้าน บริบทโค้ดเบส และ การทดสอบเชิงปฏิบัติ เพื่อตรวจสอบว่าโมเดลสามารถนำทางในโปรเจกต์ขนาดใหญ่ รันชุด regression tests และสร้าง patch ที่ใช้งานได้จริงหรือไม่ ↩︎