Google Antigravity 2.0: เมื่อ Agent หลุดจาก IDE

Google เปิดตัว Antigravity 2.0 ในฐานะ standalone desktop application สำหรับทำงานกับ agent โดยตรงบน macOS, Linux และ Windows

ประโยคที่สำคัญในโพสต์ไม่ใช่แค่ว่ามี feature ใหม่อะไรบ้าง

แต่คือ Google ระบุชัดว่า Antigravity 2.0 เป็นแอปแยกจาก Antigravity IDE และ “ไม่มี IDE” อยู่ในตัว

ผมอ่านเรื่องนี้เป็นสัญญาณใหญ่ของตลาด AI agent:

Agent กำลังแยกตัวจาก editor แล้วกลายเป็น work surface ของตัวเอง

ไม่ใช่แค่หน้าต่างแชต ไม่ใช่แค่ plugin ใน IDE แต่เป็นพื้นที่ที่เรามอบหมายงาน ตั้ง schedule ดู artifact ตรวจผล และคุม permission ได้เป็นระบบกว่าเดิม

1) มีอะไรใหม่แบบสั้น ๆ

จากโพสต์เปิดตัว Google พูดถึงความสามารถหลักของ Antigravity 2.0 หลายจุด:

• Dynamic subagents: agent หลักสามารถสร้าง subagent เฉพาะงาน เพื่อช่วยแบ่งงานและลดการปน context
• Asynchronous task management: งานและ command สามารถรันแบบไม่บล็อกงานหลัก
• JSON hooks: ผู้ใช้กำหนด hook เพื่อ intercept/control พฤติกรรม agent ได้
• Scheduled Tasks: ตั้ง one-off timer หรือ recurring schedule ด้วย /schedule
• Projects แทน workspace/repo: project หนึ่งผูกได้หลาย folder และมี setting/permission guardrail ของตัวเอง
• Slash commands: เช่น /goal, /grill-me, /schedule, /browser
• Live voice transcription: แปลงเสียงเป็นข้อความแบบ live แทนการส่งไฟล์เสียงดิบเข้า model

ถ้ามองเป็น release note ก็จบแค่นี้

แต่ถ้ามองเป็น operating model จะเห็นว่ามันกำลังจัดรูปแบบใหม่ของงานที่ agent ทำแทนเรา

2) ทำไมการแยกออกจาก IDE ถึงสำคัญ

IDE เป็นพื้นที่ของ developer

คนที่ไม่เขียนโค้ดเห็น IDE แล้วมักรู้สึกว่า “นี่ไม่ใช่ที่ของเรา”

แต่ Google บอกชัดในโพสต์ว่า coding จะขยายไปสู่ knowledge work และ agent-first surface ที่ผูกอยู่กับ IDE อย่างเดียวอาจเป็นอุปสรรคสำหรับผู้ใช้ที่ไม่คุ้นกับโค้ด

นี่คือมุมที่ธุรกิจไทยควรสนใจ

เพราะงาน agent ในบริษัทไม่ได้มีแค่เขียนโค้ด เช่น:

• สรุปรายงานยอดขายรายสัปดาห์
• ตรวจเอกสารก่อนส่งลูกค้า
• อ่าน dashboard แล้วแจ้ง anomaly
• เตรียม meeting brief
• ร่าง campaign จาก source ที่กำหนด
• ตรวจ ticket และแยกงานให้ทีม

งานพวกนี้ไม่ควรถูกบังคับให้อยู่ใน IDE เสมอไป

แต่ก็ไม่ควรถูกปล่อยเป็นแชตลอย ๆ แบบไม่มี permission, artifact, log และ approval

Antigravity 2.0 น่าสนใจตรงที่มันพยายามอยู่ระหว่างสองโลกนี้:

• ง่ายพอสำหรับการคุยและมอบหมายงาน
• มี project, permission, artifact และ schedule พอให้ทำงานเป็นระบบ

3) Scheduled Tasks คือสัญญาณว่า agent จะกลายเป็น workload

ฟีเจอร์ /schedule อาจดูเล็ก แต่จริง ๆ สำคัญมาก

เพราะเมื่อ agent ถูกเรียกตาม schedule ได้ งานจะเปลี่ยนจาก “คนเปิดแชตแล้วสั่ง” ไปเป็น “ระบบเรียก agent มาทำงานตามรอบ”

ตัวอย่างที่เริ่มได้แบบปลอดภัยกว่า:

• ทุกเช้าให้ agent อ่าน issue ใหม่แล้วสรุป priority
• ทุกเย็นให้ agent ตรวจ dashboard แล้วสรุป anomaly
• ทุกสัปดาห์ให้ agent เตรียม draft report จาก source ที่กำหนด
• ทุกวันให้ agent scan changelog ของเครื่องมือที่ทีมใช้

แต่ scheduled agent มีข้อควรระวังทันที:

ถ้า schedule ผูกกับ permission กว้างเกินไป มันจะกลายเป็น automation ที่มี blast radius ใหญ่

ดังนั้นงานที่เหมาะกับ schedule รอบแรกควรเป็นงานอ่าน, วิเคราะห์, draft, report, monitor มากกว่างานแก้ production หรือส่งข้อความออกสู่ public โดยอัตโนมัติ

4) Project-level permission สำคัญกว่า prompt ยาว

อีกจุดที่ผมชอบคือการย้ายจาก workspace/repository ไปเป็น project

project สามารถครอบหลาย folder และมี agent settings/permissions แยกได้

นี่ตรงกับโลกจริงกว่า repo เดียวมาก

ตัวอย่างบริษัทหนึ่งอาจมีงาน “Content Ops” ที่ต้องอ่าน:

• draft folder
• brand guideline
• analytics export
• source links
• image assets

แต่งานนี้ไม่ควรเห็น production secret, payroll, contract หรือ database backup

ถ้าเราคิด agent เป็น worker จริง สิทธิ์ต้องถูกจัดตามงาน ไม่ใช่ตามความสะดวกของคนตั้งค่า

แนวคิด project-level permission จึงเป็นแกนของการเอา agent เข้าองค์กรแบบไม่เละ

5) /goal กับ /grill-me: สองโหมดที่คนทำงานควรแยกให้ออก

Slash commands สองตัวที่น่าสนใจคือ /goal และ /grill-me

• /goal: ให้ agent ทำจนงานเสร็จ โดยไม่ถามระหว่างทาง
• /grill-me: ให้ agent ถามกลับก่อนเริ่ม เพื่อ align รายละเอียดของ plan

นี่คือบทเรียนที่ practical มาก

งานบางประเภทควรใช้โหมด run-to-completion เช่น:

• จัดรูปเอกสาร
• สรุป source ที่กำหนด
• generate draft จาก template
• ตรวจ checklist ที่นิยามไว้ชัด

แต่งานบางประเภทต้องถามกลับก่อน เช่น:

• requirement คลุมเครือ
• งานกระทบลูกค้า
• งานมี trade-off ทาง business
• งานแตะข้อมูลสำคัญ
• งานที่ definition of done ยังไม่ชัด

ทีมที่ใช้ agent เก่งจะไม่ถามว่า “โมเดลไหนฉลาดกว่า” อย่างเดียว

แต่จะออกแบบว่าแต่ละงานควรใช้โหมดไหน และต้องมี proof อะไรก่อนถือว่าเสร็จ

6) Dynamic subagents ไม่ได้แปลว่าปล่อยงานแตกกิ่งได้หมด

Dynamic subagents ช่วยให้ agent หลักแบ่งงานย่อยและทำงานขนานได้

ข้อดีคือ context ไม่ปนกัน และงานใหญ่แตกเป็นชิ้นเล็กได้

แต่ในงานธุรกิจจริง สิ่งนี้ต้องมาพร้อมกฎ:

• subagent ทำอะไรได้บ้าง
• ใช้ tool เดียวกับ agent หลักหรือไม่
• มี budget/time limit ไหม
• output ต้องกลับมาในรูปแบบไหน
• ใครรับผิดชอบถ้า subagent สรุปผิด

ถ้าไม่กำหนดกติกา multi-agent จะดูเท่ แต่ตรวจยาก

ถ้ากำหนดกติกาดี มันจะกลายเป็นวิธีให้ AI ทำงานเป็นทีมเล็ก ๆ โดยคนยังคุมเป้าหมายและคุณภาพได้

7) Checklist สำหรับธุรกิจไทยที่อยากทดลอง

ก่อนเริ่มใช้ Antigravity 2.0 หรือ agent-first desktop แนวนี้ ลองตอบ 8 ข้อนี้ก่อน:

1. งานที่จะให้ agent ทำมี goal ชัดไหม
2. มี input/source ที่เชื่อถือได้หรือยัง
3. งานนี้ควร run-to-completion หรือควรถามกลับก่อน
4. Project นี้ต้องเห็น folder/data อะไรบ้าง และอะไรไม่ควรเห็น
5. ถ้าใช้ schedule งานนี้เป็นงานอ่าน/report หรือเป็นงานเขียน/แก้/ส่งออกสาธารณะ
6. มี artifact ให้ตรวจไหม เช่น report, diff, screenshot, log, checklist
7. จุดไหนต้อง human approval
8. ถ้างานผิด มี rollback หรือ escalation อย่างไร

ถ้าตอบไม่ได้ อย่าเพิ่งเริ่มด้วยงานเสี่ยง

เริ่มจากงานที่มีผลกระทบต่ำ แต่ได้ operating learning สูงก่อน เช่น report, research, issue triage, content draft, QA checklist

8) สรุป

Antigravity 2.0 ไม่ได้สำคัญเพราะเป็น “อีกหนึ่ง AI coding tool”

มันสำคัญเพราะ Google กำลังบอกทิศทางว่า agent-first surface ควรถูกออกแบบแยกจาก IDE ได้ และต้องมีระบบรอบตัว เช่น project, schedule, permission, hooks, subagents, CLI, SDK และ API

สำหรับผม สัญญาณนี้ชัดมาก:

AI agent รุ่นต่อไปจะไม่ใช่แค่ chatbot ที่ฉลาดขึ้น

แต่จะเป็น workload ที่ต้องมี operating model

ใครออกแบบงาน สิทธิ์ ตารางเวลา หลักฐาน และ approval loop ได้ดี จะได้ประโยชน์ก่อน

ใครมองว่าแค่ซื้อ tool แล้วจบ อาจได้แค่ agent ที่ขยันทำงานผิดเร็วขึ้นครับ