שוב ושוב זה קורה: מפתח בכיר מבלה שלוש שעות על דיבגינג של קוד שקלוד כתב בשתי דקות. ה-AI פתר את הבעיה המקורית בצורה מושלמת, אבל יצר שלושה מקרי קצה חדשים בכל תיקון קטן.
זה לא מפתיע. זה דפוס שחוזר על עצמו בכל צוות שעובר לעבוד עם AI. וזה בדיוק הנקודה שבה נמצאת ההזדמנות הגדולה, וגם הסיכון הגדול, של AI בפיתוח תוכנה.
הפרדוקס של 40%
מחקר של Anthropic מראה שמפתחים עם כלי AI הופכים פרודוקטיביים ב-40% יותר. זה נשמע מדהים. אבל אותו מחקר מראה משהו אחר: אחרי חצי שנה, אותם מפתחים לא יכולים לפתור בעיות בלי העוזר הדיגיטלי.
קיבלנו מהירות. ויתרנו על הבנה.
מרקוס פונטורה ממיקרוסופט מנסח את זה בצורה מדויקת בספרו "Human Agency in the Digital World": האם המפתחים שלכם הם טייסים או נוסעים? טייס מבין את מערכת הטיס ויכול לנטוש את הטייס האוטומטי ברגע שנדרש. נוסע רק יושב ומקווה שהמכונה יודעת לאן ללכת.
הצוותים שמרוויחים מ-AI לטווח ארוך הם אלה שנשארים טייסים.
"הזנב מכשכש בכלב"
יש תבנית שאני רואה בצוותים שנשענים יותר מדי על AI: תיקון API פשוט שנוגע בעשרות קבצים לוקח חודשים כי אף אחד לא ממש מבין את הקוד שנוצר. כשה-AI מציע פתרון, בודקים אם הבדיקות עברו, לא אם ההיגיון נכון. הדיבגינג הופך לניסוי וטעייה עם ה-AI במקום הבנה של השורש.
זו תופעת "הזנב מכשכש בכלב": ה-AI מכשכש בצוות במקום שהצוות ינחה את ה-AI.
מתברר שיש לכך סיבה גיאומטרית: מחקר של Anthropic מראה שמודלי AI לא יכולים להבחין בין מסלולי קוד "טובים" ו"רעים" - הם נראים זהים גיאומטרית. זה כמו מפתח ג'וניור מבריק שפותר את המשימה הראשית אבל מפספס את תופעות הלוואי.
טעות הממשק: לא כל בעיה צריכה צ'אטבוט
דוגמה קלאסית: צוות שהשקיע שלושה חודשים בבניית ממשק AI בשפה טבעית, ובסוף המשתמשים נמנעו ממנו. הסיבה? תהליך העבודה של המשתמשים מבוסס על טפסים מובנים ורשימות נפתחות, לא על שיחה חופשית.
כולם בונים צ'אטבוטים כי הם נראים מרשימים במצגות. אבל הסמנכ"ל כספים לא רוצה "לשוחח" על אישור חשבוניות: הוא רוצה ולידציה בטפסים ושדות ברורים.
השימוש הנכון ב-AI הוא למלא מבנים קיימים בצורה חכמה יותר, לא להחליף את המודלים שבניתם לתחום שלכם בסתם שיחה בשפה טבעית.
ה-70% שאף אחד לא מדבר עליו
חוקרים מ-OpenAI ואנתרופיק אמרו לאחרונה, כל אחד בסגנונו: "אני לא כותב קוד יותר. 100% מהקוד מגונרט". אנתרופיק עצמה מדווחת שבין 70% ל-90% מהקוד שלה נכתב על ידי AI.
הנקודה שפחות מדברים עליה: התשתית לא נבנתה בשביל זה. ה-pull requests של GitHub, בדיקות הקוד, ה-CI pipelines: כולם תוכננו בשביל בני אדם שחושבים בשעות ובימים, לא בשביל סוכנים שמעלים קוד כל כמה דקות.
זה גם מסביר את הפרדוקס עם אלקטרון בקלוד קוד: קלוד הוציאה 20,000 דולר על "נחיל" סוכני AI לבנות C compiler (תוכנה ברמת ה-bare metal). אבל את האפליקציה שלהם לשולחן העבודה הם בנו ב-Electron, פריימוורק שכנראה הכי רחוק שאפשר מה-bare metal. ה-APIs הנייטיביים הפכו כל כך מסובכים שאפילו חברות ענק בוחרות בטכנולוגיית ווב. תהליכי העבודה שלנו ממשיכים לרוץ לפני שהכלים יכולים לתמוך בהם.
החברות שמתכננות תהליכי עבודה מותאמים לסוכנים (לא לבני אדם שעובדים לצד AI) הן אלה שיצמחו פי 3-5 בשנה הבאה.
כיצד נשארים טייסים
הגישה שאני ממליץ עליה:
בדקו ולא רק הריצו. כשה-AI מציע פתרון, שאלו: "למה?" לא רק "האם עובד?" ה-AI שלכם הוא ג'וניור מבריק, לא אורקל.
השתמשו ב-AI לרפקטורים שאנשים לא עושים. ניקוי שמות גרועים לאורך כל הקוד, פיצול קבצים של אלפי שורות למודולים, הסרת פונקציונליות כפולה: אלה המשימות שסוכני AI מצטיינים בהן. העלות של קוד ירדה עד כדי כך שאפשר להרשות לעצמנו אפס סובלנות לחריקות קוד קטנות.
התאימו את תהליכי העבודה. ה-PR reviews, ה-CI pipelines, ואפילו הדרך שמגדירים קריטריוני קבלה: כל אלה צריכים להתפתח עבור עולם שבו AI מגונרט.
שמרו על הארכיטקטים. AI יכול לכתוב קוד. רק בני אדם יכולים להחליט מה צריך לבנות, למה, ואיך זה מתחבר לצרכי העסק.
נקודות לסיכום
AI בפיתוח תוכנה הוא כלי רב עוצמה, בתנאי שאתם אלה שמחזיקים בהגה. הצוותים שמנצחים הם אלה שמשתמשים ב-AI כדי לעשות יותר מהדברים הנכונים, לא כדי להפסיק לחשוב.
השאלה שצריך לשאול לא היא "האם להשתמש ב-AI?" אלא "כיצד אנחנו נשארים הארכיטקטים?" כשיש לכם תשובה ברורה לשאלה הזו, ה-40% בפרודוקטיביות הם רק ההתחלה.