Autonomous Coding Agents — איך סוכן AI עובד על Repository אמיתי

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

מה קורה בפועל כשסוכן AI מקבל issue ב-GitHub ופותר אותו לבד: מיפוי הריפו, תכנון, עריכת קוד, הרצת בדיקות, ותיקון עצמי - כל השלבים, הכלים וההחלטות הארכיטקטוניות שמאחוריהם.

נותנים לסוכן AI issue ב-GitHub: "יש בעיית race condition בתהליך התשלום, לפעמים לקוח מחויב פעמיים". שעה וחצי אחר כך יש pull request עם תיקון, טסטים חדשים, ותיאור שמסביר את שורש הבעיה. בין ההתחלה לסוף קרה תהליך שלם - הסוכן קרא את הקוד, הבין את הארכיטקטורה, ניסח השערה, בדק אותה, כתב פתרון, הריץ בדיקות, ותיקן את עצמו כשהבדיקה הראשונה נכשלה. זה לא autocomplete חכם - זו מערכת שפועלת באופן אוטונומי על קוד אמיתי, עם כל הסיכונים וההזדמנויות שזה מביא.

מה מבדיל Coding Agent מ-Copilot רגיל

כלי השלמת קוד קלאסיים כמו GitHub Copilot פועלים בלולאה קצרה: המשתמש כותב, המודל מציע את השורה הבאה, המשתמש מאשר או דוחה. כל האחריות על הקשר, על נכונות, ועל בדיקה נשארת אצל המפתח. Autonomous Coding Agent הוא דבר אחר לגמרי - הוא מקבל משימה ברמת issue או ticket, ופועל במחזור עצמאי של תכנון-ביצוע-בדיקה עד שהמשימה הושלמה או שהוא נתקע. ההבדל המהותי הוא ב"טווח האחריות": במקום להשלים שורה, הסוכן אחראי לתוצאה שלמה - קוד שעובד, בדיקות שעוברות, ולפעמים גם commit message ו-PR description.

המעבר הזה דורש יכולות שסתם מודל שפה לא נותן מהקופסה: גישה לכלים (tools) שמאפשרים קריאה וכתיבה של קבצים, הרצת פקודות shell, וניווט בתוך repository שלם. זה הבסיס לארכיטקטורת agentic architecture - מודל שפה שמופעל בתוך לולאה שמשלבת קבלת החלטות עם פעולה בעולם האמיתי.

הלולאה המרכזית: Perceive → Plan → Act → Verify

ברוב מימושי ה-coding agents קיימת לולאה בסיסית שחוזרת על עצמה, עם וריאציות:

• Perceive - איסוף הקשר רלוונטי: קריאת ה-issue, חיפוש בקוד הקיים, בדיקת מבנה הפרויקט.
• Plan - ניסוח תוכנית פעולה, לרוב כרשימת צעדים מפורשת שהסוכן "כותב" לעצמו לפני שהוא מתחיל לפעול.
• Act - ביצוע צעד בודד: עריכת קובץ, הרצת פקודה, יצירת קובץ חדש.
• Verify - בדיקה שהפעולה הצליחה - הרצת טסטים, קריאת פלט השגיאה, השוואת תוצאה מצופה מול בפועל.

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

מיפוי הריפו - איך הסוכן "מבין" קודבייס שהוא לא הכיר

אחד האתגרים המרכזיים הוא ה-context window המוגבל מול גודל ריפו אמיתי, שיכול להכיל מאות אלפי שורות קוד. אי אפשר לזרוק את כל הקוד לפרומפט. סוכנים אפקטיביים משתמשים בשילוב של כמה טכניקות: מיפוי מבני של הריפו (עצי תיקיות, imports, dependency graph), חיפוש טקסטואלי וסמנטי לפי רלוונטיות, וקריאה ממוקדת של קבצים ספציפיים רק כשצריך. הנושא הזה מספיק עמוק כדי להצדיק התייחסות נפרדת - ראו את המדריך המורחב על Repository Mapping.

בפועל, סוכן טוב לא "קורא את כל הריפו" - הוא בונה תמונה חלקית אך מספקת: אילו קבצים קשורים לבעיה, מה מבנה המודולים, אילו conventions הפרויקט משתמש בהם (שמות, סגנון, framework). חלק מהמידע הזה מגיע מ-grep ו-glob פשוטים, וחלק מ-חיפוש סמנטי שמוצא קוד לפי משמעות ולא רק לפי מחרוזת מדויקת.

כלים (Tools) - הממשק בין המודל לעולם האמיתי

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

{
  "tools": [
    {"name": "read_file", "params": ["path", "line_range?"]},
    {"name": "edit_file", "params": ["path", "old_text", "new_text"]},
    {"name": "bash", "params": ["command", "timeout_ms"]},
    {"name": "grep", "params": ["pattern", "path_glob"]},
    {"name": "run_tests", "params": ["test_pattern?"]}
  ]
}

העיצוב של הכלים האלה הוא החלטה ארכיטקטונית לא טריוויאלית. כלי edit_file שדורש old_text מדויק מונע מהמודל "לזרוק" קובץ שלם מחדש ולאבד שינויים - זה מכריח עריכה ממוקדת שדומה יותר ל-diff. כלי bash גמיש אבל מסוכן - הוא הפתח הראשי להרצת קוד שרירותי, ולכן דורש שכבת sandboxing ובקרת הרשאות קפדנית. עיצוב הכלים משפיע ישירות על איכות הפלט - זה בדיוק העיקרון שמפורט במדריך על function calling.

Verification Loop - למה בדיקה אוטומטית היא לא Bonus אלא הליבה

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

• מריץ את סוויטת הבדיקות הרלוונטית אחרי כל שינוי משמעותי.
• קורא את פלט השגיאה במלואו - stack trace, exit code, הודעת linter.
• מנסח היפותזה לגבי הסיבה לכישלון, ולא סתם מנסה "עוד גרסה" באקראי.
• יודע מתי לעצור - אחרי N ניסיונות כושלים, לדווח למשתמש במקום להמשיך ללולאה.

המנגנון הזה קשור ישירות לתיקון עצמי (self-correction) ולעיתים משתמש ב-verifier model נפרד שתפקידו רק לשפוט האם הפתרון נכון, בלי "להתאהב" בקוד שהוא עצמו כתב - בעיה מוכרת כשאותו מודל גם כותב וגם שופט.

הרשאות וגבולות - מה קורה כשהסוכן טועה

סוכן שרץ ללא פיקוח על ריפו production הוא סיכון אמיתי - מפקודת git push --force שדורסת היסטוריה ועד קריאה בטעות ל-API חיצוני עם side effects. עיצוב אחראי כולל: הרצה בתוך container מבודד, רשימת פקודות מותרות (allowlist) במקום רשימת חסימה, ו-approval gates לפעולות בלתי הפיכות כמו merge או deploy. עקרון ה-least privilege חל כאן במלואו: הסוכן מקבל בדיוק את ההרשאות שהוא צריך למשימה הנוכחית, לא יותר.

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

דוגמה מהשטח: מ-Issue ל-Pull Request

נחזור לדוגמת פתיחת המאמר. הסוכן מקבל את הכותרת והתיאור של ה-issue, ומתחיל בשלב Perceive: מריץ grep על מונחים רלוונטיים ("payment", "charge", "webhook"), מזהה שני קבצים מרכזיים, קורא אותם במלואם. בשלב Plan הוא מנסח: "הבעיה נראית כמו race condition בין webhook כפול לבין lock שלא נבדק לפני חיוב - אבדוק את מנגנון ה-idempotency key". בשלב Act הוא מוסיף בדיקת idempotency לפני החיוב, וכותב טסט שמדמה שני webhooks מקבילים. בשלב Verify הטסט נכשל בהתחלה כי ה-lock לא async-safe - הסוכן קורא את השגיאה, מתקן ל-lock אטומי נכון, מריץ שוב, עובר. לבסוף הוא כותב תיאור PR שמסביר את הבעיה ואת התיקון, ומצרף את הבדיקה החדשה כהוכחה.

Trade-offs: אוטונומיה מול שליטה

כל החלטת עיצוב בסוכן קוד היא בעצם נקודה על ציר בין שני קצוות: אוטונומיה מקסימלית (הסוכן מחליט הכל, כולל מתי לעצור, ולעיתים גם ממזג PR בעצמו) מול שליטה הדוקה (כל צעד עובר אישור אנושי). קצה האוטונומיה מהיר יותר ומאפשר להריץ כמה משימות במקביל, אבל הסיכון לטעות שמתגלה מאוחר גדל. קצה השליטה בטוח יותר אבל הופך את הסוכן לכלי עזר איטי שלא באמת חוסך זמן. רוב המערכות בפרודקשן ממקמות את עצמן איפשהו באמצע: אוטונומיה מלאה בתוך branch מבודד ועד לרמת ה-PR, ושער אישור אנושי חובה לפני merge לענף הראשי. הבחירה הזו היא גם פונקציה של סוג המשימה - תיקון טעות כתיב או הוספת טסט יכולים לרוץ עם אוטונומיה גבוהה יותר משינוי בלוגיקת תשלומים.

ציר נוסף הוא מקביליות מול עלות. הרצת כמה סוכנים במקביל על אותו ריפו - כל אחד על issue אחר - מקצרת זמן פיתוח כולל, אבל מגדילה את הסיכון לקונפליקטים בין branches ואת עלות הטוקנים באופן ליניארי. חלק מהצוותים בוחרים להגביל את מספר הסוכנים הפעילים למשאב הצר ביותר - לרוב לא כוח מחשוב אלא היכולת של צוות אנושי לסקור את כל ה-PRs שנוצרים.

ניהול עלות ו-Latency בהרצה אוטונומית ארוכה

משימה שלוקחת סוכן שעה וחצי לרוץ לבד היא לא רק שאלה של תוצאה - היא גם שאלה של עלות. כל קריאה למודל בתוך הלולאה (Perceive, Plan, Act, Verify) צורכת טוקנים, וכשמשימה דורשת עשרות סבבים, העלות המצטברת יכולה להפתיע. שתי טכניקות מרכזיות מקטינות את זה: Prompt Caching שחוסך חישוב חוזר על הקשר קבוע כמו מבנה הריפו, ו-ניתוב חכם בין מודלים - שימוש במודל קטן וזול לצעדים פשוטים כמו הרצת grep, ובמודל חזק רק לצעדי תכנון וקבלת החלטות מורכבים. שילוב נכון של השניים יכול להוזיל הרצה ארוכה משמעותית בלי לפגוע באיכות התוצאה.

טעויות נפוצות בבנייה או שימוש בסוכני קוד

• Context רחב מדי - זריקת ריפו שלם לפרומפט מייקרת, מאיטה, ולעיתים מבלבלת את המודל יותר משהיא עוזרת.
• היעדר שער אימות - לתת לסוכן לסמן "הושלם" בלי הרצת בדיקות אמיתיות.
• הרשאות רחבות מדי - להריץ סוכן עם גישת כתיבה מלאה לפרודקשן בלי sandboxing.
• לולאות אינסופיות - חוסר גבול ברור למספר האיטרציות או לתקציב הטוקנים.
• אמון עיוור בפלט - מיזוג PR שנוצר על ידי סוכן בלי code review אנושי, במיוחד בשינויים רגישים.

שאלות נפוצות

האם סוכן קוד אוטונומי יכול להחליף מפתח אנושי?

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

איך מונעים מהסוכן להזיק לקוד קיים?

שילוב של sandboxing, הרשאות מצומצמות, שערי אישור לפעולות בלתי הפיכות, והרצה על branch נפרד עם code review לפני merge.

מה קורה כשהסוכן לא מצליח לפתור את המשימה?

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

איך שונה סוכן קוד מ-RAG רגיל על תיעוד?

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

איך מודדים אם סוכן קוד באמת עובד טוב?

לא מספיק "הרגשת מפתחים" - צריך מדדים כמותיים: אחוז PRs שנמזגים בלי שינוי מהותי, זמן ממוצע לפתרון per issue, מספר איטרציות ה-verification loop עד הצלחה, ואחוז המקרים שבהם הסוכן דיווח בכנות על כישלון במקום להגיש פתרון שגוי. מערכת evals מסודרת על סוכן קוד אמור לרוץ על מדגם קבוע של issues היסטוריים לפני כל שינוי בפרומפט או במודל, כדי לוודא שהשינוי לא פוגע באיכות.

בניית תשתית מהימנה לסוכני קוד אוטונומיים - מ-sandboxing ועד verification loops - היא בדיוק סוג הפרויקט שמדיה דיל בונה עבור חברות פיתוח. מוזמנים לקרוא על פתרונות ה-AI שלנו או לדבר איתנו ישירות בוואטסאפ.

תגיות: Autonomous Coding Agents · AI Agent · Repository · Claude Code · Verification Loop · Sandboxing · Pull Request

← חזרה לבלוג · צור קשר