تصور کنید مهندسی هستید که دیگر کد نمی‌نویسد، بلکه فقط خروجی‌های یک ماشین را تأیید می‌کند. اگر امروز تمام توابع سیستم شما توسط AI نوشته شوند، احتمالاً در کمتر از یک سال با نرم‌افزاری مواجه خواهید شد که هیچ‌کس — حتی همان AI — نمی‌تواند بدون شکستن کل ساختار، تغییری در آن ایجاد کند.
طبق گزارش وب‌سایت softwaredoug.com، در سال ۲۰۲۶ بخش بزرگی از کدهای حرفه‌ای توسط هوش مصنوعی تولید می‌شوند. اما کدنویسی دستی برخلاف تصور، به یک اثر موزه‌ای تبدیل نشده است؛ بلکه تنها راه برای درک واقعی شکنندگی سیستم و حفظ کنترل روی معماری کلان است. عمل نوشتن کد همچنان تنها روشی است که از طریق آن می‌توان شکنندگی یک سیستم را به‌طور واقعی تجربه کرد. این تغییر، نقش مهندس را از «نویسنده تابع» به «مدیر کارخانه نرم‌افزار» تغییر داده است. این تحول در واقع بخشی از روند گسترده‌تری است که در آن نقش برنامه‌نویسان از کدنویسی صرف به مدیریت و ارکستراسیون هوش مصنوعی تغییر می‌کند.
این وضعیت شبیه خط تولیدی است که در آن ربات‌ها تمام عملیات جوشکاری را انجام می‌دهند. اگر ناظر انسانی هرگز فلز را لمس نکند، ممکن است متوجه یک نقص ساختاری نشود تا زمانی که کل خودرو در اثر یک ضربه فرو بریزد. در دنیای نرم‌افزار، عامل (Agent) — یعنی برنامه‌ای که می‌تواند به‌طور مستقل هدف را دنبال کند و ابزارها را به کار بگیرد — همان ربات است و انسان، مدیر سیستم است که باید بر کل جریان نظارت کند.
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اتکای مطلق به خروجی‌های خودکار بدون نظارت دقیق، ریسک‌های سیستمی را افزایش می‌دهد. اکنون مهندسان باید روی زیرساختی تمرکز کنند که موفقیت این عامل‌ها را تضمین کند.
مدل کارخانه نرم‌افزار
در این پارادایم جدید، شغل مهندس این است که «کارخانه» را بسازد، نه فقط خودِ نرم‌افزار را. این به معنای نگهداری از خط تولید است تا هر کسی بتواند درخواستی برای تغییر ارسال کند و آن تغییر فوراً منتشر شود. تمرکز اصلی بر روی ایجاد زیرساختی است که اجازه می‌دهد عامل‌ها با موفقیت عمل کنند. برای مدیریت این حجم از عملیات، راهکارهای نوین زیرساختی مانند شبکه‌های میزبانی مخازن هوش مصنوعی برای رفع گلوگاه‌های انتقال داده در حال ظهور هستند.
مدیریت این «کارخانه نرم‌افزار» در دو حالت متمایز رخ می‌دهد:
- اقدام پیش‌دستانه (Proactive Action): استفاده از پرامپت‌ها، مهارت‌ها، پایگاه‌های دانش و فایل‌های AGENTS.md برای هدایت دقیق عامل به سمت هدف.
- حفاظت واکنشی (Reactive Protection): بهره‌گیری از ارزیابی‌های خودکار، شامل تست‌ها، ابزارهای Linting، سیستم‌های نوع‌بندی (Type Systems) و سایر ارزیابی‌های AI برای نگه داشتن عامل در مسیر درست و جلوگیری از انحراف.
وقتی این محدودیت‌ها و حفاظ‌ها برقرار باشند، حتی یک «مدل احمق» که فقط دسترسی به زمینه (Context) تازه دارد، می‌تواند تغییری ایجاد کند که به اندازه کافی خوب باشد. اما همین سهولت در تحویل، وسوسه خطرناکی ایجاد می‌کند: دست کشیدن کامل از بررسی کدها و تبدیل شدن به یک تماشاگر.
بر اساس تحلیل ۱۲ ژوئیه ۲۰۲۶ در softwaredoug.com، خطر جریان کاری «سنتور معکوس» (Reverse Centaur) در کمین است؛ وضعیتی که در آن انسان‌ها فقط کد AI را می‌خوانند و تأیید می‌کنند. نتیجه این روند، انباشت «آشغال‌های معماری» (Architectural Slop) است. عامل‌ها معمولاً تغییرات تکه‌ای و امن را به بهبودهای جامع و کل‌نگر ترجیح می‌دهند. برای مثال، یک عامل ممکن است برای حفظ یک اشتباه اولیه انسان، لایه‌های پیچیده‌ای از Wrapperها را اضافه کند تا به‌جای پیشنهاد بازطراحی کل ساختار، فقط خطا را بپوشاند؛ اتفاقی که می‌تواند تعداد خطوط کد (LoC) را برای محافظت از یک تصمیم غلط، سه برابر کند.
ریسک‌های توسعه تک‌بعدی با AI
- شکاف دقت: زبان انگلیسی یک زبان «کم‌تعریف» (Under-specified) است؛ این زبان نمی‌تواند محاسبات پیچیده را با دقتی مشابه یک گام اجرایی بیان کند. برای کارهای واقعاً الگوریتمی، توسعه‌دهندگان نیاز دارند که ایده‌ها را در قالب گام‌های اجرایی ترسیم و فکر کنند تا به درجه کالیبره شده‌ای از دقت برسند.
- اثر کارآموز: عامل‌های کدنویسی شبیه کارآموزان تازه‌واردی هستند که تازه پذیرفته شده‌اند، نه شبیه کامپایلرها. آن‌ها کدهایی را می‌خوانند که احتمالاً ناقص یا «آشغال‌شده» هستند، توصیفات غیردقیق را می‌گیرند و یک تغییر تولید می‌کنند. انسان‌ها نمی‌توانند تفکر و سلیقه فنی خود را به ارتشی از کارآموزان بسپارد. این مشکل از آن جهت است که کمبود «هوش محیطی» باعث می‌شود بسیاری از این عامل‌ها در مقیاس صنعتی شکست بخورند.
- از دست دادن مالکیت: مشاهده صرفِ تغییرات (Diffs)، رابطه‌ای غیرفعال با نرم‌افزار می‌سازد. نویسنده اشاره می‌کند که وقتی فقط کد را می‌خوانید و تأیید می‌کنید، همان حس مالکیت نسبت به اثر را نخواهید داشت. این موضوع باعث می‌شود «آشغال‌های معماری» به‌راحتی از زیر رادار شما بگذرند و در سیستم باقی بمانند.
- شکست قانون پیشاهنگی: عامل‌ها به‌ندرت از «قانون پیشاهنگی» (Boy Scout Rule) پیروی می‌کنند؛ قانونی که می‌گوید کد را بهتر از آنچه یافتید رها کنید. چون آن‌ها تمایل دارند تغییر فعلی را تا حد امکان «امن» اعمال کنند، از پاک‌سازی‌های ضروری که سلامت بلندمدت سیستم را تضمین می‌کند، اجتناب می‌کنند.
تحلیل‌های تکمیلی از dev.to پیشنهاد می‌کند که مهندس مدرن باید به یک «مدیر سیستم» تکامل یابد. در حالی که مدل‌ها می‌توانند به‌راحتی Dockerfileها یا کامپوننت‌های React را تولید کنند، ارزش واقعی اکنون در توانایی تعریف زیرساختی است که این عامل‌ها را به موفقیت می‌رساند.
ضرورت تجربه دستی
کدنویسی یعنی توجه و درک. برای اتصال واقعی به معماری سیستم، توسعه‌دهنده باید از مشاهده‌گر غیرفعال بودن در برابر تغییرات دو-بعدی (Diffs) و وصله‌ها خارج شود. نویسنده برای توصیف این نیاز، از استعاره «تجربه واقعیت مجازی 4DX با حسگرهای درد» استفاده می‌کند تا مهندس واقعاً شکنندگی سیستم را حس کند و با آن مواجه شود.
با درگیر شدن مستقیم در محیط اجرا، مهندسان می‌توانند به چندین هدف حیاتی برسند:
- شناسایی شکنندگی: اگر برای یک انسان سخت باشد که بدون شکستن چیزی روی کد فعلی بسازد، برای یک عامل هوشمند حتی سخت‌تر خواهد بود که آن را بفهمد و تغییر دهد.
- پاک‌سازی معماری: پاک‌سازی کد و مستند کردن یک اصل منسجم — بدون داشتن نیم‌دوجین استثنا — باعث می‌شود کل کارخانه نرم‌افزار با راندمان بیشتری عمل کند.
- ریشه‌کنی باگ‌ها: از طریق دیباگ دستی و شناسایی نقاط ضعف در استراتژی تست، انسان می‌تواند دسته‌های کاملی از باگ‌ها را شناسایی و به‌طور کامل ریشه‌کن کند.
تعادل بین نویسندگی AI و انسان
حتی کسانی که دچار «سیکوز AI» شده‌اند، می‌بینند که کدنویسی دستی همچنان ابزاری مفید است. رویکرد مؤثر، رد کردن AI نیست، بلکه استفاده از آن به‌عنوان یک «تقویت‌کننده» است. وقتی انسان ابتدا یک رویکرد را به‌صورت دستی آزمایش (Spike) می‌کند و سپس اجازه می‌دهد عامل الگوها را تکثیر کند، انسان در نتیجه مشارکت کرده و مالک آن است.
چه در یک زبان سطح پایین با فضای طراحی وسیع و چه در زبانی سطح بالا با محاسبات محدود، عمل کدنویسی به انسان کمک می‌کند تا فکر کند. این کار مانع از ایجاد «ذهنیت نادرست» می‌شود؛ ذهنیتی که با عامل‌ها مانند کامپایلر برخورد می‌کند و به توسعه‌دهندگان اجازه می‌دهد کدهایی با کیفیت بسیار پایین را منتشر کنند.
در نهایت، موفق‌ترین توسعه‌دهندگان سال ۲۰۲۶ کسانی هستند که از AI برای تکثیر الگوها استفاده می‌کنند اما همچنان سیستم را به‌صورت دستی کاوش می‌کنند. همان‌طور که یک کارخانه خودرو گاهی نیاز دارد خط تولید را باز کند یا یک روز را صرف مشاهده تست لنت‌های ترمز کند تا یک مشکل میدانی را بیابد، مهندسان نرم‌افزار نیز باید جزئیات ریز را به تصویر کلی متصل کنند.
برای رقابتی ماندن، باید با بازرسی ماژول‌های تولیدشده توسط AI برای یافتن «تقویت محافظه‌کارانه» شروع کنید؛ وضعیتی که در آن AI به‌جای اصلاح منطق اصلی، یک باگ را در پنج لایه حفاظتی پیچیده کرده است.
برای یادگیری بیشتر درباره پیاده‌سازی این استراتژی‌ها، به ابتکار «Ssearch with Agents» بپیوندید تا کشف کنید چگونه از عامل‌ها در جستجو استفاده کنید، RAG بهتری بسازید و از LLMها در درک کوئری‌ها بهره ببرید.
گام بعدی شما
- ماژول‌های تولیدشده توسط AI را برای یافتن «تقویت محافظه‌کارانه» بازرسی کنید؛ جایی که AI به‌جای اصلاح منطق اصلی، یک باگ را در پنج لایه حفاظتی پیچیده کرده است.
- برای هر تغییر پیچیده، ابتدا یک نسخه دستی کوچک (Spike) بزنید و سپس از عامل برای گسترش آن استفاده کنید.
- استراتژی تست‌های خود را به‌گونه‌ای تغییر دهید که نقاط شکنندگی را به‌صورت فعال به شما هشدار دهد، نه اینکه فقط خروجی را تایید کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو