קיר שלושת החודשים


אתם בונים SaaS עם vibe coding. ההתחלה מהירה. “בנה התחברות” — 30 שניות. “הוסף תשלומים” — 2 דקות. MVP יוצא לשוק תוך שלושה שבועות.

שלושה חודשים אחר כך, דברים מוזרים קורים. ה-AI “מסדר” את לוגיקת התשלום ומשנה בשקט את חישובי ההנחות. הוספת endpoint חדש שוברת את ההזדהות הקיימת. בקשת refactoring משנה שמות שדות ב-API הציבורי, והורגת כל לקוח.

זה נקרא logic drift — AI משנה בלי כוונה לוגיקה עסקית קיימת. באגי רגרסיה קיימים גם בפיתוח מסורתי. אבל logic drift שונה. שינויים שהמפתח מעולם לא התכוון אליהם קורים באופן בלתי נראה, לאורך כל ה-codebase. כל prompt מתחיל בחלון הקשר חדש.


Drift במספרים

זה לא תחושה. יש נתונים.

מהירות עולה במורכבות. צוות מחקר מ-Carnegie Mellon השווה 807 מאגרי GitHub לפני ואחרי אימוץ Cursor (MSR 2026). תוספות קוד עלו פי 3–5 בחודש הראשון. אחרי חודשיים, יתרון המהירות נעלם. מה שנשאר: אזהרות ניתוח סטטי עלו ב-30%, מורכבות הקוד עלתה ב-41% — לצמיתות.

לא נהיה מהיר יותר — נהיה איטי יותר. ארגון המחקר הלא-מסחרי METR ערך ניסוי מבוקר אקראי עם 16 מפתחי open-source מנוסים (2025). בפרויקטים שהם כבר הכירו היטב, הקבוצה שהשתמשה בכלי AI לקחה 19% יותר זמן להשלמת משימות. ובכל זאת, המפתחים עצמם חשו האצה של 20%. פער של 39 נקודות אחוז בין תפיסה למציאות. בפרויקטים חדשים התוצאות עשויות להיות שונות, אבל ההנחה “AI = תמיד מהיר יותר” נשברה.

בקנה מידה גדול, היציבות קורסת. לפי Google DORA Report (2025), כל עלייה של 25% באימוץ AI מתואמת עם ירידה של 7.2% ביציבות אספקת התוכנה.

והיא אכן קרסה. Amazon חייבה שימוש בכלי קידוד AI בכל החברה ב-2025 ופרסה 21,000 סוכני AI. באותה תקופה, כ-30,000 עובדים פוטרו, מה שצמצם דרסטית את יכולת הסקירה. השילוב של ייצור קוד מהיר על ידי AI וצוות סקירה מצומצם הוביל ל-4 תקריות Sev-1 ב-90 יום. ב-5 במרץ 2026, השבתה של 6 שעות גרמה לאובדן מוערך של 6.3 מיליון הזמנות. מסמכים פנימיים קבעו: “ייצור הקוד המהיר של GenAI חושף בלי כוונה פגיעויות, והאמצעים הנוכחיים אינם מספקים כלל.”


“תעשה TDD” זו לא התשובה

העצה הנפוצה ל-drift ב-vibe coding היא “תכתוב טסטים”. הכיוון נכון, אבל איך אתם מספקים את הטסטים קובע את התוצאה.

מחקר TDAD (arxiv 2026) בדק את זה במדויק. Qwen3-Coder 30B קיבל 100 מקרים מ-SWE-bench Verified.

תנאישיעור רגרסיה
בסיס (ללא הוראות טסטים)6.08%
הוראה פרוצדורלית “תעשה TDD”9.94% (גרוע יותר)
קבצי טסט מושפעים סופקו בהקשר1.82% (הפחתה של 70%)

לומר לסוכן “תעשה TDD” מחמיר את המצב. הסוכן סוטה מהמשימה המקורית בניסיון לעקוב אחר הוראות פרוצדורליות. אבל לספק “קבצי הטסט האלה חייבים לעבור” כהקשר קונקרטי מפחית רגרסיות ב-70%.

ההבדל ברור. לא הוראות “איך לבדוק”, אלא חוזים “מה חייב לעבור”.


Hurl: חוזים ב-plain text

Hurl הוא כלי בדיקה שמצהיר בקשות HTTP ותגובות צפויות ב-plain text. מתוחזק על ידי Orange (France Télécom), בינארי Rust ללא תלויות ריצה, 18.7k כוכבים ב-GitHub. מהיר מספיק לרוץ על כל commit ב-CI.

# Login succeeds
POST http://localhost:8080/api/auth/login
{
  "email": "test@example.com",
  "password": "secret123"
}
HTTP 200
[Asserts]
jsonpath "$.token" exists
jsonpath "$.user.email" == "test@example.com"

# Unauthenticated access returns 401
GET http://localhost:8080/api/pages
HTTP 401

שני חוזים. התחברות חייבת להחזיר 200 עם token. גישה ללא הזדהות חייבת להחזיר 401.

כשהקובץ הזה מועלה ל-git ורץ על כל commit ב-CI — ברגע שה-AI “מסדר” את לוגיקת ההזדהות ו-401 הופך ל-200, ה-commit נדחה. Drift נתפס לפני שהוא מגיע לפרודקשן.


למה Hurl

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

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

טסטים יחידתייםHurl
מאמתפנים הפונקציהחוזה HTTP
ב-refactoring של AIמשתנים יחדללא שינוי
זיהוי driftמותנה (אם נעולים)טבעי
תלות במבנה הקודגבוההאין
קריאות אנושיתרמת קודPlain text
יצירה על ידי LLMדורש הבנת מבנה הקודרק HTTP מספיק

מה ש-Hurl מאמת זה לא קוד אלא התנהגות. קוד יכול להשתנות חופשית על ידי AI. התנהגות לא חייבת להשתנות. ההבחנה הזו היא המפתח לזיהוי drift.


נעילת ratchet

כש-Hurl טסטים עוברים, נעלו אותם. זה ה-ratchet.

1. Write Hurl tests for current API (or auto-extract)
2. Run on every commit in CI
3. Passing tests cannot be deleted or modified
4. New features require new Hurl tests
5. All existing + all new tests must pass to merge

אמרו לסוכן “עשה refactor לקוד הזה” והוא משנה את הקוד בחופשיות. אבל אם Hurl טסטים נשברים, ה-commit נדחה. הסוכן חייב לשמר את כל ההתנהגות הקיימת בזמן ה-refactoring. Drift במקרי קצה שלא מכוסים על ידי Hurl עדיין אפשרי, אבל עבור התנהגות מכוסה, drift מדוכא מבנית.

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


עובד גם על legacy

כבר מריצים תוכנה שנבנתה ב-vibe coding בפרודקשן? אין צורך להתחיל מאפס.

שלב 1: תעדו את ההתנהגות הנוכחית ב-Hurl.

אם יש תיעוד API, תרגמו אותו ישירות ל-Hurl. אם אין, בקשו מסוכן לקרוא את הקוד הקיים ולכתוב Hurl טסטים. המטרה היא להצהיר “ככה זה עובד עכשיו” ב-plain text לכל endpoint.

שלב 2: חברו ל-CI.

וודאו שכל Hurl טסטים עוברים והוסיפו אותם כתנאי merge.

שלב 3: עכשיו אתם בטוחים.

בין אם AI עושה refactor או מוסיף פיצ’רים, Hurl מגן על ההתנהגות הקיימת. אם drift קורה, CI תופס אותו מיד.

לא עבודות יסוד — חיזוק סיסמי. לחזק את הבניין בלי לסגור את החנות.


לא סוף ה-vibe coding — האבולוציה שלו

Andrej Karpathy, שטבע את המונח “vibe coding”, הכריז בדיוק שנה אחר כך, בפברואר 2026, ש"עידן ה-vibe coding נגמר". הפרדיגמה החדשה היא agentic engineering — בני אדם לא כותבים קוד, הם מתזמרים סוכנים שמתכננים, מממשים ובודקים באופן אוטונומי.

Thoughtworks Technology Radar (2025) מיקם את Spec-Driven Development ברמת “Assess”. הצוות של Martin Fowler פרסם ניתוח כלי SDD. התעשייה מתכנסת לאותו כיוון.

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

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


קישורים


References