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

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

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

שינוי ההרגל

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

זה חזק, אבל זה מסיט את הבעיה. השאלה היא כבר לא רק "האם הדגם יכול לתכנת?". השאלה הופכת:

• האם נתתי לו היקף קטן מספיק?
• אתה יודע איך לבדוק את התוצאה?
• האם אני עובד בסביבה מבודדת?
• האם הביקורת הסופית עדיין אנושית וזהירה?

זרימת עבודה בריאה נראית יותר כך מאשר שרביט קסמים:

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

ההנחיה הטובה היא כמעט כרטיס טוב

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

הנחיה מועילה משעממת יותר. לדוגמה: יישמו ייצוא CSV עבור דף החשבוניות, בידיעה שהטבלה נמצאת ב-app/(dashboard)/invoices/page.tsx, השאילתות נמצאות ב-src/server/invoices.ts וכבר יש דפוס דומה ב-app/(dashboard)/reports.

לאחר מכן הוסף אילוצים ברורים: אל תשנה את סכימת מסד הנתונים, אל תוסיף תלות אם מספיקה כלי עזר קטן, שמור על סגנון ממשק המשתמש הקיים. וסגור עם האימות: npm test -- invoices וnpm run build.

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

שלוש משרות שאני מאציל ברצון

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

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

השלישית היא עבודת תחזוקה חוזרת: עדכוני תלות קטנים, ניקוי של דגלי תכונה ישנים, סיכום של PRs חסומים, בדיקת TODOs שנשכחו. זה לא זוהר, אבל זה בדיוק סוג העבודה שנוטה להיערם.

שלוש עבודות שאני שומר על בני אדם

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

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

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

הביקורת אינה אופציונלית

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

אני תמיד מסתכל על לפחות חמישה דברים:

1. האם התיקון פותר רק את המשימה המבוקשת?
2. האם הוא נגע בקבצים שלא קשורים לזה?
3. האם המבחנים מכסים התנהגות חדשה או סתם סיכוי שמח?
4. האם הקוד עוקב אחר דפוסים מקומיים?
5. האם השגיאות מטופלות כמו בשאר הפרויקט?

כשמשהו לא בסדר, המשוב צריך להיות ספציפי. "תקן את זה" זה עצלן. טוב יותר: כלי זה משכפל את parseMoney לתוך src/lib/money.ts; השתמש מחדש בפונקציה הזו, הוסף בדיקה למקרה של EUR ואל תשנה את ה-API הציבורי של מודול החיוב.

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

מעקות בטיחות שווה את המאמץ

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

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

הגבל הרשאות. פקודות כמו rg, git diff, npm test וnpm run build יכולות להיות די חינמיות. פריסות, העברת מסדי נתונים, גישה לסודות ופקודות הרסניות חייבות להישאר מפורשות.

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

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

דרך קלה להתחיל כצוות

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

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

אחרי שבועיים הייתי מסתכל על הנתונים: אילו משימות באמת זירזו, אילו ביקורות היו כבדות, אילו הנחיות היו מבלבלות, אילו חלקים של בסיס הקוד שבריריים מכדי להאציל.

זו גישה פחות מרהיבה מ"מהיום נעשה הכל עם הסוכנים", אבל היא זו שמאפשרת להגיע לשבוע השלישי בלי חרטות.

החלק הכי אנושי

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

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

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

מקורות שימושיים

• קודקס עבור (כמעט) הכל - OpenAI
• הפעלת Codex בבטחה ב-OpenAI
• הכירו את Codex - OpenAI
• מה חדש עם סוכן הקידוד של GitHub Copilot