اگر هنوز از هوش مصنوعی برای کدنویسی مثل یک موتور جست‌وجوی پیشرفته استفاده می‌کنید، احتمالاً نیمی از پتانسیل آن را از دست داده‌اید. یک برنامه‌نویس گزارش داده است که با تغییر رویکرد در Claude و جایگزینی پرسش‌های کلی با یک چارچوب «بافتار-محور»، هفته‌ای ۱۰ ساعت از زمان مفید خود را بازیابی کرده است. این تغییر رویکرد بر این اصل استوار است که با هوش مصنوعی باید مانند یک مهندس ارشد رفتار کرد که هرگز کدبیس شما را ندیده است؛ یعنی نیاز به دقت وسواس‌گونه در ارائه جزئیات است تا از چرخهٔ پاسخ‌های مبهم و بازنویسی‌های مکرر رها شوید.
چرخهٔ آماتورها
بسیاری از توسعه‌دهندگان در الگویی رایج اما ناکارآمد گرفتارند: پرسش‌های کلی می‌پرسند، پاسخ‌های کلی می‌گیرند و ساعت‌ها وقت خود را صرف اصلاحات و بازنویسی‌های بی‌پایان می‌کنند. طبق این گزارش، این وضعیت معمولاً با کپی کردن کدهایی که کاملاً درک نشده‌اند یا تکرار یک سؤال به سه شکل مختلف برای رسیدن به پاسخ درست همراه است، بدون اینکه ریشه مشکل در کیفیت ورودی شناسایی شود.
تغییر در دیدگاه بافتاری
نقطهٔ عطف این تغییر، درک این نکته بود که خروجی مدل مستقیماً با ورودی متناسب است. اگر شما ۲۰ خط بافتار ارائه دهید، ۲۰ خط پاسخ می‌گیرید؛ اما ارائهٔ ۲۰۰ خط بافتار منجر به پاسخی می‌شود که واقعاً با سیستم موجود سازگار است و در عمل درست کار می‌کند. این رویکرد در حالی رخ می‌دهد که برنامه‌نویسان از رابط‌های سادهٔ چت به سمت کدنویسی یکپارچه با AI حرکت می‌کنند.
همان‌طور که در پوشش پیشین ما از بازیابی های‌لایت‌های مسدودشده Kindle با کمک Claude Code دیدیم، تمرکز اکنون از «ابزار چه می‌کند» به «انسان چگونه هدایت می‌کند» تغییر یافته است. برای اکثر برنامه‌نویسان، گلوگاه اصلی نه هوش مدل، بلکه کیفیت پنجرهٔ زمینه (Context Window) است. این پنجره شبیه به میز کاری است که هرچه وسایل و اطلاعات مرتبط بیشتری روی آن باشد، دسترسی مدل به ابزارهای درست برای حل مسئله سریع‌تر و دقیق‌تر است.
بازبینی معماری
این توسعه‌دهنده پیش از نوشتن ویژگی‌های اصلی، از یک «بررسی پرچم قرمز» (Red-flag check) برای سنجش منطق استفاده می‌کند تا پیش از نوشتن اولین خط کد از ویژگی جدید، از صحت رویکرد و استدلال‌های خود مطمئن شود.
- سازوکار: کاربر ۵۰ تا ۱۰۰ خط از کدهای مرتبط موجود را می‌چسباند و ویژگی مورد نظر و رویکرد پیشنهادی خود را با جزئیات شرح می‌دهد.
- درخواست: پرامپت صراحتاً می‌پرسد: «۳ مورد که می‌تواند این رویکرد را با شکست مواجه کند چیست؟ راه بهتر کدام است؟»
به نقل از این گزارش، در یک مورد مربوط به سیستم اعلان‌های Node.js، برنامه‌نویس کد مربوط به صف پیام‌ها (Message Queue) را ارائه داد و پیشنهاد کرد برای جلوگیری از ارسال‌های تکراری، وضعیت اعلان‌ها در Redis کش شود. این پرامپت باعث شناسایی نقص در منطق ابطال (Invalidation) شد. طبق گزارش، این بررسی ساده باعث صرفه‌جویی در حدود ۲ ساعت دیباگ و بازطراحی در آینده شد؛ فرآیندی که اگر شناسایی نمی‌شد، دیباگ کردن آن ۳ ماه بعد «به یک جهنم تبدیل می‌شد».
بازبینی‌های هدفمند کد
به جای پرسیدن اینکه آیا کد «خوب» است یا نه، این چارچوب بازبینی را به سه محور شفافیت، عملکرد و باگ در محدوده ۲۰ تا ۵۰ خط محدود می‌کند. این محدودیت باعث می‌شود مدل از ارائه توصیه‌های کلیشه‌ای پرهیز کرده و بازخوردهای هدفمند ارائه دهد.
- ساختار: کاربر نگرانی‌های خاص خود را لیست می‌کند (مثلاً مشکل N+1 query در دیتابیس) و سه خروجی مشخص را مطالبه می‌کند: ۱) بزرگ‌ترین مشکل موجود، ۲) بازنویسی بدترین بخش کد و ۳) یک مورد که به درستی انجام شده است.
این حلقهٔ بازخورد در بهینه‌سازی SQL بسیار مؤثر بود. با چسباندن کوئری‌ای که چهار جدول را JOIN می‌کرد و تمرکز بر این موضوع که آیا تمام آن JOINها ضروری هستند یا خیر، برنامه‌نویس متوجه شد که ۵۰ ستون را فراخوانی می‌کند در حالی که فقط به ۳ ستون نیاز داشت. این اصلاح تک‌خطی باعث شد سرعت کوئری‌ها ۴۰٪ افزایش یابد و حدود ۱.۵ ساعت در زمان بررسی و تست صرفه‌جویی شود.
توضیحات بافتاری
برای مدیریت کدهای قدیمی (Legacy)، مستندات پیچیده یا کدهایی که توسط هم‌تیمی‌های دیگر نوشته شده است، پرامپت «توضیح‌دهنده بافتار» مدل را مجبور می‌کند از اصطلاحات فنی پیچیده و ژارگون‌های مهندسی پرهیز کرده و منطق را به زبان ساده و انگلیسی روان بیان کند.
- الزامات: مدل باید سه مورد را شناسایی کند: وظیفهٔ اصلی کد، یک سناریوی احتمالی که در آن کد با شکست مواجه می‌شود و نقطهٔ دقیق در کد که اگر فرآیند کند باشد، باید بررسی شود.
- پرسونا: از Claude خواسته می‌شود طوری توضیح دهد که انگار مخاطب، برنامه‌نویسی است که کاملاً با کدبیس غریبه است و برای اولین بار آن را می‌بیند.
این متد مرحلهٔ آزمون و خطای ورود به پروژه (Onboarding) را حذف می‌کند. نویسنده تخمین می‌زند که این روش در هر مورد حدود ۱.۵ ساعت صرفه‌جویی می‌کند، زیرا مطالعه طولانی مستندات و ایجاد مزاحمت برای هم‌تیمی‌ها را با خلاصه‌های خوانا برای انسان جایگزین می‌کند.
شریک دیباگینگ
وقتی برنامه‌نویس در یک حلقهٔ خطا گیر می‌کند، از پرامپت «چشم تازه» (Fresh Eyes) استفاده می‌کند. به جای پرسیدن «چرا کد خراب است»، وضعیت جامع مشکل را ارائه می‌دهد تا مدل از پیشنهاد راهکارهای بدیهی که قبلاً امتحان شده‌اند، جلوگیری کند.
- ورودی: علائم باگ، پشتهٔ فناوری (Tech Stack)، شرح دقیق اتفاقات (خروجی فعلی در مقابل خروجی مورد انتظار) و لیستی از تمام تلاش‌های قبلی که به نتیجه نرسیده است.
- بافتار: ۳۰ تا ۵۰ خط کد مرتبط برای اینکه مدل دید واضحی از محیط اجرای کد داشته باشد.
در یک مورد اخیر مربوط به Race Condition در محیط async در Node.js، برنامه‌نویس قبلاً تمام تلاش‌های خود از جمله اضافه کردن await در همه جا، استفاده از Redis locks و افزودن Timeoutها را امتحان کرده بود. با ارائه این لیست، Claude توانست تشخیص دهد که برنامه‌نویس در جای اشتباهی از await استفاده کرده است. این تشخیص باعث شد یک await جابه‌جا شده شناسایی شود که ۳ ساعت دیباگ مبتنی بر آزمون و خطا را به چند ثانیه کاهش داد.
راهنمای پیاده‌سازی
برای ویژگی‌های جدید، چارچوبی به کار می‌رود که محدودیت‌ها و الگوهای موجود در کدبیس (۱۰۰ تا ۱۵۰ خط کد) را اجباری می‌کند تا مدل راهکارهای کلیشه‌ای که با معماری سیستم در تضاد است پیشنهاد ندهد.
- محدودیت‌ها: در پرامپت دقیقاً مشخص می‌شود که ویژگی چه چیزهایی را باید مدیریت کند و چه کارهایی را «نباید» انجام دهد.
- خروجی: پاسخ مدل به یک خلاصه معماری کوتاه (۳-۴ جمله)، شبه‌کد (Pseudocode) برای تابع اصلی و یک «تلهٔ احتمالی» (Gotcha) که باید مراقب آن بود، محدود می‌شود.
برای پیاده‌سازی منطق Exponential Backoff در یک API ساخته شده با Express، برنامه‌نویس تعیین کرد که سیستم نباید در خطاهای سری 4xx تلاش مجدد کند (فقط 5xx) و باید هر تلاش را لاگ کند. با چسباندن کد API Handler، نتیجه دقیقاً با الگوهای کدبیس مطابقت داشت و ۱.۵ ساعت تحقیق و طراحی را حذف کرد.
الگوی زیربنایی
تمام این ۵ پرامپت بر یک منطق چهارگانه و ثابت استوارند:
۱. صراحت در نیاز: به جای ابهام، دقیقاً بگویید چه می‌خواهید.
۲. ارائه کد واقعی: به جای مفاهیم انتزاعی، تکه‌های کد واقعی را ارائه دهید.
۳. درخواست خروجی ساختاریافته: به جای اجازه دادن به مدل برای پرگویی‌های باز، خروجی را محدود و ساختاریافته بخواهید.
۴. لیست کردن تلاش‌های قبلی: تمام کارهایی که نکرده یا شکست خورده‌اند را بگویید تا AI آن‌ها را تکرار نکند.
این رویکرد مدل را از یک «چت‌بات گاهی مفید» به یک ابزار کاربردی و یک نیروی ضربه‌زننده (Force Multiplier) تبدیل می‌کند که بهره‌وری را ۱۰ برابر می‌کند.
اندازه‌گیری اثرات
برای کمی کردن این دستاوردها، توسعه‌دهنده جلسات کاری خود را در سه هفته ردیابی کرد. داده‌ها نشان‌دهنده کاهش چشمگیر زمان صرف شده برای هر ویژگی بود:
- قبل از تغییر: میانگین ۴ ساعت برای ساخت یک ویژگی.
- بعد از تغییر: میانگین ۲.۵ ساعت برای ساخت ویژگی با همان سطح پیچیدگی.
- سود کل: ۱.۵ ساعت صرفه‌جویی در هر جلسه × ۶ تا ۷ جلسه در هفته = ۱۰ تا ۱۱ ساعت صرفه‌جویی در هفته.
این افزایش بهره‌وری نتیجهٔ به‌روزرسانی مدل یا تغییر در الگوریتم‌های AI نیست، بلکه حاصل تغییر در رفتار انسان است. نویسنده استدلال می‌کند که مهارت اصلی در عصر فعلی، توانایی انتقال دقیق محدودیت‌ها و چارچوب‌ها به ماشین است.
برای برنامه‌نویس مدرن، مزیت رقابتی تغییر کرده است. کسانی که همچنان از AI مثل یک موتور جست‌وجو استفاده می‌کنند، توسط کسانی که آن را به عنوان یک ابزار دقیق برای معماری و بازبینی به کار می‌گیرند، پشت سر گذاشته خواهند شد. اگر می‌خواهید این نتایج را تکرار کنید، با ممیزی تعاملات AI خود در این هفته شروع کنید و تعداد دفعاتی که مجبور به بازنویسی پرامپت می‌شوید تا به پاسخ قابل استفاده برسید را بشمارید.
گام بعدی شما
- تعاملات AI خود را در این هفته ممیزی کنید و تعداد دفعاتی که مجبور به بازنویسی پرامپت می‌شوید را بشمارید.
- در اولین بازبینی کد بعدی، به جای «بررسی کن»، از ساختار «بزرگ‌ترین مشکل / بازنویسی / نقطه قوت» استفاده کنید.
- برای کدهای پیچیده، از مدل بخواهید نقش برنامه‌نویسی را بازی کند که برای اولین بار کد را می‌بیند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو