Ends coding: הקוד לא נגמר, ההקלדה נגמרה

קוד לא נגמר. נגמרה ההקלדה.

כל חצי שנה מישהו מכריז שה-AI “מסיים את הקוד”, ends coding, ושעוד רגע לא נצטרך מפתחים. אנדריי קרפתי קרא לזה vibe coding בפברואר 2025, בציוץ אחד, וזה נדבק. בסקר של Stack Overflow ל-2025, 84% מהמפתחים אמרו שהם משתמשים בכלי AI או מתכננים להשתמש, לעומת 76% שנה קודם. ב-Vellum מנו ביולי 2026 עשרה coding agents רציניים, מ-Claude Code בטרמינל ועד OpenHands שמריצים על השרתים שלכם.

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

ולמי שחושב שזה עניין סמנטי: ביולי 2025 ה-agent של Replit מחק את ה-DB של production של ג’ייסון למקין מ-SaaStr, באמצע code freeze שלמקין הכריז עליו בצ’אט, באותיות גדולות. רשומות של יותר מ-1,200 מנהלים נעלמו, וה-agent עוד דיווח שהכל בסדר. הקוד שלו לא היה הבעיה. הבעיה הייתה שלא היה שום דבר מסביב.

בגדול, ככה זה נראה כשעובדים נכון עם agent. שישה צעדים.

01 · כותבים spec לפני שכותבים prompt

סרג’ן יוביץ’ כתב בספטמבר שב-vibe coding אתם “describe intent, not implementation”. נכון. אבל כוונה בצ’אט נמרחת על 40 הודעות ואף אחד לא זוכר מה סוכם. אז הכוונה הולכת לקובץ. קובץ קצר, בתוך ה-repo, שה-agent קורא בתחילת כל משימה. הדוגמה כאן היא בדיוק זו שיוביץ’ נותן, טופס שבודק אימייל ושומר אותו:

# משימה: אימות אימייל בטופס ההרשמה

## מה צריך לקרות
- אימייל לא תקין → הודעת שגיאה מתחת לשדה, בלי קריאה לשרת
- אימייל תקין → POST ל-/api/signup, תשובה 201, ניתוב ל-/welcome

<figure><img src="/posts/ends-coding/diagram.svg" alt="איך המנגנון עובד" loading="lazy" /><figcaption>איך המנגנון עובד</figcaption></figure>

## איך יודעים שסיימנו
- npm test ירוק, כולל tests/signup.test.ts
- אין שינוי בקבצים מחוץ ל-src/signup/

## לא לגעת
- tests/ (אסור לשנות טסטים קיימים)
- prisma/schema.prisma
- כל מה שתחת infra/

מה שרואים אחרי שבוע: ה-agent מפסיק לנחש. פחות “שיפרתי גם את ה-header כשהייתי שם”. וכשמשהו לא עובד, יש קובץ להצביע עליו ולא גלילה של שיחה.

02 · נותנים ל-agent מקום לשבור

ה-agent צריך להריץ קוד, להתקין חבילות, לטעות. תנו לו לעשות את זה במקום שלא כואב. הכי פשוט: git worktree נפרד לכל משימה, branch משלו, תיקייה משלו.

git worktree add ../wt-signup -b agent/signup
cd ../wt-signup
cp ../app/.env.example .env   # ערכי dev בלבד, אף פעם לא prod

ב-Inkling מגדירים sandbox כמקום שבו “the risky delete never reached real files”. זה כל הרעיון. ב-Replit ה-agent ישב באותה סביבה שיש בה גישה ל-production. אחרי התקרית אמג’ד מסעד, המנכ“ל, כתב שזה unacceptable והבטיח הפרדה אוטומטית בין DB של פיתוח ל-DB של production. תעשו את זה אצלכם לפני שתצטרכו לכתוב פוסט-מורטם.

03 · כותבים מה אסור, בקובץ ולא בבקשה

הלקח הכי חד מ-Replit: למקין כתב ל-agent לא לגעת. זה לא עזר. הוראה ב-prompt היא בקשה. הגדרה בקובץ היא אכיפה. בקלוד קוד זה נראה ככה:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git diff:*)",
      "Bash(git status)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push:*)",
      "Bash(rm -rf:*)",
      "Bash(psql:*)"
    ]
  }
}

מה שרואים: ניסיון לקרוא .env או לעשות push פשוט נחסם, וזה לא תלוי במצב הרוח של המודל באותו רגע. ב-Cursor וב-Windsurf יש מקבילה, רשימת פקודות מותרות לטרמינל. תבדקו אותה לפני שאתם מדליקים auto-run.

רגע, מה שהקובץ הזה לא עושה: deny על Bash הוא התאמת prefix. agent נחוש יעקוף אותו עם bash -c או עם סקריפט שהוא כתב בעצמו. אז הקובץ הוא קו ראשון. הקו האמיתי הוא שבסביבה של ה-agent אין credentials של production בכלל.

04 · הבדיקה קודם, ה-agent רץ אחריה

זה הצעד שהכי משנה. יוביץ’ מתאר agents שכותבים קוד, מריצים אותו ומתקנים טעויות “largely on their own”. זה עובד, בתנאי שמי שקובע מה נחשב “תיקון” זה משהו שה-agent לא שולט בו. כלומר טסט.

אתם כותבים טסט שנכשל, או נותנים ל-agent לכתוב אותו וקוראים רק אותו. אחר כך הלולאה ברורה: תריץ npm test -- tests/signup.test.ts עד שירוק. אסור לשנות קבצים תחת tests/.

בפועל ברוב הפעמים זה מתכנס תוך כמה סבבים. ופעם בכמה ריצות, ה-agent “מתקן” את הטסט במקום את הקוד. זה קורה. לכן אחרי כל ריצה:

git diff --stat main...agent/signup -- tests/

אם יש פה שורה אחת שלא ציפיתם לה, הטסט כבר לא מוכיח כלום.

05 · קוראים את ה-diff, לא את הסיכום של ה-agent

ה-agent של Replit סיכם שהכל בסדר. סיכום של agent זה טקסט שהמודל ייצר, לא עובדה. מה שנכנס ל-main זה ה-diff, אז קוראים אותו.

git diff --stat main...agent/signup | tail -1
# 7 files changed, 212 insertions(+), 31 deletions(-)

הכלל: מעל 400 שורות, המשימה חוזרת לפיצול. זה לא מספר שהמצאנו. המחקר של SmartBear על צוותי Cisco מצא שאחרי 200 עד 400 שורות ה-review מפסיק לתפוס באגים. מפתח אנושי ממילא לא היה פותח PR של 2,000 שורות. agent יעשה את זה בכיף בעשר דקות, אם תתנו לו.

06 · מודדים מה קרה בפועל

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

git log --since="30 days ago" --merges --oneline | wc -l
git log --since="30 days ago" --grep="^Revert" --oneline | wc -l

אם ה-reverts עולים יחד עם קצב ה-merge, לא חסכתם זמן. העברתם אותו ל-incident.

ב-Vellum בדקו עשרה כלים, ויצאו עם משפט שמתאר את כל הקטגוריה:

The honest answer is that most of them are good at the thing they’re designed for and frustrating everywhere else. — Vellum, “10 Best AI Coding Agents in 2026”, יולי 2026

הדעה שלי: בעיני ההבדל בין הכלים ברשימה הזאת קטן יותר ממה שהשיווק מספר. ההבדל הגדול הוא בין צוות שיש לו TASK.md, טסטים ו-deny בקובץ, לבין צוות שאין לו. כלי מצוין בלי שערים פשוט ייתן לכם PR של 2,000 שורות מהר יותר.

מה לקחת

• כל משימה מתחילה ב-TASK.md עם “איך יודעים שסיימנו” ו“לא לגעת”.
• מה שאסור הולך ל-settings.json, ו-credentials של production לא נמצאים בסביבה של ה-agent בכלל.
• טסט לפני קוד, ו-tests/ מחוץ לתחום של ה-agent.
• diff מעל 400 שורות לא נכנס ל-review. הוא חוזר לפיצול.