تصور کنید برنامه‌نویسی هستید که دیگر کد نمی‌نویسد، بلکه فقط دستور می‌دهد و خروجی‌ها را می‌پذیرد؛ در این حالت، شما دیگر معمار سیستم نیستید، بلکه تنها یک اپراتور هستید که کنترل پروژه را از دست داده است. هوش مصنوعی می‌تواند قطعات کد کاربردی تولید کند، اما نمی‌تواند حکمت معماری بلندمدتی را که برای حفظ قابلیت نگهداری یک سیستم در طول سال‌ها تکامل لازم است، درک کند. برای مهندسانی که برای نوشتن و خواندن کد به مدل‌های زبانی بزرگ (LLM) تکیه می‌کنند، این شکاف نشان‌دهنده ریسک از دست رفتن دائمی تسلط حرفه‌ای است.
این تنش در حالی رخ می‌دهد که صنعت به سمت Vibe Coding (برنامه‌نویسی حس‌محور) — یعنی اولویت دادن به خروجی سریع و آنی به‌جای یکپارچگی ساختاری — حرکت می‌کند. به نقل از تحلیل منتشر شده در ۲۲ سپتامبر ۲۰۲۶ در وب‌سایت alexn.org، نویسنده هشدار می‌دهد که روند فعلی نادیده گرفتن بازبینی کدها (Code Review) و توقف نوشتن دستی، وابستگی خطرناکی به ابزارهایی ایجاد می‌کند که هزینه‌ی اشتباهات خود را نمی‌فهمند. این موضوع یادآور حوادثی است که در آن یک خطای کوچک در کدهای تولید شده توسط AI منجر به توقف کامل سیستم‌های احراز هویت شد.
زمینه و بستر تغییرات
احساسات جاری در صنعت اخیراً به نقطه جوش رسیده است. نویسنده اشاره می‌کند که جملاتی مانند «از سال ۲۰۲۵ تا امروز کد ننوشته‌ام»، «بازبینی کدها مُرد» و «مردم دیگر کد نمی‌خوانند» به طور گسترده شنیده می‌شود. در حالی که صنعت در حال تحول است، کسانی که در تله‌ی رها کردن عمل خواندن و نوشتن کد می‌افتند، در واقع با ریسک شخصی خود این کار می‌کنند.
دلیل این هشدار آن است که پروژه‌های حس‌محور به‌ناچار به یک آشفتگی غیرقابل مدیریت تبدیل می‌شوند. مسئله اصلی این است که قابلیت نگهداری کد (Maintainability) و معماری خوب، معیارهای اندازه‌گیری فوری ندارند. ماه‌ها یا حتی سال‌ها طول می‌کشد تا اثرات مخرب یک معماری بد در محیط عملیاتی نمایان شود.
بر اساس مستندات این گزارش، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به چند دلیل بنیادی برای مدیریت پایداری کد ناتوان‌اند:
جزئیات محدودیت‌های هوش مصنوعی
- فقدان سیگنال‌های پاداش: یادگیری تقویتی (Reinforcement Learning) به یک سیگنال پاداش نیاز دارد که فوراً قابل اندازه‌گیری باشد. چون اثرات معماری بد تنها پس از ماه‌ها یا سال‌ها ظاهر می‌شود، AI نمی‌تواند بر اساس آنچه واقعاً به معنای «قابلیت نگهداری» است، آموزش ببیند.
- داده‌های آموزشی ضعیف: مدل‌ها قوانین را از کتاب‌های راهنمایی یاد می‌گیرند که برای مبتدیان نوشته شده‌اند و الگوها را از «کدهای موجود در دنیای واقعی» (Code in the wild) استخراج می‌کنند. نویسنده خاطرنشان می‌کند که اکثر کدهای موجود در فضای باز، عمدتاً دارای کیفیت پایینی هستند.
- شکست در ساده‌سازی: مدل‌های پیشرو (SOTA) در تعریف توابع واقعاً بازاستفاده (Reusable) مشکل دارند. آن‌ها اغلب توابع را به تکه‌های کوچکی تقسیم می‌کنند که در عمل بازاستفاده نیستند؛ این یک انتخاب بد است، زیرا خواننده همچنان باید پیاده‌سازی تابع استخراج‌شده را بخواند تا منطق اصلی را بفهمد.
- نبود تابع برازش (Fitness Function): هیچ تابع برازش قابل تشخیص برای کد پایدار وجود ندارد؛ اگر چنین تابعی وجود داشت، تا امروز در ابزارهای بررسی کد (Linters) گنجانده می‌شد.
برنامه‌نویسان خبره به «حس» یا همان شمّ تشخیص بوی بد کد (Code Smell) تکیه می‌کنند؛ شهودی که حاصل سال‌ها دیباگ کردن خطاهای بحرانی در محیط عملیاتی و ساعت‌های طولانی کار برای رفع مشکلات تولید است. این تسلط، مجموعه‌ای از قوانین خشک نیست، بلکه یک هنر وابسته به زمینه است. متخصصان از قوانین پیروی نمی‌کنند، بلکه آن‌ها هستند که قوانین را می‌سازند.
وقتی توسعه‌دهندگان از تصمیم‌گیری‌های سخت و پذیرش مسئولیت خطاها دست می‌کشند، در سطح «مبتدی پیشرفته» (Advanced Beginner) در مدل دریفوس (Dreyfus model) متوقف می‌شوند. این تغییر یک اثر مرتبه دوم ایجاد می‌کند: هوش مصنوعی اشتباه می‌کند، از آن اشتباه درس نمی‌گیرد و اپراتور انسانی — که دیگر کد را نمی‌خواند — او هم فرصت یادگیری را از دست می‌دهد.
مکانیسم‌های تولید کد بد
بدون تسلط انسانی، پایگاه‌های کد (Codebases) شروع به نمایش شکست‌های خاصی می‌کنند:
- اثر پروانه‌ای: تغییر یک مورد کوچک، باعث شکست برنامه به روش‌های غیرقطعی (Non-deterministic) می‌شود یا منطق را در بخش‌هایی می‌شکند که فاصله زیادی با محل تغییر دارند.
- ناپایداری و ناسازگاری: افزودن یک ویژگی جدید تبدیل به یک اقدام دشوار می‌شود، زیرا کد باید در چندین جای مختلف تغییر کند و فراموشی اصلاح حتی یک ناحیه، منجر به ناسازگاری در کل سیستم می‌شود.
- از دست رفتن انسجام: ناورداهای طراحی (Design Invariants) مبهم می‌شوند، به‌ویژه زمانی که نویسندگان اصلی دیگر حضور ندارند تا از نقض این اصول جلوگیری کنند.
- تست‌های شکننده: کد به‌گونه‌ای می‌شود که تست کردن آن سخت است، به مقدار زیادی Mock نیاز دارد و جزئیات پیاده‌سازی را افشا می‌کند، که در نهایت مانع از هرگونه بازسازی (Refactoring) معنادار می‌شود.
برای یک توسعه‌دهنده متوسط، این به معنای کاهش احتمالی طول عمر شغلی و استقلال فنی است. اگر عضله‌ی قضاوت معماری را تمرین نکنید، تبدیل به مسافری در پروژه خودتان می‌شوید. بهره‌وری AI واقعی است — و نویسنده مقاله اعتراف می‌کند که از LLMها برای کارهای «کسل‌کننده و روح‌فرسای» (Boring, soul-sucking shit) استفاده می‌کند — اما این سرعت در حال حاضر با ثبات بلندمدت معاوضه می‌شود. در این راستا، تغییر تمرکز از سینتکس به سیستم در توسعه AI-Native باعث شده تا مالکیت کد و درک عمیق معماری بیش از هر زمان دیگری ارزشمند شود.
در نهایت، صنعت نرم‌افزار منحصربه‌فرد است چون خودش در حال حاضر یک مقیاس از اتوماسیون است. LLMها فقط یک ابزار دیگرند. پیش‌بینی می‌شود در آینده، سیاست‌های «بدون هوش مصنوعی» (NO-AI) به یک مزیت رقابتی برای شرکت‌هایی تبدیل شود که پایداری و یکپارچگی سیستم را بر نمونه‌سازی‌های سریع و شکننده ترجیح می‌دهند.
برنامه‌نویسی «حل» نشده است. در حالی که می‌توان به یک LLM دستور داد تا یک کامپایلر C/C++ بسازد، هر کسی می‌تواند برای نتیجه‌ای بهتر و رایگان، GCC یا LLVM را کلون کند. چالش واقعی، بازسازی اپلیکیشن‌های CRUD نیست، بلکه مدیریت ماهیت بی‌نهایت نیازها و خواسته‌های انسان است.
در سال‌های آینده، شاهد شکافی رو به رشد بین «برنامه‌نویسان حس‌محور» (Vibe-coders) و «معماران» (Architects) خواهیم بود، زمانی که هزینه‌های بلندمدت بدهی فنی تولید شده توسط AI، محیط‌های عملیاتی را هدف قرار دهد.
گام بعدی شما
- تمرین کنید که هر قطعه کد تولیدشده توسط AI را خط‌به‌خط بخوانید و دلیل هر تصمیم مدل را به چالش بکشید.
- در پروژه‌های حساس، بازبینی کد (Code Review) انسانی را اجباری کنید تا از انباشت بدهی فنی جلوگیری شود.
- روی یادگیری مفاهیم معماری نرم‌افزار تمرکز کنید تا بتوانید خروجی‌های AI را در یک ساختار پایدار سازماندهی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو