מערכות גורמות לגאונות לזרוח יותר תמונה: נוצרה באמצעות AI

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

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

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

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

ההיסטוריה של שחרור דרך מבנה

ב-1935, מפציץ ה-B-17 של Boeing התרסק בטיסת מבחן. לא מפני שהטייס היה חסר יכולת. המטוס הפך מורכב מדי מכדי שאדם אחד יוכל לשמור על כל הנהלים בזיכרון. הפתרון לא היה למצוא טייס מוכשר יותר, אלא ליצור רשימת בדיקה. לאחר מכן, ה-B-17 טס 1.8 מיליון מייל ללא תאונה אחת.

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

מערכת הייצור של Toyota (TPS) פועלת על אותו מבנה. משכו את חבל ה-andon והקו נעצר. לא יוצאת מכונית אחת עד שהבעיה נפתרת. הוראות עבודה תקניות (SOP) יוצרות איכות חוזרת. אבל הכוח האמיתי של TPS אינו ה-SOP עצמם. מפני שה-SOP סופג שונות בתפעול יומיומי, מהנדסים יכולים להקדיש זמן ל-kaizen, שיפור יסודי. כשמבנה לוקח על עצמו את החזרתיות, אנשים מתמקדים בשיפור.

מחקרו של אטול גוואנדה הביא זאת לחדר הניתוח. בבתי חולים שאימצו את רשימת הבדיקה של WHO לבטיחות כירורגית, סיבוכים ירדו ב-36% ותמותה ירדה ב-47%. רשימת הבדיקה היא דף נייר אחד עם 19 סעיפים. היא לא שיפרה את מיומנות המנתח. היא העבירה עומסים קוגניטיביים כמו ״לא לשכוח גזה״ אל המערכת, ואיפשרה למנתחים להתרכז בשיפוטים קשים באמת: תגובה מיידית לדימום בלתי צפוי, עיצוב מחדש בזמן אמת של גישת הניתוח.

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

אותו עיקרון חל על AI

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

תנו למודל החזק ביותר מבנה אפסי ואמרו לו ״בנה לי אפליקציה.״ מה קורה? 100 השורות הראשונות נקיות. אחרי 500 שורות הוא שוכח ממשקים שיצר. ב-1,000 שורות, כללים שנקבעו קודם מופרים מאוחר יותר. כשה-endpoints עוברים 30, סכמות DB ומפרטי API מתחילים לסטות בשקט זה מזה.

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

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

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

43 דקות, 32 endpoints, אפס באגים

יש הוכחה. מדד ZenFlow.

Claude Sonnet 4.6, לא המודל מהשורה הראשונה (Opus) אלא מדרג בינוני, בנה אפליקציה מקצה לקצה בתוך מבנה ה-SSOT של yongol.

תוצאות:

  • 32 endpoints, 9 טבלאות DB, 9 קובצי שאילתות, 37 בדיקות Hurl, הכול עבר
  • בערך 43 דקות
  • באגים בקוד שנוצר: 0

המודל לא נמנע מכל הטעויות. היו 4 שגיאות (BUG-077~080). מה שחשוב הוא ש-4 מתוכן סווגו כ״שגיאות כתיבת SSOT.״ לא באגי מחולל קוד: הסוכן כתב את המפרט בצורה שגויה. והמערכת תפסה את זה. validate דיווח על כשלונות, הסוכן תיקן את המפרטים, הריץ מחדש, ועבר.

כ-16 מתוך 43 הדקות הוקדשו ללולאת validate זו. זה הזמן שבו המערכת לימדה את הסוכן.

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

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

שלושה גלגלי שיניים

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

1. SSOT: מה לבנות

Single Source of Truth. ב-yongol, 9 קובצי מפרט דקלרטיביים ממלאים תפקיד זה. OpenAPI מגדיר endpoints, DDL מגדיר טבלאות, Rego מגדיר הרשאות. המפתח הוא ש-9 הקבצים משורשרים דרך מזהה יחיד: operationId. עבור endpoint נתון, מפרט ה-API, שאילתת ה-DB, הבדיקה וכלל ההרשאה קשורים כולם לאותו מפתח.

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

2. Codegen: כיצד לבנות

קוד נוצר מה-SSOT. הסוכן לא כותב קוד בחופשיות; הוא כותב קוד הנגזר מהמפרט. drift מדוכא מבחינה מבנית. מה שאינו במפרט לא ניתן ליצור; מה שבמפרט לא ניתן להשמיט.

מה ש-Codegen לוקח על עצמו: חזרתיות. כתיבת boilerplate ל-32 endpoints אחד אחד אינה עבודה לגאונות. המבנה עושה זאת.

3. Gate: האם נבנה נכון?

אימות דטרמיניסטי. validate בודק עקביות על פני כל 9 המפרטים. אם operationId קיים ב-OpenAPI אך לא בבדיקות Hurl, כשלון. אם עמודה קיימת ב-DDL אך אינה מוזכרת בשאילתות sqlc, אזהרה. דבר אינו עובר לשלב הבא מבלי לעבור.

מה ש-Gate לוקח על עצמו: בדיקה. בדיקת עקביות על פני 32 endpoints בעין היא כמו טייס B-17 שמנסה לזכור נהלים מהראש. מדידות קובעות את הקבלה.

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

כשגאונות זורחת

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

מי שכתב את המדריך של McDonald’s לא היה עובד. האדם שעיצב מתכונים, פירק תהליכים והחליט היכן להציב בדיקות היה מומחה. אותו דבר נכון לגבי חבל ה-andon של Toyota. תובנתו של טאאיצ׳י אונו הגדירה את התנאים לעצירת הקו. מערכות מטפלות בביצוע, לא בעיצוב. עיצוב הוא תחום הגאונות. מפני שמבנה הסיר את נטל הביצוע, גאונות יכולה להתמסר לעיצוב בלבד.

אותו דבר נכון ב-AI. כתיבת ה-SSOT של yongol (שיפוט אילו endpoints נחוצים, עיצוב יחסי טבלאות, החלטה על מודל ההרשאה) דורשת היסק עמוק. החקירה לפני שמבנה מתבסס, שיפוטים ארכיטקטוניים ללא תקדים, השאלה ״כיצד לפרק בעיה זו?״ אף אחד מאלה אינו מתאים לתוך מבנה. כאן מודל חזק מצדיק את עלותו.

אז בפועל, אני מחלק מודלים בין תפקידים. עיצוב ושיפוט הולכים ל-Opus; ביצוע בתוך מבנה הולך ל-Sonnet. תבנית המודל הכפול הזו היא המימוש הישיר ביותר של ״מערכות גורמות לגאונות לזרוח.״ Opus לא שורף tokens על שמות שדות או boilerplate. המבנה מטפל בזה. Opus מתמקד אך ורק בהחלטות ארכיטקטוניות, פירוק דומיין, שיפוט מקרי קצה, עבודה שרק Opus יכול לעשות.

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

לא חיסכון במודלים יקרים: שימוש נכון בהם

הסתכלו על התמחור.

מחיר token הפלט של Claude Sonnet הוא $15/M-token. Opus הוא $75/M-token. הפרש פי 5. ללא מבנה, הקצאת כל הצינור ל-Opus פירושה שרוב יכולת ה-Opus הולכת לייצור boilerplate ועקביות שמות שדות. כמו לשלם לאדריכל $75 לשעה כדי לסחוב לבנים.

עם מבנה הסיפור משתנה. ביצוע (יצירת קוד, שמירת עקביות, מעבר בדיקות) מטופל על ידי Sonnet בתוך המבנה. כפי שהוכח ZenFlow, באיכות שעוברת gates ב-100%. Opus מוקצה רק לעיצוב ושיפוט. אותו תקציב מרכז את תשומת ה-Opus בצפיפות פי 5.

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

שאלות פתוחות

להיות הוגן, כמה דברים עדיין לא הוכחו.

ZenFlow הוא מדד אחד. 32 endpoints הוא קנה מידה בינוני בפרקטיקה ייצורית. האם אותה תבנית מחזיקה ב-200 endpoints עדיין נאמת. יש מדידות המראות את דחיסת ההקשר של yongol בכ-10x, אבל האם זה מתרחב לינארית למאות endpoints דורש נתונים נוספים.

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

אך התבנית המרכזית מחזיקה.

כפל

״כמה חכם ה-AI שלך?״ היא רק חצי שאלה.

החצי השני הוא זה: ״לאן המבנה שלך מרכז את האינטליגנציה הזו?״

כש-B-17 לא היה לו רשימת בדיקה, אפילו הטייסים הטובים ביותר התרסקו. אחרי רשימת הבדיקה, טייסים ממוצעים טסו 1.8 מיליון מייל ללא תקרית, וטייסים יוצאי דופן קיבלו מרחב להתמודד עם אתגרים שלא היו קיימים קודם. אילו Toyota אמרה ״גייסו מהנדסים טובים יותר״ במקום ליישם את חבל ה-andon, ייצור רזה לעולם לא היה קיים. מפני שחבל ה-andon היה שם, מהנדסים יכלו להתמקד ב-kaizen.

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

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

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

מאמרים קשורים

לקריאה נוספת (חיצוני)

מקורות

  • Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
  • Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
  • Haynes, A. B., et al. (2009). “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population.” New England Journal of Medicine, 360(5), 491-499.
  • World Health Organization. (2009). WHO Surgical Safety Checklist. WHO Patient Safety.
  • מקרה רשימת הבדיקה של B-17: Schamel, J. (2012). “How the Pilot’s Checklist Came About.” Flight Safety Australia Magazine.

יומן שינויים

  • 2026-06-25: פרסום ראשון