בניית סוכני AI ו-Agentic Workflows בתוך Antigravity היא לא רק עניין של כתיבת פרומפט טוב, אלא של ניהול משאבים חכם.
בתוך סביבת פיתוח Full-stack, הבחירה באיזה מודל להשתמש לכל משימה היא ההבדל בין מערכת עבודה יעילה וזולה יחסית לבין מערכת יקרה, איטית ומתסכלת. יקרה לא רק בכסף, אלא גם בזמן המתנה, במכסות שנגמרות, בתקופות צינון ובתיקונים חוזרים שנולדו מזה שהפעלנו מודל לא מתאים על משימה לא מתאימה.
המטרה כאן היא לא להכתיר מודל אחד בתור הכי טוב. זה משתנה מהר מדי. המטרה היא להבין איך מחלקים עבודה בין מודלים בתוך Antigravity: מי חושב, מי מבצע, מי בודק, מי מתאים ל-UI/UX, ומי יכול לשמש חלק מצוות עובדים אוטונומי.
למה בכלל צריך לנהל מודלים
בצ׳אט רגיל קל לחשוב על AI כעל בחירה אחת: בוחרים מודל חזק, כותבים בקשה, מקבלים תשובה. ב-Antigravity זה עובד אחרת. הסוכן יכול לקרוא קבצים, להבין פרויקט, להציע תוכנית, לערוך קוד, להריץ פקודות, לפתוח דפדפן, לבדוק UI ולחזור עם תוצרים לבדיקה.
כל פעולה כזו צורכת הקשר ומשאבים. ככל שהמשימה רחבה יותר, הסוכן עשוי לשלוח למודל יותר מידע: מבנה תיקיות, קבצים, היסטוריית שיחה, שגיאות מהטרמינל, צילומי מסך ותיקונים קודמים.
אילו מודלים זמינים ב-Antigravity
לפי דף המודלים של Antigravity, סביבת העבודה כוללת כיום אפשרויות כמו Gemini 3.1 Pro ברמות reasoning שונות, Gemini 3 Flash, Claude Sonnet 4.6, Claude Opus 4.6 ו-GPT-OSS-120b. הרשימה יכולה להשתנות, ולכן עדיף לחשוב לפי תפקיד ולא רק לפי שם המודל.
- מודלים כבדים לחשיבה ותכנון: Gemini 3.1 Pro, Claude Sonnet 4.6, Claude Opus 4.6.
- מודלים מהירים לביצוע: Gemini 3 Flash, ולעיתים GPT-OSS-120b, לפי המשימה והזמינות.
- מודלים לבקרה: בדיקת פורמט, checklist, קישור שבור או שינוי נקודתי לא תמיד דורשת את המודל הכי כבד.
מכסות, עלויות וזמני המתנה
הרבה אנשים שנכנסים ל-Antigravity מפחדים שהם ילחצו על משהו, הסוכן ירוץ, ובסוף זה יעלה להם כסף בלי שהם הבינו מה קרה.
העבודה נספרת לפי היקף העבודה שהסוכן מבצע: כמה הקשר הוא צריך לקרוא, כמה מורכבת המשימה, כמה שלבים יש, כמה פעמים הוא מריץ או בודק, ואיזה מודל מפעילים.
מה זה זמן המתנה?
זה הזמן שבו מחכים לתגובה או לביצוע. הוא גדל כשמשתמשים במודל כבד, כשנותנים משימה רחבה מדי, כששולחים הרבה קבצים להקשר, או כשהסוכן נכנס ללולאת תיקונים.
מה זו תקופת צינון?
תקופת צינון היא מצב שבו הגעתם למגבלת שימוש זמנית, ולכן צריך לחכות עד שהמכסה מתרעננת. אפשר להתחיל גם בלי לשלם על Google AI Pro או Ultra, אבל זו לא אותה מכסה. למידה נכונה מתחילה ממשימות קטנות, עם גבולות ברורים, ובדיקה של השפעת כל סוג משימה על המכסה.
אסטרטגיית שכבות
במקום לבחור מודל אחד לכל העבודה, עדיף לבנות שכבות.
שכבה 1: המוח
Gemini 3.1 Pro או Claude Sonnet / Opus. השכבה הזו צריכה להבין את מבנה הפרויקט, לזהות קבצים רלוונטיים, להציע תוכנית, לסמן סיכונים, ולהגיד איפה לא לגעת.
שכבה 2: העובד
Gemini 3 Flash מתאים כאשר המשימה מוגדרת היטב. לא “בנה לי אתר”, אלא “הוסף כרטיס לדף links.html לפי המבנה הקיים”.
שכבה 3: הבודק
כאן המודל עובד מול checklist: האם הקישור עובד, האם תוכן העניינים מוביל למקטעים הנכונים, האם לא נשבר mobile, והאם אין שינוי בקובץ שלא ביקשנו.
איזה מודל לאיזו מטרה
| מטרה | מודל מומלץ | הערת עבודה |
|---|---|---|
| תכנון ארכיטקטורה או שינוי רחב | Gemini 3.1 Pro או Claude Sonnet 4.6 | לבקש קודם מיפוי ותוכנית. לא לאשר כתיבה לפני שרואים אילו קבצים ישתנו. |
| קוד מורכב בכמה קבצים | Claude Sonnet 4.6 או Gemini 3.1 Pro | להגדיר scope קשיח: אילו קבצים מותר לשנות ואילו לא. |
| משימה קטנה וברורה | Gemini 3 Flash | כרטיס חדש, תיקון טקסט, CSS קטן או המרת פורמט. |
| סריקת פרויקט קיים | Gemini 3.1 Pro או Gemini 3 Flash | לבקש סיכום מבנה ולא תיקון. קודם להבין, אחר כך לבצע. |
| UI/UX וביקורת מסכים | Gemini 3.1 Pro או Claude Sonnet 4.6 | לבקש screenshot או walkthrough כ-Artifact. |
| בדיקת JSON, anchors או checklist | Gemini 3 Flash | לתת checklist סגור: עבר / נכשל / צריך תיקון. |
UI/UX ובחירת מודל
מודל יכול לכתוב קוד תקין ועדיין לייצר חוויית משתמש גרועה. הכפתור עובד, אבל לא ברור. הדף נטען, אבל אין היררכיה. הקומפוננטה קיימת, אבל במובייל היא חונקת את המסך.
לכן במשימות UI/UX לא מספיק לבקש “תבנה דף יפה”. צריך להגדיר תפקיד: UI reviewer, mobile-first reviewer, conversion reviewer או accessibility reviewer.
בניית עובדים אוטונומיים
- הארכיטקט: Gemini 3.1 Pro או Claude Sonnet 4.6. ממפה פרויקט, מזהה תלות, מציע תוכנית וסיכונים.
- המפתח: Claude Sonnet 4.6 / Gemini 3.1 Pro למשימות מורכבות, Gemini 3 Flash למשימות קטנות.
- בודק ה-UI: Gemini 3.1 Pro או Claude Sonnet 4.6. בודק מסך, מובייל, CTA, עומס וקריאות.
- בודק התוכן: Claude Sonnet 4.6 או Gemini 3.1 Pro. בודק דיוק, טון, גנריות והבטחות מוגזמות.
- QA טכני: Gemini 3 Flash. בודק לינקים, anchors, build, מובייל וקבצים שנגעו בהם.
כללי עבודה פרקטיים
- לא מתחילים מביצוע. קודם מבקשים ניתוח מבנה ותוכנית עבודה בלי שינוי קבצים.
- לא שולחים את כל הפרויקט לכל משימה. הקשר גדול מתאים לסריקה ותכנון, לא לכל תיקון קטן.
- מגדירים גבולות. אילו קבצים מותר לשנות, אילו לא, ומה חייב אישור.
- מפרידים בין כתיבה, בנייה ובדיקה. אחרת הסוכן גם יוצר וגם מאשר לעצמו את העבודה.
- עוצרים לולאות תיקון. אם הסוכן מתקן את אותו דבר שלוש פעמים, צריך לעצור ולבקש אבחון של הבעיה.
המודל חשוב. שיטת העבודה חשובה יותר.