21/10/2026
เมื่อ AI Agent ผลิตโค้ดได้เยอะ และไว เปิด PR ได้ 40 แต่คนมี 3 คน
แล้วเราจะจัดการ bottomneck ยังไงดี?
เพราะปกติก็ดอง code review กันอยู่แล้ว อ่ะมั่ยชั่ย
สรุปจาก session "The Bottleneck Moved: Small-Team Architecture When Writing Code Is No Longer the Hard Part" โดยพี่คุณ Kittikorn Prasertsak — Managing Director, BorntoDev จากงาน LINE DEV CONF 2026
การพัฒนา software มี cost ที่แพง แต่ตอนนี้มี AI เข้ามา มีวิธีไหนที่ ship งานได้เร็ว และลดคอขวดของงาน เพราะงานเราไม่ได้ลดลง ใน session นี้จะเน้นการทำงานในทีมเล็ก
ตัว agent เปิดได้ 40 PR/วัน สมมุติทีมมี 3 คน ซึ่งเป็นคน review code ด้วย ก็จะกลายเป็นคอขวด เพราะตรวจไม่ทัน ถ้าจำนวนงานเยอะ ใครจะอ่าน PR ทั้งหมดไหว งานก็ต้องมีคนรับผิดชอบ
เมื่อ AI Coding Agent ช่วยให้ทีมผลิตโค้ดได้เร็วขึ้นมาก ตอนนี้มีคอขวดของการเข้าใจของทีม ต้องเข้าใจบริบทของ requirement
AI ต้องเป็นตัวขยาย ไม่ใช่ตัวแก้ อาจจะเพิ่มปัญหา แทนการลดงาน เพราะ requirement ไม่ clear
อย่าวัดด้วยความรู้สึก แต่ต้องมีตัววัด ถ้าของบางอย่างลดไม่ได้ เช่น requirement ก็ต้องลดของบางอย่างใน process ขวดของเรา
1. Context: ต้นทาง จัดการ context เข้าใจว่าโค้ดเราทำงานยังไง
2. Guardrail: ไม่ต้องมานั่งตรวจ
3. Orchestration: focus สิ่งที่เราสนใจ
1️⃣ Context: ให้ agent เข้าใจก่อนเขียน
Best practice = การทำงานขององค์กร และลูกค้าที่เราเจอ เช่น มีตัวแปร flag แต่ไม่ได้ถูกอัพเดตตามไป แล้วจะแก้ยังไงดี? แน่นอนว่ามีค่าใช้จ่ายที่เกิดขึ้น มีการขาดทุน คนไม่อยากเจออยู่แล้ว แค่ยิง ads ใส่ param ผิดก็เสียไปหลักล้านแล้ว
ต้องกำหนดขอบเขต คือ กำหนดสิ่งที่ agemt ต้องอ่าน การใช้บน cloud เครื่องมือตรงนี้ดีอยู่แล้ว ไฟล์ agents.md ต้องสั้น และเล็ก เพื่อบอกขอบเขตในการทำงานได้หลาย ๆ ไฟล์ ว่าทำอะไรได้บ้าง ต้อง run command อะไร ไม่งั้น agent คิดเองทุกรอบ แล้ว ccontext เต็ม ก็ต้องกลับไปทำความเข้าใจใหม่อีก อาจจะเกิดความเข้าใจผิด หรือเปลือง token ได้
ADR (Architecture Decision Record) คล้าย git แต่เก็บเหตุผลในการตัดสินใจ ทีมเล็กสามารถหยิบของใน repo นี้ไปใช้งานได้เลย แล้วเราหยิบไปเพราะอะไร เราต้อง review ADR แล้วไปปรับจูน
ทุกครั้งที่ตัดสินใจ มีการทำ closed-loop ทำให้ AI ฉลาดขึ้น
และถ้ายานอวกาศใส่หน่วยผิด มันจะระเบิด ดังนั้นให้ใส่หน่วยด้วย ป้องกัยการทำหน่วยผิด อาจจะทำเป็น unit test ก็ได้
2️⃣ Guardrail
เป็นการตั้งกฏกติกาใน code base ของเรา ทำให้งานตรง requirement มากขึ้น
ห้ามให้สิทธิ์ root หรือ bypass เพราะอาจจะเกิดหายนะขึ้นได้ อาจจะกำหนดสิทธิ์ด้วย prompt แต่ควรระบุไว้ในโปรแกรม ซึ่งอันนี้จะมีอยู่ในการทำ AI governance
เขียน test case วุ่นวาย ส่งให้ AI เขียนให้เราไว้ก่อนเลย แต่สุดท้ายเราเป็นคน review ไม่ให้ AI ทำงานนอกเหนือจากที่เราสั่ง → กำหนดด่านตรวจ เช่น ดู secret, typecheck โดยประหยัดเวลา
ปัญหา agent เขียน feature และ unit test อาจจะสร้างปัญหาในอนาคตได้ เราต้องสร้าง plan หรือ test case ก่อน ดูว่าระบบทำอะไร หลัก TDC ตัว test case ต้องแดง แล้วให้ agent เขียน test case ให้เขียว เราต้อง review test case ก่อน แต่เราต้องเข้าใจก่อนว่าเราอยากได้อะไร
ดังนั้นอย่าให้ agent ถือกุญแจในงานเดียวกับเรา
3️⃣ Orchestration: ทำในส่วนที่เราควรทำ เช่น
- ถ้ามี version ใหม่ ค่อยปล่อยทีละน้อย ให้ user ได้ใช้งาน เพื่อลดผลกระทบให้น้อยลง (ถ้าแอพเราก็จะเรียก roll-out คือเราจะปล่อยให้ user กลุ่มแรกกี่เปอร์เซ็นต์ ถึงจะปล่อยทั้งหมด)
- การ review อาจจะมี agent อีกตัวมาทำงานตรงนี้ เน้นดู diff
- สามารถแบ่งงานเป็น tier ได้ → Red (คน approve แต่ให้ agent ร่างได้), Green (agent เขียนโค้ดให้ผ่าน), Refactor
- ให้คนรีวิวลึกเฉพาะ Tier 2 คือพวก contract, auth, migration, payment ที่เหลือให้เครื่องบล็อกพวก permission, hook, CI ได้
- hooks: agent ทำอะไรบางอย่าง เขียนการทำงานได้ ไม่ได้ระบุ prompt แต่เป็นคู่มือในการทำงาน
📌 สรุป
- งานซํ้า ๆ เราสามารถเขียน code หรือ script ได้
- งานไหนควรทำ งานไหนไม่ควรทำ
- agent ทำงานอะไรได้บ้าง สามารถเอาไปทำเป็นระบบได้
