تصور کنید تاریخچه گیت (Git history) یک برنامه‌نویس را بررسی می‌کنید: در آن ثبت شده است که یک دکمه راهنما به یک بازی اضافه شده است، اما به‌ندرت توضیح داده شده که این افزودن به این دلیل اتفاق افتاد که توسعه‌دهنده خودش نتوانسته بود بفهمد چگونه بازی ساخته‌اش را بازی کند. این شکاف در حافظه سازمانی، دقیقاً همان مشکلی است که Coders Talk قصد حل آن را دارد، همان‌طور که در گزارشی منتشر شده در ۴ اکتبر ۲۰۲۶ به تفصیل آمده است.
اکثر توسعه‌دهندگان برای مستندسازی تغییرات به پیام‌های کامیت (Commit messages) یا درخواست‌های ادغام (Pull Requests) تکیه می‌کنند. با این حال، ارزشمندترین درس‌ها اغلب در گفتگوهای پر هرج‌ومرج بین یک انسان و یک عامل هوش مصنوعی (AI Agent)، پیش از آنکه کد نهایی کامیت شود، رخ می‌دهد. این نیاز به ثبت دقیق‌تر تغییرات، در واقع پاسخی به چالش‌های توصیف دستی تغییرات کد برای بقای برنامه‌نویسان در عصر عامل‌ها است تا منطق پشت هر تغییر برای آینده حفظ شود. وقتی شما یک فرض غلط از عامل را اصلاح می‌کنید یا یک محدودیت فنی را شفاف می‌سازید، آن «نوبت» (Turn) خاص از گفتگو معمولاً در یک لاگ طولانی دفن شده و ظرف دو هفته فراموش می‌شود. شما ممکن است به یاد بیاورید که مشکلی مشابه را حل کرده‌اید، اما به‌ندرت دقیقاً آن جمله‌ای را به یاد می‌آورید که مسیر حرکت عامل را تغییر داد.
برای درک بهتر، تصور کنید در حال ساخت یک بازی مرورگر مانند BUTTERFLY JOB با استفاده از Three.js و دارایی‌های (Assets) Blender هستید. در این بازی، بازیکن گذشته را تغییر می‌دهد تا یک سرقت از بانک در زمان حال ممکن شود. عامل هوش مصنوعی شما ممکن است تمام تست‌های واحد (Unit Tests) خودکار و بررسی‌های مرورگر را با موفقیت پشت سر بگذارد، اما بازی همچنان برای یک انسان غیرقابل‌بازی باقی بماند. در یکی از جلسات توسعه، در نقطه زمانی ۳ ساعت و ۴۳ دقیقه (+3h 43m)، توسعه‌دهنده مجبور شد مداخله کند زیرا نتوانسته بود بفهمد چه کاری باید انجام دهد. راهکار نهایی — اضافه کردن یک دیالوگ راهنما، یک راهنمای دائمی و یک دکمه کمک — در گیت تنها به عنوان یک تغییر در رابط کاربری (UI) ثبت می‌شود، اما درس واقعی — اینکه یک مسیر تست‌شده در بازی لزوماً به معنای این نیست که یک بازیکن جدید می‌تواند آن مسیر را کشف کند — یک بینش شناختی است که نیاز به رکورد مخصوص به خود دارد.
مکانیزم ثبت درس‌ها در Coders Talk
Coders Talk به عنوان لایه‌ای روی عامل‌های کدنویسی مانند Claude Code یا Codex عمل می‌کند. این ابزار به جای ذخیره یک فایل متنی خام، یک جلسه کاری را در قالب یک «Build» فشرده می‌کند. یک Build یک خلاصه ساختاریافته است که شامل یک هدف، یک خط زمانی، یک نتیجه و یک حکم (Verdict) درباره اینکه دفعه بعد چه کاری باید متفاوت انجام شود، است.
این سیستم رویدادهای جلسه را به پنج «لحظه» (Moment) متمایز دسته‌بندی می‌کند:
- پرامپت (Prompt): درخواست یا محدودیتی که مسیر کار را تعیین کرد.
- عمل عامل (Agent did): یک بازه معنادار از کار: رویکرد اتخاذ شده و آنچه تولید کرد.
- مداخله (Intervention): آنچه شخص اصلاح کرد و دلیل این اصلاح.
- شکست (Fail): آنچه خراب شد یا اشتباه از آب درآمد.
- نتیجه (Outcome): جایی که جلسه در واقع به پایان رسید، شامل تلاش‌هایی که رها شده‌اند.
هر جلسه لزوماً به تمام انواع لحظات نیاز ندارد. یک شکست یا یک اجرای بدون اصلاح انسانی همچنان ارزش نگهداشتن دارد. حیاتی‌ترین عنصر، «چرا» (Why) متصل به یک مداخله است. در حالی که یادداشتی با عنوان «من عامل را متوقف کردم» بی‌فایده است، اما یادداشتی که بیان کند «تست‌ها مسیر را پوشش دادند، اما من نتوانستم اولین اقدام را کشف کنم»، به سایر توسعه‌دهندگان یک نقطه عینی برای بررسی در پروژه‌های خودشان می‌دهد.
خط لوله فنی و حریم خصوصی
برای ایجاد یک Build، کاربران می‌توانند از دستوراتی مانند /coders-talk: build در Claude Code یا $coders-talk:build در Codex استفاده کنند. این پلاگین یک گزینه ارسال دستی ارائه می‌دهد که در آن دقیقاً نشان داده می‌شود چه چیزی آپلود خواهد شد و پیش‌نویس به کجا می‌رود.
- پردازش محلی: پلاگین پیش از آنکه داده‌ها دستگاه را ترک کنند، مواد حجیم جلسه را حذف کرده و اسرار (Secrets) شناسایی‌شده را به‌صورت محلی سانسور می‌کند.
- اعتبارسنجی سرور: سرور مجدداً داده‌ها را بررسی می‌کند. سپس یک مدل، عنوان، لحظات و یک پیش‌نویس حکم را پیشنهاد می‌دهد.
- بازبینی انسانی: نویسنده می‌تواند این پیشنهادات را ویرایش کرده و استدلال پشت اصلاحات را توضیح دهد. صفحه به‌طور صریح سهم مدل در تولید محتوا را مشخص می‌کند تا اطمینان حاصل شود که خلاصه به عنوان حقیقتی خطاناپذیر تلقی نشود.
این رکوردها در ابتدا به عنوان پیش‌نویس‌های خصوصی شروع می‌شوند. آن‌ها می‌توانند برای استفاده فردی نگه داشته شوند، در فضای یک تیم (اگر جلسه متعلق به یک مخزن تیمی باشد) به اشتراک گذاشته شوند یا به‌صورت عمومی منتشر گردند. اشتراک‌گذاری عمومی کاملاً اختیاری است. برای افراد، ارزش کار در یافتن یک اصلاح قبلی بدون نیاز به بازخوانی کل گفتگو است. برای تیم‌ها، یک مشکل تکراری می‌تواند به یک «قانون پیشنهادی» تبدیل شود که هم‌تیمی‌ها پیش از آنکه به عامل‌هایشان برسد، آن را بررسی می‌کنند و این قانون را به جلسه‌ای که آن را توضیح می‌دهد متصل نگه می‌دارند.
تبدیل رکوردها به اقدام عملی
هدف نهایی Coders Talk این است که اطمینان حاصل شود درس‌ها به جلسه بعدی می‌رسند. این امر از طریق «Playbookها» محقق می‌شود؛ مجموعه‌ای از رویکردها، تله‌ها و بررسی‌هایی که از یک Build استخراج شده‌اند.
این Playbookها می‌توانند مستقیماً از طریق روش‌های زیر در گردش‌کار یک پروژه ادغام شوند:
۱. فایل‌های CLAUDE.md یا AGENTS.md: با استفاده از ویژگی «Use this Build» برای تنظیم قوانین مخزن به عنوان یک پرامپت یا مهارت. این رویکرد در واقع راهکاری برای مدیریت پرامپت‌ها در محیط تولید است تا از تبدیل شدن آن‌ها به بدهی فنی جلوگیری شود.
۲. سرور MCP: اجازه دادن به عامل‌ها برای جست‌وجوی Buildهای منتشرشده جهت یافتن وظایف مشابه یا شکست‌های ثبت‌شده، پیش از شروع یک کار جدید یا زمانی که در جایی گیر می‌کنند.
در مثال BUTTERFLY JOB، این Playbook نیاز به بررسی اینکه «آیا یک بازیکن تازه‌وارد می‌تواند اولین اقدام را پیدا کند» را به آینده منتقل می‌کند. این Playbook توصیه را به مداخله خاص و لحظه‌ای متصل می‌کند که در آن بررسی‌های خودکار ناکافی بودند. این کار مانع از آن می‌شود که عامل به دستورالعمل مبهم «تست کامل انجام بده» تکیه کند و در عوض، بررسی دقیقی را بخواهد که در جلسه قبلی نادیده گرفته شده بود.
این تغییر، توسعه با هوش مصنوعی را از چرخه‌ای از اصلاحات تکراری به یک فرآیند یادگیری تجمعی تبدیل می‌کند. با مستند کردن «چرا»ی یک مداخله — مانند اصلاحی در جلسه BUTTERFLY JOB که الزامات دارایی‌ها را صریح کرد (اینکه هر شیء سه بعدی قابل مشاهده باید در Blender طراحی و برای مرورگر اکسپورت شود) — توسعه‌دهندگان مانع از تکرار همان اشتباه توسط عامل می‌شوند. سپس عامل می‌تواند آن خط لوله (Pipeline) را با یک دارایی نمونه اعتبارسنجی کند و سپس ادامه دهد.
برای توسعه‌دهنده انفرادی، این به معنای آن است که دیگر مجبور نیست برای به یاد آوردن نحوه حل یک باگ خاص، هزاران خط تاریخچه چت را بخواند. برای سازمان، این ابزار یک کتابخانه زنده از الگوهای همکاری انسان و عامل ایجاد می‌کند که با رشد پروژه تکامل می‌یابد. زمینه‌ای که ارائه می‌شود — شامل مدت زمان جلسه، مصرف توکن، تغییرات کد و کامیت‌ها — به دیگران کمک می‌کند تا قضاوت کنند آیا تجربه شخص دیگری با وظیفه خاص آن‌ها مرتبط است یا خیر، و اذعان می‌کند که یک اجرای موفق لزوماً یک دستورالعمل جهانی نیست.
منتظر باشید تا ببینید چگونه این رویکرد به «حافظه جلسه» ممکن است با چارچوب‌های عاملی بزرگ‌تر ادغام شود تا خط لوله‌های توسعه‌ای ایجاد کند که به‌طور خودکار اصلاح می‌شوند و در لحظه از بازخوردهای انسانی یاد می‌گیرند.
گفتگو