اگر امروز کد خود را به یک دستیار هوش مصنوعی میسپارید، احتمالاً در حال تکیه بر یک «تایپیست سریع» هستید، نه یک معمار نرمافزار. تکیه بر این ابزارها بهعنوان معمار ارشد، سریعترین راه برای فروپاشی پروژههای پیچیده است. این چالش دقیقاً همان نقطهای است که تلهی سرعت در کدنویسی با هوش مصنوعی را میسازد و هزینهی عیبیابی کدها را به شدت افزایش میدهد.
به نقل از گزارش فنی منتشر شده در dev.to در ۲۶ ژوئن ۲۰۲۶، این مدلها در واقع مانند برنامهنویسان جونیورِ بسیار بهرهور اما بیتجربه عمل میکنند؛ یعنی بهجای درک معماری سیستم، صرفاً توکنهای بعدی را پیشبینی میکنند.
این تغییر دیدگاه در لحظهای رخ میدهد که توسعهدهندگان از نوشتن اسکریپتهای ساده به سمت ساخت اپلیکیشنهای پیچیده میروند. بسیاری از کاربران تصور میکنند توانایی مدل در خواندن میلیونها خط مستندات، به معنای درک ذاتی از منطق سیستم است. در حالی که این مدلها یک مدل زبانی بزرگ (LLM) — شبیه کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — هستند و فاقد یک نقشه ذهنی واقعی از نرمافزاریاند که میسازند.
همانطور که در تحلیلهای پیشین ما دربارهی توهمات مدلهای زبانی اشاره کردیم، این نقصهای ساختاری منجر به دو بحران سیستمی میشود:
مشکل زمینه بلندمدت
مدلها با چالش «سوزن در انبار کاه» مواجهاند؛ یعنی با طولانی شدن گفتگو، تمرکز آنها کاهش مییابد. طبق این گزارش، ممکن است مدل در مرحله اول ساختار پایگاه داده را تعریف کند، اما در مرحله دهم نام متغیرها را دچار توهم (Hallucination) — مثل دوستی که خاطرهای را اشتباه تعریف میکند — شود. برای حل این مشکل، توسعهدهندگان باید از اصول تولید بازیابیافزا (RAG) — شبیه دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند — استفاده کنند و یک سند «داده مرجع» (Ground Truth) شامل قوانین کلیدی را در هر پرامپت قرار دهند.
رانش دستوری (Instruction Drift)
آموزشهای آماری اغلب بر محدودیتهای صریح غلبه میکنند. اگر ۹۹٪ اینترنت برای یک کار خاص در پایتون از یک بستهٔ خارجی استفاده کرده باشند، مدل احتمالاً همان بسته را وارد میکند، حتی اگر شما صریحاً آن را ممنوع کرده باشید.
برای مقابله با این وضعیت، مهندسان به «توسعه مبتنی بر مشخصات» روی آوردهاند. این رویکرد که محوریت آن حذف توهمات از طریق ساختارهای تعریفشده است، شامل استفاده از ابزارهایی مثل BrainGrid برای ثبت دانش دامنه به صورت مشخصات ساختاریافته است. همچنین قرار دادن محدودیتهای منفی در انتهای پرامپت، بیشترین اثر روی خروجی دارد.
یک حفاظ حیاتی دیگر، استفاده از ابزارهای بررسی کد (Linting) است. چون هوش مصنوعی در اصلاح خودکار و کورکورانه ضعیف است، توسعهدهنده باید کد را از یک کامپایلر عبور داده و کدهای خطای دقیق را به مدل بازگرداند. مدل در رفع خطاهای مشخص شده بسیار درخشان عمل میکند، حتی اگر نتواند از ابتدا جلوی آنها را بگیرد.
این یعنی نقش برنامهنویس از «کدنویسی» به «طراحی مشخصاتی» تغییر میکند که مدل را هدایت کند. هوش مصنوعی جایگزین معمار نمیشود، بلکه جایگزین تایپ کردن میشود. موفقیت اکنون در گرو شکستن پروژهها به ریز-وظایف با مرزهای سخت است. کسانی که این مرزها را نادیده بگیرند، با کوهی از بدهی فنی مواجه خواهند شد.
گام بعدی شما
- پرامپتهای فعلی خود را برای شناسایی «رانش دستوری» بازبینی کنید.
- یک مرحلهٔ اجباری برای بررسی کد (Linting) و بازگرداندن خطاها به مدل تعریف کنید.
- برای پروژههای بزرگ، یک فایل متنی کوچک حاوی قوانین ثابت پروژه بسازید و در هر درخواست ضمیمه کنید.
اما تأثیر این تغییر رویکرد بر هزینهٔ استنتاج و سختافزارهای مورد نیاز حتی پیچیدهتر است؛ به تحلیل ما دربارهی بهینهسازی GPUها مراجعه کنید.
گفتگو