آرام‌تر، این پاسخ عصر مامور است

عنوان اصلی: افکاری در مورد آهسته کردن سرعت سکس
نویسنده اصلی: ماریو زچنر
ترجمه: پگی، بلاک بیتس

یادداشت سردبیر: همزمان با شتاب گرفتن ورود هوش مصنوعی مولد به مهندسی نرم‌افزار، احساسات صنعت از «هیجان ناشی از توانایی» به «اضطراب ناشی از کارایی» تغییر می‌کند. به اندازه کافی سریع ننوشتن، به اندازه کافی استفاده نکردن، به اندازه کافی خودکارسازی نکردن - همه اینها به نظر می‌رسد فشار منسوخ شدن را ایجاد می‌کنند. با این حال، همچنان که عوامل کدنویسی واقعاً وارد محیط تولید می‌شوند، برخی مسائل عملی‌تر شروع به ظهور می‌کنند: خطاها بزرگنمایی می‌شوند، پیچیدگی از کنترل خارج می‌شود، سیستم‌ها به طور فزاینده‌ای مبهم می‌شوند و افزایش کارایی به طور متناسب به بهبود کیفیت منجر نمی‌شود.

این مقاله، بر اساس رویه‌های خط مقدم، تأملی هوشیارانه در مورد روند فعلی «کدگذاری عاملی» ارائه می‌دهد. نویسنده اشاره می‌کند که عامل‌ها مانند انسان‌ها از اشتباهات درس نمی‌گیرند؛ در غیاب گلوگاه‌ها و مکانیسم‌های بازخورد، مسائل کوچک به سرعت بزرگ می‌شوند. در پایگاه‌های کد پیچیده، دیدگاه محلی و ظرفیت محدود فراخوانی آنها، بی‌نظمی ساختار سیستم را تشدید می‌کند. ریشه این مشکلات نه در خود فناوری، بلکه در انسان‌هاست که تحت تأثیر اضطراب، قضاوت و کنترل خود را پیش از موعد رها می‌کنند.

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

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

متن اصلی در زیر آمده است:

حالت چهره لاک‌پشت نشان می‌دهد که من چگونه به این صنعت نگاه می‌کنم

حدود یک سال پیش، یک عامل کدنویسی واقعی که می‌توانست به شما در «تکمیل یک پروژه کامل از ابتدا تا انتها» کمک کند، شروع به ظهور کرد. ابزارهای اولیه‌ای مانند Aider و Cursor وجود داشتند، اما آنها بیشتر شبیه دستیار بودند تا "عامل". نسل جدید ابزارها بسیار جذاب هستند و بسیاری از مردم زمان زیادی از اوقات فراغت خود را صرف انجام تمام پروژه‌هایی کرده‌اند که همیشه می‌خواستند انجام دهند اما هرگز برای آنها وقت نداشتند.

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

در طول تعطیلات کریسمس، شرکت‌های Anthropic و OpenAI همچنین برخی «اعتبارات رایگان» را منتشر کردند و مانند یک دستگاه اسلات، مردم را به خود جذب کردند. برای بسیاری، این اولین طعم واقعی جادوی «کدنویسی عامل» بود. مشارکت رو به افزایش است.

امروزه، کدنویسی با یک عامل (Agent) نیز در حال ورود به پایگاه‌های کد عملیاتی است. دوازده ماه گذشته است و ما کم‌کم داریم عواقب این «پیشرفت» را می‌بینیم. اینها افکار فعلی من هستند.

همه چیز در حال فروپاشی است

اگرچه بیشتر این‌ها روایت‌های شخصی است، اما نرم‌افزارهای فعلی واقعاً این حس را القا می‌کنند که هر لحظه «در شرف از کار افتادن» هستند. آپتایم ۹۸٪ حتی برای سرویس‌های بزرگ، از یک استثنا به یک امر عادی در حال گذار است. رابط کاربری پر از انواع و اقسام باگ‌های مسخره است که باید توسط تیم کنترل کیفیت در یک نگاه شناسایی می‌شدند.

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

ما نمی‌توانیم وضعیت واقعی درون شرکت‌ها را ببینیم، اما گاهی اوقات نشت اطلاعات وجود دارد، مانند شایعه «قطعی AWS ناشی از هوش مصنوعی». خدمات وب آمازون فوراً این بیانیه را «تصحیح» کرد، اما بلافاصله یک طرح سازماندهی مجدد ۹۰ روزه را به صورت داخلی آغاز کرد.

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

شرکت‌هایی که ادعا می‌کنند «۱۰۰٪ محصول توسط هوش مصنوعی تولید می‌شود» تقریباً همیشه بدترین محصولاتی را که می‌توانید تصور کنید، تولید می‌کنند. نمی‌خواهم انگشت اتهام را به سمت کسی نشانه بگیرم، اما چیزهایی مثل کمبود حافظه به اندازه گیگابایت، آشفتگی رابط کاربری، نبود امکانات، کرش‌های مکرر... هیچ‌کدام از این‌ها چیزی نیست که آن‌ها به عنوان «تایید کیفیت» در نظر گرفته باشند، چه برسد به اینکه بخواهند نشانه‌ای مثبت از «بگذارید نماینده همه کارها را برای شما انجام دهد» ارائه دهند.

به طور خصوصی، شما بیشتر و بیشتر از شرکت‌های بزرگ و تیم‌های کوچک خواهید شنید که یک چیز را می‌گویند: آنها توسط «کدنویسی عاملی» به گوشه‌ای رانده شده‌اند. بدون بررسی کد، سپردن تصمیمات طراحی به Agent و سپس انباشتن مجموعه‌ای از ویژگی‌های غیرضروری - بدیهی است که این کار به خوبی تمام نخواهد شد.

چرا نباید از عامل به این شکل استفاده کنیم؟

ما تقریباً تمام نظم مهندسی و قضاوت ذهنی را کنار گذاشته‌ایم و در عوض به یک روش کار «اعتیادآور» روی آورده‌ایم: تنها یک هدف وجود دارد - تولید بیشترین کد در کمترین زمان ممکن، بدون در نظر گرفتن عواقب آن.

شما در حال ساخت یک لایه داربست برای فرماندهی یک ارتش خودکار از ماموران هستید. شما Beads را نصب کرده‌اید، اما کاملاً بی‌اطلاع هستید که اساساً یک «بدافزار» غیرقابل حذف است. شما فقط به این دلیل این کار را انجام می‌دهید که منابع آنلاین می‌گویند «همه این کار را می‌کنند». اگر این کار را به این روش انجام ندهی، "ngmi" (موفق نخواهی شد) خواهی بود.

شما دائماً در یک «حلقه‌ی تودرتو به سبک عروسک» در حال خودخوری هستید.

ببینید—شرکت آنتروپیک با استفاده از گروهی از عامل‌ها یک کامپایلر C ایجاد کرد، اگرچه هنوز مشکلاتی دارد، اما مدل نسل بعدی مطمئناً قادر به رفع آنها خواهد بود، درست است؟

حالا ببینید—کِرسِر با استفاده از گروه بزرگی از عامل‌ها یک مرورگر ساخته است، اگرچه اکنون اساساً غیرقابل استفاده است و هنوز هم گاهی اوقات به مداخله دستی نیاز دارد، مدل نسل بعدی مطمئناً قادر به مدیریت آن خواهد بود، درست است؟

«توزیع‌شده»، «تفرقه بینداز و حکومت کن»، «سیستم‌های خودمختار»، «کارخانه نور سیاه»، «شش ماه برای حل یک مشکل نرم‌افزاری»، «نرم‌افزار به عنوان سرویس (SaaS) مرده است، مادربزرگم همین الان با استفاده از Claw یک فروشگاه Shopify راه‌اندازی کرد»...

این روایت‌ها هیجان‌انگیز به نظر می‌رسند.

البته، این رویکرد ممکن است واقعاً برای پروژه جانبی تقریباً بلااستفاده شما (از جمله پروژه خودتان) «هنوز هم کار کند». شاید واقعاً نابغه‌ای وجود داشته باشد که بتواند از این روش برای ایجاد یک محصول نرم‌افزاری بی‌نقص و واقعاً قابل استفاده استفاده کند. اگر شما آن شخص هستید، پس من واقعاً شما را تحسین می‌کنم.

با این حال، حداقل در حلقه‌های توسعه‌دهندگان من، هنوز مورد واقعاً مؤثری از این روش ندیده‌ام. البته، شاید همه ما خیلی بی‌تجربه باشیم.

انباشتگی خطاها در عدم یادگیری، عدم وجود گلوگاه‌ها و انفجارهای تأخیری

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

اما «ماشین‌ها» انسان نیستند. انسان‌ها معمولاً پس از تکرار یک اشتباه چندین بار، یاد می‌گیرند که دیگر آن را تکرار نکنند - یا توسط کسی سرزنش می‌شوند، یا در یک فرآیند یادگیری واقعی تغییر می‌کنند.

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

البته، می‌توانید سعی کنید آنها را «آموزش» دهید: در AGENTS.md قوانینی بنویسید که چنین اشتباهاتی را تکرار نکنند؛ یک سیستم حافظه پیچیده برای آنها طراحی کنید تا خطاهای تاریخی و بهترین شیوه‌ها را جستجو کنند. این در واقع در انواع خاصی از مشکلات مؤثر است. اما فرض این است که - ابتدا باید مشاهده کنید که این اشتباه را مرتکب شده است.

تفاوت کلیدی این است: انسان‌ها گلوگاه هستند؛ اما ماموران اینطور نیستند.

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

با این حال، وقتی شما یک ارتش کامل از مامورانِ به خوبی هماهنگ شده را مستقر می‌کنید، هیچ گلوگاه و «احساس درد»ی وجود نخواهد داشت. این خطاهای کوچک و بی‌اهمیت که در ابتدا بی‌اهمیت هستند، با سرعتی ناپایدار روی هم انباشته می‌شوند. شما از این حلقه خارج شده‌اید، بی‌خبر از اینکه این اشکالات به ظاهر بی‌ضرر به یک غول تبدیل شده‌اند. وقتی واقعاً درد را احساس می‌کنید، معمولاً خیلی دیر شده است.

فقط وقتی که یک روز سعی می‌کنید یک ویژگی جدید اضافه کنید و متوجه می‌شوید که معماری سیستم فعلی (اساساً انبوهی از خطاها) نمی‌تواند این تغییر را در خود جای دهد، یا کاربران شروع به شکایت شدید می‌کنند زیرا آخرین نسخه دارای مشکلات یا بدتر از آن، از دست دادن داده‌ها است.

در این مرحله است که متوجه می‌شوید: دیگه نمیشه به این کد بیس اعتماد کرد.

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

تبریک می‌گویم، شما خودتان (و شرکتتان) را در چاه انداخته‌اید.

تاجر پیچیدگی

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

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

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

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

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

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

نرخ فراخوانی جستجوی عامل‌محور پایین است

شما می‌توانید امیدوار باشید که Agentها «آشفتگی‌ها را برایتان برطرف کنند»، به شما در بازسازی، بهینه‌سازی و پاک‌سازی سیستم کمک کنند. اما مشکل این است: آنها دیگر نمی‌توانند این کار را انجام دهند.

زیرا کدبیس (codebase) خیلی بزرگ و پیچیدگی آن خیلی بالاست و آنها فقط می‌توانند بخشی از آن را ببینند. این فقط به این دلیل نیست که پنجره context به اندازه کافی بزرگ نیست، یا مکانیسم long-context در مواجهه با میلیون‌ها خط کد از کار می‌افتد. مشکل، موذیانه‌تر است.

قبل از اینکه یک عامل (Agent) سعی در اصلاح سیستم داشته باشد، ابتدا باید تمام کدهایی را که نیاز به اصلاح دارند و همچنین پیاده‌سازی‌های موجودی را که می‌توانند دوباره استفاده شوند، پیدا کند. این مرحله را جستجوی عاملی می‌نامیم.

اینکه یک عامل چگونه این کار را انجام می‌دهد، به ابزاری که به آن می‌دهید بستگی دارد: می‌تواند Bash + ripgrep باشد، می‌تواند یک فهرست کد قابل جستجو، سرویس LSP، پایگاه داده برداری و ... باشد.

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

به همین دلیل است که در ابتدا آن خطاهای جزئی «بوی کد» ظاهر می‌شوند، پیاده‌سازی موجود را پیدا نمی‌کند، بنابراین چرخ را دوباره اختراع می‌کند و ناسازگاری ایجاد می‌کند. در نهایت، این مشکلات همچنان گسترش می‌یابند، همپوشانی دارند و به یک «گل گندیده» بسیار پیچیده تبدیل می‌شوند.

پس چگونه می‌توانیم از همه اینها اجتناب کنیم؟

چگونه باید با نمایندگان همکاری کنیم (حداقل فعلاً)

کدنویسی با Agentها مثل سر و کله زدن با یک هیولای دریایی است، با سرعت تولید کد فوق‌العاده بالا و آن نوع هوش «متناوب اما گهگاه خیره‌کننده» که شما را جذب می‌کند. آنها اغلب می‌توانند کارهای ساده را با سرعت و کیفیتی شگفت‌انگیز انجام دهند. مشکل واقعی زمانی شروع می‌شود که این فکر به ذهنتان خطور می‌کند - «این چیز خیلی قدرتمند است، کامپیوتر، کار را برای من انجام بده!»

البته واگذاری وظایف به خودِ نماینده مشکلی ندارد. وظایف یک عامل خوب معمولاً چندین ویژگی دارند: دامنه آن می‌تواند به خوبی تعریف شود، نیازی به درک کل سیستم نیست؛ وظیفه حلقه بسته است، به این معنی که عامل می‌تواند نتایج را به تنهایی ارزیابی کند؛ خروجی در مسیر بحرانی نیست، فقط برخی ابزارها یا نرم‌افزارهای موقت برای استفاده داخلی است، بر کاربران واقعی یا درآمد تأثیر نمی‌گذارد؛ یا فقط به یک "اردک لاستیکی" نیاز دارید تا به شما در فکر کردن کمک کند - اساساً ایده‌های شما را می‌گیرد و با دانش فشرده شده از اینترنت و داده‌های مصنوعی برخورد می‌کند.

اگر این شرایط برآورده شوند، این وظیفه برای واگذاری به نماینده مناسب است، مشروط بر اینکه شما، به عنوان یک انسان، همچنان کنترل کیفیت نهایی را بر عهده داشته باشید.

برای مثال، استفاده از روش تحقیق خودکار آندره کارپاتی برای بهینه‌سازی زمان راه‌اندازی برنامه؟ عالیه. اما ضروری است که بدانید کدی که ارائه می‌دهد به هیچ وجه آماده تولید نیست. تحقیق خودکار مؤثر است زیرا شما به آن یک تابع تناسب اندام داده‌اید تا حول یک معیار خاص (مانند زمان راه‌اندازی یا تلفات) بهینه‌سازی کند. با این حال، این تابع تناسب اندام تنها یک بُعد بسیار باریک را پوشش می‌دهد. عامل با جسارت تمام معیارهایی را که در تابع تناسب اندام لحاظ نشده‌اند، مانند کیفیت کد، پیچیدگی سیستم و در برخی موارد، حتی صحت - اگر خود تابع تناسب اندام شما دارای نقص باشد - نادیده می‌گیرد.

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

اما چیزی که واقعاً می‌خواهم تأکید کنم این است: واقعاً، کمی سرعتتان را کم کنید.

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

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

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

شما ویژگی‌های کمتری خواهید داشت، اما آنها صحیح‌تر خواهند بود. یادگیری «نه» گفتن خودش یک مهارت است. همچنین می‌توانید با خیال راحت بخوابید زیرا هنوز می‌دانید در سیستم چه اتفاقی می‌افتد، هنوز کنترل دارید. این درک است که شما را قادر می‌سازد تا به مسئله‌ی فراخوانی جستجوی عامل (agentic search) رسیدگی کنید، خروجی عامل را قابل اعتمادتر کرده و نیاز به وصله‌بندی کمتری داشته باشید.

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

همه اینها نیاز به نظم و انضباط دارد. همه اینها از انسان جدا نشدنی است.

[ مقاله اصلی ]