תכנון תוכנה AI-first מן היסוד: מדריך למתרגלים

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

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

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

אותם כלים. תוצאות הפוכות. ההבדל הזה הוא לא על המודל.

המגבר שאף אחד לא הביא בחשבון

דוח State of AI-assisted Software Development של DORA ל־2025 שם מספרים על זה. ‏90% מאנשי המקצוע בטכנולוגיה משתמשים כיום בבינה מלאכותית בעבודה, ויותר מ־80% מאמינים שהיא הגדילה את הפרודוקטיביות שלהם. שתי אלה לא מפתיעות. המסקנה שחשובה היא השלישית: אימוץ גבוה יותר של בינה מלאכותית מקושר לעלייה בתפוקת אספקת התוכנה וגם לעלייה באי־יציבות אספקת התוכנה, בבת אחת.

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

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

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

חשבו מהבעיה, לא מהכלי

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

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

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

עשו את זה בכשרות ותגלו שהבינה המלאכותית שינתה בדיוק דבר אחד — וזה לא הדבר שהקטגוריה מכרה.

עלות ייצור הקוד ירדה כמעט לאפס. עלות ההחלטה מה הקוד צריך להיות לא זזה.

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

אחת: מודל הנתונים הוא המוצר

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

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

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

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

שתיים: החלטה שנדחתה בכל זאת מתקבלת

זו זו שמתרגלים ממעיטים בערכה.

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

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

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

לפרקטיקה שמתקנת את זה יש שם עכשיו: פיתוח מונחה מפרט. כתבו קודם את הדרישות, את האילוצים ואת קריטריוני ההצלחה. התייחסו למסמך הזה כמקור האמת. תנו לסוכן לבנות מולו. ‏GitHub שילחה את Spec Kit, ‏AWS שילחה את Kiro, וההתכנסות הזאת אינה מקרית.

שלוש: כשייצור הוא בחינם, אילוצים חייבים להיות כתובים

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

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

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

כל אילוץ שאתם מחצינים הוא החלטה שהמודל לא יכול עוד לטעות בה.

ארבע: אתם בונים עכשיו לשני צרכנים

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

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

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

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

איך זה נראה בנתונים כשמדלגים

‏GitClear ניתחה 623 מיליון שינויי קוד מ־2023 עד 2026, ותמונת התחזוקתיות עקבית עם כל מה שלמעלה.

מול קו בסיס של 2023, בלוקי קוד משוכפלים עלו ב־81%. העתק/הדבק בתוך קומיט טיפס מ־9.4% ב־2022 ל־15.7% במחצית הראשונה של 2026. מבנים שמסתירים שגיאות עלו ב־47%. במקביל קריאות פונקציה בין־קבצים — האות הבהיר ביותר שזמין לשימוש חוזר בקוד — ירדו ב־35%, ופעילות השכתוב קרסה מ־21% מהשינויים ב־2022 ל־3.8% עד כה ב־2026.

הסיכוי שמפתחים יעתיקו וידביקו כיום גדול בפי חמישה בקירוב מהסיכוי שישכתבו. ב־2022 היחס הזה רץ בכיוון ההפוך.

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

איך לעבוד כך, כבר בשבוע הזה

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

1. כתבו את מודל הנתונים לפני המסך הראשון. ישויות, קשרים, עוצמות, מה הופך שורה לייחודית, מה מתגלגל במחיקה. שעה כאן היא השעה בעלת המנוף הגבוה ביותר בפרויקט, וזו שהכלים מזמינים אתכם באופן פעיל לדלג עליה.
2. הפכו את המפרט לחפץ שאתם סוקרים, לא את ההפרש. אם המפרט נכון והייצור נאמן לו, לסקור אלפי שורות של קוד שנוצר זה תיאטרון. סקרו את המסמך שהפיק אותן. התווכחו על המפרט בזמן שהוויכוח עדיין זול.
3. החצינו כל אילוץ שאתם יכולים לנקוב בשמו. לפני הייצור, פרטו את הכללים שאסור להפר לעולם ושימו כל אחד במקום שהמערכת אוכפת אותו. כל דבר שנשאר בשיחה יופר בסופו של דבר על ידי משהו שמעולם לא הצטרף לשיחה.
4. תכננו את ה־API כמשטח המוצר. אחר כך התייחסו לממשק האנושי כאחד הצרכנים שלו. זו בחירת סדר יותר מבחירה הנדסית, ולסדר אותה מאוחר זה מה שהופך אותה ליקרה.
5. מדדו אי־יציבות, לא רק תפוקה. המסקנה של DORA היא שמהירות ושבריריות עלו יחד, ולכן מדידת מהירות בלבד תראה לכם את המחצית הטובה של המגמה שלכם. שיעור כשל השינויים וזמן ההשבה הם המספרים שאומרים לכם אם המגבר עובד בשבילכם.

מה זה עולה

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

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

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

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

החלק שמעולם לא היה בר־אוטומציה

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

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

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

ההקלדה מעולם לא הייתה העבודה.

קריאה נוספת

הפרקטיקה לעומק: פיתוח מונחה מפרט. אם אתם בוחרים כלי: בוני יישומי הבינה המלאכותית הטובים ביותר ב־2026.

שאלות נפוצות

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

במה תכנון AI-first שונה מסתם שימוש בכלי קידוד בינה מלאכותית? שימוש בכלי בינה מלאכותית מוסיף יכולת לתהליך עבודה שלא השתנה. תכנון AI-first משנה את סדר הפעולות בתהליך — מודל וחוזה לפני ממשק, מפרט כחפץ הנסקר, אילוצים שנדחפים לשכבות אכיפות. המחקר של DORA ל־2025 מצא שאימוץ בינה מלאכותית העלה תפוקה ואי־יציבות יחד, וזה מה שקורה כשהכלי משתנה והפרקטיקה לא.

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

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

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

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