چرا توسعه‌دهندگان باتجربه نسبت به کدنویسی عاملیت‌محور (Agentic Development) احتیاط می‌کنند؟ — Why are good developers so wary of agentic development?
خلاصه
مقاله جدید Rachel Laycock، مدیر ارشد فناوری Thoughtworks، بررسی می‌کند که چرا برنامه‌نویسان برجسته نسبت به سپردن کامل کدنویسی به ایجنت‌های هوش مصنوعی تردید دارند. این احتیاط نه از روی ترس شغلی، بلکه ناشی از درک فاصله عمیق میان تولید کد و پایداری آن در محیط پروداکشن است.
مقدمه ایجنت‌ها و تردید توسعه‌دهندگان برتر
بسیاری از توسعه‌دهندگان باتجربه و پیشرو که معمولاً در استفاده از ابزارها و روش‌های جدید پیش‌قدم هستند، نسبت به پذیرش صددرصدی «توسعه عاملیت‌محور» یا همان Agentic Development از خود مقاومت نشان می‌دهند. این تردید اغلب به‌اشتباه به ترس از دست دادن شغل یا علاقه شخصی به کدنویسی نسبت داده می‌شود؛ اما ریشه اصلی آن در جای دیگری نهفته است.
تفاوت میان ساخته‌شدن و کارکردن در پروداکشن
توسعه‌دهندگان ارشد سال‌ها تجربه آموخته‌اند که ساختن نرم‌افزار یک چیز است و زنده ماندن آن زیر بار در محیط پروداکشن چیزی دیگر. ایجنت‌های هوش مصنوعی می‌توانند با سرعت سرسام‌آوری حجم انبوهی از کد را تولید کنند، اما پرسش‌های کلیدی مهندسی همچنان پابرجاست:
- آیا رفتار سیستم دقیقاً همان چیزی است که نیاز داریم؟
- آیا مرزهای معماری به درستی رعایت شده‌اند؟
- آیا این کدها در بلندمدت قابل نگهداری و تکامل هستند؟
- وقتی سیستم در پروداکشن دچار خطا شود، چه کسی از آن سر در خواهد آورد؟
تقریباً تمام سیستم‌های پایدار امروزی توسط انسان‌هایی باسابقه و با تکیه بر قضاوت بالینی ساخته شده‌اند. ایجنت‌ها می‌توانند کد بنویسند، اما قضاوت مهندسی و خرد ناشی از تجربه‌ی شکست‌های گذشته را ندارند.
تجربه وایت‌برد در Thoughtworks
شرکت Thoughtworks اخیراً آزمایشی انجام داد که در آن تیمی از مهندسان ارشد و طراحان محصول، تمام کد یک اپلیکیشن را صرفاً با استفاده از ایجنت‌ها و بدون نوشتن مستقیم کد توسط انسان‌ها پیاده‌سازی کردند. نتایج این آزمایش بسیار جالب توجه بود:
- حدود دو سوم از زمان تیم صرف کار روی وایت‌برد، تحلیل دامنه (Domain)، تعیین مرزها و طراحی برنامه‌ای شد که ایجنت‌ها بتوانند بر اساس آن عمل کنند.
- مابقی زمان صرف ساختن سازوکارهای کنترلی (Harness) نظیر تست‌ها، قراردادها و پایپ‌لاین‌های تحویل شد.
- با وجود اینکه اپلیکیشن کار می‌کرد، اما وضعیت بیلد (Build) مدام قرمز بود. ساختاری که در آن بیلد مداوم قرمز باشد، ارزش خود را از دست می‌دهد زیرا تیم دیگر به هشدارها اعتماد نخواهد کرد.
تحقیقات DORA در سال ۲۰۲۵ نیز تأیید می‌کند که اگرچه پذیرش هوش مصنوعی سرعت تحویل نرم‌افزار را بالا برده، اما پایداری تحویل را کاهش داده است؛ چالشی که دقیقا جنبش‌های DevOps و Continuous Delivery برای حل آن به وجود آمده بودند.
نگاه جامعه هکرنیوز
بحث‌های شکل‌گرفته پیرامون این موضوع در Hacker News ابعاد جالبی را روشن می‌کند:
- مسئله مسئولیت‌پذیری: برخی کاربران اشاره می‌کنند که توسعه نرم‌افزار بر پایه یک «شبکه اعتماد» بنا شده است. برنامه‌نویسی جفت (Pair Programming) یا توسعه آزمون‌محور (TDD) انسان‌ها را مسئول نگه‌می‌دارد، اما در کدنویسی ایجنت‌محور این خطر وجود دارد که چون پرامپت خوبی نوشته‌ایم، فرض کنیم نرم‌افزار بی‌نقص است.
- بحران‌های پنهان: یک باگ کوچک پارسینگ یا تنظیم نادرست می‌تواند سیستم‌های حیاتی را از کار بیندازد و ایجنت‌ها می‌توانند با سرعت بالاتری چنین پیچیدگی‌های مخربی را تولید کنند.
- دو روی سکه: در حالی که برخی مدل‌هایی مثل Claude در رفع باگ‌های سخت یا بررسی تغییرات API عالی عمل می‌کنند، اما گاهی فرض‌های کاملاً اشتباهی را پیاده‌سازی می‌کنند.
چرا این موضوع برای مهندسان اهمیت دارد؟
پیام این است که نباید احتیاط توسعه‌دهندگان خوب را به حساب مقاومت در برابر پیشرفت گذاشت. این احتیاط، قطب‌نمای مهندسی در یک مسیر ناشناخته (Backcountry) است که هنوز نقشه‌برداری نشده است. رهبران تیم‌ها باید به این نگرانی‌ها گوش دهند و زمان کافی برای آزمایش‌های واقعی فراهم کنند، و توسعه‌دهندگان نیز باید با آغوش باز اما هوشیارانه به استقبال این ابزارها بروند و الگوهای جدید پایداری را کشف کنند.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل