تصور کنید یک عامل هوش مصنوعی گردش‌کاری می‌سازد که در ظاهر بی‌نقص است، اما در عمل شکست می‌خورد چون یک فیلتر حیاتی حذف شده و به‌جای سه ردیف داده، شش ردیف برمی‌گرداند. این مورد خاص که در ۱۱ اکتبر ۲۰۲۶ توسط یکی از بنیان‌گذاران در وب‌سایت dev.to به اشتراک گذاشته شد، نشان‌دهنده یک بحران رو به رشد در مهندسی نرم‌افزار است: ابزارها سریع‌تر از نقش‌های انسانی تکامل می‌یابند.
برای دهه‌ها، بسیاری از سازمان‌ها مانند یک خط تولید ساده عمل می‌کردند. مدیران محصول نیازمندی‌ها را تعریف می‌کردند، لیدها آن‌ها را به تیکت‌های کوچک‌تر تقسیم می‌کردند و توسعه‌دهندگان کد را پیاده‌سازی می‌کردند. این جداسازی اجرای فنی از تصمیم‌گیری‌های تجاری برای دوران کدنویسی دستی به خوبی جواب می‌داد، اما وقتی عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای هوشمندی که می‌توانند به‌جای شما ابزارها را اجرا کنند — مسئول پیاده‌سازی می‌شوند، یک نقطه کور خطرناک ایجاد می‌شود. این چالش با شکاف عمیق میان دموهای جذاب و استقرار واقعی در مقیاس صنعتی همسو است که نشان می‌دهد چرا بسیاری از پروژه‌ها در محیط عملیاتی شکست می‌خورند.
زمینه و بستر «فرهنگ تیکتی»
برای سال‌ها، تیم‌های توسعه در یک چرخه پیش‌بینی‌پذیر کار می‌کردند: نیازمندی‌ها تعریف می‌شدند، به تیکت تبدیل می‌شدند، پیاده‌سازی می‌شدند، تست می‌شدند و در نهایت ادغام (Merge) می‌شدند. این سیستم توسعه‌دهندگان را تشویق می‌کرد تا صرفاً روی اجرای فنی یک تیکت خاص تمرکز کنند، به‌جای آنکه به هدف گسترده‌تر کسب‌وکار فکر کنند.
اکنون سازمان‌ها همین توسعه‌دهندگان را به ابزارهای کدنویس مجهز می‌کنند. ناگهان انتظارات تغییر کرده است. حالا از توسعه‌دهنده انتظار می‌رود دانش دامنه (Domain Knowledge) را بفهمد، نیازمندی‌ها را به چالش بکشد، معماری‌ها را طراحی کند و عامل‌ها را هدایت کند، در حالی که مسئولیت کامل نتیجه نهایی را بر عهده دارد. این فقط یک ارتقای ابزاری نیست؛ بلکه یک شغل کاملاً متفاوت است.
به گزارش نویسنده این مطلب، وقتی مهندسان از ابزارهایی مثل Codex، Cursor یا Claude استفاده می‌کنند، زمان تکمیل یک وظیفه می‌تواند از هفته‌ها به ساعت‌ها کاهش یابد. اما این ابزارها دانش دامنه یا تجربه معماری را منتقل نمی‌کنند. اگر مهندسی فقط برای «بستن تیکت» آموزش دیده باشد، بستر تجاری لازم برای تشخیص «مهملات متقاعدکننده» را ندارد؛ کدهایی که تست‌های فنی را پاس می‌کنند اما هدف تجاری را نابود می‌کنند.
مکانیسم شکست
همان‌طور که در آزمایش نویسنده مشاهده شد، پیاده‌سازی کد تولیدشده درست به نظر می‌رسید. احتمالاً تست‌ها هم سبز بودند و پاس شدند. اما نتیجه تجاری غلط بود. این موضوع ثابت می‌کند که هیچ مقدار کد تولیدشده نمی‌تواند جایگزین نیاز به دانش دامنه برای تأیید نتایج شود. شما باید دقیقاً بدانید چه چیزی را بررسی کنید تا بتوانید این خطاها را شکار کنید.
برای مقابله با این وضعیت، رویکرد «مهندسی مهارکننده» (Harness Engineering) پیشنهاد شده است که شامل موارد زیر است:
- مجموعه مهارت‌های مشترک: ایجاد یک مخزن مبتنی بر Git که شامل معماری‌ها، استانداردها، بهترین شیوه‌ها (Best Practices) و درس‌هایی از اصلاحات مکرر باشد. این رویکرد در راستای استانداردهای مهندسی برای تبدیل دموهای AI به عامل‌های عملیاتی است تا قابلیت اطمینان سیستم‌ها در سال ۲۰۲۶ افزایش یابد. این کار به انسان‌ها و عامل‌ها اجازه می‌دهد به‌جای تکرار اشتباهات و اصلاح مداوم یک مشکل، از دانش موجود استفاده کنند.
- آزمایشگاه‌های مهندسی عامل‌محور: جلسات عملی ۶۰ دقیقه‌ای هفتگی. این آزمایشگاه‌ها بر روی گردش‌کارهای واقعی، آزمایش‌ها و بحث درباره نقاطی تمرکز می‌کنند که عامل‌ها شکست خورده‌اند یا جایی که انتظارات از ابزار غیرواقع‌بینانه بوده است.
- تغییر مالکیت: انتقال مهندسان به مراحل ابتدایی‌تر از خط لوله محصول (Product Pipeline) تا مسئله را درک کنند، ارزش تجاری را به چالش بکشد و جایگزین‌های بهتری پیشنهاد دهند.
عنصر انسانی و ترس
این گذار بدون اصطکاک نیست. مهندسانی که ۱۰ یا ۱۵ سال وقت گذاشته‌اند تا در پیاده‌سازی استاد شوند، ممکن است احساس تهدید کنند. وقتی یک مدیر نشان می‌دهد که یک عامل می‌تواند کاری را در کسری از زمان انجام دهد، یک ترس مشروع در مورد امنیت شغلی ایجاد می‌شود.
هوش مصنوعی تغییر می‌دهد که سازمان‌ها به چه مقدار کار مهندسی نیاز دارند و چه نوع کاری را ارزشمند می‌دانند. صادقانه بگوییم، گفتن اینکه هوش مصنوعی فقط شغل همه را «بهتر» می‌کند، غیرصادقانه است. انسان‌ها یک‌شبه تغییر نمی‌کنند و کسی که از توسعه‌دهنده بودن در سطح پیاده‌سازی لذت می‌برد، شاید از اینکه از او خواسته شود به استراتژی تجاری یا معماری فکر کند، لذت نبرد.
علاوه بر این، ترس از جایگزینی می‌تواند یک تیم را فلج کند. این ترس میل توسعه‌دهنده به تجربه کردن، اشتباه کردن یا به چالش کشیدن مدیر را می‌گیرد؛ در حالی که این‌ها دقیقاً همان رفتارهایی هستند که برای موفقیت در یک محیط عامل‌محور ضروری‌اند.
بازتعریف خط لوله محصول
بهره‌وری واقعی نیازمند چیزی فراتر از لایسنس یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — است. نویسنده در حال آزمایش کل خط لوله است، از اولین مسئله مشتری تا انتشار نهایی. این فرآیند شامل پرسیدن این سوالات است:
- چه کسی مسئله را شناسایی و ارزیابی می‌کند؟
- زمان درست برای ساخت نمونه اولیه (Prototype) چه زمانی است؟
- چه کسی تصمیمات نهایی را می‌گیرد؟
- چه کسی مالک نتیجه است؟
اگر مدیریت تمام قدرت تصمیم‌گیری را حفظ کند اما انتظار خروجی بیشتر داشته باشد، ابزارها سطحی باقی می‌مانند. تغییر واقعی زمانی رخ می‌دهد که مهندسان اختیار به چالش کشیدن نیازمندی‌ها و مالکیت نتیجه نهایی را داشته باشند. این یعنی بنیان‌گذاران باید خودشان را به چالش بکشند. آن‌ها باید دانش انباشته‌شده خود از مشتریان و تاریخچه شرکت را منتقل کنند، بدون اینکه خودشان تبدیل به یک گلوگاه دائمی شوند که هر توسعه‌دهنده‌ای به آن‌ها وابسته باشد.
این بدان معناست که بنیان‌گذاران و مدیران باید تصمیماتی را بپذیرند که شاید خودشان در شرایط دیگر جور دیگری می‌گرفتند. دادن مسئولیت بیشتر به افراد در حالی که تمام تصمیمات در دست مدیریت باشد، یا انتظار بهره‌وری بالاتر با حفظ نقش‌ها و معیارهای اندازه‌گیری قدیمی، منطقی نیست.
اینکه آیا این چرخش سازمانی برای هر توسعه‌دهنده‌ای ممکن است یا خیر، هنوز یک پرسش باز است. برخی ممکن است در برابر این نقش جدید مقاومت کنند و اندازه‌گیری موفقیت «مالکیت توزیع‌شده» بسیار سخت‌تر از رصد سرعت بستن تیکت‌ها (Ticket Velocity) است. هدف این است که از صرفاً فراهم کردن ابزار، به تغییر ماهیت توزیع مسئولیت‌های مهندسی برسیم.
گام بعدی شما
- بررسی کنید آیا در تیم شما توسعه‌دهندگان فقط تیکت می‌بندند یا درک می‌کنند چرا این ویژگی برای مشتری مهم است.
- یک مخزن دانش (Knowledge Base) برای استانداردهای معماری ایجاد کنید تا عامل‌های هوش مصنوعی بر اساس آن کد بزنند.
- جلسات هفتگی برای تحلیل «شکست‌های عامل» برگزار کنید تا نقاط ضعف ابزارهای جدید شناسایی شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو