פיתוח מערכות לעסקים: הקוד תקין, והתחזוקה מתייקרת

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

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

מה 623 מיליון שינויי קוד מגלים

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

הממצא המרכזי עוסק בכפילויות. מדד שכפול בלוקי הקוד צמח ב-81 אחוז, מ-40.3 בשנת 2023 ל-73.0 בשנת 2026. העתקה והדבקה בתוך אותו commit גדלה ב-41 אחוז.

אבל הנתון שהדליק לי נורה אדומה הוא אחר. רק 3.8 אחוז מכלל השורות שהשתנו ב-2026 הן העברה או ארגון מחדש של קוד קיים. ב-2022 המדד הזה עמד על 21 אחוז.

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

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

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

פיתוח מערכות לעסקים: איפה מסתתר הסיכון בקוד

כאן נכנס המחקר השני. חברת Veracode בדקה מודלים רבים על 80 משימות תכנות, בארבע שפות. היא פרסמה את העדכון במרץ 2026.

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

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

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

הפילוח לפי שפה חד במיוחד:

גם סוג הפרצה קובע. בסוג אחד, Cross-Site Scripting, המודלים הצליחו ב-15 אחוז מהמשימות בלבד. אפילו המודלים החזקים בבדיקה עצרו ב-72 אחוז.

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

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

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

מתי פיתוח מערכות לעסקים עם AI דווקא משתלם

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

מחקר DORA של גוגל בדק כמעט 5,000 אנשי מקצוע, ופורסם בספטמבר 2025. 90 אחוז מהמשתתפים עובדים עם AI. מעל 80 אחוז מדווחים על שיפור בתפוקה. במקביל, 30 אחוז מהם לא סומכים על הקוד שהמודל מייצר.

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

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

ארבעה דברים לדרוש בפרויקט פיתוח מערכות לעסקים

1. code review בידי אדם: תדרשו שמישהו מלבד הכותב יקרא כל שינוי. זה התנאי שמפריד בין שני התרחישים של DORA.
2. בדיקות אוטומטיות בהיקף מוגדר: בקשו רשימת בדיקות, ולא הצהרה כללית. בלי זה, מהירות הופכת לחוסר יציבות.
3. סריקת אבטחה לפני מסירה: הנתון של 55 אחוז מצדיק כלי סריקה בצינור הפיתוח. הסריקה מוסיפה שכבת בקרה חשובה, אבל היא לא מחליפה סקירה אנושית ותיקון ממצאים.
4. תקציב תחזוקה לשנה קדימה: הכפילויות עלולות לייקר כל שינוי עתידי. תכננו את הכסף הזה כבר היום.

מתי הפתרון הפשוט מספיק

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

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

שאלות שחוזרות על פיתוח מערכות לעסקים

האם code review באמת חוסך כסף?

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

כדאי לבקש הנחה כי הספק עובד עם AI?

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

המחקרים האלה רלוונטיים לעסק ישראלי?

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

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