תחשבו רגע על דלת מסתובבת, שני עשורים של הנדסת תוכנה.
מצד אחד נכנסת רותם של שנת 2006. מפתחת צעירה, בלי כלי GAI, שחייבת להקליד כל שורת קוד בידיים, לדאבג שעות מול מסך כחול, ולהחזיק באג קשוח בשתיים בלילה. כל שורה מאלצת אותה לקרוא לגאסי, להבין את הבסיס ולפתח Grit הנדסי אמיתי מתוך החיכוך המתיש של היומיום. אלו 10,000 שעות הניסיון שלה.
מהצד השני של הדלת יוצאת רותם של שנת 2027. היא מפתחת צעירה שמתחילה את דרכה בעידן ה-AI SDLC שבו הכל קורה בקליק מהיר – המכונה מנסחת, מתקנת ומייצרת פתרונות בשניות. ירח דבש מושלם של פרודוקטיביות, לא? :-9
אבל כאן בדיוק מונח האתגר האמיתי שלנו. כשהמכונה עושה את העבודה השחורה, איך אנחנו מעצבים מחדש את מסלול ההמראה של המפתחים הצעירים? איך מייצרים להם את ה-10,000 שעות הנכונות, אלו שלא מבוססות על הקלדה עיוורת, אלא על הבנה עמוקה, קריאת ארכיטקטורה, דיבג ופיצוח בעיות מורכבות? אם לא נדע לעשות את זה, איך נגדל פה את ארכיטקטי הניצחון של המחר?
אל דאגה, אם לא הייתה אמונה, צסק"א לא הייתה אוכלת אותה. אנחנו נצטרך לפצח את זה, וזה יתחיל בשינוי המיינדסט של הלימוד, כי בסוף קודם כל אנשים, אחר כך טכנולוגיה.
1- אשליית ה-TTM וקיצור הדרך המדומה
דברים שאף לא השתנו גם בתקופת ה AI Powered SDLC, אני שומע את אותו המשפט: "אין לנו זמן לעשות את זה נכון, חייבים לעמוד בלו"ז ולהגיע לראשון בחודש" יותר מזה עכשיו דורשים מאיתנו מה שעשינו ספרינט של שבועיים לעשות ביומיים. המרדף אחרי ה-TTM – Time to Market הפך לחזות הכל. כיום, עם כלי ה-AI, מנהלים בדרג הבכיר בטוחים שהם מצאו את קיצור הדרך האולטימטיבי. הרי אם המכונה מייצרת קוד בשניות, חסכנו את רוב זמן הפיתוח, לא?
זו מילכוד 22 ענק. עם השנים למדתי והוכחתי שזמן כתיבת הקוד (ה-Y בנוסחה שלנו) הוא המקטע הכי פחות משמעותי בפיתוח מוצר הזמן שמוקדש לפיתוח לא יעלה על 20 אחוז מזמן שיושקע. הנדסת תוכנה אמיתית היא כמו עולם הבנייה, לצערי תעשיית התוכנה וההייטק נוטה לזלזל בעולמות אחרים, אם תרוצו להרים קירות בלי להשקיע דקה במדידות קרקע וביסודות, הבניין פשוט יקרוס בשלב מאוחר יותר, והתיקון שלו יעלה לכם פי עשרה. בעידן שבו הסינטקס עצמו הפך לחינמי לחלוטין, הערך היחיד של מהנדס התוכנה הוא בשלב התכנון, הבנת ההקשר וניהול המגבלות (שלב ה-X).
כשארגון מקצץ בשלב הניתוח והעיצוב כדי לרוץ מהר לקידוד, הוא פוגש את הקיר בשלב האינטגרציה והבדיקות (I+T). פתאום מתקבל קוד ספגטי מבוסס AI שאף אחד בצוות לא באמת מבין את החיבורים שלו, ממשקי ה-API נשברים בגלל חוסר תיאום בין המערכות, והקוד נבנה בצורה שלא מאפשרת בדיקות אוטומטיות. ה-ROI של השקעה ב-X הוא ברור ומדיד: הוא מתבטא בצמצום דרמטי של זמן האינטגרציה, בהורדה של עלות השינוי (קל לתקן אפיון בחמש דקות, קשה לתקן קוד חי בפרודקשן), ובקיצור זמן הדיבג והבאגים שמחזיקים אתכם ערים בלילה, בעצם את מי נעיר בלילה??.
המלצה אישית שלי על מנת לגרום למפתחים לעצור ולהשקיע את הזמן בעיצוב לפני שהם רצים למקלדת, אל תתנו להם תבניות בירוקרטיות. תראו להם דוגמה אישית באמת תתנו דוגמא. קחו מקרה עבר שבו חוסר תכנון גרם להם להיתקע שבועות על באג מורכב, ותוכיחו להם איך חשיבה של שעה מראש הייתה מונעת את הסיוט הזה.
שאנחנו מקצצים בזמן העיצוב והתכנון כדי לרוץ מהר לקידוד, אנחנו רק מגדילים את זמן האינטגרציה והבדיקות בדרך לקיר בטון עבה.
2- חוזרים למקורות הנדסת התוכנה: הפרדת ה-Spec מה-Body
כדי להבין איך הנדסת תוכנה צריכה להיראות בעידן ה-AI, אנחנו חייבים לחזור ארבעים שנה אחורה,בעייני זה לחזור למקורות, אל העקרונות שעמדו בבסיס של שפה מדהימה שאפשר לדבר עליה הרבה שפת עדה (Ada). השפה הזו נבנתה עבור פרויקטים צבאיים ומערכות קריטיות (Mission Critical), והיא התבססה על קונספט ארכיטקטוני פשוט אך עוצמתי: הפרדה מוחלטת ומובנית בין ה-Specification (החוזה, הטיפוסים והחתימות) לבין ה-Body (מימוש הלוגיקה והקוד בפועל). לצערי בגלל החלטות סיטנקס והיצמדות לשפת פסקל היא פחות תפסה בתעשייה האזרחית. אני יכול להגיד מהמקום הקטן שלי שגם היום היה השפה האולטימטיבית וחייבת להיות קורס לכל מפתחת ומפתח.
עקרונות השפה הם המפתח לפתרון אובדן השליטה והקניין הרוחני (IP) של הארגונים כיום. היא מגדירה שהקוד (ה-Body) הוא זמני ומתכלה (Disposable Code). הנכס האמיתי וה-IP שהמהנדסים מתחזקים ומעבירים ב-Git הוא ה-Specification, חוקי התוכנה והמגבלות שלה. זה מאפשר לנו להחליף את המימוש בקלות ללא נעילה טכנולוגית, וליצור מנגנון אימות אוטומטי שבו המערכת מוודאת שהקוד שה-AI פולט עומד ב-100% במגבלות ה-Spec עוד לפני שהוא עובר לפרודקשן. כדי לאכוף את זה, אנחנו מגדירים את ה-Spec בשפות אפיון פורמליות (כמו OpenAPI או JSON Schema), ומשלבים פיתוח מונחה בדיקות (TDD) שבו המפתחים מוודאים ומאשרים שה-AI כתב בדיקות TDD נכונות וממוקדות לפני שמייצרים את ה-Body.
למי שעובד כמהנדס.ת תוכנה ולא כמתכנת או מפתח סדר היום המוצע לא יהיה חדש , אלה אפילו הרבה יותר אפשרי:
- שיח וארכיטקטורה: מתחילים בשיח עמיתים מעמיק על הארכיטקטורה, מייצרים דיאגרמה הנדסית, ומשתמשים ב-AI כשותף פעיל שווה ערך אבל לא מוביל , זה לחלוטין AI powered SDLC.
- מערכת החוקים והמגבלות: מנסחים את ה-Rulebook של הפרויקט ומגדירים את מגבלות הנתונים באופן קשיח. בשלב זה מתייחסים יחד עם ה AI לכל נושא האוטומציה. כל דבר אבל כל דבר חייב להיות אוטומטי וברור. בשלב זה גם מגדירים ל AI מה הם גבולות הגזרה הברורים.
- החוזה והבדיקות: מגדירים את חוזה המערכת (ה-Spec), נותנים ל-AI לכתוב את בדיקות ה-TDD ומאשרים אותן באופן ידני, ורק אז מנחים את המכונה לייצר את ה-Body שמתאים לחוזים האלו. בעידן שבו הסינטקס זול והקוד הופך למשאב מתכלה, מהנדס התוכנה החדש הוא ארכיטקט של קונטקסט שמנהל Specs, לא פועל מקלדת שמייצר Body.
מתוך הניסיון האישי שלי בתור ארכיטקט תוכנה פשוט במעל 200 פרוייקטים גדולים וקטנים וותיקים וחדשים ברור לי למה זה כל כך חשוב, לצערי התעשייה בשנים האחרונות ובמיוחד בשנתיים האחרונות מייצרת לא מעט SLOP בגלל שבוחרים לקצר תהליכים. לצערי הכי גדול המהנדסות ומהנדסים הצעירים שרק נכנסים לתעשייה לא לומדים את הדברים הנכונים וישר מתובנתים על ידי AI
3- האומץ לעצור ולתקן את היסודות
אם הייתי מקבל דולר על כל פעם ששמעתי התירוץ של "אין לנו זמן לעצור ולתקן את התשתית את הליבה" הייתי יותר עשיר מאיילון מאסק. בעיני זה אחד המיתוסים הכי גדולים של התעשייה, והיום הוא חמור פי כמה. כשה-AI מייצר קוד בשניות, האינסטינקט של מפתחים הוא פשוט לבקש ממנו עוד טלאי ועוד תיקון נקודתי. הם עורמים שכבות על גבי שכבות של קוד שהם לא באמת מבינים, רק כדי לא לעצור את הרכבת. התוצאה היא מורכבות מפלצתית שקורסת לתוך עצמה. כן יש חברות ומיוחד אלו המעסיקות את המהנדסות הטובות בעולם ושעושות את זה נכון. אבל רוב החברות לא באמת יעשו Ai powered SDLC.
יש כנראה הרבה סיבות לתופעה , בעיני הפער הוא בעיקרו פסיכולוגי , פחד מהלא נודע וחוסר ביטחון מקצועי. המפתחים חוששים שכל נגיעה ביסודות תשבור את המערכת, אז הם מעדיפים להמשיך להילחם בסימפטומים. אבל פיתוח מודרני דורש את האומץ לעצור. המכונה היא כלי מעולה לעזור לנו בזה: היא יכולה למפות תלויות מורכבות ולכתוב בדיקות לקוד הישן לפני שנוגעים בו, מה שנותן לנו את הביטחון לבצע את השינוי ביומיים של עבודה נקייה במקום לגרור שבועות של סבל.
זה בדיוק מה שקורה כשמפתחים מסרבים לבנות אפליקציה קטנה בצד (Sandbox) כדי לבדוק פיצ'ר, ומעדיפים לקמפל, להריץ את כל השרתים ולחכות דקות ארוכות לכל בדיקה. הם מפספסים את החשבון הפשוט: הזמן המצטבר של ההמתנות האלה גדול פי כמה מהשעה שלוקח לבנות סביבה נקייה ומבודדת. בעידן ה-AI, מהנדס שלא יודע לעצור, לבודד את הבעיה ולבנות לה ארגז חול נקי, פשוט יטבע בתוך המורכבות של עצמו. וזו עוד יכולים שהחברים הצעירים חייבים לתרגל ולסגל
4- משבר 10,000 שעות הניסיון של הדור הבא
כמה שעות נדרש על מנת להפוך להיות מאסטרו ? הפסיכולוג השוודי פרופ' אנדרס אריקסון (K. Anders Ericsson) הוא המדען שמאחורי המחקר עליו התבסס חוק ה-10000 שעות. חשוב לציין שאלמנט השעות זה לא מספר קסם הוא מתבסס כמובן גם על כשרון ולא פחות חשוב מה עושים ב 10000 השעות האלו.
בעולם הפיתוח של פעם, חלק גדול מהשעות האלה הושקע בכתיבה סיזיפית של קוד, מאבק בלתי פוסק בסינטקס, קריאת קומפילציות ומציאת שגיאות פשוטות. כיום, ה-AI פותר את רוב החלק המכני הזה בשניות, ויוצר אשליה של קיצור דרך מטורף. חייבים לשים את האמת פשוטה: מדובר במלכודת. פיתוח מיומנות הנדסית דומה מאוד לאימון בחדר כושר, אתה לא יכול לבנות שרירים אם מישהו אחר (ה-AI) מרים עבורך את המשקולות. כתיבה עצמית והתמודדות עם הקשיים הן המשקולות של המוח.
מעבר לכך, ה-10,000 שעות מעולם לא היו רק על כתיבת הקוד עצמו, רק 20 עד 25 אחוז ברוב המקרים. הן כללו את כל הדינמיקה האנושית והתפעולית שמסביב: שיח עמיתים, הבנת תהליכים, דיבאג של קוד לגאסי מורכב, פתרון משברים בשעות הקטנות של הלילה, ומיומנויות רכות שנבנות רק דרך חיכוך יומיומי בריא. ככל שהסינטקס הופך לחינמי, הכלים האלה מנוונים את השרירים של הדור הבא ומאיימים לייצר מהנדסים חלשים שלא מסוגלים להחזיק מערכת חיה ברגע שהמכונה טועה.
כדי לייצר את החיכוך הזה מחדש, אנחנו חייבים לשנות את מסלול ההמראה של המהנדסים הצעירים. במקום לתת להם לרוץ למקלדת, אנחנו שמים את הפוקוס על הובלת ה-Spec. הג'וניור הופך לאחראי הבלעדי לנסח את האפיון, להציג אותו לצוות, ולהגן על הארכיטקטורה שלו מול המהנדסים הוותיקים לפני שבכלל נכתבת שורת קוד אחת. את זה נתבל במשימות פיתוח קטנות ומבודדות ללא AI, כדי לשמור על האינטואיציה הסינטקטית הבסיסית שלו.
עצרו, לנו יש אחריות אקוטית , חובה מוסרית ומקצועית לוודא שהם באמת צוברים את הניסיון ולא מעבירים את האחריות למכונה. אין פתרון קסם מהיר חייבים לשלב ולא להתפשר על מנטורינג צמוד מצד סניור שמאתגר את הג'וניור לחשוב על ה"למה" של הקוד ולא רק על ה"איך", לצד מדדי הערכה מבוססי גאווה מקצועית (Metrics) חשוב לזכור אנחנו כבר לא מודדים אותם על כמות המשימות שהם סגרו בג'ירה, אלא על איכות התכנון והבנת התמונה הגדולה של המערכת.
תמיד חשוב לזכור מיומנות הנדסית לא נבנית מכתיבה עיוורת של סינטקס, אלא מהחיכוך היומיומי של תחזוקת קוד לגאסי, פענוח ארכיטקטורה מורכבת והתמודדות עם באגים בלילה.
5- הגדרת המקצוע מחדש: הג'וניור כבלש וכמבקר
יש לנו אחריות היסטורית , אנחנו חייבים לגדל את הדור הבא של הארכיטקטיות והארכיטקטים, יש להגדיר מחדש את תפקיד הג'וניור אסור לנו להתפשר. בעידן שבו כתיבת הקוד עצמה היא מכנית וזולה, הג'וניור כבר לא יכול להיות מתכנת שמייצר שורות קוד. הוא נדרש להפוך לבלש ומבקר של תוצרים שונים. המיומנויות הטכניות הקריטיות ביותר שהוא חייב לפתח הן היכולת לזהות את ה-Root Cause של באגים מורכבים (בלי לרוץ ל-GAI שינחש עבורו את הפתרון), היכולת לקרוא ולפענח מערכות ותיקות ומסובכות כדי להבין את ההקשר הארגוני, ומיומנות כתיבת בדיקות ומקרי קצה (Testing & Mocking) ברמה גבוהה. וכמובן יכולת תקשורת בין אישית עם בני אדם ולא רק עם מכונות.
את שריר הבלשות הזה אנחנו מתרגלים בצוותים באמצעות שילוב מעשי:
* סקר ברמת תכנון וקוד לתוצרים של אחרים (בני אנוש ומכונות): הג'וניור לא רק מקבל משוב על הקוד שלו, אלא נדרש לבצע סקר קוד מעמיק לקוד שה-AI ייצר עבור מפתחים אחרים, ולהציג לצוות את הכשלים והשגיאות שהוא מצא.
* תרגיל סוכן מול סוכן: אנחנו מאפשרים ל-AI לכתוב קוד, ומאתגרים את הג'וניור לכתוב את סוכן ה-AI שימצא ויבדוק את מקרי הקצה הכי קשים של אותו הקוד. הוא לומד לנהל את המכונה ולא לתת לה לנהל אותו.
כדי לוודא שהצעירות והצעירים באמת צוברים את הניסיון הזה ולא מתעצלים או מעבירים את כל האחריות למכונה, אין טעם בתבניות בירוקרטיות או בנהלים נוקשים של סקרי אפיון. כאן נכנסת "נוסחת הקסם" האמיתית: שימוש במוח שני (ה-AI האישי) של הארכיטקט המנוסה. הארכיטקט, שמעורב אינטימית בתהליך ומכיר את החוזקות והחולשות של הג'וניור ושל המנטור המלווה שלו, משתמש במוח השני שלו כגשר קונטקסטואלי חכם. המוח השני יודע לאתגר את הג'וניור בנקודות המדויקות שבהן הוא צריך להתאמץ, לעזור למנטור לכוון אותו ל"למה" של הארכיטקטורה, ולוודא שהחיכוך ההנדסי הבריא נשמר בכל שלב בדרך.
חשוב לזכור הניסיון של המחר ייצבר ב-10,000 שעות של קריאת קוד, איתור חורים שחורים ודיבג של לוגיקת מכונה, ולא בהקלדה של שורות קוד גנריות.
6- המיומנויות הרכות שהופכות למצרך נדיר
זה אחד מ 2 הנושאים שהכי יושבים לי במחשבות. בזמן שהעולם מתלהב ממהירות כתיבת מוצרים על ידי בינה מלאכותית יוצרת, בשטח מתחיל להיווצר חור שחור שקט ומדאיג. מפתחים שמתרגלים לתקשר בעיקר מול המכונה, וזה הכי קל לא לתקשר בצוות, בפרומפטים, בפתרון שגיאות ובהסברים טכניים ולחלוטין מאבדים את המיומנויות הרכות (Soft Skills) שלהם, בשבילי זה סופר קריטי.
אני כבר רואה את זה קורה בלא מעט מקרים: המפתחים מפסיקים לאתגר זה את זה ומקבלים את "דעתו" של ה-AI כחזות הכל (אובדן הוויכוח ההנדסי הבריא), הם מתקשים ואפילו מסרבים להסביר לחבר לצוות או ללקוח את הלוגיקה שמאחורי הפתרון שלהם, והקשר המקצועי בין צעירים לוותיקים נשבר כי הג'וניור מעדיף להסתגר בסילוס המבודד שלו מול ה-GAI במקום לשאול שאלות.
אסור לנו להתעלם ואנחנו צריכים להסתכל בלבן של העין בנושא הבוער הזה ״בניוון המקצועי הזה״, אנחנו חייבים להכניס למודל ההפעלה היומיומי שילוב של ארבע פקודות עבודה מעשיות:
* ארכיטקט ללא סמכות: משימה שבועית שבה מפתח נדרש לשכנע את הצוות בנכונות של פתרון טכני, ללא שימוש בשקפים או במילים מפוצצות.
* תרגום אנושי ב- Review: חובה להסביר בקול, בשלושה משפטים פשוטים, את ה"למה" של הלוגיקה למהנדס אחר בצוות לפני מיזוג הקוד.
* סיעור מוחות ללא מקלדות (No-Laptop Storming): חלונות זמן שבהם המחשבים סגורים ומתרכזים בדיון פרונטלי סביב הלוח.
* תרגיל סוכן מול סוכן: אנחנו מאפשרים ל-AI לכתוב קוד, ומאתגרים את הג'וניור לכתוב את סוכן ה-AI שימצא ויבדוק את מקרי הקצה הכי קשים של אותו הקוד. הוא לומד לנהל את המכונה ולא לתת לה לנהל אותו.
גם כאן הייתי ממליץ להשתמש בטכניקת המוח השני
7- מנהיגות ללא סמכות: הארכיטקט.ת והמהנדס.ת החדש.ה
כל מי שמכיר אותי, ואם לא זה הזמן לעבור על הפוסטים בבלוג . יודעת ויודע שאני מאמין שארכיטקט ללא סמכות הוא הארכיטקט הטוב ביותר. מנהיגות טכנולוגית אמיתית נבנית אך ורק על בסיס של אמון, ענווה ומקצוענות. אם אתה נדרש להשתמש בכותרת או בכוח הפורמלי שלך כדי לשכנע את הצוות, כנראה שהרעיון שלך פשוט לא מספיק טוב. הכלל המנחה שלי הוא שמי שמחליטה היא מנהלת הפרויקט. תפקיד הארכיטקט הוא לייעץ, לכוון, לבחון ולהיות באותה סירה יחד עם הצוות ("אנחנו" ולא "הם" או "אתם"), ולא להכתיב החלטות מלמעלה.
המכשול הגדול ביותר שמונע מארכיטקטים וממובילים לבנות את האמון הזה מהיום הראשון הוא הפחד מהפריה הדדית. רבים חוששים להודות שהם לא יודעים הכל או ללמוד מהשותפים האחרים והצעירים בצוות, מחשש שזה יפגע במעמדם. כדי לשבור את מגדל השן הזה, ארכיטקט מנוסה חייב לעשות שני דברים ביומיום שלו:
* ללכלך את הידיים בקוד: להראות דוגמה מעשית ברמת המימוש ולא למכור אשליות במצגות יפות ומנותקות מהמציאות.
* ללמוד מהצעירים: לא לפחד להגיד "אני לא יודע" וללמוד מהג'וניורים, במיוחד בעידן ה-AI שבו הם מביאים מהשטח כלי עבודה ושיטות פיתוח חדשות שהם גילו.
ההבנה שאנחנו לומדים מהשותפים שלנו בדיוק באותה מידה שאנחנו מלמדים אותם היא הבסיס למקצוענות אמיתית. וגם זו יכולת שצריכים להטמיע בחברים החדשים בעולם המקצועי
8- תרבות ה"אנחנו" מול חטא היהירות
אחד הכללים שהכי מובילים אותי לאורך כל הקריירה, בכל קבוצה ובכל מיזם שהקמתי, הוא פשוט: ההצלחה היא תמיד של הצוות/מיזם, והכישלון הוא של המוביל. בעידן ה-AI, כשמפתח יכול לחטוא ביהירות ולהתנער מאחריות באמירה "זה הקוד שהמכונה פלטה לי", אנחנו חייבים לבנות חומת מגן תרבותית של בעלות משותפת. אין מקום למשחקי אשמה או אצבעות מאשימות. כשיש באג, הצוות מתכנס ופותר אותו יחד מתוך הבנה שאנחנו באותה סירה, ומתייחס לטעות כאל משוב משותף לצמיחה והפקת לקחים לפעם הבאה.
כדי לפרק את חטא היהירות הטכנולוגית ולחבר את האנשים בגובה העיניים, אנחנו מיישמים ביומיום שילוב של ארבעה מהלכים תרבותיים:
* עשרת הדברות לאדם בתוך המקצוע: אימוץ סט חוקים שמקדש ענווה, אוסר על התנשאות מקצועית ומחייב יחס אנושי ומכבד לכל חבר צוות.
* הסרת שפת ה"הם": איסור מוחלט על שימוש בביטויים כמו "הקוד שלהם" או "הטעות של ה-QA", ומעבר קפדני לדיבור במושגים של "הקוד שלנו" ו"המערכת שלנו".
* ה-Reflector הארגוני: חשיפה גלויה של פערי הבנה בצוות ללא בושה, וירידה משותפת לשטח כדי "ללכלך את הידיים" בקוד ולצמצם את הפערים ביחד.
* פיצוח משותף חוצה-צוותים: הגדרת משימות שבהן מפתחים, אנשי בדיקות ואנשי מוצר נדרשים לשבת סביב אותו הלוח ולפצח את הבעיה יחד, מה שמפרק את מחיצות האגו הארגוניות.
בסופו של דבר, הטכנולוגיה הכי מתקדמת לא תחזיק מעמד אם האנשים שמאחוריה לא ידעו לעבוד יחד מתוך שותפות ואמון אמיתי.
9- קודם כל אנשים: מודל ההפעלה בעידן ה-AI SDLC
בשורה התחתונה, מודל ההפעלה החדש של הנדסת תוכנה בעידן ה-AI מחזיר אותנו לעקרון היסוד המנחם: קודם כל אנשים, אחר כך טכנולוגיה. אל תתנו למורכבות החדשה להבהיל אתכם. מה שלא פשוט פשוט לא יקרה. המטרה שלנו כמנהיגות ומנהיגים טכנולוגיים ב-2027 היא לא לשכפל את הצבא ולבנות עוד פטישים כבדים ומסורבלים של עשרה קילו, אלא לצייד את המהנדסים שלכם בלדרמן אנושי, גמיש וקומפקטי שיודע להתאים את עצמו לכל משימה. ואם בדרך החדשה הזו תעשו טעויות, תזכרו תמיד שכישלון הוא רק משוב. פשוט תעצרו, תתקנו את היסודות ותמשיכו לרוץ קדימה מטר אחרי מטר.
כשנשכיל ליישם את מודל ההפעלה הזה, נוכל להביט שוב בדלת המסתובבת של המקצוע בביטחון מלא. רותם מודל 2027 לא תהיה עוד פועלת סינטקס עצלנית שרוכבת על אוטומציות מנותקות, אלא תצמח להיות ארכיטקטית הניצחון של המחר מהנדסת שיודעת להגדיר קונטקסט, לנהל לוגיקה עמוקה ולשתף פעולה בגובה העיניים. היא תפעל בתוך הארגון שלכם כמו הציור של הקופסה עם שלושת החורים מהנסיך הקטן: במרחב מוגן ובטוח מספיק כדי לא לחשוש מטעויות (ה-Sandbox הארגוני), אך פתוח ויצירתי מספיק כדי לאפשר לדמיון ולחדשנות שלה לנשום ולפרוץ קדימה.
זה אולי נשמע קשה או מורכב מדי ליישום בארגונים גדולים ומסורתיים, אבל בעיניי ,דעתי האישית והצנועה, הבלתי אפשרי הוא אפשרי. אשמח לשבת יחד איתך ,לשוחח ולהקשיב לקירות הארגוניים שאתם פוגשים בשטח, ולחשוב ביחד איך לבנות עבורך את ה-Sandbox הראשון שיצעיד הארגון שלך לעידן הבא.