Mastra نسخه بتای Factory را منتشر کرده؛ محیطی متنباز که کار عاملهای برنامهنویسی را از یک نشست منفرد در ترمینال بیرون میآورد و در قالب یک فرایند مرحلهبندیشده برای تحویل نرمافزار قرار میدهد. مسئله مهم در این محصول فقط تبدیل خودکار یک مسئله ثبتشده به کد نیست. خود Mastra توضیح داده که پس از تجربه اجرای کاملاً خودکار، ناچار شده برای مراحل مختلف امکان توقف و تأیید انسانی بگذارد.
فرایند توسعه به چند نقطه تصمیم تقسیم میشود
Factory کار را در مراحلی مانند دریافت درخواست، بررسی اولیه، برنامهریزی، پیادهسازی، بازبینی و پایان سازمان میدهد. هر کار یک نشست عامل مستقل با فضای کاری، فایلها، فعالیت ابزارها و گفتوگوی خودش دارد. ورودی میتواند از GitHub یا Linear بیاید و عامل پس از بررسی و برنامهریزی تا ساخت تغییر و آمادهکردن درخواست ادغام کد پیش برود.
Mastra اجازه میدهد هر مرحله جداگانه دستی یا خودکار باشد. این انتخاب حاصل تجربه خود تیم است. شرکت میگوید در نسخه اولیه، وقتی کارهای عقبافتاده به مسیر کاملاً خودکار وارد شدند، بار ناگهانی روی زیرساخت ایجاد شد و حجم زیادی خروجی شکل گرفت که بررسی آن دشوار بود. در نمونههای دیگری نیز یک هشدار اشتباه یا تشخیص نادرست در مرحله بررسی اولیه، عاملهای بعدی را به مسیر نادرست برده است.
آمار Mastra را نباید مثل بنچمارک مستقل خواند
Mastra میگوید از زمان استفاده داخلی از Factory در نسخه آلفا از ماه ژوئیه، این سامانه ۲۵ تا ۳۵ درصد درخواستهای ادغام کد را خودکار کرده و ۵۰ تا ۶۰ درصد مسئلههای ثبتشده را بسته است. همان نوشته نمودارهایی هم نشان میدهد که از ۱۶۲۷ درخواست ادغامشده، ۲۷۷ مورد، یعنی ۱۷ درصد، توسط Factory نوشته شده و از ۷۷۸ مسئله بستهشده، ۲۲۲ مورد، یعنی ۲۸٫۵ درصد، به Factory مربوط بوده است.
این اعداد الزاماً با هم تناقض ندارند؛ ممکن است بازه زمانی یا تعریف شاخصها متفاوت باشد. اما نوشته Mastra مبنای مقایسه آنها را بهطور کامل مشخص نمیکند. به همین دلیل، این ارقام را باید گزارش عملیاتی خود شرکت دانست، نه سنجش مستقل بهرهوری.
متنباز بودن با بینیازی از سرویس بیرونی یکی نیست
قالب Factory با مجوز Apache-2.0 منتشر شده و میتوان سرور آن را روی ماشین مجازی یا داخل کانتینر اجرا کرد. مخزن پروژه همچنین امکان استفاده از PostgreSQL محلی و اجرای فرمانها روی میزبان را نشان میدهد.
با این حال، نصب پیشفرض برای احراز هویت، ذخیرهسازی و محیطهای اجرای ایزوله از خدمات Mastra استفاده میکند و روند راهاندازی نیز کاربر را به حساب Mastra متصل میکند. این اجزا قابل پیکربندی جداگانه هستند، اما سازمانی که به میزبانی داخلی نیاز دارد باید بین «سرور متنباز قابل میزبانی» و «سامانهای که در حالت پیشفرض هیچ وابستگی بیرونی ندارد» تفاوت بگذارد.
این تفاوت برای محل نگهداری اعتبارنامهها، دسترسی به مخزن کد و اختیار اجرای فرمانها مهم است. اجرای رابط وب روی زیرساخت خود سازمان بهتنهایی به این معنا نیست که تمام مرزهای کنترلی نیز داخلی شدهاند.
با افزایش سرعت عاملها، مسئله اصلی تعیین اختیار است
ارزش خبری Factory در این است که Mastra محدودیتی را مستند کرده که در بسیاری از نمایشهای عاملهای برنامهنویسی دیده نمیشود: اگر فرض اشتباهی در ابتدای مسیر وارد شود، خودکارسازی میتواند آن را به برنامه، کد و در نهایت صف بازبینی تکثیر کند.
پاسخ Factory، تقسیم اختیار بین مراحل مختلف است. تیم میتواند برای هر نوع کار مشخص کند عامل تا کجا بدون دخالت انسان پیش برود. برای مدیران فنی، بنابراین سؤال مهم فقط تعداد مسئلههای بستهشده نیست. مهمتر این است که آیا سامانه میتواند یک تصمیم اشتباه را نزدیک همان نقطهای که ایجاد شده متوقف کند یا نه.
Factory هنوز در مرحله بتاست و آمار بهرهوری آن نیز مستقل تأیید نشده است. با این حال، تجربه منتشرشده Mastra نشانه مفیدی برای طراحی سامانههای مهندسی عاملمحور است: افزایش خودکارسازی باید همراه با مرزهای روشن اختیار، اجرای محدودشده و تحویلهای قابل مشاهده باشد.