רוב המפתחים מעריכים סוכני קוד מבוססי AI בצורה לא נכונה. הם מתקינים שלושה כלים, פותחים טרמינל, ומריצים את אותה פקודת "צעצוע": בנה לי דף נחיתה. ואז הם בוחרים בכל אחד מהתוצרים שנראים הכי יפים. המבחן הזה כמעט ולא אומר דבר על האופן שבו המערכות הללו מתפקדות בתוך בסיס קוד (codebase) אמיתי.

השאלה הטובה יותר היא לא איזה מודל קיבל את הציון הגבוה ביותר במבחן ביצועים (benchmark) של קוד. השאלה היא איזה מערכת יכולה לקחת אינטליגנציה גולמית וליישם אותה בפועל על פרויקטי תוכנה מורכבים ורב-קבציים. המודל מספק את המוח. ה-harness — ניהול ההקשר (context), גישה לכלים, טיפול בשגיאות ושכבות הרשאות — מספק את הידיים והעיניים. מוח מבריק עם ידיים מגושמות ישבור את קוד הפרודקשן שלך באותה מהירות כמו מוח בינוני.

הנה מה שבאמת מפריד בין הכלים המובילים כשעוברים מעבר להדגמות (demos) חדשניות ועוברים לעבודה הנדסית.

ה-Harness הוא המוצר

harness של סוכן קובע כיצד האינטליגנציה פועלת בתוך רפוזיטורי (repository). הוא שולט בכמות ההקשר שהסוכן זוכר, באילו קבצים הוא יכול לגעת, כיצד הוא מתאושש מפקודת טרמינל שנכשלה, והאם הוא יודע לעצור לפני שהוא מוחק את קובץ ה-.env שלך. שני סוכנים עשויים לרוץ על מודלים עם ציוני benchmark דומים, אך אם אחד מאבד את הקשר בין הקשרים בין מודולים לאחר שלושה עריכות קבצים בעוד השני שומר על מפה קוהרנטית של הארכיטקטורה שלך, השני יסיים את ה-refactor והראשון יגרום ל-regressions.

חשבו על זה כך: המודל הוא המנוע, אך ה-harness הוא המתלים, הבלמים וההגה. עוצמה לא שווה דבר אם אינכם יכולים להישאר על הכביש.

Claude Code: חשיבה עמוקה על הרפוזיטורי

Claude Code מצטיין כשצריך להבין בסיס קוד מורכב במקום רק להוסיף לו קוד. החוזקה שלו היא שמירה על מודל מנטלי של קשרים בין מודולים. אם אתם עוקבים אחר באג שמתחיל ב-authentication middleware, מתפשט דרך database wrapper, ומופיע ב-validation utility, Claude Code נוטה לשמור על רצף המחשבה. הוא שימושי במיוחד לתכנון refactors גדולים שבהם עליכם לשנות שם של API פנימי, לעדכן כל צרכן (consumer), ולהתאים את הבדיקות מבלי לשכוח import מוצל (shadowed import) בתיקיית utility שנשכחה.

דרך מעשית להפיק ממנו את המירב היא להשתמש בקובץ CLAUDE.md בשורש הפרויקט (project root). מסמך זה משמש כזיכרון ארגוני שניתן לקודד. תוכלו לציין שכל ה-logging חייב להשתמש ב-wrapper הפנימי במקום ב-console.log, ש-database migrations חיים רק ב-/infra/migrations, או שכל קומפוננטת React חדשה זקוקה לקובץ Storybook תואם. ללא המעקה הזה, כל סוכן יסטה לעבר ברירות המחדל של האימון שלו. עם המעקה הזה, Claude Code יכול לכבד מוסכמות (conventions) שלקחו לצוות שלכם חודשים לבסס.

בחרו בכלי זה כאשר העבודה שלכם היא חקירה (exploratory) וארכיטקטונית. אם אתם עושים debugging ללוגיקה מורכבת או מארגנים מחדש את התלות של חבילות (packages) בתוך monorepo, עומק הטיפול בהקשר בדרך כלל משתלם.

OpenAI Codex: אוטומציה מובנית

Codex נבנה עבור צוותים שזקוקים לתוצאות ניתנות לשחזור בקנה מידה גדול. בעוד ש-Claude Code נוטה לכיוון חקירה, Codex נוטה לכיוון אוטומציה. הוא עובד הכי טוב כשמשימות מוגדרות בבירור צריכות להשתלב במערכות הצוות הקיימות: יצירת boilerplate עבור microservice חדש, הקמת (scaffolding) של נקודות קצה (endpoints) מסוג CRUD עם ה-middleware stack הספציפי שלכם, או עדכון קבצי קונפיגורציה לאורך צבא של שירותים.

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

Gemini CLI: תהליכי עבודה פתוחים וניתנים לכתיבת סקריפטים

Gemini CLI מקבל צורה שונה לחלוטין. הוא פחות עוזר קוד שיחתי ויותר רכיב ניתן להרחבה בתוך סביבת הטרמינל שלכם. הוא ניתן לכתיבת סקריפטים ברמה גבוהה, מה שאומר שניתן להעביר אותו (pipe) לתוך תהליכי עבודה סטנדרטיים של Unix, לשלב אותו עם grep, awk, או jq, ולבנות שרשראות כלים (toolchains) מותאמות אישית שאינן דורשות מכם להעתיק ולהדביק בין חלונות צ'אט.

הפתיחות הזו חשובה למהנדסים שמתייחסים לטרמינל כממשק העיקרי שלהם. ניתן להשתמש בו כדי ליצור אוטומטית commit messages מתוך staged diffs, לשכתב shell scripts ישנים ל-Python עם הסברים בתוך הקוד (inline), או לסכם פלט לוגים מ-Kubernetes pod שנכשל. המצב הלא-אינטראקטיבי שלו מעשי במיוחד עבור CI pipelines. ניתן להטמיע אותו ב-GitHub Action או בשלב ב-Makefile כדי לבצע טרנספורמציות קוד קלות, ליצור קטעי תיעוד ממקור הקוד, או לנקות (sanitize) פלט שגיאות לפני פרסומו בערוץ Slack.

אם תהליך העבודה (workflow) שלך כבר בנוי סביב shell scripts וכלים מורכבים (composable tools), Gemini CLI ישתלב בקלות מבלי לבקש ממך לשנות את ההרגלים שלך.

העבודה שבאמת משנה

מחקרים על שיעורי הקבלה של סוכני AI (AI agents) חושפים דפוס שלא יפתיע מהנדסים מנוסים: שינויי תיעוד מאושרים הרבה יותר לעיתים קרובות מאשר עבודה על פיצ'רים חדשים. עדכון docstrings, תיקון הערות (comments) או הרחבת README עונים על נקודות החוזק של סוכן, מכיוון שההקשר מוגבל והסגנון כבר נקבע בתוך ה-repository. עבודה על פיצ'רים חדשים דורשת יצירתיות, חיזוי של edge cases והבנה של כוונת המשתמש שעשויה שלא להיות כתובה בשום מקום. אף כלי בודד לא מנצח בשתי הקטגוריות כי דרישות ה-harness שונות מהיסוד.

זה אומר שההערכה שלך חייבת להתאים לעבודה האמיתית שאתה עושה. אם תבחן רק משימות מוגבלות, כל כלי ייראה כמו גאון.

איפה שסוכנים באמת נשברים

רוב הכשלים מתרחשים בשכבת הביצוע (execution layer), לא בשכבת המודל (model layer). הקוד עשוי להיות מושלם מבחינה תחבירית (syntactically), אך הסוכן עדיין עלול לקרוס בגלל network timeout ל-internal API, פקודת sed שעובדת ב-macOS אך נכשלת ב-GNU/Linux, או מגבלת הרשאות (permission boundary) שהוא לא מזהה. סוכנים מתקשים כאשר:

  • API מחזיר שגיאה זמנית (transient failure) והלולאה ממשיכה להסתובב במקום לבצע back off.
  • כלי מחזיר error stream בפורמט שהסוכן מפרש לא נכון.
  • פקודה דורשת גישת sudo שאין לסוכן, מה שמוביל לתקיעה שקטה (silent hang).
  • טסטים שנוצרו עוברים בבידוד אך נכשלים כשמריצים אותם לצד מסד הנתונים האמיתי כי ה-harness לא הציג את ה-connection string בצורה נכונה.

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

איך להעריך את הכלים האלה באמת

הפסיקו לבחון סוכנים עם פרומפטים כמו build a landing page. זה מודד פלט ויזואלי, לא יכולת הנדסית. במקום זאת, הציבו כל כלי בפני אותה סדרה של משימות אמיתיות:

  • לתקן באג שמתפרס על פני מספר קבצים, שבו סיבת השורש והסימפטום נמצאים בשכבות שונות של ה-stack.
  • לבצע refactor למודול כדי להסיר תלות מיושנת (deprecated dependency) מבלי לשנות התנהגות חיצונית, ואז לוודא שסדרת הטסטים עדיין עוברת.
  • לעדכן כל mock fixture, הגדרת טיפוס (type definition) וטסט אינטגרציה לאחר ש-third-party API משנה את מבנה התגובה שלו.
  • לאבחן build שבור שנגרם על ידי קונפליקט גרסאות ולהציע תיקון שבאמת עובר קומפילציה.

עקבו אחר מדדים קשיחים (hard metrics), לא אחרי תחושות (vibes). ספרו את שיעור ההשלמה (completion rate): האם הסוכן סיים או ויתר באמצע? רשמו כמה תיקונים אנושיים נדרשו לפני שהקוד היה ניתן למיזוג (mergeable). בדקו האם הטסטים עברו בניסיון הראשון או שנדרשו מספר סבבים של טלאים. מדדו את הזמן שמהנדס בכיר השקיע בסקירת הפלט. כלי שכותב מאתיים שורות של קוד ללא רבב הוא חסר ערך אם אתם מבזבזים שעה על אימות שהוא לא נגע בקבצים שהוא היה אמור להשאיר בשקט.

השורה התחתונה

הכלי המנצח הוא לא זה שמייצר הכי הרבה תווים או את הדמו המרשים ביותר. הוא זה שמייצר את הקוד עם הכי הרבה יכולת מיזוג (mergeable) ועם הכי פחות חיכוך בזמן הסקירה (review friction). התחרות בתחום הזה עוברת מאינטליגנציה גולמית של מודלים לעבר engineering harnesses אמינים. בחרו את הסוכן שעיצוב המערכת שלו תואם למרקם העבודה האמיתית שלכם: חשיבה עמוקה (deep reasoning) לניתוחים ארכיטקטוניים, דיוק מובנה לאוטומציה של צוותים, או יכולת הרחבה לטרמינל עבור תהליכי עבודה מותאמים אישית. לאחר מכן, בדקו אותו על כשלים אמיתיים, לא על בעיות צעצוע.

ניתוח זה מתבסס על השוואות ישירות ומחקר התנהגות סוכנים המתואר ב-this detailed breakdown.

לדיונים נוספים על כלי הנדסה ותהליכי עבודה של AI, הצטרפו ל-GyaanSetu learning community.