خلاصه (TLDR): ابزارهای کدنویسی هوش مصنوعی قول داده بودند که ما را به توسعهدهندگان ۱۰۰۰ برابری تبدیل کنند. در عوض، بسیاری از ما در پروژههای نیمهتمام، برنامهریزیهای مجدد بیپایان و یک اضطراب عجیبِ جدید غرق شدهایم. من نام آن را «فلجِ کدنویسیِ حسی» (Vibe Coding Paralysis) میگذارم؛ پدیدهای که بسیار رایجتر از آن است که اعتراف میکنیم.
تلهی بهرهوری
در چند هفتهی اخیر متوجه چیزی شدهام. اول در تیم خودمان در Cua، بعد در پروژههای متنباز (OSS) و سپس در گفتگو با دوستانِ بنیانگذار در YC (Y Combinator). الگویی که همهجا به یکباره پدیدار شده است.
ما از «سیکلهای آزاد Claude Code» حرف میزنیم؛ همان زمانهایی که پس از ثبت یک دستور (Prompt)، منتظر نتیجه میمانید. کلود در حال فکر کردن، تولید کد و اجرای ابزارهاست. شما تماشا میکنید. غریزه به شما میگوید این زمان مرده را پر کنید. یک شاخهی کاری جدید (worktree) در گیت برای یک بخش موازی باز میکنید. در یک ترمینال دیگر تسک پسزمینه اجرا میکنید. یک نشست (Session) کلود در حال پیشنویس یک قابلیت است، همزمان به دیگری دستور میدهید یک ماژول را بازنویسی کند و سومی هم در حال نوشتن تستهاست.
روی کاغذ، ما داریم میترکانیم! درخواستهای ادغام (PR) ارسال میشوند، قابلیتها نهایی میشوند و نمودارهای سرعت خیرهکننده هستند.
اما یک جای کار میلنگد.
من هر روز را با خستگی مفرط تمام میکنم؛ نه از خودِ کار، بلکه از «مدیریتِ کار». شش شاخهی باز، چهار قابلیت نیمهنوشته، دو «اصلاح سریع» که تبدیل به چالههای عمیق شدهاند و یک حس فزاینده که انگار رشتهی امور کاملاً از دستم در رفته است.
وقتی این را به دوستان بنیانگذارم گفتم، همگی سر تکان دادند: «آره، دقیقاً همینطور است. راستی آن ابزار جدید برای مدیریت کارهای موازی را امتحان کردهای؟»
من آنها را امتحان کردهام. هیچکدام واقعاً جواب نمیدهند. چون مشکل از ابزارها نیست، مشکل از ماست. ما با یک حالت شکست (Failure Mode) جدید روبرو شدهایم؛ چیزی که گفتمانهای بهرهوری هرگز دربارهاش به ما هشدار نداده بودند.
فلج کدنویسی حسی چیست؟
فلج کدنویسی حسی، سندرمِ «خواستنِ انجامِ کارهای زیاد» — و «تواناییِ انجام کارهای زیاد» — است که در نهایت منجر به «تمام نکردن هیچچیز» میشود.
ماجرا اینطور است:
1. شما یک قابلیت را شروع میکنید. Claude Code در عرض چند دقیقه ساختار اولیه را میسازد.
2. در حالی که او مشغول است، به فکر یک بهبود دیگر میافتید. یک شاخه جدید باز میکنید و تسک دیگری را شروع میکنید.
3. حالا دو کار در جریان دارید. ایده سوم به ذهنتان میرسد. چرا که نه؟ یک شاخه دیگر.
4. یک ساعت بعد، شما پنج شاخه کاری، سه قابلیت نیمهتمام موازی دارید و یادتان نمیآید تسک اصلی اصلاً چه بود.
5. احساس عقب ماندن میکنید. پس دستورهای بیشتری میدهید. دوباره برنامهریزی میکنید. دوباره دستور میدهید.
برنامهریزیِ مجدد حسِ مولد بودن میدهد، اما واقعاً اینطور نیست.
پارادوکس اینجاست: هرچه توانمندی بیشتری داشته باشید، بیشتر احساس اجبار میکنید که از آن استفاده کنید. هرچه بیشتر استفاده کنید، تمرکزتان پراکندهتر میشود. هرچه تمرکز پراکندهتر شود، خروجیِ واقعیِ کمتری خواهید داشت.
این سوختگی (Burnout) به معنای سنتی نیست؛ چیزی عجیبتر است: نوعی «اضافهبارِ شناختی» که در لباس بهرهوری پنهان شده است.
فروپاشی اعتمادبهنفس
این بخشی است که هیچکس دربارهاش حرف نمیزند: فلج کدنویسی حسی، اعتمادبهنفس شما را میخورد.
وقتی Claude Code بیشترِ کد را مینویسد، یک سوالِ آزاردهنده شروع میشود: «آیا من واقعاً میفهمم اینجا چه اتفاقی میافتد؟» شما نگاهی گذرا به خروجی میاندازید. درست به نظر میرسد. تستها پاس میشوند. منتشرش کن!
اما وقتی چیزی خراب میشود — و همیشه چیزی خراب میشود — شما به کدی خیره شدهاید که خودتان ننوشتهاید، در حال حل مشکلی هستید که کاملاً درک نکردهاید، در پایگاه کدی که سریعتر از مدل ذهنی شما رشد کرده است.
پس کاری را میکنید که به نظرتان ایمن است: دوباره دستور میدهید. از کلود میخواهید توضیح دهد. میخواهید تعمیر کند. میخواهید دوباره معماری کند.
دستور دادن (Prompting) تبدیل به عصا میشود، بعد عادت و بعد اعتیاد.
من مچ خودم را گرفتهام که یک قابلیت را سه بار در یک روز دوباره برنامهریزی کردهام. نه به این خاطر که نقشه غلط بود، بلکه چون برنامهریزی راحتتر از «تعهد به اجرا» بود. هر برنامهریزی مجدد، راهی برای به تاخیر انداختنِ اضطرابِ اجرا بود. ابزاری که قرار بود به شما اعتمادبهنفس بدهد («حالا میتوانم هر چیزی بسازم!»)، آرامآرام آن را از شما میگیرد. شما وابسته به این چرخه میشوید: دستور، نقشه، دستورِ مجدد، نقشهی مجدد.
افسانه توسعهدهنده ۱۰۰۰ برابری
همه ما این افسانه را شنیدهایم: هوش مصنوعی توسعهدهندگان ۱۰۰۰ برابری خلق خواهد کرد. یک نفر که کار هزار نفر را انجام میدهد.
من بخش «توانمندی» را باور دارم. دیدهام که چه کارهایی ممکن است. یک توسعهدهنده تنها اکنون میتواند زیرساختی را برپا کند که قبلاً ماهها از یک تیم وقت میگرفت. پتانسیل خروجیِ خام واقعی است.
اما چیزی که این روایت نادیده میگیرد این است: گلوگاهِ انسانها سرعت تایپ نیست، بلکه «انسجام» (Coherence) است.
افسانه توسعهدهنده ۱۰۰۰ برابری فرض میکند خروجیِ بیشتر به معنای ارزشِ بیشتر است. اینطور نیست. ارزش از «کارهای تمامشدهای که کار میکنند» میآید. از سیستمهایی که از هم نمیپاشند. از کدی که شش ماه بعد هم بتوانید نگهش دارید.
وقتی بین پنج تسکِ مجهز به هوش مصنوعی جابجا میشوید (Context Switching)، در حال ساختن انسجام نیستید؛ در حال ساختن یک خانهی پوشالی هستید. هر کارت توسط یک نشستِ متفاوتِ کلود گذاشته شده و هر کارت با بقیه کمی ناتراز است.
انسان ضریب ۱۰۰۰ برابری نیست؛ انسان «یکپارچهساز» (Integrator) است. کسی که باید کل سیستم را در سرش نگه دارد، به آن انسجام ببخشد و مطمئن شود که واقعاً به کاربر خدمت میکند.
و یکپارچهسازی با سرعت هوش مصنوعی مقیاسپذیر نمیشود؛ بلکه با «تمرکز» مقیاس میگیرد. یعنی دقیقاً همان چیزی که فلج کدنویسی حسی نابودش میکند.
چرا این اتفاق الآن میافتد؟
این مشکلِ Claude Code نیست. مشکل هوش مصنوعی هم نیست. این مشکلِ «پیشی گرفتنِ توانمندی از سازگاری» است.
برای دههها، اصطکاکِ کدنویسی یک عاملِ بازدارنده بود. نوشتن کد کند بود، پس مجبور بودید حسابشده عمل کنید. نمیتوانستید پنج قابلیت را همزمان شروع کنید چون از نظر فیزیکی نمیتوانستید آنها را به آن سرعت پیادهسازی کنید. این محدودیت در واقع یک موهبت بود؛ شما را مجبور به اولویتبندی میکرد.
حالا آن اصطکاک از بین رفته است. ترمز بریده شده است. ابزارهای گیت و نشستهای موازی هوش مصنوعی شما را به موازیکاری تشویق میکنند. و ما هنوز ماهیچههای جدید برای کار کردن بدون آن محدودیتهای قدیمی را پرورش ندادهایم.
مثل این است که به کسی که همیشه پیادهروی کرده، یک ماشین بدهید. بله، سریعتر میرود، اما بیشتر هم تصادف میکند؛ تا زمانی که یاد بگیرد سرعت به مهارتهای جدیدی نیاز دارد: پیشبینی، رانندگی بین خطوط و دانستنِ زمانِ ترمز گرفتن.
ما همه در حال یادگیری رانندگی هستیم. و برخی از ما در حال تصادفیم.
الگوهایی که متوجه شدهام
در گفتگو با توسعهدهندگان، چند الگوی تکراری دیده میشود:
1. تلهی شروعکنندگی: شروع کردن حس فوقالعادهای دارد. هوش مصنوعی در چند دقیقه طرح شما را میسازد و دوپامین ترشح میشود. اما آن ۲۰٪ آخر — دیباگ کردن، موارد خاص، و صیقل دادن — هنوز زمانبر است. پس کارِ ۸۰٪ تمام شده را رها میکنید تا کار جدیدی شروع کنید. این چرخه تکرار میشود و شما میمانید و قبرستانی از پروژههای تقریباً تمامشده.
2. حلقه برنامهریزی: وقتی اجرا نامطمئن به نظر میرسد، برنامهریزی امن است. میتوانید ساعتها با کلود صرف طراحی سیستم شوید، بدون اینکه یک خط کد واقعی بنویسید. برنامهریزی تبدیل به «اهمالکاری در لباسِ کار» میشود.
3. فروپاشی بافت (Context Collapse): آنقدر نشستهای مختلف هوش مصنوعی دارید که یادتان میرود کدام کلود چه چیزی را «میداند». دوباره بافت را توضیح میدهید، پیشنهادهای متناقض میگیرید و هوش مصنوعی آینهای از آشفتگیِ ذهن خودتان میشود.
4. مارپیچِ اعتماد: هرچه هوش مصنوعی بیشتر مینویسد، شما کمتر به قضاوت خودتان اعتماد میکنید. هرچه کمتر اعتماد کنید، بیشتر کار را به هوش مصنوعی میسپارید. هرچه بیشتر بسپارید، کمتر یاد میگیرید. و این مارپیچ ادامه دارد.
چه کارهای متفاوتی انجام میدهم؟
من هنوز راه حل کامل را پیدا نکردهام، اما این موارد به من کمک میکنند:
• موازیکاریِ عمدی: کار موازی خوب است، به شرطی که از قبل برنامهریزی شده باشد. تله اصلی، موازیکاریِ واکنشی است: یعنی فقط چون کلود دارد فکر میکند و شما حوصلهتان سر رفته، کار جدیدی باز کنید. بنشینید و تغییر کد توسط هوش مصنوعی را تماشا کنید. حضور داشته باشید.
• زمانبندی برای برنامهریزی: به خودتان ۱۵ دقیقه زمان بدهید تا با کلود برنامهریزی کنید. بعد متوقف شوید. برنامه را اجرا کنید. نقشه نباید کامل باشد، باید «انجام» شود.
• خواندنِ کد: کد را نخوانید، آن را مطالعه کنید. قبل از ادغام هر چیزی که کلود نوشته، خط به خط آن را بفهمید. بله، سرعت را کم میکند، اما این تنها راه حفظ مدل ذهنی در سرتان است.
• آیینِ اتمامِ روزانه: در پایان روز از خودم میپرسم: امروز چه چیزی را «تمام» کردم؟ نه چه چیزی را شروع کردم یا پیش بردم. اگر جواب «هیچچیز» باشد، یعنی یک جای کار ایراد دارد.
• دستورِ کمتر، فکرِ بیشتر: قبل از رفتن سراغ کلود، سعی میکنم ۵ دقیقه با مسئله خلوت کنم. اغلب خودم جواب را میدانم. رفلکسِ دستور دادن، راهی برای فرار از فکر کردن است. گاهی اوقات، «فکر کردن» خودِ کار است.
حقیقتِ تلخ
چیزی که مدام به آن برمیگردم این است:
ابزارهای کدنویسی هوش مصنوعی واقعاً تحولآفرین هستند. اما آنها یک حقیقت ناخوشایند را برملا کردند: بهرهوری هرگز گلوگاه اصلی نبود.
گلوگاه همیشه انسجام، تمرکز، تمام کردن و قضاوت بود. دانستن اینکه «چه چیزی» بسازیم و «چرا».
اینها مسائل انسانی هستند و با تولید سریعترِ کد حل نمیشوند. در واقع، سرعتِ بیشتر اینها را سختتر میکند، چون حالا چیزهای نیمهتمامِ بیشتری برای جلب توجه شما با هم رقابت میکنند.
توسعهدهنده ۱۰۰۰ برابری کسی نیست که سریعتر دستور میدهد؛ کسی است که یاد گرفته در عصرِ «توانمندیِ بینهایت»، چطور منسجم بماند. کسی که میتواند از ابزارها استفاده کند، بدون اینکه توسط آنها تکهتکه شود.
من هنوز به آنجا نرسیدهام. هنوز در حال یادگیری رانندگی هستم.
اما نامگذاریِ مشکل، خودش یک شروع است. اگر شما هم این متن را میخوانید و سر تکان میدهید — اگر همان فلج حسی و همان خستگی عجیب را حس میکنید — بدانید که تنها نیستید.
ابزارها جدید هستند و راههای شکست خوردن هم جدید. با هم راهش را پیدا میکنیم.
فقط شاید بهتر باشد... هر بار یک کار انجام دهیم.
لینک مقاله رو نمیزاره ویرگول بزارم :)
