اولین باری که یک عامل کدگذاری واقعاً یک باگ را برای شما برطرف می کند، واکنش تقریباً همیشه یکسان است: ترکیبی از اشتیاق و سوء ظن. خوبه، حتما اما سپس به تفاوت نگاه می‌کنید و از خود می‌پرسید: "بسیار خوب، اما او دقیقاً چه چیزی را لمس کرد؟ آیا می‌توانم به او اعتماد کنم؟ آیا فردا دوباره به همان روش این کار را انجام خواهد داد؟".

اینجاست که فکر می کنم قسمت جالب شروع می شود. نه زمانی که عامل یک تابع را می نویسد، بلکه زمانی که به اندازه کافی قادر به انجام کارهای کامل می شود: مخزن را بخوانید، یک پچ ایجاد کنید، آزمایش ها را اجرا کنید، یک PR را باز کنید، پس از یک نظر بازبینی برگردید. Codex دقیقاً در این جهت حرکت می کند: کار پس زمینه، درخت کاری جداگانه، مرورگر یکپارچه، اتوماسیون، پلاگین، حافظه و کنترل های مجوز صریح تر.

نکته این نیست که آینده ای را تصور کنید که در آن هیچ کس دیگر کد نمی خواند. این آینده ای وحشتناک و همچنین کاملا ساده لوحانه خواهد بود. نکته این است که بفهمیم چگونه با عواملی کار کنیم که می توانند کارهای زیادی انجام دهند بدون اینکه به آنها اجازه انجام همه کارها را بدهند.

تغییر عادت

با تکمیل خودکار سنتی شما همیشه در فرمان بودید. هوش مصنوعی خطی را پیشنهاد کرد، شما تصمیم گرفتید. با این حال، با یک نماینده، رابطه تغییر می کند: شما به او هدف می دهید و او چندین مرحله را به تنهایی طی می کند.

این قدرتمند است، اما مشکل را تغییر می دهد. سوال دیگر فقط این نیست که "آیا مدل می تواند برنامه ریزی کند؟". سوال می شود:

• آیا به او محدوده به اندازه کافی کوچک دادم؟
• آیا می دانید چگونه نتیجه را بررسی کنید؟
• آیا من در یک محیط ایزوله کار می کنم؟
• آیا بررسی نهایی هنوز انسانی و دقیق است؟

یک گردش کار سالم بیشتر شبیه این است تا یک عصای جادویی:

کمتر رمانتیک به نظر می رسد تا "عامل همه چیز را می سازد"، اما بسیار بهتر عمل می کند. و همچنین نحوه کار تیم هایی است که با انسان ها خوب هستند: وظایف روشن، بازخورد سریع، مسئولیت پذیری صریح.

اعلان خوب تقریباً یک بلیط خوب است

خطرناک‌ترین اخطار، مبهم اما مطمئن است: "صفحه فاکتورها را اصلاح کنید"، "معماری را بهبود بخشید"، "پاکسازی ماژول احراز هویت". اینها درخواست هایی هستند که سازنده به نظر می رسند و تفاوت های زیادی ایجاد می کنند. اما بعد متوجه می شوید که مشغول باستان شناسی هستید.

یک پیام مفید خسته کننده تر است. به عنوان مثال: اجرای صادرات CSV برای صفحه فاکتورها، با دانستن اینکه جدول در app/(dashboard)/invoices/page.tsx است، پرس و جوها در src/server/invoices.ts هستند و از قبل الگوی مشابهی در app/(dashboard)/reports وجود دارد.

سپس محدودیت‌های واضح اضافه کنید: طرح پایگاه داده را تغییر ندهید، اگر یک ابزار کوچک کافی است، وابستگی اضافه نکنید، سبک رابط کاربری موجود را حفظ کنید. و با تأیید ببندید: npm test -- invoices و npm run build.

این نوع خلاصه برای "توضیح بهتر برای هوش مصنوعی" نیست. این بیش از هر چیز به شما کمک می کند تا آنچه را که به شما تفویض می کنید روشن تر کند. اگر نمی توانید آن را به طور مشخص بنویسید، شاید کار هنوز برای یک نماینده آماده نشده باشد.

سه شغلی که با کمال میل محول می کنم

اولی کار تکراری اما قابل تأیید است: افزودن آزمایش‌ها، انتقال تماس‌ها به یک API داخلی جدید، به‌روزرسانی واردات، جایگزینی مؤلفه‌های منسوخ، رفع خطاهای TypeScript. در اینجا نماینده می تواند ساعت ها را ذخیره کند و خطر قابل کنترل است.

دوم کار اکتشافی است: "این کل کجا محاسبه می شود"، "برای من توضیح دهید که چرا این تست شکننده است"، "اشکال را دوباره تولید کنید و به من بگویید به نظر می رسد کدام فایل ها تحت تاثیر قرار گرفته اند". حتی زمانی که فوراً پچ تولید نمی کند، می تواند شناسایی مفیدی انجام دهد.

سومین کار تعمیر و نگهداری مکرر است: به‌روزرسانی‌های کوچک وابستگی، پاک‌سازی پرچم‌های ویژگی قدیمی، خلاصه‌ای از PR مسدود شده، بررسی TODO‌های فراموش‌شده. این پر زرق و برق نیست، اما دقیقاً نوعی از کار است که تمایل به انباشته شدن دارد.

سه شغلی که من انسان نگه می دارم

تصمیمات محصول انسانی باقی می ماند. اگر تغییری نحوه پرداخت کاربر را تغییر دهد، داده‌ها را حذف کند، قیمت‌ها را ببیند یا یک مجوز را درک کند، من یک فرد مسئول می‌خواهم.

مرزهای امنیتی نیز مستحق توجه انسان هستند: اعتبار، نقش ها، نشانه ها، ثبت داده های حساس، انتقال پایگاه داده. یک عامل می تواند به اجرا کمک کند، اما نباید تنها تصمیم گیرنده باشد.

در نهایت، من هر چیزی را که نیاز به ذوق معماری داشته باشد، نگه می دارم. یک عامل می‌تواند یک Refactor را پیشنهاد کند، اما درک اینکه آیا یک انتزاع واقعاً ضروری است یا اینکه آیا ما فقط مشکلی را که وجود ندارد صیقل می‌دهیم، کار باقی می‌ماند.

بررسی اختیاری نیست

وسوسه، وقتی یک عامل خوب است، اعتماد به سبز CI است. قابل درک است. همچنین زمانی است که مشکلات شروع می شود.

من همیشه حداقل به پنج چیز نگاه می کنم:

1. آیا پچ فقط وظیفه درخواستی را حل می کند؟
2. آیا او فایل هایی را که ربطی به آن نداشتند، لمس کرده است؟
3. آیا آزمون‌ها رفتار بدیع را پوشش می‌دهند یا فقط شانس خوشحال کننده را؟
4. آیا کد از الگوهای محلی پیروی می کند؟
5. آیا خطاها مانند بقیه پروژه ها رسیدگی می شود؟

وقتی چیزی اشتباه است، بازخورد باید مشخص باشد. "اصلاحش کن" تنبل است. بهتر: این ابزار parseMoney را به src/lib/money.ts کپی می کند. دوباره از آن تابع استفاده کنید، یک آزمایش برای مورد EUR اضافه کنید و API عمومی ماژول صورت‌حساب را تغییر ندهید.

نمایندگان به نظرات کوچک و قابل تأیید بسیار بهتر پاسخ می دهند. عجیب است که مردم هم همینطور.

نرده های محافظ ارزش تلاش را دارد

اگر یک عامل بتواند فایل‌ها را بخواند، کد بنویسد و دستورات را اجرا کند، باید به عنوان یک فرآیند قدرتمند تلقی شود. نیازی به پارانویا نیست، شما نیاز به بهداشت دارید.

از درخت ها یا شاخه های جداگانه استفاده کنید. بنابراین می‌توانید تفاوت‌ها را مقایسه کنید، آزمایش‌های ناموفق را دور بریزید، و کار عامل را با کاری که انجام می‌دادید مخلوط نکنید.

محدود کردن مجوزها دستوراتی مانند rg، git diff، npm test و npm run build می توانند کاملا رایگان باشند. استقرار، انتقال پایگاه داده، دسترسی به اسرار و دستورات مخرب باید صریح باقی بماند.

دسترسی به شبکه را زمانی که به آن نیاز ندارید کاهش دهید. برای بسیاری از وظایف، اسناد رسمی، رجیستری بسته و خدمات داخلی خاص کافی است. سطح کمتر، شگفتی های کمتر.

ردیابی اقدامات هنگامی که یک وصله در حال بررسی قرار می‌گیرد، باید بتوانید دستورات، دستورات اجرا شده، تست‌های پاس شده و فایل‌های اصلاح شده را بازسازی کنید. نه برای ایجاد بوروکراسی، بلکه برای اینکه بتوانیم بفهمیم اگر مشکلی پیش بیاید چه اتفاقی افتاده است.

یک راه آسان برای شروع به عنوان یک تیم

اگر بخواهم عوامل را به یک تیم کوچک معرفی کنم، بدون انقلاب های بزرگ شروع می کنم.

من یک برچسب agent-ready برای مسائل با دامنه واضح ایجاد می کنم. من یک الگو با زمینه، محدودیت ها و دستورات تأیید اضافه می کنم. من می خواهم برای روابط عمومی کوچک، به طور ایده آل زیر چند صد خط. برای تغییرات قابل مشاهده به آزمایش یا اسکرین شات نیاز دارم. و مهمتر از همه، من فردی را مسئول ادغام نگه می دارم.

بعد از دو هفته به داده‌ها نگاه می‌کردم: کدام کارها واقعاً سریع‌تر شده‌اند، کدام بررسی‌ها سنگین بودند، کدام درخواست‌ها گیج‌کننده بودند، کدام بخش‌های پایگاه کد برای واگذاری آن‌قدر شکننده هستند.

این رویکردی کمتر تماشایی نسبت به "از امروز همه کارها را با عوامل انجام خواهیم داد" است، اما این رویکردی است که به شما امکان می دهد بدون پشیمانی به هفته سوم برسید.

انسانی ترین بخش

نکته خنده‌دار این است که هرچه عوامل مستقل‌تر شوند، مهارت‌های کلاسیک دوباره اهمیت بیشتری پیدا می‌کنند: نوشتن یک بلیط خوب، ایجاد برش‌های کوچک، ایجاد تست، خواندن تفاوت‌ها، برقراری ارتباط. عامل به کسانی که قبلاً می دانند چگونه خوب کار کنند سرعت می بخشد. همچنین هرج و مرج کسانی را که بد تفویض می کنند، تشدید می کند.

بنابراین نه، من گردش کار چند عاملی را میانبری برای توقف انجام مهندسی نمی بینم. من آن‌ها را راهی برای انتقال انرژی بیشتر به بخش‌های مهم می‌دانم: تصمیم‌گیری برای ساخت چه چیزی، اطمینان از کارکرد آن، قابل فهم نگه داشتن سیستم.

نمایندگان می توانند همکاران ناهمزمان عالی بسازند. اما یک همکار ناهمزمان، برای مفید بودن، نیاز به زمینه، مرزها و بررسی دارد. درست مثل بقیه.

منابع مفید

• Codex برای (تقریبا) همه چیز - OpenAI
• اجرای کدکس با خیال راحت در OpenAI
• معرفی Codex - OpenAI
• چیزهای جدید با عامل کدنویسی GitHub Copilot