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

חברות מובילות מדווחות על שיעורים עצומים של קוד שנוצר בעזרת בינה מלאכותית. מפתחים משתמשים בכלים כמו Claude Code, Codex, Cursor וכלי vibe coding נוספים כדי להאיץ את עבודת צוותי הפיתוח החל מהקוד עצמו דרך תיקון באגים תיעוד ועוד. מבחוץ, זה נראה כאילו עולם הפיתוח עומד בפני קפיצה דרמטית בפרודוקטיביות.

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

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

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

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

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

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

חמש רמות של מפתח AI
חמשת הרמות למעשה מתארות את ההתפתחות של המפתח עם כלי ה AI משלב ה Vibe Coding לתפיסה שנקראת Agentic Development (למעשה מצב בו רוב הקוד נכתב על ידי סוכני AI). חמשת השלבים הם:

שלב 0: השלמת קוד מתקדמת
בשלב זה ה-AI  משמש ככלי עזר כמו Stack Overflow  או מנוע חיפוש על סטרואידים. אנחנו כותבים ידנית את הקוד ומשתמשים מידי פעם ב AI להשלמת הקוד. אף תו לא נכתב לדיסק בלי האישור שלנו.

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

שלב 2: ה AI כמפתח צעיר
בשלב 2, אנחנו עובדים כמו ב Autopilot בכביש המהיר. בשלב זה זו שותפות אינטראקטיבית של “תכנות בזוג”. אנחנו וה-AI  מחליפים שליטה, כשאנחנו בעיקר בודקים את הקוד בזמן אמת. בתור מתכנתים, אנחנו מרגישים חופשיים. יש לנו שותף ג׳וניור שמאפשר להעביר אליו את כל הדברים המשעממים.

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

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

שלב 5: מפעל סוכנים (בחשכה)
ברמה 5 אנחנו כבר באוטונומיה מלאה, אנחנו כבר לא מנהלים תהליך של פיתוח תוכנה, זו קופסא שחורה שהופכת דרישות עסקיות למערכות עובדות. אנחנו מנהלים את המערכת ואת היעדים העסקיים, אנחנו מדברים עם סוכן מתזמר (Orchestrator) שמפעיל תתי סוכנים אוטונומיים.

הבטחתי שאסביר למה “חשוך”? כי זה כמו במפעל של Fanuc  ביפן. מפעל שפועל עם רובוטים בלבד, כך שאין צורך באור.



למה רוב הארגונים לא באמת AI-native
הבעיה היא שרוב השיח הציבורי מדבר כאילו אנחנו כבר ברמות 4 או 5. בפועל, רוב הארגונים נמצאים בין רמה 1 לרמה 3. זה פער עצום בין מה שספקי ה AI מוכרים לנו לבין המצב בפועל.

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

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

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

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

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

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

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

שיטות העבודה הישנות כבר לא מתאימות
ה Standups, sprint planning, code review ו-QA נוצרו לעולם שבו בני אדם כותבים קוד, הם נבנו סביב מגבלות אנושיות.

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

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

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

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

ארגונים שידלגו עליה יקבלו אשליית מהירות. ארגונים שישקיעו בה יוכלו להפוך AI למכפיל כוח אמיתי.

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

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

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

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

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

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

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