ה-AI תרגם 30 שנות COBOL בצורה מושלמת. ואז הוא הקריס את מסד הנתונים.

זה היה ליל שלישי, ואני בהיתי ב-stack trace חסר כל היגיון.

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

הבאג לא היה ב-Java. ה-Java הייתה מושלמת מבחינה תחבירית. הבאג היה במה שה-AI מעולם לא ראה.

משתנה בשם TRN-LIMIT — שהוגדר לא בקובץ המקור שה-AI תרגם, אלא ב-COPYBOOK שנכלל אלפי שורות קודם לכן בשרשרת הביצוע — הכיל REDEFINES פסוקית. זהו מבנה של COBOL שבו אותה כתובת זיכרון מתפרשת כשני טיפוסי נתונים שונים בהתאם לדגל שנקבע במודול אחר לחלוטין. ה-AI ראה את TRN-LIMIT כשדה מספרי פשוט. הוא לא היה כזה. הוא היה packed decimal שהתחזה למספר שלם בהתאם להקשר זמן-הריצה. ה-AI ייצר הזיה של הגדרה סטנדרטית, ואפליקציית ה-Java כתבה נתונים בינאריים משובשים לתוך עמודה במסד הנתונים.

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

בעיית ה-1.52 טריליון דולר שאיש לא רוצה לדבר עליה

הנה המציאות הלא-נוחה של הכלכלה הגלובלית ב-2025: 43% ממערכות הבנקאות עדיין רצות על COBOL, ומערכות אלו מעבדות 95% מכלל עסקאות הכספומט. התוכנה שמפעילה את חברות ה-Fortune 500? כ-70% ממנה נכתבה לפני יותר משני עשורים. החוב הטכני בארה"ב לבדה תפח לסכום מוערך של 1.52 טריליון דולר.

והאנשים שכתבו את הקוד הזה פורשים. לא "אולי יפרשו יום אחד" — הם עוזבים עכשיו, ולוקחים איתם עשרות שנים של ידע ארגוני. בינתיים, 80% מתקציבי ה-IT הפדרליים מוקדשים להשארת מערכות מדור קודם בחיים, ומותירים בקושי 20% לכל דבר חדש.

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

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

למה כולם חשבו ש-GPT יכול לתקן את זה?

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

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

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

הבעיה היא ארכיטקטונית, והיא מסתכמת באופן שבו מודלי שפה גדולים מעבדים מידע. מודלי שפה גדולים (LLM) משתמשים במנגנון קשב כדי לשקלל את חשיבותם של חלקים שונים בקלט שלהם. מודלים מודרניים מתהדרים בחלונות הקשר של עד מיליון טוקנים. אך מחקרים הדגימו תופעה הקרויה אפקט "אבודים באמצע" (Lost in the Middle): מודלי שפה גדולים מציגים עקומת ביצועים בצורת U, הם משחזרים היטב מידע בתחילת ה-prompt ובסופו, אך מדרדרים משמעותית בכל מה שנמצא באמצע.

בפרויקט מודרניזציה, תוכנית COBOL אחת יכולה להשתרע על פני אלפי שורות, ולהפנות ל-copybooks שהם עצמם באורך אלפי שורות. אם ההגדרה של MAX-TRANSACTION-LIMIT יושבת באמצע ההקשר העצום הזה, סביר סטטיסטית שה-AI יחמיץ אותה. וכשהוא מחמיץ משהו, הוא לא עוצר ושואל. הוא הוזה. הוא ממציא הגדרה מסתברת וממשיך הלאה.

מה קורה כשמתייחסים לקוד כמו לטקסט?

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

פתחתי תוכנית COBOL במחשב הנייד שלי. "מצא לי את ההגדרה של ACCOUNT-BALANCE," אמרתי.

הוא חיפש בקובץ. לא הצליח למצוא. משום שזה לא היה בקובץ הזה. זה היה ב-copybook, שנכלל באמצעות הצהרה בשורה 47, שבעצמה הפנתה ל-data division משותף שמתוחזק על ידי צוות אחר לגמרי.

"עכשיו דמיין שאתה LLM," אמרתי. "אתה מבצע חיפוש דמיון וקטורי אחר קוד הקשור ל'עיבוד תשלומים'. תמצא חמישה chunks שמזכירים את המילה 'תשלום'. תחמיץ לחלוטין את הקובץ בשם GlobalVarDef.cbl שמגדיר את שיעור המס שבו משתמשת לוגיקת התשלום — משום שהקובץ הזה מעולם אינו מזכיר את המילה 'תשלום' בשום מקום."

טכניקת Retrieval-Augmented Generation סטנדרטית, או RAG — הטכניקה שבה משתמשים רוב כלי ה-AI לכתיבת קוד כדי להוסיף ידע ל-LLM — מאחזרת הקשר על בסיס דמיון טקסטואלי. היא ממירה קוד לווקטורים ומוצאת ווקטורים דומים. זה עובד להפליא עבור צ'אטבוטים של שאלות נפוצות. זה בלתי מספק באופן קטסטרופלי עבור קוד.

קוד אינו שפה טבעית. "החתול ישב על המחצלת" אומר פחות או יותר אותו דבר בלי קשר למה שקראת לפני חמישים עמודים. אבל x = y + 1 אינו אומר כלום אלא אם כן אתה יודע את ההגדרות, הטיפוסים, והמצבים הנוכחיים של x ו-y — שאולי מוגדרים בקובץ אחר, במודול אחר, או עוברים בירושה ממחלקת אב.

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

הלילה שבו הפסקנו לבנות עטיפה טובה יותר

היה רגע — אני זוכר אותו בבירור — שבו הצוות שלי התלבט על הארכיטקטורה שלנו. היו לנו שני מסלולים. מסלול ראשון: לבנות pipeline חכם יותר של RAG. chunking טוב יותר, embeddings טובים יותר, prompts טובים יותר. לשכלל את גישת העטיפה עד שתעבוד מספיק טוב. מסלול שני: לזרוק לחלוטין את הפרדיגמה מבוססת-הטקסט ולהתייחס לקוד כפי שהוא באמת — מערכת יחסים לוגית.

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

המהנדסת הראשית שלי ניגשה ללוח מחיק ושרטטה תוכנית COBOL כגרף. צמתים עבור משתנים, פונקציות, copybooks, וטבלאות מסד נתונים. קשתות עבור CALLS, READS, UPDATES_TABLE, IMPORTS_COPYBOOK. ואז היא עקבה אחר שרשרת תלויות: מודול A קורא למודול B, שמשנה את משתנה X, שנקרא על ידי מודול C בתיקייה שונה לחלוטין.

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

אף אחד לא הצליח.

זה היה הלילה שבו התחייבנו לבנות את מה שאנחנו מכנים כיום גרף ידע מודע-מאגר (Repository-Aware Knowledge Graph) — מסד נתונים גרפי מאוחד המשלב את המבנה הסטטי של הקוד (עצי תחביר מופשטים, גרפי קריאה) עם המשמעות הסמנטית של לוגיקה עסקית (תיעוד, הערות, כוונת המשתנים). לא התכוונו לבנות מתרגם טוב יותר. התכוונו לבנות מפה.

איך הופכים שלושים שנות COBOL למפה?

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

ראשית, אנחנו מנתחים קוד מבנית, לא טקסטואלית. צינורות RAG סטנדרטיים משתמשים ב"פיצול נאיבי" — הם חותכים קובץ כל 500 טוקנים, ולעיתים קרובות מנתקים חתימת פונקציה מגופה. אנחנו משתמשים במנתחים כמו Tree-sitter כדי לייצר עצי תחביר מופשטים, המכבדים את הגבולות הלוגיים של הקוד. פונקציה נחשבת ליחידת לוגיקה שלמה, לא למקטע טקסט אקראי.

שנית, אנחנו מחלצים ישויות וקשרים. מחלקות, פסקאות, משתנים, טבלאות מסד נתונים, נקודות קצה של API — אלה הופכים לצמתים. הקשתות ביניהם — CALLS, UPDATES_TABLE, DEFINES_VARIABLE — הופכות לרקמת החיבור. כעת נוכל לתשאל את הגרף: "הראה לי כל פסקה שמעדכנת את CUSTOMER-ID שדה." תוצאות מדויקות, מיד. נסה לעשות זאת עם grep.

שלישית — וכאן זה נעשה מעניין — אנחנו מפענחים סמלים על פני המאגר כולו. מנתח סטנדרטי רואה ACCT-NUM בקובץ A ו-ACCT-NUM בקובץ B כשתי מחרוזות שונות. המערכת שלנו קובעת ששניהם מפנים לאותה רשומה ב-copybook משותף וממזגת אותם לצומת יחיד. אנחנו גם ממזגים תיעוד עם קוד: אם מסמך דרישות PDF מתאר את "User API" והקוד מכיל מחלקה בשם UserAPI, המערכת מקשרת כוונה עם מימוש.

רביעית, אנחנו מחשבים סגור טרנזיטיבי. זוכר את כשל הבנק? A תלוי ב-B, B תלוי ב-C, וה-AI ראה את A אך החמיץ את C. הגרף שלנו עובר לעומק — מ-A ל-B ל-C — כדי לזהות את הגדרת השורש של כל משתנה. כשה-AI מייצר קוד עבור מודול A, הוא מייבא את ההגדרות הנכונות ממודול C, גם אם מודול C נמצא בתיקייה או במאגר אחר לגמרי.

מדוע RAG סטנדרטי נכשל במיגרציית קוד?

אנשים תמיד מתנגדים לזה. "RAG עובד מצוין עבור קוד," הם יאמרו. "פשוט השתמש ב-embeddings טובים יותר."

תן לי לתת לך שלושה תרחישים שבהם חיפוש דמיון וקטורי מתמוטט לחלוטין:

מפתח משנה את שם Account ל-Acct. הדמיון הסמנטי יורד, למרות שהלוגיקה זהה. פונקציה בשם FNC-001 מבצעת חישוב ריבית אך אינה מכילה הערות — חיפוש אחר "חישוב ריבית" לעולם לא ימצא אותה. והכשל הנפוץ ביותר: RAG וקטורי מאחזר בדיקת יחידה והערת UI שמזכירות "תשלום", אך מחמיץ את לוגיקת הליבה העסקית משום ששמות המשתנים אינם תואמים למונחי השאילתה.

אחזור מבוסס-גרף אינו שואל "איזה טקסט נראה דומה?" הוא שואל "מה מחובר לוגית?" — וההבחנה הזו היא ההבדל בין קוד שמתקמפל לבין קוד שעובד.

מה שאנחנו מכנים GraphRAG פועל על מבנה, לא על דמיון. כשמישהו מבקש "בצע refactor ללוגיקת התשלום," המערכת משתמשת בחיפוש וקטורי כדי למצוא את נקודת הכניסה — למשל, את ProcessPayment — פסקת הקוד. אך אז, במקום לעצור, הוא עובר לאורך קשתות הגרף. הוא מושך פנימה את שגרות המשנה דרך CALLS קשתות, את הגדרות המשתנים דרך READS קשתות, את ה-copybooks דרך INCLUDES קשתות. חלקים מחוברים אלה עשויים להיות שונים טקסטואלית אך אינם ניתנים להפרדה לוגית.

מחקרים מראים ש-GraphRAG עולה משמעותית על RAG וקטורי בהיסק רב-קפיצות (multi-hop) — קישור עובדות המופרדות בכמה צעדים. בתוכנה, כמעט כל באג רציני הוא כשל של היסק רב-קפיצות. אם אשנה את לוגיקת שיעור הריבית במודול A, אילו מסכי דיווח במודול Z יישברו? RAG וקטורי אינו יכול לענות על כך. הגרף יכול, משום שהוא עובר לאורך שרשרת קריאות הפונקציה שמקשרת ביניהן.

בעיית ה-GOTO (או: מדוע COBOL גורם ל-AI להזות לולאות)

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

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

צפינו בשלושה כלי AI מסחריים שונים מנסים לתרגם מודול COBOL עם GOTO בשימוש כבד. אחד ייצר קריאת פונקציה רקורסיבית שהייתה גורמת ל-StackOverflowError בסביבת הייצור. אחר ייצר while(true) לולאה ללא תנאי יציאה. השלישי — האהוב עליי אישית — פשוט המציא זרימת בקרה שלא הייתה קיימת בקוד המקורי. היא נראתה מסתברת. היא הייתה שגויה לחלוטין.

הגישה שלנו: למפות את ה-GOTO — את היעדים שלו — כקשתות בגרף בקרת זרימה. לאחר מכן להשתמש בזיהוי תבניות על הגרף. GOTO שקופץ בחזרה לתווית מוקדמת יותר? זו לולאה. GOTO שמדלג על בלוק? זהו תנאי. GOTO לפסקת יציאה? זו הצהרת return. ה-AI, מונחה על ידי מבנה הגרף, מבצע refactor לקפיצות אלו ל-while לולאות, if/else בלוקים, או break/continue הצהרות.

בלי הגרף, ה-AI מנחש. עם הגרף, הוא מהנדס.

ההבדל בין צ'אטבוט לבין סוכן

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

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

מה שאנחנו פורסים הם סוכנים אוטונומיים שמתכננים, מבצעים, ומתקנים את עצמם. הסוכן מנתח את ה-AST של קובץ ה-COBOL היעד, מזהה תלויות, מתשאל את גרף הידע, מייצר קוד Java, ואז מקמפל אותו ב-sandbox. אם המהדר זורק שגיאה — "variable not found" — הסוכן קורא את השגיאה, מתשאל את הגרף עבור התלות החסרה, ומייצר מחדש. לאחר מכן הוא מריץ בדיקות יחידה הנגזרות מעקבות הביצוע המקוריים של COBOL כדי לאמת שקילות התנהגותית.

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

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

ומה בנוגע לקוד מת?

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

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

"האם חלונות הקשר גדולים יותר לא יפתרו את זה?"

אני עדיין מקבל את השאלה הזו כל הזמן. ההנחה היא שאם GPT-5 או Claude 4 יכולים להתמודד עם עשרה מיליון טוקנים, בעיית ה"אבודים באמצע" נעלמת.

היא לא תיעלם. והנה מדוע.

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

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

המפה היא הנכס

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

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

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

קוד אינו טקסט

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

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

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

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

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