‏چرا سیستم‌های agentic شخصی به «توپ گِلی» تبدیل می‌شن

نویسنده این مقاله از NN/g می‌گه ساختن سیستم برای کار با AI agentها، چه سازنده‌اش بدونه چه ندونه، مهندسی نرم‌افزاره. این روزها خیلی از این سازنده‌ها vibe architect هستن، یعنی آدم‌هایی با پیش‌زمینه فنی کم که سیستم‌های پیچیده با context libraryهای بزرگ می‌سازن. تو یه مطالعه روی همین کاربرها، تیم NN/g یه الگوی قدیمی رو دید: big ball of mud، یعنی سیستمی که برای کارکرد کوتاه‌مدت سرهم شده نه برای دوام بلندمدت.

این اصطلاح از مقاله Brian Foote و Joseph Yoder میاد. به گفته مقاله، توپ گِلی معمولاً از کمبود زمان و پول و تخصص درست می‌شه. ولی الان قضیه برعکسه: AI ساختن رو ارزون کرده، پس چیزی مجبورت نمی‌کنه اولویت‌بندی کنی و آدم‌ها زیادی می‌سازن. یکی از شرکت‌کننده‌ها گفته چون ساختن با AI خیلی راحته، آدم‌ها زیادی می‌سازن، چون این کار حس بهره‌وری بهشون می‌ده.

نویسنده پنج الگو رو تو جلسه‌ها دیده. اول Throwaway Code: یه فایل rules.md یا اتوماسیون سرسری که فقط پیش‌نویس بوده ولی کم‌کم کل workflow به اون وابسته می‌شه. دوم Piecemeal Growth: مثلاً یه ویجت ساده Asana که اول دشبورد بهش اضافه شد و بعد با الگوریتم پیش‌بینی تاریخ اتمام به یه ابزار کل سازمان تبدیل شد، اونم توسط کسی که کدنویسی بلد نبود. بعضی شرکت‌کننده‌ها حتی نمی‌تونستن فایل‌های مهم سیستم خودشون رو پیدا کنن و باید از AI می‌پرسیدن.

سوم Keep It Working: سیستم خراب می‌شه و کاربر فقط وصله‌ش می‌کنه، مثل کسی که بعد از کرش اپ AI فایل‌ها رو از سطل زباله درآورد و از اون به بعد همه جلسه‌ها رو از پوشه Downloads اجرا کرد. چهارم Sweeping It Under the Rug: همه چی تو یه پوشه ریخته می‌شه که مثل کشوی خرت‌وپرت‌هاست، مثل پوشه to be synthesized که AI ازش مقاله اشتباه برداشت و کاربر ۴۵ دقیقه وقت گذاشت تا دستورها رو درست کنه. پنجم Reconstruction: وقتی سیستم دیگه به نیاز نمی‌خوره، دیگه کسی نمی‌فهمه چطور کار می‌کنه، یا یه روش بهتر پیدا می‌شه.

سؤال کلیدی مقاله برای اینکه بفهمی وقت بازسازیه یا نه اینه: اگه بخوای رفتار سیستم رو عوض کنی، می‌دونی کجای context library باید تغییر کنه؟ مقاله سه نوع context تعریف می‌کنه: global (دستورهایی که همه‌جا اعمال می‌شن)، local (مخصوص یه پروژه یا تسک) و ambient (جریان‌هایی مثل ایمیل و Slack که AI بهشون دسترسی داره ولی عمداً نگهداری نمی‌شن). اگه جواب «نه» باشه، یعنی این‌ها قاطی شدن و AI تنها کسیه که راه رو بلده.

پیشنهاد نویسنده چند عادت کوچیکه: context‌ها رو تو فایل‌های جدا نگه دار، موقع درخواست تغییر اسم نوع context رو بگو («global context رو آپدیت کن» نه «هر جا لازمه درستش کن»)، global context رو کوتاه نگه دار و هر از گاهی کامل مرورش کن، و وقتی خروجی‌ها خراب شدن local context رو تازه کن. به گفته مقاله، هدف جلوگیری از بازسازی نیست؛ اینه که وقتی لازم شد، خودت هدایتش کنی نه AI.

نکات کلیدی:

• اصطلاح big ball of mud از مقاله Foote و Yoder (چاپ‌شده در Pattern Languages of Program Design 4، سال ۱۹۹۹) میاد.
• پنج الگو: Throwaway Code، Piecemeal Growth، Keep It Working، Sweeping It Under the Rug و Reconstruction.
• سه نوع context: global، local و ambient؛ قاطی شدنشون نشونه نزدیک شدن به بازسازی اجباریه.
• global context باید اونقدر کوتاه باشه که تو یه نشست کامل مرور بشه.
• یه کاربر به خاطر پوشه نامرتب ۴۵ دقیقه صرف درست کردن دستورهای AI کرد.
• بهترین موقعیت رو کاربرهایی داشتن که می‌تونستن محدودیت‌های سیستمشون رو دقیق توضیح بدن.