عامل‌های کدنویسی داخلی ساخته شده‌اند؛ مدل‌ها همچنان اجاره می‌شوند

کوین‌بیس، شاپیفای و رمپ عامل‌های کدنویسی داخلی توسعه داده‌اند، اما مدل‌های پایه را جایگزین نکرده و برای موتورهای استنتاجی ارائه‌شده توسط شرکت‌هایی مانند Anthropic، OpenAI و Google هزینه می‌پردازند.

تمرکز روی هارنس عامل، نه خود مدل

این شرکت‌ها لایهٔ ارزش‌آفرین را در داخل سازمان ساخته‌اند: هارنسِ عامل — محیط اجرایی که زمینهٔ سازمانی، مدیریت مجوزها، ارکستراسیون جریان‌کار، دسترسی به ابزارها و اعتبارسنجی را کنترل می‌کند. مدل زبان بزرگ به‌عنوان یک وابستگی زیرساختی باقی می‌ماند و موتور استدلال را فراهم می‌کند، اما کنترل نحوهٔ به‌کارگیری آن در دست پلتفرم است.

الگوهای تکرارشونده و متن‌باز

الگوی عامل‌های داخلی چنان جا افتاده که گروه‌هایی مثل LangChain نسخه‌های عمومی را با پروژه‌هایی مانند Open SWE متن‌باز کرده‌اند. پیاده‌سازی‌های متن‌باز بازتابی از رویکردهایی است که پیش‌تر در شرکت‌هایی مانند Stripe، Ramp و Coinbase به کار رفته‌اند.

چه مسئله‌ای حل می‌شود؟

نسل جدید پلتفرم‌ها روی چهار پایهٔ مشترک تکیه دارند:

  • محیط‌های اجرایی پایا و ایزوله برای اجرای امن عامل‌ها،
  • دسترسی امن و مدیریت اعتبارنامه به سیستم‌های سازمانی،
  • ارکستراسیون جریان‌کار و اتوماسیون اتصال بین ابزارها،
  • اعتبارسنجی خودکار و بازبینی قبل از انتشار کد.

نگاهی به Forge، River و Inspect

Forge (Coinbase) جریان‌کاری را که Slack، GitHub و Linear را به هم پیوند می‌دهد خودکار می‌کند: از گزارش خطا تا تولید pull request. Forge مخازن لازم را بازیابی، کد تولید، تغییرات را اعتبارسنجی و حتی بیلد موبایل برای بازبینی آماده می‌سازد.

River (Shopify) روی یک پلتفرم توسعه‌دهندهٔ قابل تکثیر متمرکز است: monorepo سراسری، جلسات اجرایی پایا، محیط‌های ایزوله، مدیریت اعتبارنامه و مهارت‌های مهندسی قابل‌استفادهٔ مجدد. شاپیفای گزارش می‌دهد که River اکنون در یکی از هر هشت pull requestِ ادغام‌شده نقش دارد.

Inspect (Ramp) الگو را با اجرای عامل‌ها در ماشین‌های مجازی ایزوله تقویت می‌کند تا محیط محلی توسعه‌دهندگان را شبیه‌سازی کند. Inspect رویکرد بی‌طرفی نسبت به مدل دارد و با ابزارهایی مانند Datadog، Sentry، LaunchDarkly و Buildkite یکپارچه می‌شود و از چندین مدل مرزی پشتیبانی می‌کند.

نمایی از معماری عامل کدنویسی و ادغام سیستم‌های مهندسی

دلایل ساخت هارنس درون‌سازمانی

این روند شبیه موج ایجاد پلتفرم‌های توسعه‌دهنده در دههٔ گذشته است؛ سازمان‌ها به‌جای ساخت کامل زیرساخت ابری، روی لایه‌هایی سرمایه‌گذاری کردند که تجربهٔ توسعه، امنیت و سازگاری را استاندارد کنند. مدل زبان بزرگ امروز همان نقش را به‌عنوان یک سرویس زیرساختی ایفا می‌کند و سازمان‌ها کنترل سیاست‌های مسیر‌یابی، درج زمینهٔ اختصاصی، اعمال مجوزها و اعتبارسنجی را در سطح خود نگه می‌دارند.

بهینه‌سازی هزینه‌ها؛ تجربهٔ کوین‌بیس

کوین‌بیس نشان داده که وقتی هارنس در اختیار تیم است، بهینه‌سازی هزینه‌ها ساده‌تر می‌شود. تیم‌های پلتفرم می‌توانند مرکزی سیاست‌های مسیر‌یابی را به‌روزرسانی کنند، مدل پیش‌فرض کم‌هزینه‌تری انتخاب نمایند، پرامپت‌ها را کش کنند و پنجره‌های متن را کوچک‌تر نگه دارند — همه بدون نیاز به تغییر رفتار هزاران توسعه‌دهنده. کوین‌بیس همچنین مدل‌های وزن‌باز مانند GLM 5.2 و Kimi K2.7 را برای تعادل هزینه و عملکرد آزمایش کرده است.

دستیاران کدنویسی تجاری همچنان کاربردی‌اند

مالکیت هارنس به معنی حذف کامل دستیاران تجاری نیست. Claude Code از Anthropic همچنان در میان مهندسان کوین‌بیس کاربرد دارد و توسعه‌دهندگان شاپیفای علاوه بر River از ابزارهایی مانند Claude Code و Codex بهره می‌برند. Anthropic همچنین Ramp را در فهرست مشتریان سازمانی خود ذکر می‌کند و گزارش‌هایی از استفادهٔ هفتگی گسترده در برخی تیم‌ها منتشر شده است.

تقسیم مسئولیت‌ها و چشم‌انداز آتی

مزیت رقابتی اغلب بیرون از مدل قرار دارد: در طراحی هارنس، سیاست‌گذاری، و ترکیب ابزارها و فرایندها. مدل‌های پایه همچنان موتور تعقل خواهند بود و انتخاب مدل به‌صورت یک گزینهٔ پیکربندی در سطح پلتفرم در می‌آید. شرکت‌ها احتمالاً سرمایه‌گذاری خود را بر روی ارتقای تضمین‌های امنیتی، شفافیت هزینه، مدیریت داده‌های سازمانی و امکان سوییچ سریع بین مدل‌ها متمرکز می‌کنند. در آیندهٔ نزدیک ترکیبی از مدل‌های تجاری و متن‌باز زیر یک هارنس سازمانی هماهنگ خواهند شد تا سرعت توسعه، ایمنی و کنترل هزینه را هم‌زمان افزایش دهند.