השלמת-קוד מול סוכן שמשנה קבצים
כלי-AI לתכנות עובדים בשתי רמות שונות מאוד. עוזר-השלמה (ראו "עוזר-קוד") מציע את השורה או הבלוק הבאים בתוך הקובץ שהמתכנת כותב כרגע. סוכן-קידוד, לעומתו, מקבל משימה ומבצע אותה בעצמו: התיעוד של Claude Code מתאר סוכן שמחפש את הקבצים הרלוונטיים, קורא כמה מהם, מבצע עריכות מתואמות, מריץ בדיקות ומבצע commit אם מבקשים — ומציין במפורש שזה שונה מעוזרים שרואים רק את הקובץ הנוכחי. גם התיעוד של Cursor מתאר סוכן שמריץ פקודות-טרמינל ועורך קוד באופן עצמאי. GitHub מבחינה בתוך הקטגוריה עצמה בין שתי צורות: "מצב סוכן" בעורך, שמבצע עריכות ישירות בסביבת-הפיתוח המקומית, ו"סוכן ענן" שעובד ברקע בסביבה זמנית משלו, על ענף נפרד, ופותח בקשת-מיזוג (pull request). ההבחנה חשובה כי היא קובעת את סוג הביקורת: בהשלמה המתכנת מאשר כל הצעה לפני שהיא נכנסת; בסוכן, השינוי כבר קיים בקבצים והבדיקה מתבצעת אחריו.
לפני שמתחילים: הוראות-פרויקט ונקודת-חזרה
שני דברים כדאי שיהיו במקום עוד לפני המשימה הראשונה. הראשון הוא קובץ-הוראות קבוע שהסוכן קורא בכל פעם: ב-Claude Code זה CLAUDE.md (או AGENTS.md שנכתב לסוכנים אחרים), וב-GitHub אלה "הוראות מותאמות" שנשמרות כקבצים במאגר. התיעוד של Anthropic ממליץ לכלול בו פקודות שהסוכן לא יוכל לנחש וכללי-סגנון שחורגים מברירת-המחדל, ולהשאיר אותו קצר — לפי התיעוד, קובץ מנופח גורם לסוכן להתעלם מההוראות עצמן. השני הוא נקודת-חזרה: התיעוד של Codex CLI ממליץ ליצור נקודות-שמירה ב-git לפני משימה ואחריה כדי שאפשר יהיה לבטל שינויים. Aider בנוי סביב אותו רעיון — לפי התיעוד שלו, הוא מבצע commit לכל עריכה שלו, ואם יש בקבצים שינויים שהמשתמש טרם שמר ב-git, הוא שומר אותם קודם ב-commit נפרד, כך שעבודת האדם ועבודת הסוכן נשארות מופרדות.
ניסוח המשימה
לפי המלצות Anthropic, ככל שההוראה מדויקת יותר נדרשים פחות תיקונים. ההמלצות מנוסחות כזוגות של "לפני" ו"אחרי": במקום "הוסף בדיקות", לציין איזה קובץ, איזה תרחיש ואילו העדפות-בדיקה; במקום "תקן את הבאג בהתחברות", לתאר את התסמין, את המיקום הסביר ואיך נראה "מתוקן" — למשל לבקש קודם בדיקה שנכשלת ומשחזרת את התקלה, ורק אז תיקון. עוד המלצה היא להפנות את הסוכן לדפוס קיים בקוד ("ראה איך בנויים הרכיבים הקיימים") במקום לתאר הכול מאפס. במשימות גדולות מומלץ להפריד בין שלבים: קודם חקירה ותכנון במצב שבו הסוכן אינו עורך קבצים, ורק אחר-כך ביצוע. ההפרדה הזו מוסיפה זמן, ולכן התיעוד מציע כלל-אצבע: אם אפשר לתאר את השינוי במשפט אחד, אפשר לדלג על שלב-התכנון.
לתת לסוכן דרך לבדוק את עצמו
אחד העקרונות שחוזרים בתיעוד של Anthropic הוא שסוכן עוצר כשהעבודה "נראית גמורה". בלי בדיקה שהוא יכול להריץ, "נראית גמורה" היא האות היחיד שיש לו — והאדם הופך ללולאת-הבדיקה, שכל טעות ממתינה עד שהוא ישים לב אליה. לכן מומלץ לתת לסוכן משהו שמחזיר "עבר" או "נכשל": חבילת-בדיקות, קוד-יציאה של בנייה, כלי-lint, או צילום-מסך להשוואה מול עיצוב. כשהבדיקה קיימת, הסוכן עובד, מריץ אותה, קורא את התוצאה וממשיך עד שהיא עוברת. באותו אופן, לפי GitHub, סוכן-הענן שלה עובד בסביבת-פיתוח זמנית משלו, שבה הוא יכול להריץ בדיקות אוטומטיות וכלי-lint. התיעוד של Anthropic ממליץ גם לבקש ראיות במקום הצהרות: את פלט-הבדיקות, את הפקודה שהורצה ואת מה שהחזירה — קריאת ראיה מהירה יותר מהרצה חוזרת של הבדיקה.
קריאת ה-diff וביטול שינויים
בסוף כל משימה עומד diff — רשימת השורות שנוספו, נמחקו או שונו — וקריאתו היא עיקר העבודה של האדם. הכלים מספקים לכך דרכים שונות: ב-Aider הפקודה /diff מציגה את כל השינויים מאז ההודעה האחרונה, והפקודה /undo מבטלת את השינוי האחרון; ב-Claude Code נשמר עותק של כל קובץ לפני עריכה, ואפשר לחזור אחורה בלחיצה כפולה על Esc; ב-GitHub אפשר לעבור על ה-diff שסוכן-הענן יצר, לבקש שינויים ורק אז לפתוח בקשת-מיזוג. דף-האבטחה של Claude Code קובע במפורש שהאחריות לבדוק קוד ופקודות לפני אישורם היא של המשתמש, וממליץ לבדוק בקפדנות שינויים בקבצים קריטיים. חשוב לזכור את גבול מנגנוני-הביטול: לפי התיעוד, נקודות-השחזור מכסות רק קבצים מקומיים, ופעולות על מסדי-נתונים, ממשקי-API או פריסות אינן ניתנות לביטול כך.
הרשאות ואישור לפני מיזוג
השאלה כמה לתת לסוכן לעשות בלי לשאול נפתרת בדרך כלל במצבי-הרשאה. ב-Claude Code, למשל, יש מצב שבו כל עריכה ופקודה דורשות אישור, מצב שבו עריכות-קבצים מאושרות אוטומטית, מצב-תכנון שאינו עורך קבצים, ומצב שבו מודל-מסווג נפרד חוסם פעולות שנראות מסוכנות. ב-Codex, לפי התיעוד של OpenAI, שני מנגנונים פועלים יחד: ארגז-חול שקובע לאילו קבצים ומשאבי-רשת יש גישה, ואישורים שקובעים מתי הסוכן עוצר. בשלב המיזוג נכנסים כללי-המאגר עצמם: GitHub מציינת שכלל-הגנה על ענף שאינו תואם את סוכן-הענן יחסום אותו, ושהסוכן יכול לעבוד על ענף אחד ולפתוח בקשת-מיזוג אחת לכל משימה. הדפוס המשותף הוא שהסוכן מציע והאדם ממזג — דוגמה מעשית לעיקרון "אדם-בלולאה" (ראו ערך נפרד).
מי בודק את הבודק: שכבות של אימות
התיעוד של Anthropic מתאר כמה דרגות של אכיפת הבדיקה, מהפשוטה למחמירה. בדרגה הבסיסית, מבקשים מהסוכן באותה הודעה להריץ את הבדיקה ולחזור עליה עד שהיא עוברת. בדרגה הבאה, מגדירים "יעד" שמעריך נפרד בודק אחרי כל תור, והסוכן ממשיך לעבוד עד שהיעד מתקיים. דרגה מחמירה יותר היא hook דטרמיניסטי: סקריפט שמריץ את הבדיקה ולא מאפשר לסוכן לסיים עד שהיא עוברת. ובדרגה של "דעה שנייה", סוכן נפרד, בהקשר נקי, מנסה להפריך את התוצאה — כך שהסוכן שעשה את העבודה אינו זה שנותן לה ציון. אותו רעיון מופיע בדפוס של "כותב וסוקר": סשן אחד כותב את הקוד וסשן אחר, שלא ראה את תהליך-הכתיבה, סוקר אותו, כי לפי התיעוד הקשר רענן משפר סקירה — הסוכן אינו מוטה לטובת קוד שהוא עצמו כתב זה עתה. כל דרגה כזו מחליפה זמן-הגדרה בתשומת-לב אנושית, אבל אף אחת מהן אינה מבטלת את קריאת ה-diff לפני מיזוג.
דפוסי-כשל מוכרים
המלצות Anthropic מונות כמה דפוסי-כשל חוזרים בעבודה עם סוכן-קידוד. "סשן כיור-המטבח": מתחילים במשימה אחת, עוברים לשאלה שאינה קשורה וחוזרים — וההקשר מתמלא במידע לא רלוונטי; התיקון המוצע הוא לנקות את ההקשר בין משימות שאינן קשורות. "תיקון אחרי תיקון": הסוכן טועה, מתקנים אותו, והוא עדיין טועה — וההקשר מזדהם בניסיונות שנכשלו; ההמלצה היא, אחרי שני תיקונים כושלים, להתחיל מחדש עם הוראה פותחת טובה יותר שכוללת את מה שנלמד. "פער האמון": הסוכן מייצר מימוש שנראה סביר אך אינו מטפל במקרי-קצה; התיקון הוא לספק תמיד דרך אימות — ובלשון התיעוד, אם אי-אפשר לאמת, לא משחררים. ו"החקירה האינסופית": בקשה לא-תחומה "לבדוק משהו" גורמת לסוכן לקרוא מאות קבצים ולמלא את ההקשר; הפתרון הוא לתחום את החקירה או להעביר אותה לתת-סוכן.
עלות ומדידה בארגון
לסוכן-קידוד יש עלות שאינה קיימת בעוזר-השלמה פשוט, משום שכל משימה כוללת קריאת קבצים, הרצות חוזרות וסבבי-תיקון. ב-GitHub, למשל, סוכן-הענן צורך דקות של GitHub Actions וגם קרדיטי-AI, שהיקפם תלוי במודל ובמספר הטוקנים שעובדו בסשן. כדי לדעת אם זה משתלם, GitHub מאפשרת למנהלי-ארגון למדוד את תוצאות העבודה ולא רק את השימוש: כמה בקשות-מיזוג יצר הסוכן, כמה מהן מוזגו בפועל, ומה זמן-המיזוג החציוני לעומת בקשות אחרות. Anthropic ממליצה, מצידה, להתחיל בקבוצת-פיילוט קטנה ולמדוד בסיס-השוואה לפני פריסה רחבה. המשותף לשתי הגישות: הערכת סוכן-קידוד נעשית על מה שנכנס בסוף לקוד, ולא על כמות הקוד שהוא הפיק.
מגבלות ותקלות נפוצות
חלון-ההקשר הוא המשאב הראשון שנגמר: לפי Anthropic, סשן-דיבוג אחד יכול לצרוך עשרות אלפי טוקנים, וביצועי המודל יורדים ככל שהחלון מתמלא — הסוכן עלול "לשכוח" הוראות מוקדמות ולטעות יותר. לכן מומלץ לפצל עבודה ארוכה ולשמור כללים קבועים בקובץ-ההוראות ולא בשיחה. מגבלה שנייה היא זמן והיקף: סוכן-הענן של GitHub, למשל, מוגבל ל-59 דקות לסשן ולמאגר אחד בכל ריצה, והתיעוד שם ממליץ לפרק משימות מורכבות למשימות קטנות. סיכון שלישי הוא תוכן לא-מהימן: דף-האבטחה של Claude Code ממליץ להימנע מהזנת תוכן לא-מהימן ישירות לסוכן ולהריץ סקריפטים בסביבה מבודדת, כמו מכונה וירטואלית, בעיקר כשעובדים מול שירותי-רשת חיצוניים — משום שהוראות זדוניות בתוך מסמך או דף-אינטרנט עלולות לנסות להסיט את הסוכן ממשימתו.