‏وقتی چند کارخونهٔ نرم‌افزاری هوش مصنوعی داری، چطور مدیریتشون کنی؟

تو این مقاله از MindStudio اومده که یه AI software factory (یعنی سیستمی که agentها توش یه release رو به تیکت می‌شکنن و هر تیکت رو از مراحل plan، implement، validate و merge رد می‌کنن) روی یه ریپو با چندتا پرامپت و اسکریپت راحت جمع می‌شه. مشکل وقتی شروع می‌شه که یه شرکت ده‌ها factory روی ده‌ها ریپو داره. به گفتهٔ نویسنده، راه‌حل اضافه کردن یه لایهٔ governance روی factory‌هاست، نه بازسازی خودشون.

چرا خود حلقهٔ اصلی کافی نیست؟ مقاله سه تا دلیل میاره. اول، agentها معمولاً با اکانت GitHub خود برنامه‌نویس کار می‌کنن، پس وقتی یه چیزی تو production خراب می‌شه نمی‌شه فهمید کد رو آدم نوشته یا agent. دوم، skillها (یعنی دستورالعمل‌های دقیقی که هر مرحلهٔ حلقه رو پیش می‌برن) تو هر تیم کپی و دستکاری می‌شن و کم‌کم نسخه‌های مختلف از مثلاً «چطور PR رو ریویو کنیم» همزمان اجرا می‌شه. سوم، از خود کد نمی‌شه فهمید صاحب یه سرویس کیه یا یه تغییر تأیید انسانی لازم داره یا نه.

برای دو تا مشکل اول، مقاله دو تا registry پیشنهاد می‌ده. skill registry یه مخزن مرکزی و version-control‌شده برای همهٔ skillهاست که تعداد نسخه‌های مختلف هر skill رو هم نشون می‌ده؛ عدد بالا یعنی drift اتفاق افتاده. چرخهٔ عمر هم داره، از انتشار و تأیید تا منسوخ کردن. agent registry هم برای هر agent (مثل planner یا reviewer) ثبت می‌کنه روی چه پلتفرمی اجرا می‌شه (Claude Code، Codex، Vertex AI یا Bedrock)، از چه مدلی استفاده می‌کنه، چه دسترسی‌هایی داره و وضعیت تأییدش چیه.

با این کار هر agent یه هویت جدا و قابل ردیابی پیدا می‌کنه، یعنی یه خرابی تو production رو می‌شه تا یه agent و نسخهٔ مشخص دنبال کرد، نه یه اکانت مشترک. برای مشکل سوم، مقاله از context lake حرف می‌زنه: لایه‌ای که factory رو به GitHub، CI، Jira، Slack و SharePoint وصل می‌کنه تا agent بدونه صاحب سرویس کیه، سرویس چقدر حساسه و آیا merge بدون آدم مجازه یا نه.

این اطلاعات دو جا به درد می‌خوره: موقع برنامه‌ریزی، که یه plan بهتر از plan صرفاً مبتنی بر کد می‌سازه، و موقع اجرا، که مشخص می‌کنه یه تغییر خودکار merge بشه یا بره پیش یه آدم. مثلاً یه ابزار داخلی کم‌ریسک می‌تونه بدون ریویو merge بشه، ولی یه سرویس مشتری‌محور تأیید صریح می‌خواد. تو عمل این زمینه از طریق یه MCP server به agent داده می‌شه. Scorecardها هم معیار مشترکی از ریپوی سالم (مثل پوشش تست، مالک مشخص و سلامت CI) تعریف می‌کنن و همهٔ factoryها رو باهاش می‌سنجن.

نویسنده تأکید می‌کنه که برای یه factory و یه تیم، هیچ‌کدوم از اینا لازم نیست و بهتره ساده شروع کنی. ولی وقتی چندتا factory تو چندتا تیم داری، این ریسک‌ها واقعی می‌شن. شرط اصلی اینه که لایهٔ governance دور factory بشینه و داخلش رو عوض نکنه، چون ارزش واقعی تو skillها و agentهاییه که براشون وقت گذاشتی. Port به‌عنوان نمونهٔ پلتفرمی که این لایه رو می‌ده معرفی شده.

نکات کلیدی:

• AI software factory حلقهٔ plan، implement، validate و merge رو برای تیکت‌های کدنویسی خودکار می‌کنه
• agentها معمولاً با اکانت GitHub برنامه‌نویس کار می‌کنن و commitهاشون از commit انسان قابل تشخیص نیست
• skill registry نسخه‌های هر skill رو مرکزی نگه می‌داره و تعداد نسخه‌های موازی رو به‌عنوان علامت drift نشون می‌ده
• agent registry برای هر agent پلتفرم اجرا، مدل، دسترسی‌ها و وضعیت تأیید رو ثبت می‌کنه
• context lake داده‌های Jira، Slack، GitHub و SharePoint رو از طریق MCP server به agent می‌رسونه
• برای یه factory روی یه ریپو، این لایهٔ مدیریتی پیچیدگی اضافه‌ست و ارزشش رو نداره