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