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

«این پروژه را بهتر کن» محدودهٔ مشخصی ندارد. دستیار ممکن است همزمان معماری، وابستگی‌ها و رابط کاربری را تغییر دهد؛ بعد پیدا کردن علت رگرسیون دشوار شود. درخواست بهتر یک رفتار مشاهده‌پذیر را هدف می‌گیرد: مثلاً جلوگیری از ثبت تکراری سفارش با همان کلید درخواست.

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

هدف: درخواست تکراری، سفارش تازه نسازد.
محدوده: سرویس سفارش و تست مرتبط.
محدودیت: تغییر قرارداد پرداخت ممنوع.
شاهد پایان: تست تکرار و همزمانی پاس شود.
توقف: نیاز به تغییر دادهٔ واقعی یا قرارداد API.

• رفتار فعلی را با یک درخواست یا تست بازتولید کنید.
• نزدیک‌ترین مسیر اجرای همان رفتار را بخوانید.
• یک تغییر کوچک اعمال و تست شکست‌خورده را اجرا کنید.
• diff را برای تغییر نامرتبط یا حذف کنترل امنیتی مرور کنید.
• شواهد را برای بازبینی انسانی نگه دارید.

این گردش کار نسخهٔ واحدی برای همهٔ پروژه‌ها نیست. در مخزن کوچک، تست کامل سریع است. در سامانهٔ بزرگ ابتدا تست همان ماژول و بعد بررسی‌های مشترک لازم را اجرا می‌کنید. مهم این است که ادعای «درست شد» به نتیجهٔ قابل‌تکرار وصل باشد.

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

یک باگ صفحه‌بندی را انتخاب کنید. ابتدا ورودی و نتیجهٔ درست را بنویسید. به ایجنت اجازه بدهید محل خطا را پیدا کند و اصلاح محدود پیشنهاد دهد. در پایان مستقل از توضیح ایجنت، نتیجه را با درخواست واقعی بررسی کنید. سپس یک ورودی مرزی تازه اضافه کنید تا معلوم شود راه‌حل فقط همان مثال اولیه را حل نکرده است.

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