AI Briefing/בלוג
vibe engineering·9 באוקטובר 2026·6 דקות קריאה

Vibe engineering בשישה צעדים: המודל כותב, אתם מחליטים

Vibe engineering בפועל: spec עם החלטות פתוחות, AGENTS.md, plan mode, hook שאוכף tests ו-review של ה-diff. שישה צעדים עם קבצים להעתקה.

ההבדל בין vibe coding ל-vibe engineering הוא לא מי כותב את הקוד. בשניהם המודל כותב.

קאושיק גופאל שם את זה בטבלה של שתי שורות. שורה אחת: מי מייצר את הקוד. שורה שנייה: מי מחזיק את ה-design ואת ה-quality bar. ב-vibe coding התשובה לשתיהן היא המודל. ב-vibe engineering המודל עדיין מייצר, אבל ה-design נשאר אצלכם. זה כל ההבדל, וזו גם כל העבודה.

קצת רקע. אנדריי קרפתי טבע את vibe coding בציוץ מפברואר 2025: להיכנע לווייב ו“לשכוח שהקוד בכלל קיים”. סיימון וויליסון הציע באוקטובר 2025 את vibe engineering בתור הצד השני: מהנדסים מנוסים שעובדים עם agents ונשארים אחראים על מה שיוצא. השם נדבק, וב-2026 כבר יש עליו פוסטים מכל כיוון, וגם סרטון של Udacity.

אז מה זה אומר בפועל, ביום שני? הטעות הנפוצה היא לקנות כלים ולחכות לתוצאה. ב-mfbt קנו לכל המהנדסים מנוי Claude Code של $100 לחודש. אחרי כמה חודשים פיצ’רים גדולים עדיין לקחו שבועות. הסניורים טסו, הג’וניורים חסכו קצת זמן פה ושם, וזהו. ההסבר שלהם: הסניורים קיבלו החלטות מוצר ו-architecture תוך כדי עבודה, והג’וניורים קפאו מול כל חור ב-spec וחיכו לתשובה בסלאק.

בקיצור, הכלי לא היה הבעיה. חסר תהליך. הנה התהליך שאני עובד איתו בקלוד קוד, בשישה צעדים. ב-Codex וב-OpenCode זה כמעט אותו דבר.

01 · spec שמסמן מה עוד לא הוחלט

לפני שפותחים טרמינל, כותבים spec קצר. לא מסמך של עשרים עמודים: מה המטרה, מה מחוץ ל-scope, ואיך יודעים שסיימנו. ובעיקר סעיף של החלטות פתוחות.

זה התיקון הישיר לבעיה של mfbt. ה-agent ימצא חורים ב-spec בשלב ה-planning, זה בטוח. השאלה היא אם החור נופל על ג’וניור שקופא, או שכבר כתוב מה ברירת המחדל ומי מאשר.

מה עושים: קובץ specs/<feature>.md עם שלוש כותרות — Goal, Done when, Open decisions. ליד כל החלטה פתוחה כותבים ברירת מחדל ושם של בן אדם. למשל: pagination: cursor (default), ask Dana if offset is needed.

מה רואים: ה-spec הראשון שלכם ייצא עם 2–3 החלטות פתוחות שלא ידעתם שקיימות. יפה. מצאתם אותן לפני הקוד, לא בסלאק אחרי.

$100 לחודש למהנדס לא קנו תהליך: הסניורים טסו והג'וניורים קפאו מול חורים ב-spec (credit: mfbt.ai)
$100 לחודש למהנדס לא קנו תהליך: הסניורים טסו והג’וניורים קפאו מול חורים ב-spec (credit: mfbt.ai)

02 · AGENTS.md: מה ה-agent צריך לדעת בכל session

כל session מתחיל מאפס. מה שלא כתוב, ה-agent ינחש. אז שמים בשורש ה-repo קובץ AGENTS.md. Codex ו-OpenCode קוראים אותו לבד. קלוד קוד קורא CLAUDE.md, אז שמים בו שורה אחת: @AGENTS.md.

מה נכנס: פקודות, Definition of done, איפה לא נוגעים, ומה עושים כשה-spec לא ברור. מה לא נכנס: הטפות. “כתוב קוד נקי” לא עוזר לאף אחד. פקודה עוזרת.

AGENTS.md
# Rules for coding agents
<figure><img src="/posts/vibe-engineering/diagram.svg" alt="איך המנגנון עובד" loading="lazy" /><figcaption>איך המנגנון עובד</figcaption></figure>
## Commands
- Install: npm ci
- Typecheck: npm run typecheck
- Tests: npm test
- Lint: npm run lint -- --fix
## Definition of done
- Typecheck, tests and lint pass locally. Paste the last 5 lines of test output.
- No new dependency without asking.
- Diff under ~300 lines. If bigger, stop and propose a split.
## Don't touch without asking
- migrations/
- src/shared/types.ts (other modules depend on these shapes)
## When the spec is unclear
- Open decision with no default: stop and ask.
- Open decision with a default: use it, list it in the PR description.

השורה על types.ts היא לא סתם. היא באה מהסיפור של הצעד הבא.

03 · תוכנית בכתב לפני שורת קוד אחת

קאמן ז’קוב כתב על זה בינואר 2026. הוא ביקש מ-OpenCode פיצ’ר ל-Puppypal, אפליקציה שהוא בונה לאילוף הגור שלו. ה-agent עשה בערך תריסר שינויים והודיע שסיים. בפועל הוא לא סיים, וגם שבר פיצ’רים אחרים, כי שינה data structures שחלקים אחרים בקוד השתמשו בהם. ז’קוב עשה git reset והתחיל מחדש, הפעם עם תהליך.

The difference is usually not the model, but rather whether I treated it like a slot machine or like a fellow engineer. — Kamen Zhekov, A Practical Guide to Vibe Engineering

מה עושים: בקלוד קוד נכנסים ל-plan mode עם Shift+Tab פעמיים. ה-agent קורא קוד ולא נוגע בו. מבקשים שהתוכנית תכלול רשימת קבצים שישתנו, וגם מי עוד משתמש בכל טיפוס שמשנה צורה. קוראים, מתקנים, ורק אז מאשרים.

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

04 · ה-agent לא מחליט מתי הוא סיים

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

בקלוד קוד עושים את זה עם hook מסוג PostToolUse, שרץ אחרי כל עריכה. אם typecheck או tests נופלים, ה-hook יוצא עם קוד 2, וה-stderr חוזר למודל. הוא רואה את השגיאה ומתקן לפני שזה בכלל מגיע אליכם.

.claude/settings.json
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|MultiEdit|Write",
"hooks": [
{
"type": "command",
"command": "npm run -s typecheck 1>&2 && npm test -s 1>&2 || exit 2",
"timeout": 120
}
]
}
]
}
}

מה רואים: בהתחלה זה מאט. כל עריכה מחכה ל-tests. אם ה-suite לוקח יותר מ-30 שניות, תריצו רק את ה-tests של החבילה שהשתנתה, אחרת ה-session מתברבר בהמתנות. ב-Codex וב-OpenCode שמים את אותו כלל ב-AGENTS.md, אבל שם זה חלש יותר: שם זו בקשה, פה זו אכיפה.

הדעה שלי: אם הייתי צריך לבחור צעד אחד מתוך השישה, זה הוא. spec אפשר לכתוב רע ותוכנית אפשר לאשר בלי לקרוא, אבל typecheck שנופל לא מתווכח איתכם.

ה-agent לא מכריז שסיים: קוד 2 מחזיר את השגיאה אליו, ורק עריכה ירוקה מגיעה ל-commit ולעיניים שלכם (Claude Code hooks)
ה-agent לא מכריז שסיים: קוד 2 מחזיר את השגיאה אליו, ורק עריכה ירוקה מגיעה ל-commit ולעיניים שלכם (Claude Code hooks)

05 · branch לכל משימה, ו-reset בלי רגשות

commit אחרי כל צעד שעבר את ה-hook. ככה ה-git reset של ז’קוב עולה דקה ולא יום.

מה עושים: git switch -c agent/search-pagination בתחילת משימה. git diff --stat main לפני review, ואם יש שם יותר מ-300 שורות, עוצרים ומפצלים. ואם משהו התברבר, git reset --hard ל-commit הירוק האחרון, רק על ה-branch של ה-agent.

עוד כלל: אם ה-agent נכשל פעמיים על אותו דבר, לא מנסים פעם שלישית באותה שיחה. reset, מעדכנים את ה-spec במה שלמדתם, ופותחים שיחה חדשה. שיחה ארוכה עולה יותר בכל הודעה וגם עונה פחות טוב.

מה רואים: הרבה commits קטנים עם הודעות של ה-agent. זה בסדר. עושים squash ב-merge.

06 · קוראים את ה-diff, לא את הסיכום

הסיכום שה-agent כותב בסוף הוא שיווק. ה-diff הוא מה שקרה. פה ה-design נשאר שלכם, וזו בדיוק השורה השנייה בטבלה של גופאל.

מה עושים: עוברים על ה-diff עם אותן שאלות כל פעם. נוצרה abstraction שלא ביקשתי? השמות מתאימים לשאר הקוד? יש טיפוס ששינה צורה? לפני שאתם נכנסים, אפשר להריץ מודל שני כ-reviewer עם ה-spec ביד: “מה מתוך Done when לא מכוסה ב-tests?”. הוא לא מחליף אתכם, הוא מסנן.

ליאנדרו (leandronsp) כתב במאי 2026 שזה לא עניין של מהירות, אלא של ביטחון. אני מסכים. הצעדים האלה לא יהפכו אתכם למהירים יותר כבר ביום הראשון. אבל תעשו merge בלי לחשוש.

אותו מודל כותב את הקוד בשני המקרים, ו-vibe engineering מתחיל כשה-design חוזר אליכם (credit: Kaushik Gopal)
אותו מודל כותב את הקוד בשני המקרים, ו-vibe engineering מתחיל כשה-design חוזר אליכם (credit: Kaushik Gopal)

מה לקחת

מקורות

  1. We're Not Vibe Engineering · 2026-03-24
  2. Vibe Coding vs. Vibe Engineering · 2026-02-20
  3. Path to Vibe Engineering · 2026-05-02
  4. What Is Vibe Engineering? The Future of AI-Driven Software Development
  5. A Practical Guide to Vibe Engineering
  6. AI-assisted coding → Vibe Engineering ← Vibe Coding - Kaushik Gopal's Website

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

עוד מונחים

כל המונחים →
3/4

ChatGPT מקרוב: הפיצ'רים שמהנדסים משאירים כבויים

Projects, memory, canvas, deep research, agent ו-connectors ב-ChatGPT: מה כל אחד עושה, איפה הוא נופל, ומה להפעיל כבר השבוע.

1/5

Claude Code בפרקטיקה, חלק 1: CLAUDE.md קצר, הרשאות קשוחות

שלושת קבצי ה-CLAUDE.md, auto memory, הרשאות ב-settings.json ופקודות שכדאי שיהיו באצבעות. צעד אחרי צעד, לצוות אמיתי.

2/5

Claude Code בפרקטיקה, חלק 2: hooks, MCP ו-skills, מה הולך לאן

CLAUDE.md אומר מה חייב, skill איך, MCP מה אפשר, hook אוכף. PreToolUse שחוסם commit ל-main, formatter אוטומטי, שרת MCP ו-SKILL.md ראשון.