تصور کنید در شرکتی کار می‌کنید که هیچ‌کس کد نمی‌زند یا تیکت پشتیبانی پاسخ نمی‌دهد، اما همه چیز با دقت میلی‌متری پیش می‌رود. در EarthLink Network، این یک تخیل نیست، بلکه نتیجه‌ی استقرار اکوسیستمی است که در آن انسان‌ها دیگر «اجراکننده» نیستند، بلکه «داور» هستند. اداره کردن یک شرکت به‌طور کامل با هوش مصنوعی، نیازمند چیزی فراتر از یک ابزار واحد است؛ این امر مستلزم یک اکوسیستم هماهنگ از عامل‌های تخصصی و زیرساخت‌های متصل است.
به نقل از گزارشی که در ۲۵ اوت ۲۰۲۶ منتشر شد، این شرکت برای عبور از تله‌ی «تکه تکه بودن هوش مصنوعی» — وضعیتی که در آن ابزارهای پراکنده (LLM wrappers) بدون هماهنگی استفاده می‌شوند و نمی‌توانند بهره‌وری سیستماتیک ایجاد کنند — ۱۸ محصول داخلی ساخته است تا کل چرخه ساخت، نظارت، تعمیر و مدیریت نرم‌افزار را خودکار کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی عامل‌های هوش مصنوعی اشاره کردیم، چالش اصلی سازمان‌ها تبدیل ابزارهای چت به جریان‌های کاری واقعی است. در این مسیر، بسیاری از سازمان‌ها با چالش‌های جدی در استقرار تجاری عامل‌های هوش مصنوعی مواجه شده‌اند که مانع از رسیدن آن‌ها به بهره‌وری سیستماتیک می‌شود. EarthLink این مشکل را با تبدیل نیازهای عملیاتی به یک خط تولید محصول حل کرده است. در این معماری، فرضیه این است که نسل بعدی بهره‌وری نه با سرعت عرضه کد، بلکه با «درستی قضاوت‌های انسانی» اندازه‌گیری خواهد شد. در این مدل، کارهای روتین به هوش مصنوعی سپرده شده و انسان‌ها منحصراً بر روی قضاوت و تصمیم‌گیری تمرکز می‌کنند.
این مجموعه محصولات از ابتدا به صورت یک نقشه راه طراحی نشده بود، بلکه از یک توالی طبیعی از نیازها پیروی کرد: ابتدا ساخت $\rightarrow$ سپس نظارت $\rightarrow$ سپس تعمیر $\rightarrow$ سپس مدیریت $\rightarrow$ و در نهایت مدیریتِ مدیریت. هر نیازی که در مسیر ظاهر می‌شد، به محصول بعدی در این اکوسیستم تبدیل می‌شد. این فهرست نشان‌دهنده وضعیت فعلی تلاش‌های EarthLink Network برای خودکارسازی کل شرکت است.
زیرساخت‌های بنیادین
برای جلوگیری از تکرار تلاش‌ها و موازی‌کاری، شرکت ابتدا یک شالوده مشترک از اجزا و زیرساخت‌ها ساخت:
platform: یک مخزن واحد (Monorepo) که قطعات مشترک چندین محصول را در یک مکان جمع کرد و از بسته‌های متعددی که در یک مخزن مدیریت می‌شوند استفاده می‌کند. تیم توسعه، ویرایشگرهای بلوکی، مدیریت مشترک DynamoDB، سیستم‌های محدودکننده نرخ (Rate Limiting) و اعلان‌ها را از مخازن مجزا خارج کرد. آن‌ها قبل از بازنشسته کردن نسخه‌های قدیمی، فراخوان‌ها را بر اساس اندازه‌گیری‌های واقعی تغییر دادند. در جریان این پاک‌سازی، ۸ مخزن کتابخانه مشترک پس از تایید عدم استفاده، حذف شدند و تنها یک مخزن (lime قدیمی) در حال انتقال است.
onion: یک شالوده برای ورود یکپارچه (SSO) که دسترسی به تمام سرویس‌ها، از جمله promptflow، sage، alive365 و plovant را یکپارچه می‌کند. این سیستم صدور کلاینت و ابطال توکن را به صورت یک API ارائه می‌دهد که اجازه می‌دهد CI و Claude مستقیماً آن را هدایت کنند. سیستم بومی‌سازی این ابزار، ۱۳٬۰۸۰ پیام (۱۰ زبان $\times$ ۱۶ حوزه) را بدون هیچ خطای اعتبارسنجی مدیریت می‌کند.
notify: زیرساختی مشترک برای ارسال اعلان در ایمیل، Slack، LINE و Webhooks. این سیستم دارای قابلیت مقاصد اولویت‌بندی شده با جایگزینی خودکار (Failover) است؛ یعنی اگر مقصد اول با خطا مواجه شود، پیام به‌طور خودکار به مقصد بعدی منتقل می‌شود. همچنین شامل یک API برای کلیدهای Idempotency است تا اطمینان حاصل شود که ارسال مجدد با همان کلید نادیده گرفته شود و از ارسال دوگانه پیام‌ها جلوگیری شود.
dotvault: یک SaaS داخلی برای توزیع اسرار (Secrets) که فایل‌های .env، .npmrc، kubeconfig و گواهینامه‌ها را از طریق یک دستور ساده
dotvault pullبه کامپیوترها یا CI می‌رساند. این ابزار به عنوان جایگزینی داخلی برای Doppler یا Infisical عمل می‌کند و نیاز کاربران به داشتن حساب‌های AWS را از بین می‌برد. مؤسس شرکت، بخش‌های سازمان، مجوزها، لاگ‌های حسابرسی و سیستم پرداخت را در ماه ژوئن طی ۱۲۷ کامیت، بر اساس مشخصاتی که در اواخر می تدوین شده بود، ساخت.
- billing: شالوده‌ای که پرداخت‌های چندین محصول SaaS داخلی را با پوشش دادن (Wrapping) Stripe یکپارچه می‌کند. این سیستم قراردادها، کوپن‌ها و پرداخت‌های تک‌مرحله‌ای را از طریق یک API واحد مدیریت می‌کند. هنگام پرداخت یا لغو اشتراک، سرویس‌ها از طریق Webhookهای امضا شده مطلع می‌شوند. اعلان‌هایی که با خطای 5xx مواجه می‌شوند، به‌طور خودکار در بازه‌های ۱ ثانیه $\rightarrow$ ۵ ثانیه $\rightarrow$ ۱۵ ثانیه، تا سه بار بازتلاش (Retry) می‌شوند.
ابزارهای رشد و جذب مخاطب
رشد شرکت توسط مجموعه‌ای از ابزارها هدایت می‌شود که برای مدیریت حضور در وب و جذب مخاطب طراحی شده‌اند:
web-platform (plovant): یک سیستم مدیریت محتوا (CMS) چندمستاجری که ۱۰ تا ۲۰ سایت را از یک صفحه مدیریت واحد اجرا می‌کند. پیش از این، هر Push به شاخه main باعث بازنصب (Redeploy) هفت سایت به‌طور همزمان می‌شد؛ این مشکل با تجمیع در یک اپلیکیشن واحد که سایت‌ها را بر اساس Hostname مسیریابی می‌کند، حل شد. این پلتفرم دارای ویرایش بلوکی برای صفحات فرود، تولید صفحه و تصویر با AI و ترجمه چندزبانه در سطح بلوک است.
aio-helper: یک SaaS عملیاتی که از ویژگی‌های سئو در web-platform استخراج شده است. این ابزار به‌طور خودکار داده‌های Google Search Console را دریافت کرده و بهبودهای سئو را از طریق تولید بازیابی‌افزا (RAG) پیشنهاد می‌دهد. پیاده‌سازی فعلی شامل ۱۴ صفحه فرانت-اند، ۲۸ API و ۱۲ جدول دیتابیس است و در نقشه راه خود، قصد دارد از یک ابزار داخلی به یک محصول تجاری خارجی تبدیل شود.
curation: ابزاری برای جمع‌آوری اخبار مربوط به AI و امنیت، که سپس با استفاده از Gemini آن‌ها را برای تحویل به افراد، خلاصه‌سازی و ترجمه می‌کند. برای مدیریت هزینه‌ها، یک مرحله غربالگری (Triage) اضافه شد تا مقالات قبل از تحلیل AI انتخاب شوند. این تغییر اجازه داد سیستم ۲٬۵۱۶ مقاله در روز را مدیریت کند در حالی که هزینه‌های تحلیل را ۹۴٪ کاهش داد و مبلغ روزانه را از ۱.۰ تا ۳.۷ دلار به تنها ۰.۱۳ دلار رساند.
ارکستراسیون و اجرای AI
جریان‌های کاری حول ابزارهایی متمرکز شده‌اند که از مدیریت ساده وظایف به ارکستراسیون پیچیده AI حرکت می‌کنند:
sage (usesources): فضای کاری یکپارچه‌ای که ویکی‌ها، تخته‌های وظایف، چت اختصاصی، جستجوی متقاطع و عامل‌های AI را ترکیب می‌کند. این ابزار مدیریت دسته‌جمعی را ممکن می‌سازد؛ برای مثال، ایجاد یک پروژه به‌طور خودکار صفحات، تخته و چت مربوط به آن را می‌سازد، و حذف یک عضو، تمام مجوزهای زیرمجموعه او را به‌طور دسته‌جمعی لغو می‌کند. این ابزار از یک جستجوی RAG در ابزارهای SaaS به یک مدیر یکپارچه وظایف و چت تکامل یافت.
promptflow (Prompt Flow Studio): یک SaaS که مدل‌های AI از OpenAI، Anthropic و گوگل را در یک صفحه مدیریت می‌کند. این ابزار در چهار حالت عمل می‌کند: چت، مقایسه، مناظره و جریان کاری. این سیستم می‌تواند یک سوال واحد را به‌طور همزمان روی چندین مدل اجرا کند تا خروجی‌ها را مقایسه و درباره آن‌ها مناظره کند، در حالی که کنترل کامل نسخه (Version Control) را فراهم می‌کند. این یکی از بزرگترین محصولات از نظر مقیاس توسعه است و نسخه iOS آن در حال حاضر در دست ساخت است.
local-commander: ارکستراتور توسعه AI که از یک LLM محلی به عنوان داور روی ماشین کاربر (به جای ابر) استفاده می‌کند. این ابزار تسک‌ها را به دسته‌های «اجرای محلی»، «نیاز به ابر» یا «نیاز به تایید» مرتب می‌کند. سپس پیاده‌سازی را به Codex یا Claude Code ارجاع داده و عملیات Push، PR، بررسی، ادغام و به‌روزرسانی تسک‌ها را خودکار می‌کند. تصمیم برای خرید سخت‌افزار اختصاصی DGX Spark بر اساس بنچمارک‌های اندازه‌گیری شده در ۱۶ مورد مختلف اتخاذ شد.
claude-plugins (ELN workflow): یک شالوده پلاگین خصوصی داخلی که فرآیندهای مشخصات (Spec)، استانداردهای کیفیت و انضباط عملیاتی را از طریق Claude Code توزیع می‌کند. این سیستم به جای یک سند متنی، به صورت مجموعه‌ای از «مهارت‌ها» پیاده شده است که باید دنبال شوند. این سیستم مانع از آن می‌شود که کاربران یک تسک را بدون مشاهده واقعی لاگ‌ها، تغییرات دیتابیس یا خروجی تست‌ها، به عنوان «انجام شده» علامت بزنند. در حالی که EarthLink بر خودکارسازی تکیه کرده است، برخی سازمان‌ها برای عبور از سد باگ‌های پیچیده، دوباره به کدنویسی دستی در سیستم‌های Human-AI OS بازگشته‌اند تا کنترل دقیق‌تری بر کیفیت داشته باشند. همین سیستم برای ایجاد این وبلاگ استفاده شده است.
نظارت و عملیات
پایداری و هزینه از طریق نظارت خودکار و زیرساخت به عنوان کد (IaC) مدیریت می‌شوند:
- alive365: یک SaaS نظارت بر پایداری (Uptime) که بررسی‌های زنده در مکان‌های مختلف، مدیریت حوادث، صفحه وضعیت (Status Page) و بررسی‌های عملیات مرورگر را ترکیب می‌کند. با اجرای بررسی‌های HTTP بدون نیاز به پردازش مقیم و شروع بررسی‌های مرورگر بر اساس تقاضا، شرکت توانست تجهیزات خطی که همیشه روشن بودند و ماهانه ۵۸ تا ۶۶ دلار هزینه داشتند را حذف کند.
- eln-infra-ops: یک شالوده زیرساخت داخلی که عملیات دستی SSH را حذف می‌کند. این سیستم باعث می‌شود ناوگان سرورهای CI داخلی (چندین ماشین به علاوه یک ماشین اختصاصی) از طریق کد بازتولید شوند. سیستم از طریق یک «تست کشتن» (Kill-test) سخت‌افزاری واقعی اعتبارسنجی می‌شود؛ به این صورت که یک ماشین را از مدار خارج می‌کنند تا اطمینان حاصل شود سرویس‌ها بدون وقفه زنده می‌مانند. پس از حادثه‌ای که در آن دو ماشین به‌طور همزمان به عنوان Primary فعال شدند، اصلاحیه‌ای در همان روز اعمال شد تا زمان Failover به ۱۸ ثانیه کاهش یابد.
- kale: یک شالوده مدیریت هزینه چند-ابری که هزینه‌های AWS، GCP، Azure و OpenAI را در یک صفحه نمایش می‌دهد. این ابزار در صورت تخطی از بودجه یا مشاهده ناهنجاری‌ها، به Slack و Teams هشدار می‌دهد. افزودن یک ارائه‌دهنده جدید تنها به یک ورودی در تنظیمات نیاز دارد؛ برای مثال GCP و OpenAI در یک روز اضافه شدند. یک عامل Claude Code از kale برای شناسایی ناهنجاری‌های ساعتی و گزارش‌های روزانه استفاده می‌کند.
پشتیبانی و تایید
لایه نهایی بر موفقیت مشتری و تایید کل سیستم تمرکز دارد:
desk: شالوده‌ای که FAQ، ظاهر و پیام‌های اولیه را بر اساس شناسه سایت تغییر می‌دهد. این سیستم چت‌بات‌های RAG را برای چندین سایت روی یک پایه واحد اجرا می‌کند. همچنین شامل یک حالت تست با پاسخ‌های از پیش تعیین شده است که بدون نیاز به کلید OpenAI کار می‌کند و اجازه می‌دهد شرایط پذیرش مشابه محیط عملیاتی در طول توسعه تایید شود.
community-v2: یک SaaS برای جامعه پذیرندگان AI که دارای کتابخانه قالب‌ها، پست‌ها، بررسی پرامپت، درس‌های کوتاه AI، اعلان‌ها و جستجو است. این سیستم از اپلیکیشن‌های مجزا برای کاربران و مدیران استفاده می‌کند. برای پایین نگه داشتن هزینه‌ها، هزینه‌های Build تنها در زمان اقدامات صریح کاربر رخ می‌دهد و نه با هر بار Push.
tessvia: شالوده‌ای که پخش آموزش‌ها، تولید دفترچه راهنما، تست‌های E2E و نظارت بر پایداری را از یک سناریوی مرجع واحد استخراج می‌کند. این ابزار حاصل ادغام دو پروژه مجزا (یک سازنده تست E2E و یک ابزار آموزش داخلی) بود، پس از آنکه تیم متوجه شد به‌طور مستقل دو ابزار با طراحی یکسان، حتی با انتخاب‌های رنگی مشابه، ساخته‌اند. تولید دستی در این سیستم به جای ابر، به یک
claude -pمحلی متصل شده است.
این معماری نشان می‌دهد که «شرکت قدرت‌گرفته از AI» یک اپلیکیشن واحد نیست، بلکه یک حلقه بازگشتی از خودکارسازی است. در واقع EarthLink با ساخت ابزارهایی برای مدیریت ابزارها، به‌طور موثری در حال خودکارسازیِ مدیریتِ مدیریتِ خود است.
برای شما به عنوان متخصص، این یعنی مزیت رقابتی تغییر کرده است. ارزش دیگر در توانایی نوشتن یک پرامپت یا عرضه یک ویژگی نیست، بلکه در توانایی طراحی سیستمی است که آن ویژگی‌ها را به‌طور خودکار نظارت و تعمیر می‌کند.
کسانی که علاقه‌مند به پیاده‌سازی الگوهای مشابه هستند، باید زنجیره تکاملی این ابزارها را بررسی کنند — اینکه چگونه نیاز به نظارت منجر به نیاز به تعمیر شد و سپس به نیاز به مدیریت ختم شد. آخرین صفحات، جزئیات و نسخه‌های بومی‌سازی شده (انگلیسی، کره‌ای، چینی، تایلندی) در صفحه رسمی محصولات در دسترس است.
گام بعدی شما
- بررسی زنجیره نیازها (نظارت $\rightarrow$ تعمیر $\rightarrow$ مدیریت) برای شناسایی نقاط کور در جریان کاری خود.
- جایگزینی مستندات متنی با «مهارت‌های اجرایی» (مانند مدل claude-plugins) برای تضمین کیفیت خروجی تیم.
- پیاده‌سازی لایه‌ی «داور محلی» برای کاهش هزینه‌های استنتاج در ابر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو