מותו של ה-Build or Buy: איך ה-AI הפך את בניית התוכנה לבעיה ארכיטקטונית

במשך עשורים, אחת השאלות המרכזיות שכל CTO או VP R&D היה צריך לענות עליהן הייתה הדילמה הקלאסית: Build or Buy. האם אנחנו משקיעים את המשאבים היקרים של הצוות שלנו בבניית כלי פנימי, או שאנחנו פותחים את הארנק ומשלמים לספק SaaS חיצוני כדי לחסוך זמן?

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

אבל אז הגיע ה-AI וקבר את הדילמה הזו סופית.

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

החלום העסקי: פתרון קאסטם עד ארוחת צהריים

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

זה נראה מדהים ב-ROI. במקום לשלם דמי מנוי חודשיים על מערכת מורכבת שרק 20% ממנה רלוונטי לנו, אנחנו בונים בדיוק את מה שאנחנו צריכים. ה-AI כותב את הקוד, מחבר את ה-APIs ומייצר לנו דאשבורד יפהפה.

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

הבעיה היא שצבא הבוטים הזה בונה מהר, אבל הוא מקבל החלטות ארכיטקטוניות בשושו. כשמפתח אנושי כותב קוד, יש (או אמור להיות) תהליך של חשיבה. למה בחרנו בדאטה-בייס הזה? איך המערכת הזו תתמודד עם עומס? מה קורה כשצריך להרחיב אותה? כשה-AI מייצר אלפי שורות קוד בשניות, התהליך הזה נדחק הצידה.

המלכודת של ה"טיים טו מרקט"

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

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

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

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

מנהלי עבודה או מהנדסי בניין?

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

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

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

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

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

סיכום: ביוניים, לא פסיביים

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

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

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

השורה התחתונה למחשבה:

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

נקודות עיקריות

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

אל תתנו לזנב לכשכש בכלב. הישארו הארכיטקטים של המוצר שלכם.

הצטרפו לדיון: