تصور کنید ابزاری دارید که می‌تواند در چند ثانیه هزاران خط کد بنویسد، اما شما دیگر نمی‌دانید چرا این کدها نوشته شده‌اند یا اصلاً چه هدفی دارند. این همان نقطه‌ای است که سرعت خیره‌کننده هوش مصنوعی به یک کابوس مدیریتی برای برنامه‌نویسان تبدیل می‌شود. «حالت‌های برنامه‌ریزی ساختاریافته در حال منسوخ شدن هستند.» این درک حیاتی برای توسعه‌دهنده‌ای بود که سعی داشت یک «پروتز برای ذهن انسان» بسازد.
در ۲۵ سپتامبر ۲۰۲۶، ایمن ندیم (Ayman Nadeem) جزئیاتی از شکست اپلیکیشن کدنویسی خود به نام Nuanced را منتشر کرد. او توضیح داد که چرا این ابزار با وجود حل مشکل فنی سرعت تولید کد توسط هوش مصنوعی، نتوانست مورد استقبال قرار گیرد. از نظر او، مشکل اصلی نه در توانایی کدنویسی هوش مصنوعی، بلکه در رابط کاربری (Interface) مورد استفاده برای مدیریت این هوش بود.
انگیزه‌های پشت ساخت Nuanced
ندیم بر اساس یک مشاهده خاص تحریک به ساخت این ابزار شد: هوش مصنوعی سرعت و حجم تولید کد را به‌طور رادیکالی افزایش داده بود، اما رابط‌های کاربری مورد نیاز برای پشتیبانی از این سرعت جدید در کار، پیشرفت نکرده بودند. او معتقد بود که در عصر هوش مصنوعی زاینده (Generative AI)، برنامه‌ریزی به حیاتی‌ترین بخش ساخت نرم‌افزار تبدیل خواهد شد.
او می‌خواست به یک سؤال بنیادی پاسخ دهد: انسان‌ها چگونه می‌توانند مدل ذهنی منسجمی از یک سیستم نرم‌افزاری حفظ کنند، در حالی که ماشین‌ها سریع‌تر از توان بررسی انسان، تغییرات را اعمال می‌کنند؟ بدون راهی برای مدیریت این وضعیت، مدل‌ها می‌توانستند در عرض چند دقیقه هزاران خط کد بنویسند. این امر باعث ایجاد یک بار نگهداری (Maintenance Burden) عظیم می‌شد، حتی پیش از آنکه برنامه‌نویس بتواند به این فکر کند که اصلاً چه چیزی را می‌سازد یا چرا می‌سازد. این فشار مدیریتی با کاهش رضایت شغلی مهندسان نرم‌افزار به دلیل پیچیدگی مدیریت ابزارهای هوش مصنوعی همسو است.
ریسک‌های تولید سریع کد
این سرعت بالا باعث ایجاد چندین اصطکاک روان‌شناختی و فنی شد:
- پنهان شدن تصمیمات: سهولت در تولید کد باعث ایجاد یک پاداش دوپامینی می‌شد، اما کار دشوار و ناخوشایند ارزیابی محصول، طراحی و تصمیمات زیرساختی را پنهان می‌کرد. این روند، فرآیند درک اینکه چرا ساختن چیزی اهمیت دارد، یا اصلاً آیا اهمیت دارد یا خیر را تیره و تار می‌کرد.
- تثبیت زودهنگام خطاها: فرض‌های نادرست اغلب پیش از آنکه مورد تأمل و استدلال قرار گیرند، در قالب کد تثبیت می‌شدند. این موضوع دیباگ کردن رفتار سیستم را در مراحل بعدی دشوار می‌کرد. ندیم متوجه شد که اغلب پیش از آنکه آگاهانه هرگونه تصمیم واقعی درباره محصول بگیرد، به یک محصول نهایی رسیده است.
- شکاف‌های معماری: اگر کاربر معماری را به‌طور ناقص تعریف می‌کرد، عامل (Agent) این آزادی را به خود می‌داد تا آن شکاف‌ها را پر کند. این کار اغلب مرزهای انتزاعی (Abstraction Boundaries) ایجاد می‌کرد که بعدها در پروژه منجر به بروز مشکلات جدی می‌شد.
- انتشار پنهان خطاها: سوءتفاهم‌ها درباره رفتار مورد انتظار، در چندین فایل مختلف و بسیار عمیق‌تر از سطح چت پخش می‌شدند و به‌راحتی نادیده گرفته می‌شدند. جستجو برای یافتن این مشکلات پیچیده و نامفهوم، بسیار ناکارآمدتر از این بود که سیستم از ابتدا به‌درستی طراحی می‌شد.
ندیم این تجربه را به «احساس گسست ذهنی و زامبی‌وار» تشبیه کرد؛ به‌ویژه زمانی که اپلیکیشن‌هایی مانند Conductor و Codex امکان اجرای موازی چندین عامل را فراهم کردند. او حس می‌کرد دیگر نمی‌تواند مانند دوران «پیش از این‌ها» (beforetimes) تمرکز کند یا به همان عمق درک دست یابد. هیچ ردپای شفاف و قابل تفسیری وجود نداشت که پرامپت کاربر را به تصمیم عامل، سپس به کد و در نهایت به رفتار محصول متصل کند. این تغییر نقش برنامه‌نویس را به چیزی شبیه به تجربه‌ی مهندسانی تبدیل می‌کند که دیگر کد نمی‌نویسند و به ارکستراتورهای سیستم تبدیل شده‌اند.
شکست رویکرد «برنامه به مثابه یک اثر»
Nuanced طراحی شده بود تا برنامه‌ریزی را به یک رکن اصلی (First-class Primitive) تبدیل کند. ندیم زمان زیادی را صرف جابجایی بین Claude Code CLI، Conductor و Codex کرده بود و متوجه شد که برای اصلاح برنامه‌ها، مجبور است تکه‌هایی از چت را کپی کرده و در پیام‌های جدید قرار دهد تا آن‌ها را بازبینی کند. این گردش کارِ «برش و چسباندن» (Cut-and-paste) بسیار بدقلق و طاقت‌فرسا بود. او می‌خواست برنامه‌ها را از «توده‌های متنی گذرا» که در تاریخچه چت ناپدید می‌شدند، به یک سند زنده، پویا و ماندگار تبدیل کند.
سیستم Nuanced به کاربران اجازه می‌داد تا رشته‌های گفتگو (Threads) ایجاد کنند تا درباره ساخت یک قابلیت بحث کنند. سیستم ابهامات و تصمیماتی که نیاز به ورودی کاربر داشت را شناسایی می‌کرد و پیش از شروع پیاده‌سازی، به یک برنامه ثابت می‌رسید. این ابزار قرار بود برای ذهن‌های دارای ADHD (بیش‌فعالی و نقص توجه) مانند یک پروتز عمل کند تا هم به کاربر دستورالعمل دهد و هم به او کمک کند تا کنترل پروژه را حفظ کند. هدف او ایجاد یک خط لوله (Pipeline) سرتاسری بود که با «قصد» (Intent) شروع شده و به پیاده‌سازی، بازبینی و تأیید ختم شود.
با این حال، این رویکرد با چهار دیوار سخت برخورد کرد:
۱. خلط برنامه‌ریزی با سند برنامه:
ندیم آموخت که برنامه‌ریزی (به عنوان یک فرآیند) و برنامه (به عنوان یک اثر یا سند) یکی نیستند. در حالی که فضای فکر کردن ارزشمند بود، کاربران اولیه به‌طور غافلگیرکننده‌ای اشتیاق کمی برای خواندن سند ساختاریافته نهایی (Spec) داشتند.
۲. هم‌پوشانی توانایی‌های مدل:
با بهبود مدل‌ها در استفاده از زمینه (Context) و حافظه برای کاوش در مخازن کد و گرفتن فرض‌های منطقی، نیاز به دستورالعمل‌های صریح کاهش یافت. در واقع، توانایی مدل به رقیبی برای رابط کاربری تفکر انسانی تبدیل شد؛ هر تصمیمی که مدل می‌توانست به‌طور قابل‌اعتمادی بگیرد، یک تصمیم کمتر بود که نیاز به نمایش برای انسان داشت.
۳. خستگی از متن‌های تولید شده توسط هوش مصنوعی:
مشخصات (Specifications) تولید شده توسط هوش مصنوعی اغلب طولانی و بیش از حد ساختاریافته بودند. ندیم متوجه شد که ریتم متن‌های هوش مصنوعی باعث می‌شود چشم‌های او «خیره و بی‌روح» (glaze over) شود؛ یعنی اطلاعات بیشتری ارائه می‌شد بدون اینکه شفافیت بیشتری ایجاد شود. برای حل این مشکل، آن‌ها یک «تور بازدید از سند» (Spec Tour) ساختند تا کاربران را در بخش‌های مهم راهنمایی کند، اما این کار فقط پیچیدگی و حجم متنی که نیاز به توجه داشت را افزایش داد. او دریافت که اگر برای کاربردی کردن سند به یک نمایش کوتاه‌تر نیاز است، پس خود سند کامل بی‌فایده است.
۴. تضاد بین خطی بودن و واقعیت:
گردش کار در Nuanced بیش از حد متوالی (Sequential) بود: چت $ \rightarrow $ رفع ابهام $ \rightarrow $ تولید سند $ \rightarrow $ بررسی سند $ \rightarrow $ اصلاح سند $ \rightarrow $ تأیید $ \rightarrow $ پیاده‌سازی $ \rightarrow $ بررسی کد. اما تفکر واقعی ارگانیک است. یک برنامه‌نویس چیزی را امتحان می‌کند، تولید کد به او چیز جدیدی می‌آموزد و سپس نظرش تغییر می‌کند. Nuanced کاربران را مجبور می‌کرد تا برای شروع ساخت، تفکر خود را به‌طور زودهنگام «تمام کنند». وقتی پیاده‌سازی شروع می‌شد، بازگشت به استدلال‌های مبتنی بر چت، مانند حرکت به عقب در گردش کار احساس می‌شد.
تغییر به سمت حلقه‌های تکرار شونده
ندیم مشاهده کرد که مرز بین برنامه‌ریزی و اجرا در حال ناپدید شدن است. در ابزارهایی مانند Codex، این فرآیند به یک چرخه مداوم تبدیل شده است: درک، اقدام، بازرسی، شفاف‌سازی، تنظیم و اقدام مجدد. این رویکرد مشابه مدل AI-DLC است که در آن اجرای نرم‌افزار به‌طور کامل به عامل‌ها سپرده شده و انسان تنها در نقش ناظر باقی می‌ماند.
از نظر تاریخی، گردش کار «برنامه $ \rightarrow $ تأیید $ \rightarrow $ اجرا» ضروری بود زیرا هزینه حرکت در مسیر اشتباه به‌طور قابل‌توجهی بالاتر بود. اما اکنون، عامل‌ها در اقدام مستقل، تست کردن کارهای خود و بازبینی رویکردشان پس از بررسی نتیجه، توانمندتر شده‌اند. برنامه‌ریزی همچنان اتفاق می‌افتد، اما دیگر نیازی نیست به شکل سندی به نام «برنامه» ظاهر شود. ندیم به این نتیجه رسید که بزرگترین اشتباه او تبدیل کردن برنامه به یک «اثر» (Artifact) بود، به جای اینکه فرآیندی برای بهبود درک انسان طراحی کند.
اصطکاک تغییر «حالت» (Mode Switching)
ابزار Nuanced دارای یک «حالت برنامه‌ریزی» (Plan Mode) و یک «حالت ساخت» (Build Mode) مجزا بود. حالت برنامه‌ریزی همیشه یک سند Spec تولید می‌کرد، در حالی که حالت ساخت برای کارهای کوچک‌تری بود که توجیه داشتن یک سند را نداشتند. این موضوع یک بار شناختی (Meta-cognitive Burden) ایجاد می‌کرد: کاربر باید تصمیم می‌گرفت که آیا یک تسک «لایق» برنامه‌ریزی هست یا نه و سپس به یاد می‌آورد که حالت درست را از طریق دکمه یا میانبر کیبورد فعال کند.
ندیم متوجه شد که این تفکیک چیزی است که هوش مصنوعی باید بر اساس بستر (Context) انجام دهد. او اشاره کرد که سادگی یک رابط چت — جایی که برنامه‌ریزی در صورت نیاز انجام می‌شود و نه به‌طور پیش‌فرض — در واقع برتر است؛ درکی که او آن را با «میم میدویت» (midwit meme) مقایسه کرد.
مشکل حل‌نشده‌ی درک انسانی
با وجود مرگ «حالت برنامه‌ریزی» به عنوان یک ویژگی، مشکل زیربنایی درک انسانی همچنان باقی است. فکر کردن به اینکه چه چیزی ساخته شود و چرا اهمیت دارد، همچنان ضروری است، اما حجم زیادی از متن‌های تولید شده توسط هوش مصنوعی، رابط مناسبی برای این کار نیستند.
همان‌طور که سیستم‌ها از ۵ عامل به صدها عامل گسترش می‌یابند، خطر گسست ذهنی افزایش می‌یابد. به‌روز ماندن نمی‌تواند به معنای خواندن هر گفتگو یا درخواست توضیح برای هر تغییر کد باشد. مسئله باز و حل‌نشده این است که چگونه به انسان‌ها کمک کنیم تا زمانی که صدها عامل توانمند به‌طور همزمان در حال تغییر یک سیستم هستند، جهت‌نمای خود را حفظ کنند.
ندیم نتیجه می‌گیرد که آینده در دست عامل‌هایی است که بتوانند کمترین نقاطی را شناسایی کنند که توجه انسان در آن‌ها بیشترین تأثیر را دارد و فقط مقدار کافی از زمینه (Context) را برای مفید کردن آن توجه، ارائه دهند. در حالی که رابط‌ها و فناوری‌ها تغییر می‌کنند، نیاز به تبدیل پیچیدگی به چیزی قابل‌فهم، یک چالش همیشگی است.
گام بعدی شما
- اگر از ابزارهای کدنویسی عامل‌محور استفاده می‌کنید، به جای اصرار بر نوشتن اسناد دقیق اولیه، روی حلقه‌های «اجرا-بازرسی-اصلاح» تمرکز کنید.
- در پرامپت‌های خود به جای درخواست «برنامه جامع»، از مدل بخواهید در هر مرحله نقاط تصمیم‌گیرنده (Decision Points) را شناسایی و گزارش کند.
- ابزارهایی را امتحان کنید که اجازه می‌دهند کد در حین تولید، به‌صورت پویا تغییر یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو