اگر برای سرعت بخشیدن به تسک‌های دوهفته‌ای خود از مدل‌های زبانی استفاده می‌کنید، احتمالاً در حال ساخت کدهایی هستید که هیچ انسانی در آینده قادر به مدیریت آن‌ها نخواهد بود. در ۸ ژوئن ۲۰۲۶، جسی اسکینر (Jesse Skinner) جزئیات بحرانی را افشا کرد که در آن هوش مصنوعی زاینده، بدترین ویژگی‌های «برنامه‌نویسان ستاره» را تقلید می‌کند: تولید کدهایی درخشان و سریع، اما کاملاً غیرقابل‌فهم.
الگوی برنامه‌نویس ستاره
تصور کنید یک برنامه‌نویس ارشد با انرژی زیاد به تیم می‌پیوندد. او پارادایم‌های جدید، ابزارهای تازه و معماری‌های نوآورانه‌ای را معرفی می‌کند. او معماری هسته شرکت را بازنویسی کرده و با رد کردن اکثر درخواست‌های ادغام (Pull Requests)، استانداردهای تیم را بالا می‌برد. او سخت‌ترین کارها را سریع‌تر از هر کسی انجام می‌دهد، اما مهندسی او چنان خیره‌کننده و پیچیده است که فقط خودِ این «ستاره» می‌داند قطعات مختلف در واقعیت چگونه به هم متصل شده‌اند. بقیه اعضای تیم برای همگام شدن با کتابخانه‌های جدید و پذیرش «روش ستاره‌ای» او دست‌وپا می‌زنند.
سپس، این ستاره تیم را ترک می‌کند. او خسته شده و به دنبال پروژه‌ای چالش‌برانگیزتر در شرکتی بزرگ‌تر می‌رود. حالا شما باید پروژه‌های او را به ارث ببرید و متوجه می‌شوید که زیر آوار کدهای پیچیده دفن شده‌اید.
پیامدهای «درخشش»
به نقل از گزارش وب‌سایت codingwithjesse.com، پیامدهای این درخشش ویرانگر است. ممکن است متوجه شوید که صرفاً برای اجرا کردن کد روی لپ‌تاپ خود، یک هفته زمان نیاز دارید. جریان داده‌ها چنان دشوار و مبهم است که انگار کسی سعی داشته جای یک جنایت را بپوشاند. نیمی از کد با زبانی نوشته شده که شما نمی‌شناسید و نیمی دیگر از کتابخانه‌هایی استفاده می‌کند که هرگز نامشان را نشنیده‌اید. حتی وقتی پیشنهاد بازنویسی می‌دهید، مدیران ممکن است مخالفت کنند، زیرا کد توسط خودِ آن برنامه‌نویس ستاره نوشته شده است.
این برنامه‌نویسان ستاره عاشق کدنویسی و به چالش کشیدن توانایی‌های خود تا آخرین حد هستند. آن‌ها پیچیده‌ترین و هوشمندانه‌ترین کدهای ممکن را می‌نویسند تا با حداکثر سرعت پیش بروند. متأسفانه، آخرین چیزی که برای آن‌ها اهمیت دارد، نوشتن کدی است که دیگران بتوانند با آن کار کنند یا آن را توسعه دهند.
ظهور ستاره‌های هوش مصنوعی
اکنون این الگوی مخرب در مقیاس وسیع توسط عامل‌های هوش مصنوعی تکرار می‌شود. هر بار که یک برنامه‌نویس چت جدیدی را شروع می‌کند، در واقع ریسک اضافه کردن یک «ستاره» جدید به تیم را می‌پذیرد. این ستاره‌های دیجیتالی با مجموعه‌ای از رفتارهای مشکل‌ساز عمل می‌کنند:
- فراموشی زمینه‌ای: عامل‌ها هیچ چیز از کارهایی که دیروز انجام داده‌اند به یاد نمی‌آورند و این منجر به ایجاد منطق تکه‌تکه و گسسته می‌شود.
- مهندسی بیش از حد: آن‌ها بر رویکرد «کمربند و تعلیار» (احتیاط بیش از حد) اصرار دارند و بهترین روش‌های جعبه‌ابزار خود را حتی زمانی که پیچیدگی از سود حاصله بیشتر است، اعمال می‌کنند.
- سرعت به جای شفافیت: آن‌ها در چند دقیقه ده‌ها هزار خط کد تولید می‌کنند، بدون اینکه بررسی کنند آیا سیستم قابل‌فهم‌تر شده است یا وضعیت بدتر شده است.
- بازبینی سخت‌گیرانه: هنگام بررسی کد، لیست‌های طولانی از اصلاحات ارائه می‌دهند که برنامه‌نویس انسانی اغلب با آن‌ها مخالف است.
این وضعیت پدیده‌ای را می‌سازد که اسکینر آن را «کدنویسی حسی» (Vibe Coding) می‌نامد. برخلاف یک ستاره انسانی که معمولاً یک چشم‌انداز طراحی واحد (هرچند ناقص) دارد، توده‌ی کدهای حسی نتیجه‌ی صدها چت و زمینه‌ی متفاوت است. انگار یک کدبیس توسط صدها ستاره‌ی مختلف نوشته شده باشد که هر کدام در هر لحظه فقط یک ویژگی یا یک باگ را اصلاح کرده‌اند.
تله‌ی وابستگی
برای برنامه‌نویس معمولی، سطح ورود به بازی در حال بالا رفتن است. بسیاری احساس می‌کنند برای عقب نماندن مجبورند از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — استفاده کنند. این یک وابستگی خطرناک است. اسکینر اشاره می‌کند در حالی که مردم از عقب ماندن می‌ترسند، اما کسانی که اجازه می‌دهند LLM تمام کدهایشان را بنویسد، در نهایت همان‌هایی خواهند بود که واقعاً عقب می‌مانند.
وقتی سیستمی چنان پیچیده شود که تنها راه درک آن استفاده از یک LLM باشد، تیم در واقع هنرِ ساخت (Craftsmanship) را به یک ماشین برون‌سپاری کرده است. این تغییر، سیگنالی از گذار از «بدهی فنی قابل‌مدیریت» به حالتی است که در آن بدهی هرگز تسویه نمی‌شود و برای همیشه باقی می‌ماند.
استراتژی‌های نرم‌افزار پایدار
برای اجتناب از این تله، باید با LLM به عنوان ابزاری در جعبه‌ابزار برخورد کنید، نه به عنوان معمار ارشد. بر اساس مستندات اسکینر، چند نرینگ حفاظی ضروری است:
- رهبری مهندسی: مدل را هدایت کنید تا تکه‌های کوچک کد تولید کند، نه بلوک‌های عظیم و یکپارچه.
- ترمز بگیرید: اگر متوجه شدید نمی‌فهمید چرا مدل چنین کاری می‌کند یا منطق آن چیست، سرعت را کم کنید تا کیفیت تضمین شود.
- ساده‌سازی: با ساده کردن معماری تا حدی که با پیچیدگی واقعی مسئله همخوانی داشته باشد، جلوی مهندسی بیش از حد را بگیرید.
- کدنویسی دستی: هیچ اشکالی ندارد که LLM را در جعبه‌ابزار بگذارید و خودتان کد را بنویسید.
هنر ساخت نرم‌افزار همچنان مسئولیت انسان است؛ تنها چیزی که هرگز نمی‌توان به ماشین سپرد. هدف این است که نرم‌افزاری تولید کنید که تیم شما فردا واقعاً بتواند با آن کار کند.
گام بعدی شما
- در بازبینی کدهای تولید شده توسط AI، هر بخش پیچیده‌ای را که نتوانید در ۳۰ ثانیه توضیح دهید، بازنویسی کنید.
- استراتژی «تولید تکه‌ای» (Small Snippets) را جایگزین درخواست‌های جامع برای ساخت کل ویژگی‌ها کنید.
- یک جلسه «پاک‌سازی بدهی فنی» ماهانه ترتیب دهید تا کدهای حسی را به کدهای استاندارد تبدیل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو