קודם כל: אנחנו כותבים עם הכלים האלה כל יום
אני רוצה לפתוח בזה כדי שהמאמר לא ייקרא כמו של מישהו שמגן על מקצוע. אנחנו משתמשים בכלי AI בפיתוח באופן יומיומי, הם חלק מהתהליך שלנו, והם אחת הסיבות שאנחנו יכולים להוציא MVP תוך 3 עד 6 שבועות במחיר שמתחיל ב-4,000 ש"ח. אין כאן שום נוסטלגיה.
אבל בדיוק בגלל השימוש היומיומי אנחנו רואים מקרוב איפה זה נשבר. ולא, זה לא נשבר בשבוע הראשון — שם הכול נראה מצוין. זה נשבר בערך אחרי שמונה חודשים, כשמגיע השינוי הראשון שנוגע בליבה.
מה הדאטה אומרת
ארבעה ממצאים מ-2026 שכדאי להכיר לפני שמקבלים החלטה על ספק או על שיטת עבודה.
היקף. כלי AI מייצרים היום כ-41% מכלל הקוד החדש שנכתב. זה כבר לא נישה ולא ניסוי — זו ברירת המחדל בענף.
איכות. קוד שנוצר ב-AI מכניס כ-1.7 יותר בעיות לכל בקשת מיזוג בהשוואה לקוד שנכתב בידי אדם. מחקר שבחן 302,600 קומיטים שנכתבו ב-AI ב-6,299 מאגרים מצא שיותר מ-15% מהם הכניסו לפחות בעיה אחת, ושכ-22.7% מהבעיות האלה עדיין לא תוקנו בגרסה האחרונה של אותם מאגרים.
חוב טכני. ארגונים שאימצו כלי AI ראו עלייה של 30% עד 41% בחוב הטכני. פורסטר צופה שאצל 75% מהארגונים החוב הטכני יגיע ב-2026 לרמה בינונית או גבוהה, כשהמנוע המרכזי הוא שימוש ב-AI בפיתוח בלי בקרות מספקות.
קצב. כלים כאלה מייצרים 140 עד 200 שורות קוד משמעותיות בדקה, מול 20 עד 40 של מפתח מרוכז. פער של פי חמישה עד שבעה.
הממצא האחרון הוא זה שמסביר את כל השאר, והוא גם המפתה מכולם. הבעיה היא שקצב כתיבה מעולם לא היה הצוואר בקבוק בפרויקט תוכנה.
חוב ההבנה — למה זה מתפוצץ בשנה השנייה
יש ממצא אחד שאני חושב שהוא החשוב מכולם, והוא כמעט לא מדובר: מפתחים שהשתמשו ביצירת קוד באמצעות AI כשיטת העבודה העיקרית שלהם קיבלו ציון נמוך ב-17% במבחני הבנת קוד לעומת עמיתים שכתבו יותר בעצמם.
זה לא ממצא על הקוד. זה ממצא על האנשים. וזה מדויק להחריד למה שאנחנו רואים בפרויקטים שמגיעים אלינו אחרי שספק אחר בנה אותם.
המערכת עובדת. היא עברה בדיקות ידניות, היא עלתה לאוויר, יש לה משתמשים. ואז מגיע שינוי שנראה קטן — להוסיף סוג משתמש חדש, לשנות את אופן חישוב ההנחה, לתמוך במטבע נוסף — ומתברר שאף אחד לא יודע להגיד למה החלק הזה בנוי כמו שהוא בנוי. אין החלטה מאחוריו. הוא פשוט נכתב.
וכשאין החלטה, אי אפשר לשנות בבטחה. כל שינוי הופך לניחוש, כל ניחוש מייצר באג במקום אחר, ואת זה מרגישים בחשבון: צוותים שלא מנהלים את החוב הזה באופן פעיל רואים עלויות תחזוקה שמגיעות עד פי ארבעה מהרגיל בשנה השנייה.
איפה AI באמת מאיץ, ואיפה הוא יוצר חוב
ההבחנה הזו היא כל התורה. היא לא בין "כלים טובים לרעים" אלא בין סוגי משימות.
| המשימה | AI מאיץ בצורה אמיתית | למה |
|---|---|---|
| קוד חוזר — טפסים, CRUD, המרות פורמט | כן, דרמטית | הדפוס ידוע, אין החלטות אמיתיות, הטעות מיידית וגלויה |
| כתיבת בדיקות אוטומטיות | כן | הכוונה ברורה, והבדיקה עצמה היא מנגנון האימות |
| מיגרציות והמרות בין ספריות | כן | עבודה מכנית בהיקף גדול, שאדם עושה גרוע יותר משעמום |
| פרוטוטייפ לבדיקת רעיון | כן, וזה שימוש מצוין | הקוד לא אמור לשרוד — הוא כלי חשיבה |
| ארכיטקטורה ומבנה מסד הנתונים | לא — כאן נוצר החוב | אלה החלטות שכל השאר נשען עליהן, והמודל בוחר את הנפוץ ולא את המתאים |
| מודל הרשאות ובקרת גישה | לא | נראה עובד בבדיקה ידנית, נכשל בדיוק במקרה שלא בדקתם |
| טיפול בכסף — תשלומים, זיכויים, מסים | לא | מקרי הקצה הם כל הסיפור, והם בדיוק מה שמודל מדלג עליו |
| טיפול בשגיאות ומקרי קצה | לא | המודל מייצר את המסלול המוצלח היטב, ואת השאר באופן גנרי |
אם מסתכלים על העמודה השמאלית, מגלים דפוס: AI מצוין כשיש דפוס ידוע והאימות מיידי, וגרוע כשצריך לבחור בין אפשרויות שכולן נראות סבירות. זה בדיוק ההבדל בין כתיבה לבין הנדסה.
חמישה סימנים שהמערכת שלכם נכתבה ככה
אלה סימנים שיזם לא-טכני יכול לזהות, בלי לקרוא שורת קוד אחת.
- הכול היה מהיר עד ההשקה, ומאז כל שינוי לוקח נצח. העקומה ההפוכה הזו היא החתימה הקלאסית.
- "זה מה שהיה שם". התשובה שמקבלים כששואלים למה חלק מסוים בנוי כך. אין החלטה — יש היסטוריה.
- תיקון אחד שובר משהו אחר, שוב ושוב. סימן שאין הפרדה אמיתית בין חלקי המערכת, גם אם היא נראית מסודרת.
- אין בדיקות אוטומטיות, או שיש והן מכובות. מצב נפוץ במיוחד בקוד שנוצר מהר.
- אף אחד לא מוכן לגעת במודול מסוים. בכל צוות יש קובץ שכולם עוקפים. אם הוא בליבה, יש בעיה.
מה עושים אחרת — ארבעה מעקות
אני לא מכיר צוות רציני ב-2026 שלא משתמש בכלים האלה. מה שמפריד בין צוותים זה מה שמסביבם.
1. אדם מחליט על הארכיטקטורה, לפני שמייצרים שורה
מבנה הנתונים, הגבולות בין חלקי המערכת ומודל ההרשאות נקבעים בישיבה ונרשמים במסמך. אחרי זה אפשר לייצר קוד בתוך המסגרת הזו כמה שרוצים. ההיפך — לתת לכלי להחליט ואז לחיות עם ההחלטה — הוא המקור לרוב מה שתיארתי למעלה.
2. כל שורה עוברת קריאה של בן אדם
לא "הרצתי וזה עבד". קריאה. אם אף אחד בצוות לא יכול להסביר מה הקוד עושה ולמה, הוא לא נכנס. זה מאט את השלב הראשון ומקצר את כל השאר.
3. בדיקות אוטומטיות על הליבה
לא כיסוי מלא — על החלקים שכסף וזהות עוברים בהם. אלה גם החלקים שכלי AI כותב בהם הכי הרבה בדיקות טובות, אז זה זול במיוחד.
4. יחידות עבודה קטנות
שינוי של 2,000 שורות שנוצר בבת אחת לא נקרא באמת על ידי אף אחד. אנחנו עובדים בספרינטים שבועיים עם דמו חי בסוף כל אחד, וזה בין השאר מה שמחייב עבודה בחתיכות שאפשר להבין.
מה זה אומר ליזם שלא מבין קוד
שתי מסקנות מעשיות.
הראשונה: אל תשלמו על מהירות בלבד. הצעת מחיר נמוכה במיוחד עם לוח זמנים אגרסיבי במיוחד היא לרוב לא יעילות — היא ויתור על השלבים שלא רואים. מה בדיוק לחפש בהצעה פירטנו במאמר על קריאת הצעת מחיר לפיתוח.
השנייה, והחשובה: ודאו שאתם יכולים לעזוב. קוד שאתם הבעלים שלו, בחשבון שלכם, עם תיעוד להרצה מקומית ורשימת שירותים חיצוניים — זה מה שהופך בעיה של חוב טכני מלכודת לבעיה שאפשר לפתור עם מישהו אחר. הסעיפים שקובעים את זה מפורטים במאמר על חוזה פיתוח ובעלות על הקוד.
ואם אתם שוקלים בכלל לוותר על פיתוח ולבנות על פלטפורמת No-Code, זו שאלה נפרדת וטובה — כתבנו עליה בנפרד, כולל מתי זה באמת מספיק.
שורה תחתונה
הכלים האלה הם השיפור המשמעותי ביותר בפרודוקטיביות של מפתחים שראיתי בקריירה שלי, ואני אומר את זה כמי שמשתמש בהם כל יום. הם גם מייצרים, כשמשתמשים בהם בלי מעקות, את סוג החוב שהכי קשה לשלם — כזה שלא רואים עד שכבר בנו עליו.
הדבר האחד שהייתי רוצה שכל יזם ייקח מכאן: השאלה הנכונה לספק ב-2026 היא לא "אתם משתמשים ב-AI?" אלא "מי קורא את מה שנוצר, ומי החליט על המבנה?". התשובה לשאלה הזו שווה יותר מכל שורה בהצעת המחיר. אצלנו אפשר לשאול אותה ישירות.
נכתב על ידי אביתר אדלר, CTO ב-FlowDev, על בסיס עבודה יומיומית עם הכלים האלה ופרויקטים שהגיעו אלינו אחרי שנבנו בלי מעקות. הנתונים נכונים לאוגוסט 2026.
