הסתכלתי לטורף שלי בעיניים. עכשיו הוא עובד אצלי

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

אם אתם מחכים לרגע שבו התחום יהיה בשל, בטוח והרמטי, כנראה שתחכו לנצח

מאת אלעד מידר

לפני שלוש שנים ישבתי מול המחשב במשרד ושיחקתי עם GPT-3.5 בפעם הראשונה. אז הייתי שותף בחברה עם 50 מפתחים. ביקשתי מהמודל לכתוב אפליקציה קטנה למובייל שאפשר להכניס בקובץ אחד, והוא כתב אותה. ביקשתי אחת מסובכת יותר, והוא כתב גם אותה. תוך כמה שעות הייתה לי אפליקציה עובדת שלא כתבתי בה שורה אחת.

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

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

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

לא משנה מה קורה, האחריות היא עלינו

כשהתחלנו לעבוד עם אייג'נטים עצמאיים, בחרנו בשני מודלים: Codex של OpenAI ו-Devin של Cognition. את השיעור הראשון והכואב קיבלנו דווקא מקודקס.

באחד הימים השארנו את Codex עם משימה שנראתה לנו טריוויאלית: "קדם את הדמו של המודול החדש". בהקשר הפנימי שלנו, המשפט הזה אומר דבר מאוד ספציפי: חשיפה מבוקרת לצוות מצומצם. את המילים הוא הבין, אבל לא את ההקשר.

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

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

מתברר ששאלנו את השאלה הלא נכונה

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

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

בפועל, היו לנו שלושה תנאים:

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

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

חצי שעה, ארבע משימות

מה ששכנע אותי לבחור ב-Devin בסופו של דבר הוא דווקא לא בנצ'מרק, אלא יומן. בחצי שעה רצו אצלנו ארבעה סשנים במקביל: סוכן אחד סרק ספרייה מקצה לקצה והחזיר 12 ממצאים – מכתובת שנבנתה לא נכון ועד שלושה קבצים מתים שאף אחד כבר לא קורא להם. השני תיקן את כולם. השלישי בנה ספרייה חדשה מאפס. הרביעי כתב לה תיעוד.

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

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

בכל סשן יש רגע שבו האייג'נט עוצר ושואל, וביומן זה נשמר כשורה יבשה (דימוי: Dreamstime)

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

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

שמתם לב שצוואר הבקבוק זז?

עכשיו, כשיש לנו מודלים, ייצור קוד הוא כבר לא הבעיה. הם כותבים קוד סביר בכמויות, וזה נכון לכל הכלים המובילים היום. אבל התור לא נעלם, הוא רק זז תחנה אחת קדימה – ועכשיו הוא נערם ב-Code review.

הכפילו את כמות ה-PRs פי כמה והשאירו את אותו מספר אנשים שמאשרים – וקיבלתם פקק. וגרוע מכך, עכשיו יש לחץ לאשר מהר. כל מי שאישר פעם PR כי היה עמוס יודע בדיוק על מה אני מדבר, וזה המקום שבו נכנסים בטעות באגים. אז מצד אחד האצנו את הכתיבה, ומצד שני החלשנו את הבקרה – וזו עסקה שאף מנהל לא היה חותם עליה במודע.

הפתרון שגיבשנו הוא אותו עיקרון מהטיקטים, רק בכיוון ההפוך: אייג'נט עושה מעבר ראשון על הקוד לפני שבן אדם מסתכל. טעויות לוגיקה, מקרי קצה שנשכחו, סטיות מהמוסכמות של הצוות. אבל הבודק האנושי לא נעלם – הוא מגיע ל-Diff שכבר עבר סינון, ומתפנה לשלוש השאלות שהמכונה לא יכולה לענות עליהן: האם זהו הפתרון הנכון, האם הוא נוגע במשהו רגיש, ואם זה מה שהמשתמש ביקש מלכתחילה.

בפועל, Devin עושה את המעבר הזה היטב. הממצאים שהוא מעלה הם לא הערות לינטר משודרגות, אלא דברים עמוקים מהסוג שדורש להבין מה המוצר מנסה לעשות: למה השינוי הזה שובר הנחה שמודול אחר נשען עליה, למה מקרה הקצה הזה בכלל קיים אצלנו. חלק גדול מזה מגיע מ-DeepWiki, הכלי של Cognition שממפה את הריפו לתיעוד חי, ככה שהאייג'נט מגיע לבדיקה כשהוא כבר מכיר את הארכיטקטורה והכוונות, ולא רק את ה-Diff שמולו. זה סוגר מעגל: אותו הקשר ארגוני קבוע, שהוא אחד משלושת התנאים שהצבנו לעבודה עם אייג'נט, מתברר כתנאי גם כשהאייג'נט הוא הבודק ולא הכותב.

ה-SDLC לא נשבר, הוא קיבל עובד חדש

אחד הפחדים הגדולים כשנותנים לאייג'נטים להתחיל לעבוד באמת הוא שהם יעקפו את התהליכים. אצלנו קרה ההפך, והוא השתלב ב-SDLC הקיים כמו עוד חבר צוות: הוא מקבל טיקטים מאותו board, הקוד שלו עובר את אותו CI ו-Quality gates ואת אותם Code reviews. שום דבר בפייפליין לא נבנה מחדש עבורו.

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

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

מה הייתי עושה עכשיו במקומכם

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

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

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