اگر ساعت‌ها از زمان خود را صرف رفع توهمات هوش مصنوعی در پروژه‌های پیچیده می‌کنید، احتمالاً در تله‌ی «کدنویسی بر اساس حس» افتاده‌اید. باید بدانید که این رویکرد در مقیاس واقعی، نه تنها سرعت را نمی‌افزاید، بلکه زمان عیب‌یابی را به شدت افزایش می‌دهد.
بسیاری از برنامه‌نویسان از هوش مصنوعی زاینده (Generative AI) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای نمونه‌سازی سریع استفاده می‌کنند. طبق گزارشی که در ۱۹ مه ۲۰۲۶ در پلتفرم dev.to منتشر شد، این روش که «پرامپت‌نویسی بر اساس حس» (VCP) نام دارد، در پروژه‌های بزرگ شکست می‌خورد. این مدلِ کار، به‌ویژه در استراتژی‌های کشینگ و عملکرد SQL، خروجی‌هایی تولید می‌کند که برای محیط عملیاتی (Production) مناسب نیستند.
برای حل این مشکل، توسعه‌دهنده‌ای در dev.to رویکرد «توسعه‌ی مستندمحور» (Spec-Driven Development یا SDD) را جایگزین کرد. در این روش، مدل نه به عنوان یک تایپیست سریع، بلکه شبیه به یک مدیر پروژه حرفه‌ای مدیریت می‌شود. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نظم در ورودی‌ها، کیفیت خروجی را تضمین می‌کند. مسیر اجرایی این متدولوژی شامل مراحل زیر است:
- راه‌اندازی زیرساخت: مقداردهی اولیه دستی پروژه‌هایی مثل Laravel یا Next و تعریف مسیرهای اولیه.
- همراستاسازی الگوها: تعریف «مهارت‌های» خاص برای عامل تا الگوهای کدنویسی مورد نظر را بشناسد.
- فاز مستندسازی: ایجاد پوشه‌ی
specs/و نوشتن یک فایلreadme.mdکه شامل دلیل تغییرات و تمام نیازمندی‌های ذینفعان باشد. - حلقه‌ی تأیید: دستور به مدل برای تحلیل مستندات و پرسیدن سؤالات احتمالی، پیش از تولید هرگونه برنامه اجرایی.
- بازبینی انسانی: اصلاح مرحله‌به‌مرحله‌ی برنامه‌ی توسعه توسط انسان، پیش از نوشتن اولین خط کد.
بر اساس مستندات این گزارش، این مسیر ساختارمند تعداد باگ‌ها را کاهش داد و زمان کل توسعه را بیش از ۳۰٪ پایین آورد. با انتقال فشار کاری به بخش تحلیل، زمان کمتری صرف رفع توهم (Hallucination) — شبیه دوستی که خاطره‌ای را با اطمینان اما اشتباه تعریف می‌کند — شد.
این تغییر، نقش برنامه‌نویس را از یک «مهندسی پرامپت (Prompt Engineering)» — هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — به یک «معمار سیستم» تبدیل می‌کند. شما دیگر با خروجی‌های نامنظم مدل نمی‌جنگید، بلکه بر تصمیمات سطح‌بالای مهندسی تمرکز می‌کنید.
گام بعدی شما
- در ویژگی پیچیده بعدی خود، ابتدا تمام نیازمندی‌ها را در یک فایل Markdown بنویسید.
- مدل را مجبور کنید پیش از تولید کد، درباره‌ی مستندات شما سؤال بپرسد و ابهامات را برطرف کند.
- نقشه‌ی راه تولید کد را به صورت گام‌به‌گام بازبینی کرده و سپس اجازه اجرا بدهید.
اما تأثیر این رویکرد بر هزینه‌های استنتاج در مقیاس سازمانی متفاوت است — به تحلیل ما درباره‌ی بهینه‌سازی GPUها مراجعه کنید.
گفتگو