قرارداد بازخورد: جایگزینی اتونومی مطلق با تعریف دقیق «پایان کار» در عامل‌های

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

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

در دنیای واقعی توسعه وب، این وضعیت شبیه این است که به یک پیمانکار بودجه بیشتری بدهید اما نقشه‌ی ساختمان را به او ندهید؛ در نهایت کار بیشتری انجام می‌شود، اما لزوماً خانه درست ساخته نمی‌شود.

شکست «کدنویسی بر اساس حس»

به نقل از تحلیل دقیقی که در ۱۷ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، بیشتر بازخوردهای طراحی برای انسان‌ها نوشته می‌شوند. عباراتی مثل «این طرح کلیشه‌ای است»، «سلسله‌مراتب بصری رعایت نشده» یا «می‌شود خلوت‌ترش کنی؟» حاوی بستری از مفاهیم مشترک انسانی هستند که انسان‌ها از طریق تجربه به اشتراک گذاشته‌اند. اما عامل‌های هوش مصنوعی (AI Agents) این جملات را دعوت‌نامه‌هایی باز برای جابه‌جایی تصادفی کدهای CSS می‌بینند.

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

یکی از نمونه‌های این رویکرد، ابزار Hallmark است. این ابزار فعالیت‌ها را به چهار بخش ساخت، بازرسی، بازطراحی و مطالعه تقسیم می‌کند و الگوهای ضد طراحی (anti-patterns) را به عنوان دروازه‌های عبور صریح تعریف می‌کند. نکته کلیدی اینجا نیست که طراحی «حل شده» است، بلکه این است که عامل حالا می‌تواند در یک چک‌لیست مشخص شکست بخورد، به جای اینکه صرفاً «حس» مورد نظر طراح را تشخیص ندهد یا نادیده بگیرد.

تبدیل درخواست‌ها به محدودیت‌ها

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

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

• محدودیت‌های طراحی:
  • حفظ سلسله‌مراتب فعلی تیترها.
  • عدم استفاده از گرادینت یا کارت‌های تزئینی.
  • نمایان بودن اقدام اصلی (primary action) در عرض ۳۲۰ پیکسل.
• الزامات رفتاری:
  • غیرفعال بودن دکمه «ذخیره» تا زمان تغییر در فیلدها.
  • نمایش خطای سرور در کنار فیلد خطا دار.
  • حفظ تغییرات پس از درخواست‌های ناموفق.
  • بازگرداندن فوکوس به اولین فیلد نامعتبر.
• مراحل تأیید:
  • گرفتن اسکرین‌شات در حالت دسکتاپ و عرض ۳۲۰ پیکسل.
  • تست یک ذخیره‌سازی موفق و یک ذخیره‌سازی رد شده.
  • ثبت خطاهای کنسول در هر دو جریان.

شکاف میان دید و ردیابی

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

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

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

بدون هر دو، دموهای عامل‌ها معمولاً تقلب می‌کنند. آن‌ها کدی را تغییر می‌دهند تا اسکرین‌شات زیباتری تولید کنند و تظاهر می‌کنند حلقه بسته شده است. در واقعیت، هنوز نمی‌دانیم آیا تعاملات کار می‌کند، کنسول پاک است یا عامل واقعاً کامپوننت را درست کرده است یا فقط روی symptom (نشانه) رنگ زده است.

اثبات به عنوان یک محصول

در ۱۷ ژوئیه ۲۰۲۶، بحث‌های کاربران در Hacker News درباره ابزار ProofShot بر این نکته تاکید داشت که «پایان کار» نباید یک پیام متنی از سوی هوش مصنوعی باشد. «پایان» باید سندی باشد که بازبین بدون اجرای مجدد کل فرآیند، بتواند آن را بررسی کند. اسکرین‌شات یک سند است، اما گواه بر رفتار نیست. یک جریان ذخیره‌سازی خراب، یک رگرسیون در دسترس‌پذیری یا کامپوننتی که فقط با داده‌های دمو کار می‌کند، همگی می‌توانند اسکرین‌شات‌های بی‌نقصی تولید کنند.

مدرک باید با ریسک مطابقت داشته باشد. یک تغییر در فاصله‌گذاری (spacing) شاید فقط به دو عکس قبل و بعد در دو عرض مختلف نیاز داشته باشد، اما تغییر در بخش پرداخت (checkout) نیازمند تست‌های رفتاری و مدارک حالت شکست است. این تغییر رویکرد در پذیرش خروجی، ما را به سمتی می‌برد که به جای بازبینی خط‌به‌خط، از مدل‌های مسئولیت‌پذیری برای مدیریت خروجی‌های هوش مصنوعی استفاده کنیم. یک بسته اثباتی جامع باید شامل موارد زیر باشد:

• نماهای قبل و بعد برای تمام اندازه‌های صفحه نمایش مرتبط.
• جریان دقیق کاربر (user flow) که در هنگام اصلاح اجرا شد.
• خطاهای کنسول و درخواست‌های شبکه ناموفق.
• اتصال مستقیم المان بصری به کد منبع تغییر یافته.
• چک‌های پذیرش مشخصی که پاس شدند یا شکست خوردند.
• گزارشی از تأییداتي که عامل نتوانست تکمیل کند.

چارچوب عملیاتی برای پیاده‌سازی

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

۱. چه محدودیت بصری یا رفتاری باید حتماً حفظ شود؟
۲. کدام مسیر (route)، اندازه صفحه، وضعیت داده یا وضعیت کاربر، مشکل را نمایان می‌کند؟
۳. المان بصری چگونه به وضعیت زمان اجرا و کد ردیابی می‌شود؟
۴. دقیقاً چه تعاملی یا چه چکی باید اجرا شود؟
۵. عامل چه مدرکی را باید برای بازبینی برگرداند؟
۶. عامل در مورد چه چیزهایی می‌تواند تصمیم بگیرد و چه چیزهایی هنوز به انسان نیاز دارد؟

عبور از وسواس «اتونومی حداکثری»

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

این رویکرد، انتخاب ابزار را به یک تصمیم منطقی بر اساس نیازهای قرارداد تبدیل می‌کند:

• دید خواندنی مرورگر: برای چک‌های ساده رندر شده کافی است.
• تست‌های کنترل‌شده مرورگر: برای جریان‌های فرم چندمرحله‌ای ضروری است.
• نگاشت DOM به منبع: برای باگ‌های وابسته به وضعیت کامپوننت لازم است.
• چک‌های دسترس‌پذیری: برای الزامات پرریسک دسترس‌پذیری اجباری است.

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

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

گام بعدی شما

• به جای توصیفات صفت‌محور (مثل «زیباتر» یا «بهینه‌تر»)، از چک‌لیست‌های Markdown برای تعریف خروجی عامل‌ها استفاده کنید.
• ابزارهایی مانند ProofShot یا Domscribe را برای تبدیل اسکرین‌شات‌های ساده به مدارک فنی قابل ردیابی بررسی کنید.
• در پرامپت‌های خود، بخشی را به «مدارک مورد نیاز برای پذیرش» اختصاص دهید تا عامل را مجبور به گزارش شواهد کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.