Code Agents: Writing Code Is the Easy Part - Let's Talk About the Rest

Code agents כבר יודעים לכתוב קוד. זה החלק הקל. השאלה המעניינת היא מה קורה בכל שאר היום: ה-PR שמחכה, הטסטים שהצטברו, השירות שאף אחד לא מכיר, ה-query שמכביד על ה-database, וה-secret שנשאר בטעות ב-Git. שחר פולק מציג בהרצאה הזאת איפה agent יכול לקצר עבודה אמיתית - ואיפה אסור לתת לו להחליף שיפוט אנושי.

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

Code agents מתחילים איפה שהקוד נגמר

שחר מבחין בין chat, assistant ו-agent. ב-chat מכניסים שאלה ומקבלים תשובה. assistant כבר עובד מול API. agent, לפי ההגדרה שהוא מציע, מקבל משימה ואז יכול לפנות ל-assistants אחרים, לכלים ול-API עד שהוא מחזיר את ה-output של המשימה.

זה משנה כי יום פיתוח אינו רצף של prompts. שולחים PR, מחכים ל-review, מתקנים ומחכים שוב. שחר לא מציע לזרוק את ה-review האנושי. הוא מדגיש את הערך של אדם שעובר על הקוד, נותן רפלקציה ומאתגר את ההחלטה. אבל הרבה מהמשוב אפשר לקבל מוקדם יותר: בדיקה מול conventions, כללים שהארגון הגדיר ודפוסים חוזרים. כשה-feedback מגיע בתוך שניות במקום אחרי שעות או ימים, ה-feedback loop מתקצר והמפתח מגיע ל-review האנושי עם פחות רעש.

יותר tests לא בהכרח אומר יותר ביטחון

LLMים מגדילים את כמות הבדיקות שנכנסת ל-repository. מכאן קל להגיע לסיסמה של 100% coverage. שחר עוצר שם: אפשר להגיע ל-100% coverage ולא לבדוק שום דבר מועיל. המדד לא מספר אם הבדיקה נוגעת בסיכון אמיתי, אם היא כפולה, או אם היא פשוט מאטה את כל ה-pipeline.

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

זה לא רק עניין של עלות מכונות ב-CI/CD. יותר בדיקות פירושו גם המתנה ארוכה יותר למפתח, כלומר Developer Experience גרוע יותר. כאן ה-agent לא מחליף החלטה על איכות. הוא מציף את העבודה שאף אחד לא רוצה לעשות ידנית, כדי שהצוות יחליט מה באמת שווה להריץ.

תיעוד חי הופך ידע ארכיטקטוני לזמין

legacy code אינו הופך לברור רק כי מישהו ביקש עליו תיעוד. שחר מספר על mega repo שבנה חבר בצוות: הוא עובר על repositories אחרים, מייצר תיעוד מרוכז ומתעדכן מחדש דרך GitHub Action כשמשהו משתנה. התוצאה היא לא רק wiki מסודר יותר. היא דרך לשאול שאלות על הביזנס ועל הקוד ולקבל תשובה שמחברת בין services, tables והרשאות.

לפי הדוגמה, השכבה הזאת מאפשרת להבין מי יכול להקפיא הרשאה למשתמש, גם כשהתשובה פרוסה על פני כמה services ו-tables. היא גם מוציאה ידע ארכיטקטוני מידי “זקני השבט”: אפשר להבין איך services מתקשרים, מתי יש queue ומתי HTTP request, לבצע תכנון ראשוני ואז לעשות review מהיר יותר עם הארכיטקט.

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

MCP הוא החיבור בין ה-agent לעבודה האמיתית

בהתחלה שחר התייחס ל-MCP כהייפ. אחר כך הוא ראה מה קורה כשמחברים כלים. מתוך CLI אחד אפשר למשוך ticket מ-Jira, לקרוא context מ-Confluence, לעבור ל-GitHub כדי לפתוח pull request, ולעדכן Terraform או להריץ פעולות CI/CD. במקום לקפוץ בין חמש או שש מערכות, העבודה נשארת באותו interface.

MCP גם נותן ל-LLM “עיניים”. בדוגמה מההרצאה, חיבור ל-Puppeteer אפשר לבקש בדיקת performance ו-network על חנות חדשה. הדוח מצא תמונות שנטענו מ-S3 במקום CDN, תמונות 4K למובייל והזדמנות ל-lazy loading עבור תוכן below the fold. זו לא יכולת שאי אפשר לגלות ידנית. היתרון הוא להגיע לאבחנה ולתכנית mitigation בשניות במקום להרחיב את אותה בדיקה על פני שעות.

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

מה מחפשים ב-database ובפרודקשן

ההרצאה יורדת לפרקטיקה. בארגון של שחר משתמשים ב-ORM, אבל בסוף ה-ORM מתורגם ל-SQL. agent שמחובר ב-read-only ל-database ול-logs ב-DataDog יכול לעבור על הקוד ולחפש N+1, בעיות ביצועים וטבלאות שאינדקס עשוי לשפר. הפלט אינו שינוי אוטומטי ב-production, אלא דוח: מה לבדוק, מה צפוי להשתנות ומה רמת הקושי של התיקון.

בדיבוג, שחר מזכיר את Sentry ואת Seer: לא רק התראה על exception שלא טופל, אלא גם הצעה לשורת הקוד, לכיוון פתרון ולמי שכתב אותו דרך Git blame. המהירות כאן חשובה. כשדבר נשבר בפרודקשן, agent טוב מקצר את החיפוש. הוא לא פוטר את הצוות מלבדוק את ההסבר שלו.

אבטחה לא מחכים אליה לשחרור הגדול

security scan הוא עוד מקום שקל לדחות. הוא כואב, מגיע לפני release גדול או דרישת ISO, ולכן לא תמיד מריצים אותו כל הזמן. שחר מביא סיפור אישי על SDK פומבי ב-Python ועל קובץ .env שלא הוחרג. גם בלי push, ה-branch וה-secrets נשארו בהיסטוריית Git.

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

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

• code agent מועיל כשהוא מקצר feedback וחקירה, לא כשהוא רק מייצר עוד קוד.
• PR review אנושי נשאר. AI יכול להכין את הקרקע ולסנן רעש לפניו.
• 100% coverage אינו מדד לאיכות. חפשו tests חסרים, מיותרים וכפולים.
• תיעוד שמתעדכן אוטומטית מאפשר לשאול שאלות טובות יותר על systems, ארכיטקטורה ו-onboarding.
• חיבור MCP לכלים חוסך קפיצות בין מערכות, אבל גישה לנתונים חייבת להיות תחומה - למשל read-only.
• בפרודקשן ובאבטחה, הערך של agent הוא לזהות מהר, להציע כיוון ולהשאיר את ההחלטה והאחריות אצל הצוות.