‏REA: روشی پنج‌مرحله‌ای برای اینکه ایجنت هوش مصنوعی یه فیچر رو از نو بسازه

Reverse Engineer Anything (به‌اختصار REA) یه ریپوی گیت‌هابه برای ایجنت‌های کدنویسی هوش مصنوعی. ایده‌ش اینه که به‌جای گفتن «یه اسکرین‌رکوردر برام بساز»، ایجنت رو سمت یه فیچر مشخص تو یه اپ مشخص بفرستی، مثلاً حباب شناور دوربین تو Loom. ایجنت رفتار اون فیچر رو بررسی می‌کنه و بعد همون کارکرد رو تو کدبیس خودت از نو می‌سازه. نه کدی کپی می‌شه، نه فایل و asset.

REA کار رو به پنج مرحله تقسیم می‌کنه. اول انتخاب یه فیچر، یعنی فقط یه تیکه از اپ، نه کل اپ. دوم route by build، یعنی ایجنت قبل از بررسی می‌فهمه اپ اصلی احتمالاً با چه تکنولوژی‌ای ساخته شده، چون این روی ابزارهای بررسی اثر داره. سوم summary first: تو مقاله اومده که تحلیل خام Loom از یه گیگابایت بیشتر شده بود. REA اینو به یه خلاصه‌ی کوتاه تبدیل می‌کنه که می‌گه چی کار می‌کنه، چطور کار می‌کنه و چی هنوز معلوم نیست، و اونو لوکال ذخیره می‌کنه که ایجنت هر بار تحلیل رو از اول اجرا نکنه.

مرحله‌ی چهارم به گفته‌ی نویسنده همونیه که بیشتر آدما جا می‌ندازن: هر یافته یه برچسب می‌گیره، seen (یعنی مستقیم دیده شده و می‌شه بهش ارجاع داد)، inferred (یعنی داده‌ها قویاً نشونش می‌دن ولی تأیید نشده) یا unknown. دلیلش اینه که ایجنت‌ها معمولاً حدس رو با همون اطمینانِ واقعیت تأیید‌شده می‌گن. اگه روی یه حدس بسازی، ممکنه یه فیچری رو دیباگ کنی که اصلاً اون‌جوری ساخته نشده بوده. مرحله‌ی پنجم rebuild and testـه: ساختن و تست‌کردن یه مرحله‌ست و ایجنت اونقدر تکرار می‌کنه تا رفتار با نسخه‌ی اصلی بخونه.

نویسنده می‌گه فرق اصلیش با «یه کلون بساز» دقیق‌بودن هدفه. درخواست مبهم، خروجی کلی و معمولی می‌ده، ولی وقتی یه فیچر واقعی رو نشون می‌دی، اپ عملاً می‌شه مشخصات محصول. این همون تکنیکیه که بهش reverse engineering the output می‌گن: مثلاً یه ایجنت ده‌ها ریلز موفق اینستاگرام رو فریم‌به‌فریم بررسی کرده و سبک تدوینشون (فونت، ترنزیشن، ریتم B-roll) رو درآورده و ازش یه skill قابل‌استفاده ساخته.

به گفته‌ی مقاله، REA برای بازسازی تجربه‌ی ضبط Loom (حباب دوربین متحرک، توقف و ادامه، شمارش معکوس) به‌شکل یه رکوردر لوکال که فایل‌ها رو تو یه پوشه ذخیره می‌کنه، و برای ساختن یه ابزار ارزیابی با الهام از Langfuse استفاده شده. تو همه‌ی این موارد ظاهر نتیجه با اپ اصلی فرق داشته. نویسنده قبول داره که ایده‌ی پایه جدید نیست، ولی می‌گه ارزش REA اینه که یه روند تکرارپذیر بسته‌بندی‌شده‌ست، با این هشدار که کارکرد رو مطالعه کن، نه کد و asset کس دیگه رو، هم به دلیل عملی و هم برای دوری از نقض مالکیت فکری.

نکات کلیدی:

• REA پنج مرحله داره: انتخاب فیچر، route by build، summary first، برچسب seen/inferred/unknown، و rebuild and test.
• تحلیل خام Loom از یه گیگابایت بیشتر شده بود و REA اونو اول به یه خلاصه‌ی لوکال کوتاه تبدیل می‌کنه.
• برچسب seen/inferred/unknown جلوی ساختن روی حدس‌های تأییدنشده‌ی ایجنت رو می‌گیره.
• مثال‌ها با ابزارهای Claude (Claude Code و Opus) اجرا شدن، ولی روش با بقیه‌ی ایجنت‌های کدنویسی هم کار می‌کنه.
• REA کد یا asset اپ اصلی رو کپی نمی‌کنه و فقط رفتار رو از نو پیاده‌سازی می‌کنه.
• بزرگ‌ترین اشتباه اینه که ایجنت رو سمت کل اپ بفرستی، نه یه فیچر مشخص.