Reins Engineering — בינה מלאכותית עם מושכות Image: AI generated

סוס ללא מושכות

כלי קידוד AI הפכו מהירים. התחברות ב-30 שניות. תשלום ב-2 דקות. MVP נשלח בשלושה שבועות.

שלושה חודשים אחר כך, הכול קורס.

ה-AI “מסדר” את לוגיקת התשלום ומשנה חישובי הנחות. בקשת רפקטורינג משנה שמות שדות ב-API הציבורי. הוספת פיצ’ר חדש שוברת אימות. לפי מחקר של קרנגי מלון (MSR 2026), מורכבות הקוד עולה באופן קבוע ב-41% לאחר אימוץ כלי קידוד AI. דוח Google DORA Report (2025) מראה ירידה של 7.2% ביציבות ההפצה על כל עלייה של 25% באימוץ AI.

הבעיה היא לא ש-AI טיפש. הבעיה היא שאין מושכות.

רתמה היא גדר

התעשייה הגיבה עם “harness engineering”. לינטרים, פורמטרים, CI/CD, מבנה פרויקט, כללי קידוד. גדרות שמונעות מהסוכן לצאת החוצה.

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

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

Reins Engineering

Reins Engineering הוא גישה הנדסית שנותנת לסוכני AI חוזים דטרמיניסטיים וחוסמת התקדמות כשחוזים מופרים.

הוא מורכב משלושה מרכיבים:

1. משוב דטרמיניסטי

תנו לסוכן עובדות, לא דעות. לא “זה נראה מוזר” אלא “שורה 41: אי-התאמה בשם שדה, צפוי ‘user_id’, התקבל ‘userId’.” משוב ללא מרחב ל-sycophancy. לפי מחקר TDAD (arxiv 2026), הוראות פרוצדורליות “עשה TDD” מחמירות רגרסיות (6.08% → 9.94%), בעוד שמתן קבצי בדיקה ספציפיים בהקשר מפחית רגרסיות ב-70% (6.08% → 1.82%).

2. נעילת חוזים (Ratchet Pattern)

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

3. הפרדת החלטות מיישום

שלושה דברים מעורבים בקוד — החלטות משתמש, לוגיקה עסקית, פרטי יישום — מופרדים. החלטות חיות במפרטים הצהרתיים (OpenAPI, DDL, דיאגרמות מצב). היישום נוצר בחופשיות על ידי AI. ה-AI לא יכול לטעות ולהחליף החלטות בפרטים. הישרדות ההחלטות הופכת עצמאית מגודל המודל.

אבולוציה

Prompt Engineering      → אמור נכון וזה עובד
Context Engineering     → תן הקשר טוב וזה עובד
Harness Engineering     → הכל במבנה
Reins Engineering       → כוון עם מושכות

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

Reins Engineering הוא לא גדר — הוא מושכות. הוא לא מגביל את חופש הסוכן; הוא מבטיח שהסוכן מגיע ליעד.

80 : 20

Reins Engineering לא מכסה הכול. הוא יודע בדיוק מה הוא מכסה.

Deque Systems ניתחה כ-300,000 בעיות איכות נגישות ביותר מ-13,000 עמודים (2021). 57% היו ניתנים לאוטומציה מלאה, 23% דרשו סיוע AI, ו-20% רק בני אדם יכלו לשפוט. נגישות וקוד הם תחומים שונים, אך הם חולקים את אותו מבנה: “איזה חלק מכונות יכולות לשפוט?”

דרך עדשה זו, איכות קוד מתחלקת כך:

  • 57% — טריטוריה של הרצ’ט. להצהיר התנהגות, מכונות שופטות הפרות בלי לשאול. go test, Hurl, yongol check, filefunc validate.
  • 23% — טריטוריה של הרתמה. Linters, מעצבים, CI. המנגנון דטרמיניסטי, אך עומק האימות נשאר בשטח. לא תופסים נכונות התנהגותית, אך אוכפים מבנה וסגנון, ומעלים את איכות היצירה של AI.
  • 20% — טריטוריה אנושית. התאמה עסקית, UX, כיוון ארכיטקטוני.

Reins Engineering לא מחליף את הרתמה. הוא רוכב עליה.

רתמה (דטרמיניזם שטחי)     23%
+ רצ'ט (דטרמיניזם התנהגותי)   57%
──────────────────────
                          80%

בני אדם מתמקדים ב-20% הנותרים.

למה מודלים גדולים יותר הם לא התשובה

“GPT-6 יתקן את הכול.”

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

מודל מקומי של 4.5B פרמטרים (Gemma4) עם משוב דטרמיניסטי + הקשר דוגמאות עורך SSOT ללא שגיאות. מודל frontier שעורך קוד גולמי מייצר סחיפה. ההבדל הוא מבנה, לא אינטליגנציה.

אל תחליפו מודל. הוסיפו חוזה.

ראיות

yongol הוא המימוש של Reins Engineering. הוא מאמת צולב את העקביות של 10 מפרטים הצהרתיים (SSOT) עם 287 כללים ומייצר קוד.

בנצ’מרק ZenFlow — SaaS אוטומציית זרימות עבודה רב-דייר. 32 endpoints, 14 טבלאות, 47 בקשות Hurl. 11/11 שלבים עברו. הוספת פיצ’רים לא האטה את התהליך. בדיקות קיימות מעולם לא נשברו.

בקאנד עובד נוצר בהצלחה עם מודל מקומי של 4.5B פרמטרים. עלות: $0. אופליין. Reins מגשר על הפער שגודל המודל משאיר.

לא אוטומציית סקירה על ידי AI — אלא אוטומציית סקירה על ידי קוד

הגישה הרווחת בתעשייה היא אוטומציית סקירה על ידי AI. מודל שפה גדול אחד מייצר קוד, ומודל שפה גדול אחר סוקר אותו. שיכור שואל את חברו השיכור “אני שיכור?”. שיעור הכניעה ל-sycophancy של מודלי frontier הוא 58%. שיעור ה-false pass של LLM-as-Judge הוא 36%. הכפלת ייצור הסתברותי באימות הסתברותי מדרדרת את הדיוק.

Reins Engineering הוא אוטומציית סקירה על ידי קוד. LLM מייצר, קוד דטרמיניסטי מאמת. validate לא מחמיא. go test לא הוזה. מדידת כיסוי לא משקרת. pass זה pass ו-fail זה fail.

אוטומציית סקירה על ידי AI:    LLM → אימות LLM → חנופה → false pass → סחיפה
אוטומציית סקירה על ידי קוד:   LLM → אימות קוד → עובדות → pass/fail → התכנסות

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

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

רתמה ללא מושכות היא רק גדר

AI כבר חזק מספיק. מה שחסר זה כיוון.

בנו גדרות גבוהות יותר והסוכן יסחף מהר יותר בתוכן. תפסו מושכות והסוכן ירוץ ליעד.

Reins Engineering — אימות דטרמיניסטי מובנה לסוכני AI.

התכנסות עצמאית

5 פרויקטים שהתכנסו באופן עצמאי על אותו עיקרון:

  • episteme — מישור בקרה קוגניטיבי לסוכני AI מאת חוקר ב-UIUC. מכריח יצירת Reasoning Surface ברמת מערכת הקבצים לפני פעולות בלתי הפיכות. אותו עיקרון כמו ratchet, מימוש שונה.
  • MagLab — צנרת מחקר פיזיקה מאת חוקר ספינטרוניקה ב-KAIST. “LLMs only reason and plan. They do not compute numbers, fabricate citations, or generate figure data.” כלים דטרמיניסטיים מייצרים את כל הפלטים המספריים.
  • Manifesto — MEL להגדרה הצהרתית של מעברי מצב בצד הלקוח. “Agent proposes, World verifies.” הסוכן מציע רק כוונה; מעברי מצב מאומתים באופן דטרמיניסטי.
  • NEKOWORK — שער אבטחה שסורק הבדלי קוד AI עם כללים דטרמיניסטיים לפני מיזוג. עובד ללא קשר למקור. ה-LLM לא שופט.
  • oh-my-kamisama — מנצח רב-CLI שמתזמר את Claude, Codex ו-Gemini. הוא קורא את ה-git diff האמיתי במקום את הצהרות ה-workers («diffs beat claims»), ומכריז על השלמת המשימה רק לאחר שמבחני הפרויקט עוברים. כל הרצה נשמרת בדיסק כארטיפקט הניתן לביקורת — לא צ’אט שנעלם.

לסיכום: ייצור יכול להיות הסתברותי. אימות חייב להיות דטרמיניסטי.

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

References

  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Google Cloud (2025). DORA Report 2025. cloud.google.com
  • Wang, Z. et al. (2026). “TDAD: Test-Driven Agentic Development.” ACM AIWare 2026. arxiv.org/abs/2603.17973
  • Karpathy, A. (2026). “From Vibe Coding to Agentic Engineering.” thenewstack.io
  • Deque Systems (2021). “Automated Testing Study…” deque.com
  • Anthropic (2026). “Demystifying Evals for AI Agents.” anthropic.com

יומן שינויים

  • 2026-05-23: פרסום ראשוני
  • 2026-05-27: הוספת סעיף “התכנסות עצמאית” (episteme, MagLab, Manifesto, NEKOWORK)
  • 2026-05-28: סעיף “80 : 20” — רתמה (23%) + רצ’ט (57%) = 80%, נתונים אמפיריים של Deque
  • 2026-05-31: הוספת oh-my-kamisama להתכנסות העצמאית