Agentic Engineering: תפסיקו לוייב קודינג, תבנו שכבה

1,468 שעות. 685 סשנים של Claude Code. שתי מכונות שרצות במקביל בסלון. אחרי כל זה אני מרשה לעצמי להגיד את זה בלי להתנצל: הבעיה היא לא המודל. הבעיה היא שאנחנו נותנים לסוכן AI להיכנס לקודבייס כמו אורח בלי מפתח, בלי מפה, בלי גבולות, ואז מופתעים כשהוא חוזר עם פאטץ׳ שאף אחד לא מבין.

זה לא עוד שם יפה לפרומפטים

Agentic Engineering זה לא לבקש מ-Claude Code או Cursor: ״תבנה לי את הפיצ׳ר״. זה עדיין וייב קודינג. לפעמים זה עובד. לפעמים זה משאיר אותך עם שינוי ב-7 קבצים, 14 טסטים אדומים, והתחושה הלא נעימה שאתה לא באמת יודע מה קרה. ראיתי את זה קורה לי בעצמי בשבוע הראשון של דצמבר. שרפתי יום וחצי על לבטל commit שאני בכלל לא הצלחתי לקרוא לעומק.

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

לא כי אתה סומך על המודל.

כי בנית לו מסילה.

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

איפה זה נופל	וייב קודינג	Agentic Engineering
נקודת פתיחה	פרומפט רחב בצ׳אט	בריף עם מטרה, גבולות ותנאי סיום
הקשר	המודל מחפש לבד עד שהוא ״מרגיש״ שהוא הבין	הקודבייס אומר לו בדיוק מה לקרוא קודם
כלים	הכל פתוח כל הזמן	כלים נפתחים לפי משימה, שלב ורמת סיכון
בטיחות	מקווים שהוא ישאל לפני שהוא דופק משהו	Hooks עוצרים, חוסמים או מבקשים אישור
סיום	הסוכן אומר ״סיימתי״	בדיקות, לוגים ו-review מחליטים אם זה באמת סיים

השכבה עצמה: 5 חלקים

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

1. חוזה הקשר

הסוכן צריך כניסה קצרה לקודבייס. זה יכול להיות AGENTS.md, קובץ CLAUDE.md, מפת repo, סקיל, או פקודת prime. השם פחות משנה. ההבטחה משנה: ״כשאתה עובד פה, קודם תקרא את זה, ואז תעבוד לפי הכללים האלה.״

חוזה טוב לא מנסה להרשים. הוא אומר באיזה package manager משתמשים, אילו טסטים מריצים, איזה תיקיות מסוכנות, איפה יש קוד שנשבר בקלות, ואיך מדווחים בסוף. אצלי ב-ai-news-site ה-CLAUDE.md מתחיל בשלוש שורות פרקטיות:

# Package Manager: pnpm (local), npm ci (CI)
# Build before commit: pnpm lint && pnpm build
# Never touch: .env, supabase/admin.ts, proxy.ts CSP nonce

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

2. Workflow בקוד

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

אצלי זה נראה ככה. סקריפט verify.sh אחד שמריץ ארבעה דברים בסדר קבוע:

#!/bin/bash
set -e
pnpm type-check    # ~28s
pnpm lint          # ~12s
pnpm test --run    # ~45s
pnpm build         # ~90s
echo "OK" > .verify.last

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

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

3. כלי עבודה לפי שלב

יותר מדי כלים יכולים להרוס סוכן. כל MCP, script או פקודה שנכנסים ל-context מוסיפים רעש. ספרתי פעם 47 כלים שהיו פתוחים אצלי בסשן אחד אחרי שהוספתי שלושה MCP servers חדשים. הסוכן בילה 3 דקות רק כדי להחליט באיזה כלי לקרוא לקובץ. שלוש דקות. לקרוא קובץ.

אחרי שצמצמתי ל-12 כלים מתויגים לפי שלב, הזמן הזה ירד ל-9 שניות. אותו מודל, אותה משימה, רק פחות בלגן בראש.

הגישה הנכונה היא קטלוג כלים שמשתנה לפי context. בשלב planning יש לסוכן רק read, grep ו-list. בשלב execution הוא מקבל write ו-bash. בשלב review הוא מקבל git diff ו-screenshot. כתבנו על זה גם במדריך מה זה MCP לסוכני AI, אבל הכלל קצר: אם הכלי לא רלוונטי למשימה הספציפית הזאת, הוא לא צריך להיות בתוך הראש של הסוכן.

אל תעשו: לחבר את כל ה-MCP servers שגיליתם השבוע ולקוות שזה ״יעבוד יותר טוב״. זה לא יעבוד יותר טוב. זה רק יבלבל את המודל יותר טוב.

4. Hooks ובטיחות

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

תתחילו מהשכבה הכי לא סקסית: חסימת פקודות הרסניות, הגנה על .env, .ssh, קבצי production, lockfiles, קונפיגים מקומיים, וכל דבר שאתם לא רוצים שסוכן ייגע בו על אוטומט. ה-Hook הראשון שלי הוא חמש שורות YAML שחוסכות לי לילות:

hooks:
  PreToolUse:
    - match: "Bash"
      block_patterns:
        - "rm -rf /"
        - "git push --force"
        - "DROP TABLE"
        - "chmod 777"
        - ".env"

בפעם הראשונה שזה חסם לי rm -rf node_modules/../ (שורה שהמודל ניסה להריץ באמת באמת ב-2:14 לפנות בוקר, כי הוא טעה ברמת התיקיה), הבנתי שהשכבה הזאת לא bonus. היא mandatory. global hooks ברמת מכשיר, project hooks ברמת repo. שתי שכבות. תמיד.

5. לולאת אימות

״סיימתי״ זו לא הוכחה. זו טענה.

סיום אמיתי מגיע מבדיקות: types, tests, lint, build, screenshot אם יש UI, migration check אם יש DB, ו-review על הדיף. צ׳קליסט פשוט אצלי נראה כך:

# .agents/verify-checklist.md
- [ ] pnpm type-check exit 0
- [ ] pnpm test --run exit 0
- [ ] pnpm build exit 0
- [ ] git diff < 400 lines? (else flag)
- [ ] no new files in .env or supabase/admin
- [ ] screenshot if UI changed

במשימות מסוכנות, תוסיפו סוכן בודק עם context נקי. כן, זה עולה יותר tokens. בערך פי 1.3 לכל משימה. אחלה. פאטץ׳ גרוע שעולה לפרודקשן עולה הרבה יותר, גם בזמן וגם בלילות שינה. הסוכן הבונה לא יכול לעשות review של עצמו, כי יש לו כבר התחייבות רגשית לקוד שכתב.

למה בלופרינטים מנצחים פרומפט חופשי

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

הם מקודדים את הטקסים האלה לתהליך.

תחשבו על משימת קוד רגילה. יש החלק היצירתי: להבין את הבעיה, לבחור גישה, לשנות קבצים. ויש החלק הטקסי: להריץ טסטים נכונים, לבדוק diff, לעדכן docs, לפתוח PR, לחכות ל-CI, לתקן לפי feedback. החלק הטקסי לא צריך להיוולד מחדש בכל סשן.

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

אצלי, הטמעת בלופרינט אחד טוב הורידה את הזמן הממוצע למשימת תיקון bug מ-22 דקות ל-9 דקות. אותו מודל. רק עם פחות חופש להמציא איך מתנהלים.

שלב	עדיף בקוד	עדיף בשיקול דעת של סוכן
התמצאות	טעינת docs, סטטוס git, קבצים שהשתנו	להבין איזה subsystem באמת רלוונטי
תכנון	דרישה לתוכנית או checklist	בחירת הדרך הקטנה והאמינה ביותר
בנייה	formatters, טסטים, build	כתיבת הקוד ותיקון כשלים
Review	איסוף diff, לוגים, screenshots	שיפוט סיכונים ומקרי קצה
Handoff	נתיבים, פקודות, סטטוס, blockers	להסביר מה השתנה ומה עדיין מפחיד

שכבת בטיחות היא לא בונוס

פה אני אהיה חד: אם אתם נותנים לסוכן להריץ shell בלי שכבת בטיחות, אתם לא עושים אוטומציה. אתם עושים הימור. ה-Hook research מהמחקר אומר את זה בלי ניואנסים: חסמו patterns ידועים בכללים דטרמיניסטיים, והשתמשו ב-prompt-based checks רק למקרים המעורפלים שעוד לא הצלחתם לקודד.

אישור ידני לכל פקודה גם לא פותר את זה. אחרי 30 popups, הבן אדם הופך למכונת Enter. ראיתי את זה אצלי. אחרי 4 שעות עבודה, אני מאשר אוטומטית. בטיחות טובה לא מציפה. היא חוסמת את הברור (rm -rf, force push), שואלת רק על האפור (״מחיקה של 12 קבצים, רוצה להמשיך?״), ונותנת לפעולות בטוחות לרוץ בלי דרמה.

אל תעשו: לבנות שכבת approval על כל פעולה. הבן אדם מאחורי המקלדת לא יקרא את ההודעה ה-50. הוא ילחץ Enter והפיצ׳ר שלכם הופך לטקס דתי בלי משמעות.

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

ארכיטקטורה שאפשר לבנות השבוע

לא צריך להתחיל מ-board של 9 סוכנים. באמת שלא. תתחילו ממשהו שאפשר לבדוק אחר הצהריים אחד. הנה מבנה התיקיות שאני משתמש בו ב-ai-news-site, בערך 60 שורות סך הכל:

repo/
├── CLAUDE.md              # context contract (the orientation file)
├── AGENTS.md              # per-agent rules
├── .agents/
│   ├── briefs/            # task brief templates
│   ├── workflows/         # plan-build-review, fix-bug, add-feature
│   ├── hooks.yaml         # safety rules (PreToolUse blocks)
│   ├── verify.sh          # one command, runs everything
│   └── ledger/            # one .md per run
└── .claude/
    └── commands/          # /plan, /verify, /handoff

שכבה	ארטיפקט	מה התפקיד שלה	גרסה ראשונה
התמצאות	AGENTS.md	להסביר לסוכן איך ה-repo עובד	פקודות, מבנה תיקיות, כללי סיכון
בריף	task-brief.md	לנקות את הקלט לפני עבודה	מטרה, גבולות, קבצים, תנאי סיום
Workflow	/plan-build-review	לשמור על שלבים	תכנון, עריכה, בדיקה, review, handoff
בטיחות	Pre-tool hooks	לשלוט בסיכון של shell וקבצים	חסימת פקודות הרסניות ונתיבים מוגנים
אימות	check script	להחליט אם העבודה אמיתית	types, tests, lint, build, screenshot אם צריך
זיכרון	run ledger	לעזור לסוכן הבא להבין מה קרה	מה נעשה, אילו פקודות רצו, איפה ממשיכים

וזה מתחבר גם לזיכרון של AI. זיכרון הוא לא רק ״תזכור שאני אוהב תשובות קצרות״. בעולם של סוכנים, זיכרון הוא תפעולי: מה נשבר בפעם הקודמת, איזה טסט איטי (אצלי e2e:checkout לוקח 4:12 דקות, וסוכן לא צריך להריץ אותו אם הוא לא נגע ב-checkout), איזה קובץ מסוכן, איזו החלטה כבר התקבלה. אם זה מעניין אתכם, יש לנו גם השוואה של Zep מול Mem0 מול Letta.

איך מתחילים בפועל

הגרסה שאני הייתי בונה השבוע. שעה ביום במשך 5 ימים, וזה מספיק.

1. יום 1 (60 דקות): בחרו repo אחד. לא מערכת אוניברסלית. repo אחד שבו סוכנים כבר מבזבזים לכם הכי הרבה זמן. אצלי זה היה דווקא ה-repo הקטן יותר, כי הסיכון לטעויות שם היה אישי, לא ארגוני.
2. יום 2 (90 דקות): כתבו חוזה repo. פתחו CLAUDE.md בשורש. כתבו: package manager, פקודת test, פקודת build, 3-5 נתיבים מסוכנים, הגדרה של ״עבודה הסתיימה״. עד 200 שורות. לא יותר.
3. יום 3 (60 דקות): צרו תבנית בריף. .agents/briefs/template.md עם 4 שדות בלבד: Goal, Files in scope, Files NOT to touch, Done criteria. הסוכן ממלא אותה לפני שהוא נוגע בקוד.
4. יום 3 (30 דקות): בנו workflow של plan-build-review. שלוש פקודות slash. /plan שמוציאה תוכנית בלי לגעת בקוד. /build שמבצעת לפי תוכנית. /review שעוברת על הדיף עם context נקי.
5. יום 4 (45 דקות): הוסיפו Hooks. פתחו .agents/hooks.yaml. חסמו 5 patterns: rm -rf /, git push --force, DROP TABLE, גישה ל-.env, ועריכה ב-node_modules. תוכלו להרחיב אחר כך.
6. יום 4 (30 דקות): כתבו פקודת אימות אחת. ./verify.sh שמריצה ארבעה דברים: type-check, test, lint, build. קוד יציאה 0 = עבר. קוד אחר = לא עבר. אין דיון.
7. יום 5 (45 דקות): שמרו ledger. כל ריצת סוכן כותבת .agents/ledger/2026-05-10-1430.md: מה נעשה, אילו פקודות רצו, מה עבר, מה נכשל, איפה ממשיכים. בסוף שבוע, יש לכם 5-10 entries שמלמדים את הסוכן הבא יותר ממה שמדריך אחד יוכל אי פעם.

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

מה לא לבנות עכשיו

המחקר מלא ברעיונות מפתים: צוותי סוכנים, long-context boards, ספריות פרטיות של skills, Tool Shed, orchestration בין כלים, סוכנים שרצים על כמה מכשירים. חלק מזה שווה. לא עכשיו. ראיתי שלושה דברים ספציפיים שאנשים מבזבזים עליהם שבועות:

• Multi-agent orchestration לפני שסוכן אחד עובד. בזבזתי שבועיים על להרים תזמור של ארבעה סוכנים מקבילים לפני שווידאתי שאחד מהם בכלל מסיים משימה בלי שאחזור על הוראות. אל תחזרו על הטעות. סוכן אחד אמין מנצח ארבעה לא-אמינים.
• Dashboard מרהיב לפני שקבצי handoff שלכם בכלל קריאים. ראיתי דאשבורד React מהמם שדרש 800 שורות קוד כדי להציג שלוש שורות מידע שאף אחד לא הסתכל עליהן. תכתבו קודם markdown טוב. ויזואליזציה אחר כך.
• 40+ MCP servers ״כי זה מרגיש חזק״. פתחתי פעם 17 servers במקביל. הסוכן בילה 4 דקות בכל ריצה רק כדי להחליט מאיפה להתחיל. חזרתי ל-5 servers ממוקדים. הזמן ירד ל-30 שניות.

אל תחשפו 47 כלים רק כי זה מרגיש חזק. אל תרדפו אחרי local models לתכנון קריטי אם הם לא מחזיקים את ה-context. ואל תתנו לסוכן לאשר לעצמו עבודה מסוכנת. סוכן שמעריך את עצמו הוא סטודנט שבודק את המבחן של עצמו.

קודם תעשו את הלולאה הקטנה משעממת.

אחר כך תגדילו.

שאלות קצרות

זה פשוט prompt engineering?

לא. Prompt engineering משנה את ההוראה. Agentic Engineering משנה את סביבת העבודה: הקשר, כלים, הרשאות, Workflow, בדיקות וזיכרון. אם prompt engineering זה לכתוב טוב יותר את השאלה במבחן, Agentic Engineering זה לעצב את כל החדר שבו הסטודנט עונה.

צריך כמה סוכנים כדי שזה יעבוד?

לא בהתחלה. סוכן אחד עם בריף טוב, workflow ברור, Hooks ובדיקות ינצח צוות סוכנים מבולגן ברוב המקרים. אצלי, 95% מהעבודה היומיומית נעשית על ידי סוכן אחד. תוסיפו סוכן reviewer רק כשיש סיכון שמצדיק את העלות הנוספת של בערך 30% tokens.

להשתמש ב-MCP לכל דבר?

לא. MCP שווה כשהכלי באמת שייך ל-workflow. אבל כל כלי פתוח מוסיף context וסיכון. בהרבה repos, פקודת CLI או script קטן ב-bash יהיו נקיים יותר משרת MCP שתמיד יושב בראש של המודל ואוכל 600 tokens מה-context window רק על תיאור עצמו.

איך זה קשור ל-AutoResearch?

AutoResearch עושה את אותו עיקרון על ניסויי ML: לולאה, מדד ברור, evaluation שלא משתנה, ו-keep-or-revert אוטומטי. זה לקח מצוין לסוכני קוד: תנו להם לולאה מדידה, לא משאלה. אם אתם לא יכולים למדוד אם המשימה הסתיימה, הסוכן לא יכול לדעת אם הוא סיים.

המבחן האמיתי

השלב הבא ב-AI coding הוא לא ״לסמוך יותר על הסוכן״.

השלב הבא הוא לגרום לזה שפחות תצטרכו לסמוך עליו.

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

כמה זמן ייקח לכם לבנות את השכבה הראשונה סביב repo אחד?