לבנות מערכות שסוכנים יכולים לתפעל

Image generated by Google Gemini

אם סוכן AI שבר לכם את האפליקציה במהלך refactoring, אם אתם רוצים להפוך מערכות legacy לסביבה שבה AI יכול לעבוד, אם אתם רוצים להפוך את תקציבי תחזוקת ה-legacy של Fortune 500 לתקציבי טרנספורמציה – המאמר הזה הוא מפת הדרכים.

זיכרון נעול

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

הזיכרונות האלה היו נעולים. לא ניתנים לחיפוש, לא ניתנים לאימות, לא ניתנים להגעה (unreachable). השיטה היחידה: בן אדם קורא בעצמו, מבין בעצמו, מתקן בעצמו. לכן 60 עד 80 אחוז מתקציבי ה-IT של Fortune 500 הולכים על תחזוקת הזיכרון הנעול הזה. אי אפשר לפתוח, אז רק שומרים.

כרגע אנחנו באמצע מה שנקרא בועת ה-AI. המשמעות האמיתית של התקופה הזו היא לא שהמודלים נעשים חכמים יותר. אלא שזיכרונות legacy ישנים של חברות מתחילים להפוך לנגישים (reachable).

אבל עדיין לא. ב-2026, סוכני AI כותבים קוד. 68 דקות, מיליוני tokens נשרפו, ה-refactoring הסתיים. האפליקציה שבורה לגמרי. סיפור שעולה כל יום ב-X.

למה זה חוזר על עצמו?

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

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

מה זה Agent-Operable

כדי שסוכן יעבוד באופן אוטונומי, נדרשים שלושה תנאים:

1. חייב להיות אפשר לקרוא — בלי רעש

בקובץ של 2,000 שורות, כדי למצוא פונקציה אחת, 1,950 שורות הן רעש. במסד נתונים לא מנורמל, למצוא מידע על לקוח דורש join של שלוש טבלאות. כללים עסקיים מוסתרים בגיליונות Excel בלתי נגישים לסוכן.

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

2. חייב להיות אפשר לאמת — באופן מכני

אם אחרי שהסוכן שינה משהו אי אפשר לדעת מה נשבר, נכנסים ל-doom loop. לקוד צריך בדיקות, למסד נתונים צריך constraints, ל-API צריך schema validation, למפרטים צריך cross-validation.

LLM שמאמת LLM זה כמו לשאול חבר שיכור “אני שיכור?”. go test לא הוזה. CHECK constraints לא משקרים. JSON Schema לא סוחף.

3. המצב חייב להישמר — גם אם הסוכן מת

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

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

שלב 0: לפחלץ את הבאגים

שלושת התנאים הם היעד. נקודת ההתחלה שונה. אין תיעוד, אין בדיקות, 300 קבצים של 2,000 שורות כל אחד — זה ה-legacy שממנו מתחילים.

במצב הזה, אם אומרים לסוכן “תעשה refactoring”, מה קורה? הוא “מתקן” באג בן 10 שנים. הבעיה: הבאג הזה הוא לא באג.

Hyrum’s Law: לכל התנהגות נצפית של API ישן מספיק, מישהו תלוי בה. שגיאת עיגול שהתעלמו ממנה 10 שנים קשורה ללוגיקת תשלום של לקוח VIP. באג בפרסור תאריכים יצר מאקרו Excel שמחזיק את כל מחלקת הנהלת החשבונות. באגים ישנים הם מפרטים עסקיים מרומזים.

המשימה הראשונה של הסוכן היא לא לתקן קוד. אלא לפחלץ את ההתנהגות הנוכחית.

דוקרים את ה-API. מקליטים את התגובה. מקבעים אותה כבדיקת Hurl. באג מוזר או התנהגות מכוונת — לא מבדילים. מפחלצים כמו שזה. זה השן הראשון של ה-ratchet — נועלים כדי שהסוכן לא “ישפר” לפי ראות עיניו.

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

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

לא רק קוד

“Agent-operable codebase” היא נקודת ההתחלה. הנכסים הדיגיטליים של חברה לא מסתכמים בקוד.

כל אחד בנפרד זה “צריך לסדר יותר טוב”. ביחד זה מערכת.

Symbolic Feedback Loop

מבנה משותף מאפשר את המעבר הזה.

LLM מייצר -> כלי דטרמיניסטי שופט -> התוצאה חוזרת ל-LLM -> חוזרים

בקוד, בבדיקות, במפרטים, בנתונים — אותה לולאה עובדת:

מבנה קוד:        filefunc validate -> משוב הפרה -> תיקון LLM -> חזרה
בדיקות:          go test + coverage -> שורות לא מכוסות -> חיזוק LLM -> חזרה
עקביות מפרטים:   yongol check -> משוב drift -> תיקון LLM -> חזרה
כללי משתמש:      rulecat evaluate -> משוב הפרה -> תיקון LLM -> חזרה

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

זו לא המצאה. C. elegans משקיע 60 מתוך 302 הנוירונים שלו (20%) בתפיסה. לא ייצור — אימות. זו המסקנה של 500 מיליון שנות אבולוציה: לשפר את איכות המשוב עדיף להישרדות מאשר להגדיל את מספר הנוירונים.

התעשייה מאיצה את הרכבת (המודל). מודלים גדולים יותר, סוכנים חכמים יותר, prompts טובים יותר. אבל ככל שהרכבת מהירה יותר, המסילות חשובות יותר.

80/20

במצב הסופי, המערכת מתחלקת לשתי שכבות.

SSOT (80~90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── מיוצר מהמפרט. drift חסום במקור. הסוכן יכול לשנות בחופשיות.

Custom (10~20%)
├── כללים עסקיים, לוגיקת domain, חישובים משפטיים/מדיניותיים
└── מובנה ב-filefunc, בדיקות מובטחות ב-tsma. בדיקה אנושית.

הקוד שבאמת דורש תשומת לב אנושית דחוס ל-10-20%. את השאר הסוכן מייצר מהמפרט, והמכונה מאמתת.

60% של Fortune 500

60 עד 80 אחוז מתקציבי ה-IT של Fortune 500 הולכים על תחזוקת legacy. 42% מזמן המפתחים נבלע בחוב טכני. 70% מהגירות legacy ידניות נכשלות.

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

מזינים את ה-legacy בשלמותו ומקבלים מערכת agent-operable. זו ההבטחה של Building Agent-Operable Systems.

למה Big Tech לא עושים את זה

Anthropic ו-OpenAI בונים מודלים כלליים. לשפר מודל ב-10% חל על כל הלקוחות. אבל לבנות feedback loop של Go test חל רק על מפתחי Go. לבנות כלי coverage ל-Python חל רק על פרויקטי Python.

אימות סימבולי הוא מטבעו ספציפי לתחום. כל שפה, כל framework, כל מפרט דורש מאמת שונה. אין אוניברסליות, ולכן אין ROI ל-Big Tech.

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

שאלות

הסוכן שלך כותב קוד. אבל מי בודק שהקוד נכון?

סוכן אחר? או go test?

ה-LLM שלך קורא באמת את כל 100,000 השורות?

או מעמיד פנים שהוא קורא?

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

Sources

• Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
• Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
• McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
• Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
• Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
• White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
• Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
• METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
• GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
• Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks