تصور کنید در دنیایی زندگی میکنیم که تولید کد ارزان شده، اما تأیید صحت آن گرانتر از همیشه است. جتبرینز روی این شرطبندی پیش میرود که گلوگاه بعدی مهندسی، خودِ کد نیست، بلکه زیرساختی است که باید عاملهایی (Agents) را که کد مینویسند، مدیریت کند. به نقل از وبلاگ رسمی این شرکت، در حالی که هوش مصنوعی میتواند کد تولید کند، سازمانها همچنان باید «نرمافزار» تولید کنند و توسعهی عاملمحور (Agentic Development) هزینهی اشتباه کردن را کاهش نداده است.
برای ۲۶ سال، این شرکت بر میز کار توسعهدهنده متمرکز بود. اما اکنون با معرفی JetBrains Air یک چرخش راهبردی را آغاز کرده است. این اقدام نشان میدهد دوران محصور کردن کل چرخه توسعه در یک پنجره IDE به پایان رسیده است. JetBrains Air به عنوان یک سیستم باز و منسجم از محصولات برای توسعهدهندگان، تیمها و سازمانها طراحی شده که هم درون و هم بیرون از محیطهای IDEهای جتبرینز عمل میکند.
شکاف نظارتی (The Governance Gap)
بسیاری از سازمانها اکنون با یک «شکاف نظارتی» روبرو هستند. توسعهدهندگان سریعتر از آنکه سازمانها زیرساختهای لازم را بسازند، به استفاده از عاملها روی آوردهاند. طبق گزارش جتبرینز، از ماه مارس ۲۰۲۴ مشاهده شده که در حالی که قابلیتهای عاملها پیشرفت کرده و مدلهای مختلف برای وظایف متفاوت مفید بودهاند، هماهنگیهای محیطی و مدیریت هزینههای آنها همگام با این پیشرفت پیش نرفته است.
برای بسیاری از برنامهنویسان، عاملها — شبیه دستیارهای هوشمندی که کارهای تکراری را میگیرند تا برنامهنویس روی معماری تمرکز کند — ارزش عملی ایجاد کردهاند. این رویکرد یادآور تجربههایی است که در آن معماریهای عاملمحور توانستهاند عملیاتهای پیچیده و ۲۴ ساعته را به طور کامل خودکار کنند. اما در سطح سازمانی، اثبات اقتصادی این ابزارها سختتر است. هزینهها در بازبینی (Review)، بازنویسی (Rework)، امنیت، زیرساخت و مخارج کلی ظاهر میشوند. سازمانها اکنون با پرسشهای حیاتی روبرو هستند: کدام عاملها میتوانند به کد شرکت دسترسی داشته باشند؟ دادهها به کجا میروند؟ کدام خروجیها نیاز به بازبینی انسانی دارند؟ در حالی که یک عامل به صورت دورکار در حال فعالیت بود، چه اتفاقی افتاد؟ چه کسی تغییرات را تأیید کرد و این تغییرات چگونه تأیید شدند؟
تکه تکه شدن ابزارها در این سطح، اندازهگیری و نظارت بر توسعه نرمافزار را دقیقاً در لحظهای که حجم بیشتری از کار به عاملها واگذار میشود، سختتر میکند. در حالی که میتوان کار را به عامل سپرد، مسئولیتپذیری را نمیتوان واگذار کرد. یک عامل در ساعت ۳ صبح وقتی سیستم میپاشد، تماس تلفنی را پاسخ نمیدهد؛ مسئولیت نهایی آنچه منتشر میشود، همچنان بر عهده انسانها و سازمانهایی است که آن را عرضه میکنند.
زمینه و تکامل (Context and Evolution)
این تحول پس از یک دوره آزمایش شدید رخ داد. شش ماه پیش، جتبرینز آزمایشهای عمومی خود را روی محیطهای توسعه عاملمحور آغاز کرد. تقریباً در همان زمان، آنها JetBrains Central را به عنوان یک سیستم کنترل و اجرای باز برای توسعههای مبتنی بر عامل معرفی نمودند.
پس از این مرحله، شرکت شروع به عرضه مجموعهای از ابزارهای تخصصی برای پشتیبانی از جنبههای سازمانی هوش مصنوعی کرد. این مجموعه شامل JetBrains Central CLI، زمینه مشترک (Shared Context)، عاملهای ابری (Cloud Agents)، اتوماسیونها، ابزارهای نظارتی (Governance) و کنترلهای هزینه AI مخصوص تیمها و سازمانها بود. این اتوماسیونهای پیشرفته شباهت زیادی به سیستمهای محتوایی صفر-لمسی دارد که با ترکیب مدلهای زبانی و ابزارهایی مانند n8n ایجاد شدهاند. اکنون JetBrains Air تمام این تلاشها را در قالب یک سیستم منسجم گرد هم آورده است.
معماری JetBrains Air
JetBrains Air یک ابزار واحد نیست، بلکه سیستمی چندوجهی و چند-سرویسی از محصولات است. طبق وبلاگ رسمی شرکت، این سیستم بر این باور استوار است که آینده توسعه عاملمحور «چند-تأمینکننده» (Multi-vendor) خواهد بود؛ به این معنا که هیچ مدل، عامل یا سرویس واحدی برای هر توسعهدهنده، تیم یا تسک مناسب نخواهد بود.
این اکوسیستم از سه بخش اصلی تشکیل شده است:
- Air در IDEهای جتبرینز: این بخش تجربه بنیادین عاملمحور را مستقیماً در ویرایشگر ادغام میکند. محیطی کامل برای هدایت و سازماندهی عاملها و تأیید کار آنها با استفاده از هوش کدنویسی قطعی (Deterministic Code Intelligence) جتبرینز فراهم میکند.
- Air Teams: روشی جدید برای هماهنگی و خودکارسازی جریانهای تحویل نرمافزار. این ابزار فعالیتهای فردی عاملها را به جریانهای کاری هماهنگ تیمی تبدیل میکند که هم توسعهدهندگان و هم عاملهای خودمختار در آن نقش دارند.
- Air Governance: (که پیشتر JetBrains Central بود) این محصول سیاستهای سازمانی، شفافیت، قابلیت حسابرسی، مدیریت هزینه و مسئولیتپذیری را برای توسعههای کمکگرفته از AI و عاملمحور فراهم میکند.
در مرکز این اکوسیستم، Junie قرار دارد؛ عامل کدنویسی اختصاصی جتبرینز برای توسعه حرفهای نرمافزار. Junie در تمام سطوح Air پشتیبانی خواهد شد. با این حال، JetBrains Air به گونهای طراحی شده است که محصولات مربوط به کارهای فردی و کنترلهای سازمانی را به هم متصل کند و در عین حال نسبت به ابزارها و عاملهایی که توسعهدهندگان انتخاب میکنند (حتی آنهایی که توسط جتبرینز ساخته نشدهاند) باز بماند.
حل مشکل تکهتکه شدن چند-تأمینکنندگی
جتبرینز معتقد است بازار هوش مصنوعی به دلیل تغییر رتبهبندی مدلها هر چند ماه یکبار، به سرعت یکپارچه نخواهد شد. استاندارد شدن روی یک تأمینکننده در این بازار متلاطم، به معنای یک تعهد چندساله در محیطی ناپایدار است. باز نگه داشتن گزینهها رویکردی منطقی است، اما این باز بودن در حال حاضر هزینهای دارد: هر مدل جدیدی که اضافه میشود، شفافیت را کاهش میدهد، زیرا زمینه (Context) بین ابزارها منتقل نمیشود و هزینهها را نمیتوان به راحتی به هر بخش نسبت داد. همچنین سیاستها اغلب باید برای هر سرویس به صورت جداگانه بازسازی شوند.
برای حل این مشکل، جتبرینز پروتکل کلاینت عامل (Agent Client Protocol یا ACP) را معرفی کرد. این پروتکل اتصال بین IDE و بدنه کامل (Harness) یک عامل را استاندارد میکند، که شامل موارد زیر است:
- برنامهریزی و منطق (Planning and Logic)
- استفاده از ابزار (Tool Usage)
- مسیریابی مدل (Model Routing)
- مشاهدهپذیری (Observability)
از طریق ACP Registry، توسعهدهندگان میتوانند طیف گستردهای از عاملهای سازگار را پیدا و اجرا کنند، در حالی که همچنان درون IDEهای جتبرینز کار میکنند. Air Governance این شفافیت و نظارت بر هزینه را در میان تأمینکنندگان مختلف گسترش میدهد. این امر به توسعهدهندگان اجازه میدهد بهترین مدل را برای یک تسک خاص انتخاب کنند، بدون اینکه سازمان مجبور شود کنترل یا زمینه را فدا کند.
تغییر اقتصادی در مهندسی
جتبرینز استدلال میکند که ریسک اصلی در توسعه عاملمحور، کدهای «تقریباً درست» است. کدی که آشکارا غلط است سریعاً شناسایی میشود. اما مشکل سختتر، کدی است که پذیرفتنی به نظر میرسد و از بررسیهای سطحی میگذرد، اما حاوی یک فرض غلط یا ناسازگاری معماری است که تا زمانی که هزینه اصلاحش بسیار بالا برود، شناسایی نمیشود.
با افزایش اجرای کد توسط عاملها، گلوگاه از «تولید تغییر» به «درک، تأیید و مالکیت» تغییر میکند. جتبرینز برای مقابله با این موضوع، ۲۶ سال تجربه هوش مهندسی خود را به کار میگیرد. با دادن دسترسی عاملهای AI به هوش کدنویسی قطعی، آنها به عاملها کمک میکند تا ساختار و رفتار نرمافزارهای پیچیده را بفهمند، نه اینکه صرفاً کد بیشتری تولید کنند.
این یک مزیت اقتصادی قابل توجه ایجاد میکند. عاملها اغلب زمان و هزینه زیادی را صرف بازکشف اطلاعاتی میکنند که پیش از این در کدبیس موجود است. عاملی که بتواند این دانش را از طریق هوش قطعی بازیابی کند، ارزانتر و دقیقتر از عاملی است که باید آن را بازسازی کند. از آنجایی که این هوش متعلق به یک مدل خاص نیست، مزیت آن به تمام عاملها و سرویسهای پشتیبانی شده تعمیم مییابد.
نقشه راه آینده
JetBrains Air از طریق مجموعهای از نسخههای جاری توسعه خواهد یافت. شرکت به طور صریح اعلام میکند که چه قابلیتهایی اکنون در دسترس هستند، چه مواردی در حالت پیشنمایش (Preview) قرار دارند و چه بخشهایی جزئی از جهتگیری بلندمدت هستند.
توسعههای کلیدی آینده عبارتند از:
- تجربههای موبایلی و دورکاری: اجازه دادن به کاربران برای شروع، نظارت، بازبینی و ادامه کارهای عاملمحور در حالی که بین محیطهای مختلف جابهجا میشوند. هدف بازسازی IDE در هر سطح نیست، بلکه در دسترس قرار دادن زمینه و کنترلهای مناسب در هر جایی است که تصمیمگیری صورت میگیرد.
- هوش تقویتشده: استخراج زمینه غنیتر از معماری، مخازن (Repositories)، رفتار زمان اجرا (Runtime) و دانش سازمانی. این شامل روشهای بهتر برای مسیریابی کار بین توسعهدهندگان، مدلها، عاملها و سرویسها است.
- محرکهای خودکار (Automated Triggers): عبور از پرامپتهای دستی. بخش بیشتری از کارها به جای باز کردن ویرایشگر توسط توسعهدهنده، توسط رویدادهای مخزن کد، زمانبندیها و فرآیندهای تحویل (Delivery) تحریک خواهند شد.
جتبرینز همچنین این عاملها را در داخل سازمان خود به کار گرفته و جریانهای کاری خود را بازطراحی کرده است تا یاد بگیرد کجا افزایش بهرهوری فردی واقعاً به تحویل نرمافزار بهتر منجر میشود و کجا صرفاً کار را به جای دیگری منتقل میکند.
این تغییر نشان میدهد شرکتهایی که در پذیرش AI موفق میشوند، لزوماً کسانی نیستند که بیشترین کد را تولید یا بیشترین عاملها را مستقر میکنند. در عوض، موفقیت متعلق به کسانی است که میتوانند آزمایشها را گسترش دهند بدون اینکه کیفیت، زمینه، انضباط هزینه یا درک انسانی را از دست بدهند. هدف JetBrains Air تولید کد بیشتر نیست، بلکه تولید نرمافزاری است که توسعهدهندگان، تیمها و سازمانها بتوانند آن را درک کنند، تأیید کنند و پشت آن بایستند.
گام بعدی شما
- اگر مدیر تیم هستید، بررسی کنید که آیا توسعهدهندگان شما از عاملهای مختلف بدون نظارت مرکزی استفاده میکنند یا خیر.
- پروتکل ACP را دنبال کنید تا متوجه شوید چگونه میتوانید عاملهای مختلف را بدون تغییر IDE جابهجا کنید.
- روی استراتژی «تأیید کد» (Verification) بیشتر از «تولید کد» سرمایهگذاری کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو