Google פרסמה ב-22 באוקטובר את Elephant-Goldfish Model, תוסף בקוד פתוח שנועד לארגן את שלב התכנון בפיתוח תוכנה עם סוכני AI. הרעיון המרכזי פשוט: סשן אחד מחזיק את ההקשר והכוונה של הפרויקט, בעוד סוכנים נפרדים מקבלים את מסמך התכנון ומנסים למצוא בו עמימות, הנחות חסרות ופערים. הכתיבה של הקוד אמורה להגיע לאחר בירור הדרישות והביקורת, ולא להחליף אותם.
לפי Google, התוסף פותח תחילה עבור מהנדסים בחברה ומשמש אלפי עובדים. זהו נתון שהחברה מסרה, ואינו מדד עצמאי לאיכות התוכנה שנוצרת בשיטה. המאגר מופץ ברישיון Apache 2.0, ובתיעוד מופיעה הבהרה נוספת: אין מדובר במוצר שנתמך רשמית בידי Google. ההבחנה חשובה לצוותים השוקלים לשלב אותו בתהליך פיתוח שעליו הם מסתמכים מדי יום.
למה צריך גם זיכרון וגם התחלה חדשה
השם Elephant-Goldfish הוא דימוי לחלוקת העבודה. ה-Elephant הוא סשן עשיר בהקשר, שמחזיק את ההיסטוריה, הארכיטקטורה וההחלטות הקטנות שמתקבלות לאורך הדיון. ה-Goldfish מקבל התחלה נקייה יחסית: עליו לקרוא את המפרט ולבחון אותו בלי להסתמך על ההסברים שהצטברו בשיחת התכנון. אין כאן טענה שמדובר בשני מודלים חדשים או באימון של מערכת חדשה.
החלוקה נוגעת לבעיה מוכרת בעבודה משותפת, גם בלי AI. אנשים שניהלו דיון ארוך יודעים לעיתים למה התכוונו, אף שהמסמך שכתבו אינו מסביר זאת היטב. קורא חדש חושף את הפער ברגע שהוא מפרש משפט בדרך אחרת. השיטה מנסה להפוך את הרגע הזה לחלק מכוון מהתהליך, לפני שמפרט עמום מתורגם לקבצים ולפונקציות שקשה יותר לשנות בהמשך.
הפרדת השיחות אינה מבטיחה ביקורת נכונה. סוכן יכול לפספס פגם, לייחס חשיבות לבעיה שולית או להסכים עם תכנון חסר. היתרון האפשרי הוא מבני: הביקורת מקבלת תפקיד וקלט משלה, במקום להיבלע באותה שיחה שיצרה את התוכנית. מהנדס עדיין צריך להחליט אילו הסתייגויות מוצדקות ואילו שינויים משפרים את הפתרון. מספר סוכנים לבדו אינו תעודת איכות.
3 שלבים לפני המעבר לקוד
הודעת Google מתארת 3 שלבי תכנון משותף. תחילה מגדירים את הבעיה ומתווכחים על חלופות, תחת כלל שלפיו אין כותבים קוד בשלב הזה. בהמשך נבנה מסמך Markdown הכולל את הבעיה, התוכנית הטכנית, חלופות שנשקלו ותוכנית מימוש מפורטת. לבסוף מופעל תהליך ביקורת של סוכנים נפרדים, שמטרתו לבחון אם המסמך ברור ומוכן ליישום.
זהו שינוי בדגש, לא רק תוספת של פקודה לכלי הפיתוח. במקום למדוד התקדמות לפי כמות הקוד שהסוכן הפיק, נקודת הביניים היא מסמך שאדם אחר יכול להבין ולבקר. עבור צוות, מסמך כזה עשוי לאפשר דיון מוקדם בשאלה מה ייחשב הצלחה, אילו קבצים צפויים להשתנות ומה נשאר מחוץ להיקף העבודה. אלה החלטות מוצר והנדסה, גם כשה-AI מסייע לנסח אותן.
הגישה גם יוצרת תוצר שאפשר לחזור אליו כאשר המימוש משתנה. מפרט כתוב אינו מבטיח שהקוד יישאר נאמן לו, אך הוא נותן בסיס להשוואה. בלי תיעוד של ההחלטה המקורית, קשה לעיתים להבחין בין שינוי מכוון לבין סטייה שהתרחשה במהלך העבודה. לכן הערך האפשרי אינו מסתכם ברגע יצירת הקוד הראשון, אלא ביכולת להסביר בהמשך מדוע נבחר הפתרון.
ביקורת מתחילה בהבנה, לא ברשימת תלונות
בשלב הביקורת שמציגה Google, סוכן נפרד צריך תחילה להסביר את הארכיטקטורה ואת הכוונה של המסמך. אם אינו יכול לתאר אותן באופן מדויק, זו אינדיקציה לכך שהמפרט עדיין עמום. אחר כך מגיעים בודקים ספקניים שמחפשים מקרי קצה, תלויות נסתרות ופערים לוגיים. בדיקה נוספת עוסקת במוכנות למימוש ובמידע הדרוש לביצועו.
הסדר הזה שימושי משום שרשימת הערות יכולה להיראות יסודית גם כאשר הבודק לא הבין את הבעיה. דרישה להסבר חוזר מעבירה את הדיון מהשאלה אם הטקסט נשמע מקצועי לשאלה אם אדם או סוכן אחר יכולים לפעול לפיו. כאשר ההבנה שגויה, תיקון של משפט מפתח עשוי להיות מועיל יותר מהוספת עמוד של הנחיות. כאשר ההבנה נכונה, אפשר לבחון את התכנון עצמו.
גם מוכנות למימוש צריכה להיקרא בזהירות. מסמך מפורט יכול להסיר ספק לגבי שמות קבצים, מבני נתונים וממשקים, אך אינו מחליף בדיקות של הקוד שנכתב בפועל. הוא גם אינו בודק מעצמו את כל תנאי סביבת הייצור. משמעותו היא שקיימת תוכנית שאפשר להתחיל לממש באופן מוגדר, לא שהשינוי קיבל אישור בטיחות כולל או שהוא חופשי מתקלות.
תוסף פתוח, אחריות שנשארת אצל המפתחים
Google מציגה את התוסף כחלק מגישה שבה האדם שומר על שיקול הדעת ההנדסי. התיעוד במאגר כולל מסלולי התקנה עבור Antigravity, Claude Code ו-Codex, לצד הנחיות לסביבות נוספות. צוות שבוחר להשתמש בו צריך להתייחס לתיעוד המתאים לסביבתו ולגרסה שבה הוא עובד. רשימת אפשרויות התקנה אינה מבטיחה שכל סביבת עבודה תקבל התנהגות זהה או אותה רמת תמיכה.
החברה לא הציגה בהודעת ההשקה השוואה כמותית המוכיחה כמה תקלות התוסף מונע או כמה זמן הוא חוסך בכל פרויקט. ייתכן שתכנון נוסף יחסוך עבודה חוזרת, אך הוא גם דורש זמן, קריאה והכרעה בין הערות. עבור משימה קטנה, העלות הזאת עשויה להיות מורגשת יותר; עבור שינוי עם תלות בכמה מערכות, בירור מוקדם עשוי לקבל משקל אחר. זו החלטה שקשורה להיקף העבודה.
לצוותים בישראל, הרלוונטיות היא בראש ובראשונה לתהליך העבודה עם כלי פיתוח קיימים. אין בהודעה מסלול ישראלי נפרד או הבטחה לתמיכה ייעודית בעברית. אפשר ללמוד ממנה עיקרון רחב יותר: כאשר הסוכן עומד לבצע שינוי, כדאי שההוראות יעמדו בפני עצמן. מסמך שתלוי בזיכרון השיחה עלול לאבד את המשמעות שלו ברגע שמתחלף הכלי, המפתח או מי שאמור לבדוק את העבודה.
החדשות כאן הן פתיחת כלי שמנסה לתת לתכנון ולביקורת מעמד ברור בתוך עבודה עם סוכנים. הוא אינו מבקש מהמהנדס להפסיק להבין את המערכת, אלא מציע דרך לבדוק אם ההבנה נכתבה באופן שאחרים יכולים להשתמש בו. אם התהליך עובד היטב, השיחה הארוכה מפסיקה להיות המקום היחיד שבו חיה הכוונה. היא מקבלת מסמך, קוראים ביקורתיים ואדם שאחראי להחלטה הסופית.