המאגר שלכם מעולם לא היה כל הסיפור

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

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

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

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

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

הבעיה אינה שהקוד מטעה. הקוד עונה על שאלה צרה יותר.

חמש שכבות של אמת הנדסית

רוב השינויים המשמעותיים בתוכנה תלויים בחמש שכבות שונות של ראיות.

1. כוונה — איזו תוצאה המשתמש, הלקוח או העסק מבקשים? זה יכול להופיע במפרט, בכרטיס משימה, בשיחת תמיכה או בהערת פגישה.
2. מגבלות — מה אסור שיישבר? הבטחות תאימות, גבולות אבטחה, רגולציות, חוזים, תקציבים ודדליינים נמצאים לעיתים קרובות מחוץ למאגר.
3. מימוש — איך המערכת עובדת היום? הקוד, הבדיקות, הסכמות, התלויות ותצורת הפריסה מספקים את השכבה הזאת.
4. ראיות זמן ריצה — מה קורה במערכת האמיתית? לוגים, traces, metrics, נתוני ייצור ודוחות תקריות יכולים לסתור הנחות שנראות סבירות בקוד.
5. היסטוריית החלטות — למה נבחרה הגישה הנוכחית? Pull requests, דיוני תכנון, חלופות שנדחו ותקריות קודמות מחזיקים את התשובה.

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

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

patch נכון מקומית עדיין יכול להיות השינוי הלא נכון.

מה המאגר לא יכול לענות עליו לבדו

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

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

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

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

גם יותר הקשר יכול להוביל לתשובה שגויה

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

זה יוצר גישה, לא הבנה.

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

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

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

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

יותר הקשר אמור לייצר יותר ראיות, לא יותר ביטחון בלי ראיות.

יחידת העבודה האמיתית היא השינוי

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

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

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

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

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

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

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

AI צריך לצמצם את הצורך בשחזור, לא לבטל שיקול דעת

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

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

היכולות האלה אינן מבטלות שיקול דעת הנדסי. הן הופכות אותו למבוסס יותר על מידע.

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

הרף אינו "האם הוא יכול לייצר קוד?"

הרף הוא "האם הוא יכול להסביר למה זה השינוי הנכון עכשיו?"

ממודעות למאגר קוד למודעות לעבודה

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

הצעד הבא הוא מודעות לעבודה שסביב מאגר הקוד.

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

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

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

הסיפור המלא משנה את מה שנבנה

כשיש רק את הקוד, השאלה הטבעית היא:

איזה שינוי מתאים למערכת הזו?

עם ההקשר הרחב יותר, השאלה הופכת ל:

איזה שינוי מתאים למערכת הזו, לדרישה הזו, להיסטוריה הזו ולרגע הזה?

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

המאגר שלכם מעולם לא היה כל הסיפור.

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