نوشتهٔ کوامه بواتنگ
کدنویسی با کمک هوش مصنوعی اغلب نسخهای سریعتر از برنامهنویسی دونفره توصیف میشود. اما این مقایسه دیگر بیش از حد محدود است. وقتی یک عامل میتواند یک مخزن را بررسی کند، چندین فایل را تغییر دهد، ابزارها را اجرا کند، یک پیشنمایش بسازد و یک درخواست ادغام باز کند، مسئلهٔ اصلی همکاری دیگر صرفاً این نیست که «آیا میتواند کد بنویسد؟» مسئله این است که «آیا افراد میتوانند ببینند، بررسی کنند، تأیید کنند و بعداً بازسازی کنند که چه اتفاقی افتاده است؟»
به همین دلیل، مهمترین تغییر طراحی در تیمهای نرمافزاریِ مجهز به عامل شاید گذار از پرامپتهای خصوصی به فضاهای کاری قابل مشاهده باشد. برای مثال، Slack Code بهعنوان ترکیبی از کانالهای پروژه با عوامل کدنویسی، ممیزی تفاوتهای کد، پیشنمایش زندهٔ HTML، گردشکارهای بازخورد و تأیید، بایگانی خودکار و گزارشهای ممیزی توصیف شده است. اپلیکیشن Copilot گیتهاب نیز یک پنل «کارهای من» برای سازماندهی مسائل و درخواستهای ادغام در پروژههای مختلف اضافه کرده است. این قابلیتها به سوی یک اصل عملی اشاره دارند: کار یک عامل باید کمتر شبیه پاسخی مبهم و بیشتر شبیه مجموعهتغییری باشد که در یک فرایند تولید کنترلشده پیش میرود.
گفتوگو، سابقهٔ کار نیست
گفتوگو با یک عامل میتواند برای بررسی یک ایده مفید باشد، اما سابقهٔ قابل اتکایی نیست. جزئیات مهم ممکن است در یک رشتهٔ طولانی مدفون شوند: کدام فایلها تغییر کردهاند، کدام فرمانها اجرا شدهاند، عامل چه فرضهایی داشته، بازبین چه چیزی را رد کرده و آیا نتیجهٔ نهایی با پیشنهاد اولیه تفاوت دارد یا نه.
یک فضای کاری ماندگار این جزئیات را قابل بررسی میکند. این فضا باید درخواست را به یک مخزن یا پروژهٔ مشخص متصل کند، برنامهٔ عامل را حفظ کند، اقدامات ابزارها و تغییرات فایلها را نشان دهد، به آزمونها و پیشنمایشها پیوند بدهد و ثبت کند چه کسی نتیجه را تأیید کرده است. رابط دقیق میتواند متفاوت باشد—ردیاب مسئله، درخواست ادغام، کانال همکاری یا کنسول عامل—اما اطلاعات باید پس از پایان جلسه نیز باقی بماند.
این موضوع فقط برای رعایت مقررات مهم نیست؛ دلایل معمول مهندسی نیز دارد. اگر دو هفته بعد یک باگ ظاهر شود، تیم به چیزی بیش از تفاوت نهایی نیاز دارد. ممکن است لازم باشد نیازمندی اولیه، برنامهٔ تولیدشده، شواهد آزمون، نظر بازبین و این موضوع را بداند که آیا انسانی صراحتاً یک مصالحهٔ پرریسک را پذیرفته است یا نه. یک سابقهٔ ماندگار، این بررسی را کوتاهتر میکند.
پنج لایهٔ کار قابل مشاهده
تیمهایی که عوامل کدنویسی را به کار میگیرند میتوانند با هر تغییر مانند یک پروندهٔ کوچک و قابل بررسی برخورد کنند. پنج لایه بهویژه مفیدند:
- هدف: مسئله، معیارهای پذیرش، محدودیتها و دامنهٔ درخواستی.
- برنامه: رویکرد پیشنهادی عامل پیش از ویرایش فایلها. برای یک کار غیرساده، این یک نقطهٔ کنترل برای تأیید است، نه چیزی تزئینی.
- تفاوت: افزودنها، حذفها، تغییرات وابستگی، ویرایشهای پیکربندی و داراییهای تولیدشدهٔ دقیق.
- شواهد: نتایج آزمون، خروجی lint، بررسیهای امنیتی، نماگرفتها و در صورت مرتبط بودن، پیشنمایش زنده یا قابل استقرار.
- گزارش تصمیم: نظرات بازبین، تغییرات درخواستی، تأیید، رد، بازگردانی یا کار پیگیری.
هدف این نیست که هر تغییر را از یک کمیتهٔ سنگین عبور دهیم. یک غلط تایپی و تغییری در جریان پرداخت نباید کنترلهای یکسانی داشته باشند. هدف این است که میزان موشکافی با اثر بالقوه متناسب باشد.
تأییدها باید به اقدامات گره بخورند
«انسان در حلقه» برای اینکه یک کنترل مفید باشد، بیش از حد مبهم است. ممکن است فردی برنامه را بدون دیدن تفاوت نهایی تأیید کند، یا تغییر کد را تأیید کند بیآنکه متوجه شود عامل یک فایل استقرار را نیز تغییر داده است. گردشکارهای بهتر مشخص میکنند که هر تأیید چه چیزی را مجاز میکند.
برای مثال، یک تیم ممکن است به عامل اجازه دهد یک مخزن را بخواند و آزمونهای محلی را بهطور خودکار اجرا کند، پیش از نوشتن خارج از شاخهٔ تعیینشده تأیید بخواهد و پیش از ادغام یا استقرار نیز تأیید جداگانهای لازم بداند. عامل میتواند یک مهاجرت پایگاه داده را پیشنهاد کند، اما از اجرای آن در محیط تولید منع شود. رویکرد پیشنهادی امارات متحدهٔ عربی برای طبقهبندی اینکه عاملها کدام وظایف را میتوانند کامل کنند و کدام را صرفاً توصیه کنند، بازتاب همین الگوی گستردهتر است: خودمختاری باید بر اساس وظیفه تخصیص داده شود، نه اینکه بهطور کلی فرض گرفته شود.
تأییدها همچنین به دامنه و تاریخ انقضا نیاز دارند. تأیید «بهروزرسانی متن صفحهٔ فرود» نباید بیسروصدا مجوز افزودن یک بستهٔ تحلیلی جدید را بدهد. برنامهای که دیروز تأیید شده نباید امروز خودکاراً شامل تفاوتی شود که بهطور اساسی تغییر کرده است. رابط باید این مرزها را آشکار کند.
پیشنمایشها، بررسی را به بازرسی تبدیل میکنند
بررسی کد اغلب زمانی آسانتر است که افراد بتوانند نتیجه را ببینند، نه اینکه آن را از روی فایلهای منبع استنباط کنند. یک پیشنمایش زندهٔ HTML میتواند فاصلهگذاری خراب، وضعیتهای مفقود، کنترلهای غیرقابل دسترس یا تغییری ناخواسته در ناوبری را آشکار کند؛ چیزهایی که بازبین ممکن است در یک تفاوت متنی نادیده بگیرد.
پیشنمایشها اثبات درستی نیستند. آنها باید در کنار آزمونها و بررسی منبع قرار بگیرند، نه جایگزین آنها شوند. اما یک موضوع مشترک برای گفتوگو ایجاد میکنند: بازبین میتواند به صفحه، وضعیت یا تعامل مشخصی اشاره کند و بازخوردش را به تغییر پیشنهادی پیوست کند.
این موضوع زمانی که افراد غیرمتخصص نیز در بررسی حضور دارند، ارزش ویژهای دارد. یک مدیر محصول شاید نتواند تغییر چارچوب را ارزیابی کند، اما ممکن است فرد مناسبی برای تأیید تطابق گردشکار با نیازمندی باشد. یک طراح میتواند پسرفت بصری را اعتبارسنجی کند. یک متخصص امنیت میتواند بر مجوزها و نحوهٔ مدیریت داده تمرکز کند. فضای کاریِ مجهز به عامل میتواند هر پرسش را به فردی ارجاع دهد که بهترین جایگاه را برای پاسخدادن به آن دارد.
تفاوتها به زمینه نیاز دارند، نه فقط رنگ
تفاوت آشنای قرمز و سبز همچنان ضروری است، اما تغییرات تولیدشده توسط عامل میتوانند آنقدر گسترده باشند که بازبین را سردرگم کنند. تیمها باید از عاملها بخواهند commitها یا گروههای تغییر را محدود نگه دارند، توضیح دهند چرا هر فایل مهم تغییر کرده است و فایلهای تولیدشده یا فروشنده را جداگانه مشخص کنند.
پرسشهای مفید برای بازبینی عبارتاند از:
- چه رفتار قابلمشاهدهای برای کاربر تغییر کرده است؟
- کدام فایلها صرفاً برای پشتیبانی از پیادهسازی تغییر کردهاند؟
- عامل دربارهٔ رفتار موجود چه فرضهایی داشته است؟
- کدام آزمونها اضافه یا اصلاح شدند، یا اجرا نشدند؟
- آیا این تغییر میتواند بر مجوزها، نگهداشت داده، صورتحساب یا APIهای خارجی اثر بگذارد؟
این پرسشها بازبینی را از یک درخواست مبهمِ «نگاهی به این بیندازید» به بررسیای تکرارپذیر تبدیل میکنند. همچنین به آشکار شدن یک حالت شکست رایج کمک میکنند: قابلیتی ظاهراً معقول که با بهروزرسانی ناقص آزمونها یا تغییری تصادفی در پیکربندی همراه است.
استدلالهای مهم را بایگانی کنید
حفظ تکتک توکنهای هر گفتوگوی مدل، خودبهخود مفید نیست. تاریخچههای طولانی میتوانند پرهزینه باشند و جستوجو در آنها دشوار شود، و پژوهشهای مربوط به فشردهسازی زمینه هشدار میدهند که خلاصهها ممکن است اطلاعات مهمی را از دست بدهند. بنابراین، یک ردپای حسابرسی عملی باید بهجای ذخیرهٔ بیتمایز همهچیز، مصنوعات مرتبط با تصمیم را حفظ کند.
حداقل، درخواست، برنامهٔ تأییدشده، diff نهایی، نتایج ابزارها و آزمونها، مرجع پیشنمایش یا استقرار، تصمیمهای بازبین، و هر استثنای اعطاشده را نگه دارید. اگر عاملی از منابع خارجی استفاده کرده یا اسناد داخلی را بازیابی کرده است، ارجاعهای مرتبط به منابع و نقطهای را که این منابع بر تغییر اثر گذاشتهاند ثبت کنید. برای کارهای پرخطر، نگهداشتن گزارش کامل تعامل و اجرا ممکن است موجه باشد.
هرجا اهمیت موضوع ایجاب میکند، سوابق را بهگونهای ثبت کنید که دستکاریشدنشان آشکار باشد، و پیش از وقوع بحران، قواعد نگهداری را تعریف کنید. ردپای حسابرسیای که با بایگانی شدن یک کانال ناپدید میشود—یا نمیتواند نتیجهٔ اصلاحشده را از نتیجهٔ اصلی متمایز کند—از یک بررسی جدی پشتیبانی نخواهد کرد.
این موضوع چه تغییری برای مشاغل نرمافزاری ایجاد میکند
مهارت نوظهور صرفاً نوشتن پرامپتهای بهتر نیست. مسئله، طراحی کاری است که شخص دیگری بتواند آن را بررسی و به آن اعتماد کند. توسعهدهندگان باید در تعیین معیارهای پذیرش، تجزیهٔ وظایف، بازبینی diffها در مقیاس وسیع، ساخت آزمونهای معنادار، و تصمیمگیری دربارهٔ زمان توقف عامل و درخواست راهنمایی مهارت داشته باشند.
متخصصان محصول و طراحی نقش بزرگتری در بازبینی پیشنمایشها و روشنکردن منظور خواهند داشت. مهندسان QA میتوانند به تعریف دروازههای تأیید و موارد شکست کمک کنند. مدیران مهندسی باید بهرهوری را بدون پاداش دادن به ریسکپذیری نامرئی اندازهگیری کنند. نویسندگان فنی و متخصصان عملیات نیز میتوانند با ماندگار کردن تصمیمها، استثناها و راهنماهای اجرایی مشارکت کنند.
یک تمرین مفید این است که یک قابلیت معمولی را انتخاب کنید و زنجیرهٔ شواهد آن را ترسیم کنید: درخواست، برنامه، شاخه، diff، آزمونها، پیشنمایش، تأیید، انتشار و بازگردانی. سپس بپرسید همکار آینده در کجا ناچار خواهد بود حدس بزند. هر حدس، نامزدی برای یک فضای کاری بهتر، مجوزی روشنتر یا سابقهای ماندگارتر است.
یک قاعدهٔ عملی ساده
به عاملها اجازه دهید در مسیری قابلمشاهده و برگشتپذیر، سریع حرکت کنند. فضای کاری مشخصی در اختیارشان بگذارید، اقدامات حساس را محدود کنید، در مرزهای معنادار تأیید بخواهید، شواهد را به تغییر پیوست کنید و تصمیم نهایی را حفظ کنید. هدف این نیست که خودکارسازی را آنقدر کند کنیم تا شبیه کدنویسی دستی شود؛ هدف این است که سرعت را با پاسخگویی سازگار کنیم.
در توسعهٔ یاریگرفته از عاملها، بهترین همکار سیستمی نیست که در انزوا بیشترین کد را تولید میکند. بهترین سیستم، سیستمی است که کارش قابلفهم، قابلچالش، قابلتأیید، قابلبرگشت و قابلیادگیری باشد.
