העולם של מנהלי פיתוח (CTOs) וסמנכ"לי פיתוח השתנה מקצה לקצה בחודשים האחרונים. אם פעם הפגישה עם מייסד הייתה מתחילה בתיאור החזון ובדיון על תקציב גיוס צוות, היום היא מתחילה לעיתים קרובות במילים: "תראה מה בניתי לבד עם קלוד".
על פניו, זה נראה כמו חלום של כל יזם ו-ROI פסיכי. במקום לאשר תקציבים לכלי מדף או להמתין חודשים ל-MVP, אפשר להגיד לצבא הבוטים שלנו להרים פתרון קאסטם עד ארוחת הצהריים. אבל מתחת לפני השטח, ה-AI יצר שתי דמויות חדשות של מייסדים ושני סוגים של כאבי ראש ארכיטקטונים שנוחתים בסופו של דבר על השולחן שלכם.
המייסד ה-Vibe-Coder: המלכודת של המהירות
לא מזמן, שבועיים אחרי פסח בערך, ישבתי בזום עם מייסד שהראה לי בגאווה את מה שבנה. "עשיתי את זה לבד, מחנוכה אני על זה, ועכשיו אני רוצה מפתח שיקח את זה הלאה", הוא אמר.
על המסך שהוא שיתף ראיתי משהו שאפשר רק לקרוא לו "חצי שנה של בלאגן AI". זה מה שאנחנו קוראים לו 'וייבקודינג' (Vibe Code) - קוד שמרגיש מהיר ומתפקד בהתחלה, אבל אין לו שום עומק ארכיטקטוני. אותו התנאי הלוגי ממומש באלף דרכים שונות, וכל תיקון שנעשה דרך הפרומפט יצר עוד טלאי על טלאי.
הבעיה עם ה'וייבקודינג' היא שהוא יוצר אשליה של התקדמות. המייסד מרגיש שהוא בנה 80% מהמוצר, כשבפועל הוא יצר חוב טכני שיקח יותר זמן לתקן מאשר פשוט לכתוב מחדש מאפס. זה הופך להיות נטל כבד, קופסה שחורה מפוצצת בטלאים שאי אפשר לתחזק ביום שאחרי.
המייסד החרדתי: השאיפה לשלמות שמשתקת את הביצוע
מהצד השני של המתרס, פגשתי מייסדים שהגיעו למסקנה הפוכה לחלוטין. הם ראו מה ה-AI מסוגל לעשות, נבהלו מחוסר העקביות, ופשוט הפסיקו לסמוך עליו.
באחד המקרים, יזם שאל אותי ברצינות: "אולי כדאי שאוציא תואר במדמ"ח כדי לכתוב את זה? נמאס לי לחפש מפתחים ואני לא סומך על ה-AI כאן".
זהו רגע קלאסי שבו ה-AI, במקום להיות כלי עזר אדיר, הופך למחסום. המייסד הזה מחפש את הדיוק המוחלט והשלמות הארכיטקטונית עוד לפני שיש לו משתמש אחד. הוא מבין שה-AI יכול להזות (מלשון הזיות) או לייצר קוד שביר, ובגלל שהוא לא יודע איך לנהל את ה"קסם" הזה, הוא נכנס לשיתוק. הוא לא יכול לקבל החלטות.
דילמת ה"לבנות או לקנות" מתה (והבוטים קברו אותה)
המתח בין שני סוגי המייסדים האלו מתרחש על רקע שינוי עמוק יותר בתעשייה: המוות של דילמת ה-Build vs Buy, מהלך שעליו הרחבתי במאמר ה-AI לא מחליף את המהנדס - הוא מחליף את השאלה.
מבחינה עסקית, היום קל מתמיד להחליט "לבנות". כל מפתח בצוות שלכם הפך פתאום למנהל עבודה שמפקח על צבא של בוטים. אנחנו משיקים כלים פנימיים ופיצ'רים בקצב פסיכי, אבל פה מתחיל החשבון האמיתי.
הבוטים האלה בונים מהר, אבל הם מקבלים החלטות ארכיטקטוניות בשושו. אם אתם לא שמים לב, אתם דוחפים לפרודקשן משהו שאין לכם מושג איך הוא בנוי באמת. "טיים טו מרקט" הופכת להיות מילה יפה למה שקורה כשהזנב מתחיל לכשכש בכלב.
איך הופכים 'צעצוע' למוצר אמיתי?
אז איך מנווטים בין המייסד שרץ מהר מדי לזה שתקוע במקום? הפתרון הוא להבין שה-AI הוא כלי מעולה לסקיצות, אבל גרוע כמהנדס בניין.
הנה הגישה שאני מציע למנהלים טכנולוגיים שרוצים לרתום את הכוח של ה-AI מבלי לאבד שליטה על הארכיטקטורה:
- ה-AI הוא לסקיצה, לא לבסיס: תשתמשו ב-AI כדי לבנות סקיצה ראשונית ומהירה. תבנו איתו מספיק כדי להסביר את הרעיון, למפות את התהליכים (לוגין -> העלאת דאטה -> תוצאה) ולתקשר את החזון.
- מנהל עבודה מול מהנדס בניין: קבלן ביצוע מהיר (ה-AI) זה מעולה ל-ROI, אבל את תפקיד מהנדס הבניין אתם חייבים להשאיר אצלכם. אתם אלו שצריכים לפרק את הקוד, לפקפק ב"קסם" ולוודא שהבעלות על הארכיטקטורה נשארת בידיים אנושיות.
- חשבו פעמיים, ממשו פעם אחת: אל תתנו למהירות של הבוטים לפתות אתכם לדלג על שלב התכנון. קוד שנועד לתקשר חזון הוא לא קוד שצריך להישאר בבסיס המערכת לאורך זמן ואפשר לרוץ בו, אבל לא קוד של מוצר אמיתי.
השורה התחתונה: תהיו ביוניים, לא פסיביים
העתיד שייך למומחים ה"ביוניים" - אותם מנהלים ויזמים שיודעים להשתמש ב-AI כדי לרוץ פי 10 יותר מהר, אבל לא הופכים לתלויים בו או פסיביים מולו.
כשמגיע אליכם מייסד 'וייבקודר' או כזה עם פחד מה-AI, התפקיד שלכם הוא להיות השותף הטכנולוגי שבונה מוצר, לא צעצוע. תבנו מערכות שישרדו את המציאות, לא רק את הדמו.
נקודה למחשבה: מתי בפעם האחרונה אישרתם קנייה של מוצר מדף, במקום פשוט לבקש מהצוות (ומהבוטים שלו) לבנות גרסה משלכם?
Takeaways
- ה-AI מאיץ פיתוח אבל עלול ליצור "חוב טכני" אם הוא לא מנוהל ארכיטקטונית.
- פחד מחוסר עקביות של AI יכול לשתק קבלת החלטות ולמנוע חדשנות.
- "Build vs Buy" נעשה ל"Build" כמעט אוטומטית, מה שמחייב שמירה על בעלות אנושית על הארכיטקטורה.
- השתמשו ב-AI לסקיצות מהירות ואיטרציות של הדגמות, אבל הקפידו שמומחים אנושיים יבנו את הבסיס הארכיטקטוני.
- מנהלים טכנולוגיים צריכים להיות "מפקחים ביוניים" על הפיתוח שנעשה עם AI ובאחריותם לשלב מהירות עם תכנון עמוק.