ارباب حلقه ها: بازگشت به شایر

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

چند وقت پیش می خواستم مشکل تایپ فارسی در OpenCode WebUI رو حل کنم. بعضی ابزارهای تحت وب با شروع نوشتن فارسی، جهت کادر متن رو RTL می کنن، اما خیلی ها این رفتار رو ندارن. اول issueهای پروژه رو بررسی کردم. چند نفر قبلا تلاش کرده بودن، ولی بعضی راه حل ها زیادی پیچیده شده بودن و بعضی PRها هم به نظر نمی رسید به این زودی پذیرفته بشن.

رفتم سراغ پیاده سازی، این بار مطابق اصول مشارکت خود پروژه. تقریبا هم به نتیجه رسیدم، اما موقع آماده کردن PR دیدم احتمالا مسیر merge شدنش طولانیه و یک PR تازه هم برای همین موضوع باز شده. تازه اگر تغییر من پذیرفته می شد، فقط مشکل OpenCode حل شده بود، بقیه ابزارها همچنان همون وضعیت رو داشتن.

پس تصمیم گرفتم یک افزونه برای فایرفاکس بسازم. وسط کار بررسی کردم و دیدم چندین افزونه برای همین کار وجود داره. پروژه رو کنار گذاشتم، یکی رو نصب کردم و مشکل حل شد.

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

برنت فیتزجرالد در مطلب The human is the loop از تجربه ای نوشته که به همین موضوع نزدیکه. بعد از چند هفته فاصله گرفتن از AI، به مجموعه ای از agentها و گفت وگوهای نیمه تمام برگشته بود. میگفت احساس اینکه حالا باید بتونه کارهای بیشتری انجام بده، باعث شده بود مرتب پروژه تازه ای شروع کنه، حتی وقتی نیاز مشخصی به نتیجه اون نداشت.

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

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

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

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

در «برج دیده بانی» گفتم لازم نیست تمام مسیر اجرای agent رو دوباره طی کنیم. اینجا همون بحث یک شرط مهم پیدا می کنه: فاصله گرفتن از جزییات اجرا نباید باعث بشه تصویرمون از سیستم رو از دست بدیم. از بالای برج باید بتونیم بیشتر ببینیم.

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

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

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