حالت پلان مرده است

در اوایل سال جاری، من معتقد بودم که برنامه ریزی قرار است به مهم ترین بخش ساخت نرم افزار با هوش مصنوعی تبدیل شود.

اعتقاد من به این ایده آنقدر قوی بود که یک برنامه برنامه نویسی دسکتاپ کامل را پیرامون آن ساختم و راه اندازی کردم. انگیزه Nuanced مشاهده شد که هوش مصنوعی سرعت و حجم تولید کد را به شدت افزایش داده است، اما رابط‌های مورد نیاز برای پشتیبانی از این سرعت جدید کار هنوز به نتیجه نرسیده بودند.

رویکرد Nuanced به برنامه‌ریزی شکست خورد، اما همچنین به من نشان داد که چگونه حالت‌های برنامه به طور گسترده‌تر دیگر چندان مفید نیستند. از لحاظ تاریخی، حالت‌های پلان دو هدف را دنبال می‌کردند: (1) دستورالعمل‌هایی را مشخص می‌کردند که به اندازه کافی برای یک عامل دقیق بودند، و (2) به انسان‌ها کمک می‌کردند بفهمند چه چیزی می‌سازند.

من فکر می کنم شماره 1 با بهتر شدن مدل ها به سرعت در حال منسوخ شدن است. من فکر می‌کنم شماره 2 بیش از هر زمان دیگری اهمیت دارد، اما حالت‌های پلان انتزاع اشتباهی برای آن هستند، به خصوص که تعداد عوامل موازی که اجرا می‌کنیم افزایش می‌یابد.

محصولی که من انگیزه ساخت آن را داشتم در نهایت به سوالی پاسخ داد که فکر می‌کنم هنوز مرتبط است و همیشه مرتبط خواهد بود، و آن این است: چگونه انسان‌ها یک مدل ذهنی منسجم از یک سیستم نرم‌افزاری را حفظ می‌کنند در حالی که ماشین‌ها آن را سریع‌تر از آنچه انسان‌ها می‌توانند تغییرات را بررسی کنند، تغییر می‌دهند؟

مدل‌ها می‌توانند هزاران خط کد را در عرض چند دقیقه بنویسند، به این معنی که شما حتی قبل از اینکه به چیزی که می‌سازید یا چرا فکر کنید، بار تعمیر و نگهداری عظیمی را به ارث خواهید برد. این امر استدلال در مورد رفتار و اشکال زدایی مفروضات نادرست را که پیش از موعد به کد تبدیل شده بودند دشوار می کرد.

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

این سوء تفاهمات در مورد رفتار و طراحی مورد نظر از طریق چندین فایل بسیار زیر سطح چت منتشر می شود و به راحتی می توان آنها را از دست داد. ماهیگیری در اطراف برای مشکلات غیرقابل درک در زیر این سطح کارایی کمتری نسبت به طراحی درست چیزی داشت.

چیزی در مورد این تجربه وجود داشت که باعث شد من از نظر ذهنی احساس عدم ارتباط و زامبی مانند کنم، به خصوص که برنامه های کدنویسی مانند Conductor و Codex توانایی اجرای موازی عوامل بیشتری را فعال می کنند. احساس می‌کردم نمی‌توانم واقعا تمرکز کنم و به همان عمق یا درک آنچه که قبلا روی آن کار می‌کردم دسترسی داشته باشم. این امر همچنین بررسی درستی نتایج تولید شده را برای من دشوارتر کرد.

هیچ ردی واضح و قابل تفسیری وجود نداشت که ارتباط بین درخواست کاربر → تصمیم نماینده → کد → رفتار محصول را نشان دهد. این بدان معنا نیست که من می‌خواهم به روزهای قدیمی نگاه کردن به خطوط کد یا فایل‌ها برگردم. من در واقع احساس کردم که استدلال درباره ایده ها به زبان طبیعی آسان تر و کارآمدتر است. من می‌خواستم با اطمینان بالای کد حرکت کنم بدون اینکه نیازی به فدا کردن درک خود از نحوه عملکرد سیستم داشته باشم.

من احساس کردم که در حالی که حالت های پلان وجود دارد، انتزاع مناسب برای برنامه ریزی خوب وجود ندارد. همانطور که از طریق Claude Code CLI چرخیدم، به Conductor، و در نهایت Codex هنگام راه اندازی آن، متوجه شدم که به طور دقیق برنامه ها را شکل می دهم و آنها را کوچک می کنم بدون اینکه خانه روشنی برای تکرار آنها داشته باشم. من این کار را با استفاده از چت انجام می‌دهم و سپس قطعات یک طرح را در پیام‌های جدید کپی می‌کنم تا آنها را اصلاح کنم (قبل از ویژگی‌های حاشیه نویسی Codex). این گردش کار برش و چسباندن به نظر سخت بود و کار روی یک ایده و در عین حال پیگیری برنامه فعلی را سخت می کرد.

می‌خواستم به برنامه‌هایم سرمنزلی بدهم، آن‌ها را در جریان کار کلی‌ام قرار دهم، و آنها را از حباب‌های متنی زودگذری که با پیشرفت مکالمات در صفحه پشتی ناپدید می‌شدند، به یک سند زنده، نفس‌گیر و پایدار تبدیل کنم. به چند دلیل می‌خواستم حالت پلان را به یک توسعه راهنمای ابتدایی درجه یک تبدیل کنم:

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

من یک خط لوله سرتاسری می‌خواستم که با قصد شروع شود و تا اجرا، بررسی و تأیید ادامه یابد. من به آن بیشتر به عنوان یک پروتز برای ذهن انسان (یا ذهن ADHD من) بیشتر از یک برنامه کدنویسی دیگر نگاه کردم، زیرا طراحی شده بود تا همانقدر که به من کمک کند تا از آنچه در حال انجام است یاد بگیرم.

این به این معنا نیست که ایده‌های من در مورد شکاف‌های موجود در ابزارهای موجود یا نحوه تغییر SDLC نادرست بود، بلکه اجرای ما راه‌حلی را که انتظار داشتیم ارائه نکرد. این به این دلیل است که:

اولین چیزی که فهمیدیم این بود که برنامه ریزی را با یک برنامه ترکیب کرده بودیم. اینها در واقع یک چیز نیستند. فرض من این بود که داشتن فضایی برای فکر کردن کامل در مورد چیزی قبل از اجرا ارزشمند است. من همچنین فکر می‌کردم حفظ این فکر در یک مصنوع ساختار یافته بزرگ با تکامل پروژه ارزشمند خواهد بود. اما کاربران اولیه به طرز شگفت انگیزی اشتهای کمی برای آن مشخصات داشتند.

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

من در ابتدا به قابلیت مدل به عنوان رقابت با طراحی رابط بهتر برای تفکر انسان فکر نمی کردم، اما از بسیاری جهات اینطور بود. این به این دلیل است که هر تصمیمی که مدل می توانست به خودی خود به طور قابل اعتماد بگیرد، یک تصمیم کمتر بود که باید ظاهر می شد.

مشخصات حاوی اطلاعات بیشتری بدون ایجاد وضوح بیشتر بود. این به این دلیل است که مشخصات ما طولانی بود. آنها تصمیمات مهمی را گرفتند و حاوی زمینه های زیادی بودند که مفید به نظر می رسید، اما مشکل این بود: آنها توسط هوش مصنوعی تولید شده بودند. چیزی در مورد سرعت و ماهیت بیش از حد ساختارمند متن تولید شده توسط هوش مصنوعی وجود دارد که خواندن آن را بسیار دشوار می کند. چشمانم مدام برق می زد.

به جای واکنش به این کشف با از بین بردن مشخصات، ما یک تور Spec Tour برای حل این موضوع ایجاد کردیم. ما فکر کردیم که به جای اینکه از کسی بخواهیم کل سند را جذب کند، Spec Tour می تواند آنها را در قسمت های مهم راهنمایی کند. اما این فقط روی یک لایه پیچیدگی اضافی پیچید، متن بیشتر روی صفحه من توجه را می طلبد. اگر لازم بود نمایش کوتاه تری از مشخصات ایجاد کنیم تا مشخصات قابل استفاده باشد، در وهله اول سند کامل چه فایده ای داشت؟

گردش کار ما خیلی خطی و متوالی بود. روند ما چیزی شبیه به این بود:

چت ← رفع ابهام با پاسخ دادن به سوالات ← تولید مشخصات ← بررسی مشخصات ← اصلاح مشخصات ← تایید ← اجرا → کد بررسی

تفکر واقعی به این شکل اتفاق نمی افتد و جدایی بین این بخش ها مصنوعی و اجباری احساس می شود. معمولا بخشی از مشکل را درک خواهید کرد، چیزی را امتحان کنید، نسل اولیه چیز جدیدی به شما یاد می دهد، که ممکن است باعث شود نظر خود را در مورد آن تغییر دهید و چیز دیگری را امتحان کنید. هر مرحله یک سوال جدید را آشکار می کند. برنامه‌ریزی و ساختن به هم پیوسته‌اند و بیشتر از آنچه که حالت‌های پلان اجازه می‌دهند ظاهر می‌شوند، به‌خصوص اینکه چگونه آن را در Nuanced ساختیم. رابط ما کاربران را مجبور کرد که زودتر از موعد "تفکر را به پایان برسانند" تا بتوانند شروع به ساخت کنند.

هنگامی که پیاده سازی شروع شد، بازگشت به استدلال مبتنی بر چت قبلی مانند حرکت به عقب در گردش کار بود. امکان برگشت از آبشار وجود نداشت.

وقتی به نحوه عملکرد Codex در حال حاضر نگاه می‌کنید، مرز بین برنامه‌ریزی و اجرا در حال ناپدید شدن است، زیرا آنها به یک تبدیل می‌شوند. پیش از این، عوامل برنامه نویسی از جریان کاری که در آن انسان ها کارهای زیر را انجام می دادند، سود می بردند:

در آن زمان، هزینه رفتن در مسیر اشتباه به طور قابل توجهی بالاتر بود. اما همانطور که عوامل در درک سیستم ها بهتر شدند، در عمل مستقل و آزمایش کار خود نیز بهتر شدند. آنها همچنین در بازنگری رویکرد خود پس از بررسی نتیجه خوب هستند. این یک حلقه متفاوت را فعال می کند:

درک → عمل → بازرسی → روشن کردن → تنظیم → دوباره عمل کنید

هنوز حجم عظیمی از برنامه ریزی در این حلقه اتفاق می افتد، اما لزوما نیازی نیست که به عنوان سندی به نام "طرح" ظاهر شود. فکر می کنم بزرگ ترین اشتباهی که مرتکب شدم این بود که به جای طراحی فرآیندی برای درک بهتر انسان، طرح را به یک مصنوع تبدیل کردم.

Nuanced یک حالت پلان و حالت ساخت داشت و کاربران می توانستند با هر کدام شروع کنند. حالت پلان همیشه یک مشخصات تولید می‌کند، در حالی که حالت ساخت کاربران را مجبور به یک مشخصات نمی‌کند و می‌تواند برای کارهای کوچک‌تری که مشخصات را توجیه نمی‌کنند استفاده شود. اما جداسازی بین این حالت‌ها ناخوشایند بود و کاربر را ملزم می‌کرد که این سوال متا را از خود بپرسد که آیا یک کار مستحق برنامه‌ریزی است یا خیر، و سپس به یاد داشته باشد که در صورت انجام، حالت پلان را از طریق یک دکمه یا میانبر صفحه کلید فعال کند.

به نظر می رسد که نوع تمایزی که هوش مصنوعی باید برای شما بر اساس زمینه ای که در حال حاضر دارد ایجاد کند، و به یاد آوردن حالتی که باید در آن باشید احساس می کنید که بار شناختی بیشتری را معرفی می کند.

این درک باعث شد که من احساس کنم شبیه میم میانه شوم، به این دلیل که سادگی یک رابط چت که در آن برنامه ریزی به جای پیش فرض بر اساس نیاز انجام می شد، در واقع بسیار عالی بود.

فکر کردن در مورد اینکه چه چیزی بسازید، چرا اهمیت دارد و ارزیابی تصمیمات همچنان مهم است. مردم باید یک مدل ذهنی منسجم از آنچه در حال وقوع است بسازند، اما من فکر نمی‌کنم حجم وسیعی از متن تولید شده توسط هوش مصنوعی رابط مناسبی برای آن باشد. کار بر روی تصمیمات در چت بصری تر به نظر می رسد، اما به روز نگه داشتن این درک با تغییر سیستم همچنان یک مشکل باز است.

وقتی از پنج نماینده به صدها کارگزار می‌روید، این مشکل سخت‌تر می‌شود. ادامه دادن نمی تواند به معنای خواندن هر مکالمه و تلاش برای ارائه توضیح برای هر تغییر کد باشد. کارگزاران باید کمترین مکان‌هایی را که توجه انسان می‌تواند بیشترین تأثیر را داشته باشد شناسایی کنند و زمینه را برای مفید ساختن آن توجه نشان دهند.

ما هنوز حل نکرده‌ایم که چگونه به مردم کمک کنیم تا جهت‌گیری داشته باشند، زیرا صدها عامل توانمندتر یک سیستم را به یکباره تغییر می‌دهند. اما من فکر می‌کنم مشکل عمیق‌تر، یعنی اینکه انسان‌ها چگونه سیستم‌ها را درک می‌کنند، سلسله مراتب اطلاعات پیچیده را هدایت می‌کنند و از ابزارهای قدرتمند استفاده می‌کنند، مشکلی پایدار است. رابط‌ها در کنار فناوری‌هایی که به آن‌ها قدرت می‌دهد تغییر می‌کنند. نیاز به قابل درک کردن پیچیدگی نیست.