כל הפוסטים

מודל חדש לא יציל אותך

מודל AI חדש מול סביבת פיתוח מורכבת, עם צ׳קליסטים, בדיקות, דיזיין וניטור סביבו

אתמול יצא Claude Fable 5, המודל החדש של Anthropic. לפי איך שהם מציגים אותו, זה המודל הכי חזק שלהם שזמין לקהל הרחב, כזה שאמור להחזיק משימות ארוכות ומורכבות יותר, כולל פרויקטי coding גדולים, vision, מחקר ו-knowledge work.

אני מבין למה זה מלהיב. כל פעם שמודל חדש יוצא, במיוחד אחד שמוצג כקפיצה משמעותית, קל לדמיין שעוד רגע חלק גדול מהכאבים שלנו נעלם. עוד קצת reasoning, עוד קצת context, עוד קצת יכולת להחזיק משימה לאורך זמן, והנה - coding agents סוף סוף יעבדו כמו שדמיינו.

בחלק מהמקרים זה גם באמת יקרה. בפרויקטים קטנים, אצל מפתחים יחידים, או במשימות שהגבולות שלהן ברורים, מודל חזק יותר יכול לעשות הבדל גדול. אם ה-scope קטן, ה-tests ברורים והתוצר קל לבדיקה, כנראה ש-Fable 5 יצליח לקחת אותנו רחוק יותר ממודלים קודמים.

אבל במערכות אמיתיות, בעיקר במערכות גדולות, השאלה היא לא רק כמה המודל חכם. השאלה היא מה הוא יודע על העבודה שלכם.

מודל חזק עדיין צריך מסלול

אפשר לתת למודל חדש טיקט מפרודקט ולבקש ממנו “לממש”. אם הטיקט טוב, אם הקוד יחסית נקי, ואם יש מספיק דוגמאות באזור, יכול להיות שהוא יגיע לתוצאה לא רעה.

אבל לרוב זה רחוק מלהוציא תוצר אמיתי שאפשר לסמוך עליו במערכת גדולה ומורכבת.

כדי להגיע לשם הוא צריך לדעת הרבה יותר ממה שכתוב בטיקט. איפה מתחילים לקרוא. איזה קונבנציות קיימות באזור הזה. איזה PRs קודמים כדאי לבדוק. איזה API אסור לשבור. איך נראה דיזיין שעומד בסטנדרטים. איזה tests באמת אומרים משהו. ואיזה מטריקות צריך לבדוק אחרי rollout.

מודל טוב יותר יכול לנחש חלק מזה טוב יותר. הוא יכול לקרוא יותר מהר, להסיק יותר טוב, ולתפור פתרון שנראה הרבה יותר משכנע. אבל אם המסלול לא מוגדר, הוא עדיין מנחש.

הבעיה היא לא רק היכולת של המודל

אני חושב שזו הנקודה שקל לפספס בכל השקה כזאת. אנחנו מסתכלים על benchmark, על demo, על סרטון שבו המודל עובד שעות על משימה, ואז שואלים: “אוקיי, אז עכשיו אפשר לתת לו את הטיקט ולחזור אחר כך?”

לרוב לא.

לא כי המודל לא טוב. להפך, ככל שהמודלים טובים יותר, זה אפילו נהיה מסוכן יותר. תוצר בינוני של מודל חלש נראה בינוני. תוצר בינוני של מודל חזק יכול להיראות כמעט מוכן. הוא עובר על הרבה קבצים, מוסיף tests, מסכם יפה, ואפילו מסביר בביטחון למה הבחירות שלו נכונות.

אבל אם הוא לא מכיר את ה-context האמיתי של המערכת, הוא עדיין יכול לפספס את הדבר החשוב: edge case של לקוח, החלטת product שלא כתובה, convention שחי רק בראש של הצוות, או flow שחייבים לבדוק ידנית לפני שמעלים.

מה כן משתנה

מודל כמו Fable 5 כן מעלה את התקרה. אני לא מזלזל בזה. אם הוא באמת מחזיק משימות ארוכות יותר, יודע לכתוב בדיקות טובות יותר, להבין קבצים ויזואליים ולעבוד יותר זמן בלי להתפזר, זה משמעותי.

אבל זה לא מבטל את העבודה שלנו. זה משנה את המקום בוא היא יושבת.

במקום להשקיע את כל האנרגיה בלכתוב את הקוד עצמו, צריך להשקיע יותר בהגדרת העבודה: איך נראה input טוב למודל, איזה context חייב להיכנס, איזה צ׳קליסט מוכיח שהמשימה באמת Done, ואיפה המודל חייב לעצור ולחזור אלינו.

במילים אחרות, המודל החדש לא מחליף workflow. הוא מגדיל את התמורה על workflow טוב.

מה אני הייתי עושה

אם מחר אני מחבר Fable 5 ל-codebase גדול, הדבר הראשון שאני לא עושה הוא לזרוק עליו את הטיקט הכי גדול שיש לי.

אני מתחיל ממסלול קטן וברור: אזור קוד אחד, סוג משימה אחד, בדיקות ידועות, reviewer expectations כתובות, ולידציה שאפשר להריץ, ומטריקות שצריך לבדוק אחרי rollout. אחר כך אני הופך את זה ל-skill, doc או צ׳קליסט שה-agent יכול לקרוא לפני שהוא מתחיל.

רק אחרי שזה עובד, אני מגדיל scope.

כי בסוף, מודל חכם יותר הוא חומר גלם טוב יותר. הוא יכול לעזור יותר, לרוץ רחוק יותר, ולחסוך הרבה עבודה ידנית. אבל אם אתם לא יודעים להסביר לו מה “טוב” אומר אצלכם, הוא לא ימציא את זה לבד.

עוד מודל חדש לא יציל אותנו מלהגדיר טוב את העבודה. הוא רק יעניש מהר יותר מקומות שבהם לא עשינו את זה.