בגל ה-AI לתכנות הזה, מושגים עפים באוויר, כלים מחליפים “סקין” כל יום, אבל בתשתית זה לא כזה מיסטי.
סוכן (Agent) הוא לא קסם; במהות זו שכבה של “אילוץ מובנה” (Harness) שמלבישים על מודל שפה גדול (LLM) לא יציב, כדי להפוך את הפלט ליותר נשלט. Claude Code ו-Codex הולכים בדיוק בכיוון הזה.
1）קודם להבין את ה-LLM לעומק: הוא פשוט מנחש את ה-טוקן (Token) הבא
ברגע שמבינים את זה, הרבה “בעיות מיסטיות” כבר לא מיסטיות.
איך שאתה מזין הקשר, לשם הוא ייטה; איך שאתה מכוון, לשם הוא ילך.
לכן זה בלתי נמנע שפרומפטים (Prompt) יעברו מ“פולחן פורמט” ל“ביטוי טבעי”, אבל לדעת לשאול עדיין זו יכולת קשוחה.
2）פרומפט (Prompt) לא נהיה חסר ערך, פשוט צריך “פחות הובלה, יותר משוב”
- אל תדחוף פתרון ישר מההתחלה; קודם תאר מצב ויעד, ותן למודל זוויות;
- איטרציה מונחית-בעיה: רואים תוצאה → מצביעים על הטעות → משכתבים הנחיות → מאמתים בשיחה חדשה;
- מילות מפתח נוקשות מדי דווקא גוררות את המודל לתעלה.
במשפט אחד: פחות לשלוט במסלול, יותר לאמת את התוצאה.
3）AGENTS.md חשוב מאוד, אבל אל תכתוב אותו כ“אנציקלופדיית חוקים”
בקהילה יש הרבה “חובה/אסור/עקרונות” באורך מוגזם—ברובו רעש.
כשדוחפים למודל יותר מדי מגבלות, לרוב הוא לא נהיה יציב יותר—אלא קהה יותר.
מה שהנחיות גלובליות אמורות לעשות זה להגדיר גבולות ולהסביר כלים, לא לאלף סגנון.
4）אל תיתן ל“שיווק של מושגים חדשים” לגרור אותך
RAG, הנדסת הקשר (Context Engineering), MCP, מיומנויות (Skills)…
הרבה מזה הוא בעצם אריזה חדשה לבעיות ישנות, או הפיכת פרומפטים (Prompt) לסטנדרט.
מה שכדאי לרדוף אחריו הוא לא ה“מילים”, אלא: האם זה באמת מפחית חיכוך ומקצר את מסלול המסירה.
5）לפיתוח מקביל יש תקרה: שתי משימות הן הגבול של רוב האנשים
לפתוח שלושה-ארבעה סוכנים (Agent) נראה יעיל, אבל בפועל זה פיצוץ קאש במוח.
התראות שמצלצלות בלי הפסקה רק שוברות את ה-flow ויוצרות אשליה של “אני ממש עסוק”.
המלצה: לכבות התראות, ולבדוק סטטוס בצורה יזומה.
תגובה פסיבית להתראות = להיות נשלט על-ידי הקצב; ביקורת יזומה על משימות = אתה שולט בקצב.
6）קבצים הם זיכרון: להעביר את ההקשר מ“המוח” ל“מערכת הקבצים”
סוכן CLI (CLI Agent) נשען עוד יותר על לוגיקת חיפוש טקסט.
כדי שהסוכן (Agent) יהיה יציב, זה לא תפילות—אלא תיעוד פרויקט שניתן לחיפוש ושימוש חוזר.
קבצים צריכים להיות מוכווני ביצוע סופי; אל תדחוף זבל תהליכי.
במהות זה להשלים את החסרונות המולדים של הקשר ותשומת לב במודל.
7）פישוט תהליך: קודם תכנון, ואז קידוד
שיטת שני השלבים שלך עכשיו מאוד פרקטית:
- דיון חוזר והקשחת התוכנית (PLAN / תיקיית plans)
- מימוש הקוד לפי התוכנית הסופית, והפקדת תיעוד מימוש (תיקיית docs)
קובץ התוכנית הוא עוגן, הקוד הוא התוצר.
8）מוכוון-תוצאה: פחות להיתקע על “תהליך אלגנטי”, יותר על “מסירה ניתנת לאימות”
לעבור מ“אני מלמד את הסוכן (Agent) לכתוב קוד יד-ביד” ל“אני מנהל את הפתרון וקריטריוני הקבלה”.
טעויות קטנות באמצע—אל תחפור עליהן; לרכז אותן לשלב סקירה ולתקן בבת אחת.
איכות קוד לא נקבעת לפי מצב רוח, אלא לפי בדיקות ומבנה שניתן לחקירה.
יש רק יעד אחד: It just works.
9）שדרוג מנטלי: ממבצע למנהל
להשתמש ב-Codex כ“מוח חיצוני + ברווז גומי”: אתה מפרק בעיות, מגדיר סטנדרטים, ועושה החלטות;
הוא מבצע בהיקף גדול.
אל תהפוך את הסוכן (Agent) לאל, ואל תהפוך אותו לצעצוע—הוא מגבר: הוא מגביר את שיקול הדעת שלך, וגם את הבלגן שלך.
10）לקחים מפרקטיקות שגויות
- לרדוף בעיוורון אחרי “הרצה אוטונומית (autonomous) ארוכת זמן” לא ממש מועיל;
- מה שבאמת בעל ערך הוא להפחית התערבות ידנית ולהעלות את ההסתברות למסירה יציבה;
- להעתיק פרומפטים (Prompt)/מיומנויות (Skills) של אחרים מאיץ התחלה, אבל לא בהכרח מתאים לפרויקט שלך;
- מסלול הצמיחה היעיל ביותר: לעקוב אחרי תהליך הביצוע, למצוא את שורש הכשל, ולאטרץ את המתודולוגיה שלך.
