بدهی شناختی؛ دلیل بازگشت برخی برنامه‌نویسان به تایپ دستی کدهای هوش مصنوعی

تصور کنید کدی را در پروژه خود دارید که دقیقاً نمی‌دانید چگونه کار می‌کند، اما چون «کار می‌کند»، به آن دست نمی‌زنید. این دقیقاً همان نقطه‌ای است که برنامه‌نویسان مدرن در آن کنترل خود را بر معماری نرم‌افزار از دست می‌دهند.

به نقل از پست ۳ آگوست ۲۰۲۶ در دفترچه یادداشت آنکور ستی (Ankur Sethi)، اتکای کامل به مدل‌های زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای پیاده‌سازی سریع ویژگی‌های کامل (One-shot features)، توسعه‌دهندگان را از کار خود جدا و سردرگم می‌کند. او هشدار می‌دهد که این رویکرد باعث می‌شود برنامه‌نویس نسبت به محصول خود بی‌تفاوت شود و این وضعیت را یک بحران خاموش در مهندسی نرم‌افزار می‌نامد که او با امتناع از کپی-پیست کردن کدهای تولید شده توسط AI با آن مبارزه می‌کند.

زمینه: بدهی شناختی چیست؟

ستی پذیرفته است که هنوز برای پروژه‌های شخصی از دستیارهای کدنویسی استفاده می‌کند تا «بخش‌های خسته‌کننده را سریع رد کند». با این حال، او استدلال می‌کند که برون‌سپاری این تفکرات به ماشین، حجم عظیمی از «بدهی شناختی» (Cognitive Debt) ایجاد می‌کند. برای مثال، او اشاره می‌کند که هرچند ممکن است از بررسی مفصل مستندات جنگو (Django) برای افزودن قابلیت تگ‌گذاری به یک وب‌سایت متنفر باشد، اما او همچنان به‌طور بنیادین می‌خواهد بفهمد این مکانیسم در پس‌زمینه چگونه عمل می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی تأخیر در ابزارهایی مثل Oxlo.ai اشاره کردیم، تمرکز ما بر جنبه‌های فنی بود، اما ستی روی جنبه انسانی یعنی «تأخیر شناختی» متمرکز است؛ تأخیری که وقتی تفکر را به ماشین می‌سپاریم، ایجاد می‌شود.

این چالش در «سال نفرین‌شده ۲۰۲۶» به اوج رسیده است؛ سالی که صنعت به سوی مدلی حرکت کرده که در آن ربات‌ها درخواست‌های تغییر کد (PR) را ایجاد می‌کنند و انسان‌ها صرفاً بازبین آن‌ها هستند. این روند باعث شده تا ابزارهای جدیدی برای مدیریت حافظه و کدها ظهور کنند؛ برای نمونه پروژه‌ی Arka Sentinel تلاش می‌کند با جایگزینی موتور حافظه محلی با بردار معنایی، امنیت و کنترل توسعه‌دهنده بر کدهایش را افزایش دهد. طبق گزارش ستی، بازبینی صدها خط کدِ تولیدشده توسط AI — که اغلب بیش از حد تدافعی (Overly-defensive)، به‌طور ظریفی غلط و با کامنت‌های بد نوشته شده‌اند — تجربه‌ای پوچ و بدون لذت است. او تاکید می‌کند که در پروژه‌های شخصی، لذت باید از «فرآیند» کدنویسی باشد، نه فقط رسیدن به «نتیجه».

جزئیات: پیاده‌سازی دستی و سخت‌گیرانه

ستی برای بازپس‌گیری کنترل، یک گردش‌کار عمداً ناکارآمد را تعریف کرده است. او اجازه نمی‌دهد دستیار کدنویسش «آزادانه» (Roam free) در پروژه عمل کند و دستورالعمل‌های سخت‌گیرانه‌ای را در تمامی فایل‌های عامل (Agent) خود قرار داده است:

• یکپارچگی فایل‌ها: مدل هرگز نباید فایل‌ها را بسازد، ویرایش کند، جابه‌جا کند، تغییر نام دهد یا حذف کند، مگر اینکه صریحاً خواسته شود. تمامی ویرایش‌های پیشنهادی باید ابتدا در محیط چت نمایش داده شوند تا کاربر آن‌ها را به‌صورت دستی تایپ کند.
• کنترل دستورات: مدل اجازه ندارد دستوراتی را که باعث تغییر در فایل‌های پروژه، نصب وابستگی‌ها (Dependencies) یا تغییر وضعیت مخزن کد (Repository) می‌شود اجرا کند. در عوض، باید این دستورات را در چت نمایش دهد تا کاربر آن‌ها را به صورت دستی اجرا نماید.
• سطح تخصص: چون او یک برنامه‌نویس باتجربه است، به AI دستور داده شده که سینتکس، APIها، مفاهیم برنامه‌نویسی یا جزئیات پیاده‌سازی را توضیح ندهد، مگر اینکه او صراحتاً درخواست توضیح کند.

ستی ادعا می‌کند با تایپ تک‌تک خطوط، یک نقشه ذهنی و فضایی (Spatial Map) دقیق از فضای کد خود می‌سازد. او به‌دقت می‌داند هر تکه از عملکرد (Functionality) دقیقاً در کجا قرار دارد. این فرآیند به او اجازه می‌دهد توهمات (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد — یا تصمیمات طراحی ضعیف را در لحظه شناسایی کند و سپس آن‌ها را بازطراحی (Refactor)، سازماندهی مجدد کرده و کامنت‌هایی متناسب با سلیقه شخصی خود به آن‌ها اضافه کند.

تحلیل: توازن بین درک و بهره‌وری

بر اساس گزارش ankursethi.com، این متد سرعت توسعه را به‌شدت کاهش می‌دهد. در حالی که دیگران با سپردن تفکر به ماشین ممکن است «۱۰ برابر سریع‌تر» باشند، ستی احتمالاً تنها «۲ برابر سریع‌تر» از زمانی است که هیچ LLM-ی در اختیار ندارد. اما او استدلال می‌کند که آنچه در سرعت از دست می‌دهد، در درک عمیق‌تر از نحوه قرارگیری کد در بدنه کلی پروژه به‌دست می‌آورد. اگر او با یک الگوریتم یا API ناآشنا مواجه شود، متوقف می‌شود تا درباره آن تحقیق کند یا از LLM یک توضیح خاص و هدفمند بخواهد.

در حالی که ستی بر روی فرآیند تمرکز دارد، بسیاری از کاربران به دنبال رابطه‌های تعاملی‌تر با هوش مصنوعی هستند؛ موضوعی که در بررسی تفاوت‌های شخصیتی مدل Opus 5 و چت‌جی‌پی‌تی به عنوان عاملی برای جذب یا دفع توسعه‌دهندگان مورد تحلیل قرار گرفت. او این وضعیت را با نحوه یادگیری برنامه‌نویسان در دهه‌های گذشته مقایسه می‌کند. مربیان باتجربه توصیه می‌کردند کدهای نمونه را از کتاب‌ها، وب‌گاه‌ها یا فروم‌ها کپی-پیست نکنند، بلکه دانش‌آموزان باید آن‌ها را دستی تایپ می‌کردند تا منطق برنامه را واقعاً درونی کنند.

برای یک توسعه‌دهنده معمولی، این یعنی «بهره‌وری» وعده داده شده توسط عامل‌های هوش مصنوعی ممکن است توهمی بر پایه سرعت موقت باشد. اثر درجه‌دوم این روند، توده‌ای از بدهی شناختی است که وقتی سیستم شکست بخورد و هیچ انسانی نفهمد کد چگونه کار می‌کند، باید پرداخت شود. ستی از آینده‌ای می‌ترسد که در آن دیگر نفهمیم بخش‌های بزرگی از زیرساخت‌های دیجیتال ما چگونه سر هم شده‌اند و عدم درک نرم‌افزاری که خودتان نوشته‌اید را «قصور حرفه‌ای» (Professional Malpractice) می‌نامد.

اگر احساس می‌کنید از پروژه‌های خود فاصله گرفته‌اید، سعی کنید سه تابع اخیر که با AI تولید کرده‌اید را بازبینی کنید. اگر نمی‌توانید هر خط را بدون کمک مدل توضیح دهید، در حال انباشت بدهی شناختی هستید.

گام بعدی شما

• آخرین توابع تولیدشده توسط AI در پروژه خود را بررسی کنید و سعی کنید منطق آن‌ها را روی کاغذ رسم کنید.
• در پرامپت‌های خود شرط بگذارید که مدل به‌جای تغییر مستقیم فایل، ابتدا کد پیشنهادی را برای بازبینی شما بنویسد.
• برای مفاهیمی که مدل به‌طور خودکار پیاده کرده، مستندات رسمی زبان یا فریم‌ورک را بخوانید تا شکاف شناختی پر شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.