Superset บน Vercel: เมื่อ Agent หลายตัวต้องการ Platform ที่เร็วพอ

Vercel เผยแพร่ customer story เรื่อง How Superset built the IDE for AI agents on Vercel เมื่อวันที่ 10 พฤษภาคม 2026

บทความนี้ดูเหมือน case study ของ startup หนึ่งราย แต่ผมคิดว่ามันเป็นสัญญาณที่ใหญ่กว่านั้น

เพราะมันตอบคำถามที่หลายทีมกำลังจะเจอเร็ว ๆ นี้:

ถ้า AI agent ไม่ได้ทำงานทีละตัว แต่ทำงานพร้อมกันหลายตัว platform หลังบ้านต้องเปลี่ยนอย่างไร

Superset วางตัวเป็น IDE สำหรับ multi-agent development ให้ developer สั่ง coding agents หลายตัวทำงานขนานกัน แต่ละตัวมี isolated workspace ของตัวเอง และทำงานหลาย branch พร้อมกันได้

Vercel ระบุว่า Superset ใช้งานประมาณ 1,000 ถึง 1,400 deployments ต่อสัปดาห์, มี preview deployments ภายในประมาณ 600 ครั้งต่อวัน, build time เฉลี่ยประมาณ 30 วินาที และช่วงที่เล่า case มี DAU growth ระดับ 57 ถึง 64% week-over-week

ตัวเลขเหล่านี้ไม่ได้แปลว่าเราควร copy stack ของ Superset ทันที

แต่แปลว่าโลก software กำลังขยับจาก “คนหนึ่งคนคุม assistant หนึ่งตัว” ไปสู่ “คนหนึ่งคนคุม agent หลายตัวพร้อมกัน”

และเมื่อเปลี่ยนแบบนั้น สิ่งที่สำคัญไม่ใช่แค่ model

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

1) Parallel agent ไม่ได้แปลว่า parallel outcome เสมอไป

ฟังดูง่ายมาก:

ถ้า agent หนึ่งตัวช่วยเขียนโค้ดได้เร็วขึ้น งั้น agent สิบตัวก็น่าจะเร็วขึ้นสิบเท่า

แต่ในงานจริง มันไม่ตรงไปตรงมาแบบนั้น

เพราะงาน software มีคอขวดหลายชั้น:

• clone repo
• setup dependency
• run tests
• build app
• create preview URL
• review diff
• merge branch
• deploy
• rollback ถ้ามีปัญหา

ถ้าแต่ละขั้นยังต้องรอ manual setup หรือรอ queue เดียวกัน agent สิบตัวก็จะไม่ได้ขนานจริง

มันแค่สร้าง output สิบกองที่ไปรอคิวเดียวกัน

นี่คือเหตุผลที่ Superset น่าสนใจ

Vercel เล่าว่า Superset ให้แต่ละ branch มี preview deployment อัตโนมัติ และ platform ไม่บังคับให้ workflow ต้องกลับไปต่อคิวแบบเดิม

บทเรียนคือ:

agent concurrency ต้องการ infrastructure concurrency

ถ้า infrastructure ไม่พร้อม ความเร็วของ model จะกลายเป็นแค่ความเร็วในการสร้างงานค้าง

2) Preview URL กลายเป็น proof ไม่ใช่ของแถม

ในโลกเดิม preview deployment เป็น convenience

ในโลก agent มันเริ่มกลายเป็น proof layer

เพราะถ้า agent สร้าง patch มาให้ review เฉย ๆ คนยังต้องเดาว่า:

• app รันได้จริงไหม
• UI พังไหม
• flow สำคัญยังทำงานไหม
• dependency ติดตั้งครบไหม
• edge case ที่ agent อ้างว่าแก้แล้วผ่านจริงไหม

แต่ถ้าทุก branch มี preview URL อัตโนมัติ คน review จะเห็นหลักฐานเร็วขึ้น

นี่สำคัญมากสำหรับทีมเล็ก

เพราะทีมเล็กไม่มีเวลานั่งอ่าน diff ทุกบรรทัดจาก agent หลายตัวทั้งวัน

สิ่งที่ควรออกแบบคือ review workflow ที่มี proof เป็นหลัก:

• preview URL
• test result
• build log
• screenshot
• reproduction note
• rollback path

agent ที่ไม่มี proof จะกลายเป็นภาระใหม่ของหัวหน้าทีม

agent ที่มี proof จะกลายเป็น worker ที่พอ review ได้จริง

3) Small team ไม่ได้แปลว่าต้องมี platform team เสมอไป

Vercel ระบุว่า Superset เริ่มจากทีมเล็กมาก และรันหลาย Next.js projects บน Vercel โดยไม่ต้องตั้ง platform engineering team แยก

นี่เป็นมุมที่น่าสนใจสำหรับธุรกิจไทย

เพราะหลายบริษัทพอพูดถึง AI agent แล้วจะคิดว่า:

“ถ้าจะทำจริง ต้องมีทีม infra ใหญ่ ต้องมี MLOps ต้องมี DevOps เต็มรูปแบบ”

บางงานอาจต้องมีจริง

แต่ case นี้สะท้อนอีกทางหนึ่ง:

ทีมเล็กสามารถใช้ managed platform เพื่อซื้อความสามารถบางชั้นแทนการสร้างเอง เช่น preview deployment, routing, model gateway, storage, cron, compute, bot filtering, และ rollback

ประเด็นไม่ใช่ต้องใช้ Vercel เท่านั้น

ประเด็นคือก่อนให้ agent ทำงานจริง เราต้องรู้ว่าชั้นไหนควร build เอง และชั้นไหนควรใช้ platform ที่พิสูจน์แล้ว

ถ้าทีมเล็กพยายามสร้างทุกอย่างเองก่อนใช้ agent จริง อาจเสียเวลาที่ควรเอาไปใช้กับ product, customer, หรือ workflow

แต่ถ้าใช้ platform โดยไม่มี guardrail ก็เสี่ยงอีกแบบ

ดังนั้นคำถามที่ควรถามคือ:

เราจะซื้อความเร็วจาก platform โดยไม่ซื้อความเสี่ยงเพิ่มได้อย่างไร

4) Agent product ต้องคิดเรื่อง cleanup ตั้งแต่วันแรก

เมื่อ agent ทำงานพร้อมกันเยอะขึ้น สิ่งที่ตามมาคือ environment, preview, artifact, branch, log, และ temporary resource จำนวนมาก

Vercel บอกว่า Superset ใช้ Cron Jobs เพื่อกันไม่ให้ parallel environments สะสมทับกัน

นี่เป็น detail เล็กที่สำคัญมาก

เพราะ agent workflow ที่ไม่มี cleanup จะค่อย ๆ กลายเป็นต้นทุนแฝง:

• preview เก่าค้าง
• branch เก่าค้าง
• storage เต็ม
• log หาไม่เจอ
• secret scope กระจาย
• cost อ่านยาก
• คนไม่รู้ว่าอันไหนยังใช้จริง

นี่คือความต่างระหว่าง demo กับ operation

demo สนใจว่า agent ทำงานได้ไหม

operation สนใจว่า agent ทำงานซ้ำได้ไหม โดยไม่ทิ้งภาระไว้ข้างหลัง

สำหรับทีมที่เริ่มใช้ coding agents ผมแนะนำให้ตั้ง cleanup rules ตั้งแต่แรก:

• branch ที่ไม่มี activity กี่วันควรถูกปิด
• preview URL อายุเท่าไร
• artifact เก็บนานแค่ไหน
• log อะไรต้องเก็บเพื่อ audit
• secret ถูก revoke อย่างไร
• job ที่ fail ซ้ำต้อง alert ใคร

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

5) ตัวชี้วัดของ agent ไม่ควรหยุดที่จำนวน task

สิ่งที่หลายทีมอาจพลาดคือวัด agent จากจำนวน task ที่มันรับ

เช่น “วันนี้ agent ทำ 30 tickets”

ตัวเลขนั้นมีประโยชน์ แต่ยังไม่พอ

ถ้าจะใช้ agent เป็น operating system จริง ผมอยากเห็น metric แบบนี้มากกว่า:

• lead time จาก issue ถึง preview
• percentage ของ agent output ที่ผ่าน test ครั้งแรก
• review time ต่อ PR
• rollback frequency
• cost ต่อ merged change
• จำนวนงานที่ต้องให้คนแก้ซ้ำ
• จำนวน incident ที่เกิดจาก agent output
• queue time ของ build และ deploy

Superset case ทำให้เห็นว่าความเร็วของ agent ต้องผูกกับความเร็วของ platform

ถ้า build เฉลี่ยประมาณ 30 วินาที คน review จะวน feedback ได้เร็ว

ถ้า preview deployment วันละหลายร้อยครั้งยังไหลอยู่ agent หลายตัวก็มีพื้นที่ทำงาน

แต่ถ้า build ช้า 20 นาที หรือ preview ต้องกดมือ ความได้เปรียบของ agent จะหายไปมาก

6) มุมมองของผม: อย่าเพิ่ม agent ก่อนออกแบบ queue

ผมคิดว่าองค์กรจำนวนมากจะเจอปัญหานี้ในปี 2026:

มี agent มากขึ้น แต่ throughput ไม่เพิ่มตาม

สาเหตุไม่ใช่เพราะ agent ไม่เก่ง

แต่เพราะระบบรับงานยังเป็นคอขวดเดิม:

• มีคนเดียวอนุมัติทุกอย่าง
• ไม่มี preview อัตโนมัติ
• ไม่มี test ที่เชื่อถือได้
• ไม่มี environment แยก
• ไม่มี queue policy
• ไม่มี owner ของ cleanup
• ไม่มี rollback ที่คนกล้ากด

ถ้าจะใช้ agent หลายตัวจริง อย่าเริ่มจากเพิ่มจำนวน agent

ให้เริ่มจากวาด workflow queue ก่อน:

1. Agent รับงานจากที่ไหน
2. Agent ทำงานใน environment แบบไหน
3. Proof ที่ต้องส่งก่อน review คืออะไร
4. คน review ตัดสินจากหลักฐานไหน
5. อะไร merge ได้เอง และอะไรต้องขอ approval
6. ถ้า deploy แล้วพัง rollback อย่างไร
7. Resource ที่ agent สร้างจะถูก cleanup เมื่อไร

เมื่อคำถามพวกนี้ชัด การเพิ่ม agent จะเริ่มมีเหตุผล

แต่ถ้ายังไม่ชัด agent หลายตัวจะไม่ได้ทำให้บริษัทเป็น AI-first

มันแค่ทำให้คอขวดเดิมดังขึ้น

7) Checklist สำหรับทีมไทย

ก่อนให้ coding agent หลายตัวทำงานพร้อมกัน ลองเช็ก 10 ข้อนี้:

1. ทุก agent มี workspace แยกหรือยัง
2. ทุก branch มี preview URL อัตโนมัติไหม
3. test command และ build command เป็นมาตรฐานหรือยัง
4. secret ถูกจำกัดตามงานหรือยัง
5. egress/network ถูกจำกัดตามความจำเป็นหรือยัง
6. artifact และ log เก็บในที่เดียวกันไหม
7. คน review เห็น proof ก่อน merge ไหม
8. มี rollback ที่เร็วและซ้อมแล้วไหม
9. มี cleanup policy สำหรับ preview, branch, artifact หรือยัง
10. มี metric วัด cost per accepted outcome หรือยัง

ถ้ายังตอบไม่ได้ ไม่ได้แปลว่าห้ามใช้ agent

แต่ควรเริ่มจากงานเล็กที่ environment คุมได้ และมี proof ชัดก่อน

อย่าเริ่มจากให้ agent สิบตัววิ่งเข้า repo production พร้อมกัน

สรุป

Superset case บน Vercel เป็นสัญญาณว่า AI development กำลังขยับจาก single-agent assistant ไปสู่ multi-agent operating model

เมื่อถึงจุดนั้น คำถามจะไม่ใช่แค่:

“agent ตัวไหนฉลาดที่สุด”

แต่จะเป็น:

“platform ของเราพร้อมให้ agent หลายตัวทำงานพร้อมกันอย่างรับผิดชอบหรือยัง”

ถ้า platform พร้อม agent จะกลายเป็นแรงทวีคูณ

ถ้า platform ไม่พร้อม agent จะกลายเป็นเครื่องสร้าง queue, cost, และ review burden

สำหรับผม นี่คือบทเรียนหลักจาก Superset:

AI agent ที่ดีไม่ได้ต้องการแค่ model ดี

มันต้องการระบบที่เร็วพอ, แยกพอ, ตรวจได้, rollback ได้ และ cleanup ได้

นั่นแหละครับ ถึงจะเริ่มเรียกว่า agent ทำงานเป็นทีมได้จริง