تصور کنید برنامه‌نویسی هستید که می‌خواهد یک سامانه پیچیده را به هوش مصنوعی بسپارد؛ اما متوجه می‌شوید ابزاری که برای انسان «ساده» بود، برای مدل «کورکننده» است. امروز، پیچیدگی زیرساختی دیگر یک مانع نیست، بلکه به نقطه قوت رقابتی برای توسعه‌های عامل‌محور تبدیل شده است.
بر اساس تحلیلی که ۷ جولای ۲۰۲۶ در وب‌سایت dev.to منتشر شد، تغییر رویکرد به سمت عامل‌هایی با «زمینه غنی» (Context-rich)، ارزش انتزاع‌های جعبه-سیاه را وارونه کرده است. در واقع همان پیچیدگی‌هایی که زمانی سرعت توسعه‌دهندگان انسانی را می‌گرفت، اکنون دقیقاً همان سیگنال‌هایی هستند که عامل‌های هوش مصنوعی (AI Agents) — مانند دستیارانی که می‌توانند به‌تنهایی ابزارهای مختلف را مدیریت کنند — برای حفظ صحت سیستم به آن‌ها نیاز دارند. در نتیجه، زیرساخت‌های پیچیده دیگر یک بدهی یا نقطه ضعف نیستند، بلکه به یک اهرم رقابتی برای توسعه‌های مبتنی بر هوش مصنوعی تبدیل می‌شوند.
برای سال‌ها، روند صنعت به سمت زیرساخت‌های «جعبه-سیاه» متمایل بود؛ پلتفرم‌هایی مثل Vercel، Supabase و Cloudflare Workers که جزئیات به‌هم‌ریخته بک‌اند را پشت یک قرارداد (Contract) sharp یا صریح پنهان می‌کردند. این رویکرد زمانی جواب می‌داد که عامل‌ها «فقیر از زمینه» بودند و به‌راحتی در حلقه‌های استدلالی پیچیده گم می‌شدند. هدف این بود که سطح تماس (Surface Area) را کوچک کنیم تا از اشتباهات هوش مصنوعی جلوگیری شود. استراتژی ساده بود: یک رابط کاربری تمیز ارائه دهید، بک‌اند شلوغ را پنهان کنید و با سرعت پیش بروید. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کاهش سطح تماس همیشه راهکار اول برای جلوگیری از خطا بود.
اما ماهیت ابزارها تغییر کرده است. عامل‌های مدرن اکنون می‌توانند زمینه‌های ساختاریافته بزرگی را پردازش کنند. این یعنی آن‌ها دیگر با سربارِ طرح‌های ارائه‌دهنده (Provider Schemas) یا سیاست‌های پیچیده دسترسی (IAM) دست‌وپنجه نرم نمی‌کنند. در حقیقت، این جزئیات صریح — شامل منابع، طرح‌های ارائه‌دهنده، صف‌های صریح، هشدارها و شبکه‌ها — اکنون بالاترین سطح سیگنالی هستند که یک توسعه‌دهنده می‌تواند به یک عامل ارائه دهد تا یک استقرار مبنی‌سازی‌شده (Grounded Deployment) را تضمین کند. نکته این است که AWS ساده‌تر نشده است؛ اصلاً نشده. راه‌اندازی آن هنوز زمان‌بر است و سیم‌کشی CI/CD همچنان نیاز به کار زیادی دارد. تغییر واقعی این است که عامل‌ها به‌سادگی در خواندن پیچیدگی‌ها خبره شده‌اند. در همین راستا، تلاش‌هایی برای بهینه‌سازی سرعت این فرآیند در جریان است و برای مثال، حالت Express در AWS توانسته است زمان استقرار عامل‌های هوش مصنوعی را تا حد زیادی کاهش دهد.
شکاف عملکرد در Terraform
مقایسه HCL/Terraform در ارائه‌دهندگان مختلف این تحول را به خوبی نشان می‌دهد. در حالی که زبان و گردش‌کار در همه جا یکسان باقی می‌ماند، میزان «قرارداد عملیاتی» قابل مشاهده به‌شدت متفاوت است. سوال کلیدی این است: یک عامل چقدر می‌تواند توپولوژی زیرساخت را تنها از روی کد HCL و طرح ارائه‌دهنده بازسازی کند؟
AWS: ارائه‌دهنده AWS تقریباً در سطح استانداردهای صنعتی (Battle-tested) است و توسط حجم عظیمی از ماژول‌ها و مثال‌های عمومی پشتیبانی می‌شود. طرح AWSCC آن به‌صورت خودکار از طرح منابع CloudFormation تولید می‌شود. این ویژگی تضمین می‌کند که AWSCC پوشش CloudFormation را به‌دقت دنبال کرده و سرویس‌های جدید را به‌سرعت جذب کند. در نتیجه، اکثر جزئیات توپولوژی زیرساخت — از صف‌ها، نقش‌ها و مجوزها گرفته تا زمان‌بندی‌ها، هشدارها و سیم‌کشی‌های لایه داده (Data-plane) — در یک آرتیفکت واحد قابل مشاهده است. این صراحت در لایه‌های پایین‌تر، مکمل پیشرفت‌هایی در لایه‌های مدیریتی است؛ چنان‌که مدل‌های عامل AWS Bedrock اکنون با تعداد دفعات بسیار کمتری از فراخوانی API مستقر می‌شوند.
Cloudflare: اگرچه Cloudflare در حال بهبود نسخه پنجم Terraform خود است (که یک بازنویسی کامل بر پایه OpenAPI است)، اما بسیاری از رفتارهای آن همچنان پنهان است. هرچند نسخه ۵ گام بزرگی در راستای همسویی با API و پوشش گسترده‌تر است، اما هنوز در بازه‌های زمانی کوتاهی در حال تثبیت است. یک فایل Terraform می‌تواند به عامل بگوید که یک اتصال (Binding) وجود دارد، اما نمی‌تواند توضیح دهد که آن اتصال چگونه استفاده می‌شود. مسئولیت‌ها و رفتارها در فایل‌های
wrangler.json، کدهای Worker، مهاجرت‌های D1، فایلpackage.jsonو قراردادهای مختلف فریم‌ورک‌ها پراکنده شده‌اند.
بازسازی‌پذیری و تحمل خطا
وقتی این ارائه‌دهندگان را از دریچه عامل‌های هوش مصنوعی می‌بینیم، تفاوت در آنچه واقعاً از روی کد قابل بازسازی است، نهفته است:
- شکل زیرساخت (Infra Shape): در AWS، شکل زیرساخت تا حد زیادی از روی HCL قابل بازسازی است. در Cloudflare، این بازسازی تنها به‌صورت جزئی رخ می‌دهد، زیرا معناشناسی (Semantics) برنامه در جاهای دیگر قرار دارد.
- تحمل پرامپت‌های کوتاه (Terse-Prompt Tolerance): AWS تحمل بالایی نشان می‌دهد زیرا الگوهای رایج به‌خوبی بازنمایی شده‌اند. در Cloudflare، این تحمل برای استک‌های کوچک بالاست، اما به محض اینکه Workerها با D1، R2، KV، Durable Objects، صف‌ها و اتصال‌ها تعامل کنند، نرخ تحمل افت می‌کند.
این یک نقد به Cloudflare نیست، بلکه تمایزی در استراتژی است. Cloudflare روی استقرار بومی-فریم‌ورک و مبتنی بر قصد (Intent-based) شرط‌بندی کرده است. آن‌ها با خرید شرکت‌هایی مثل VoidZero، آینده‌ای را متصور هستند که در آن یک دستور ساده‌ی deploy در Vite، نیاز به دیتابیس را شناسایی کرده و به‌طور خودکار منبع D1 یا R2 را بدون نیاز به مراحل دستی در داشبورد ایجاد کند. این یک آینده منسجم است، اما شرط‌بندی متفاوتی نسبت به فلسفه «همه چیز صریح به عنوان کد» (Everything explicit as code) است. این رقابت میان رویکردها، یادآور جدال‌های گسترده‌تر در مورد تسلط بر لایه کنترلی عامل‌ها میان پروژه‌هایی نظیر OpenClaw و Hermes است.
خطر «موفقیت ظاهری»
با این حال، نویسنده هشدار می‌دهد که یک «تیک سبز» در ترمینال به‌معنای صحت سیستم نیست. دو مطالعه کلیدی، «شکاف صحت-همگرایی» (Correctness–Congruence Gap) را برجسته کرده و ثابت می‌کنند که موفقیت ظاهری با درست بودن سیستم یکی نیست:
- مطالعه Nekrasov و همکاران (۲۰۲۵): این تحقیق نشان داد که دانش طرح‌های ساختاریافته، مدل‌ها را به کدنویسان بهتری تبدیل می‌کند. موفقیت اعتبارسنجی فنی از ۲۷.۱٪ به ۷۵.۳٪ رسید و موفقیت کلی به ۶۲.۶٪ رسید. اما همراستاسازی با قصد کاربر (Intent Alignment) درجا زد. نتیجه‌گیری این بود: داشتن یک HCL معتبر (Valid)، لزوماً به معنای ایجاد همان زیرساختی نیست که شما واقعاً درخواست کرده بودید.
- پژوهش TerraProbe (Alsaid و همکاران، ۲۰۲۶): این تحقیق فاش کرد که اصلاحات امنیتی تک‌مرحله‌ای (One-shot) اغلب فریب‌دهنده هستند. در یک مطالعه، ۸۳٪ از مشکلات شناسایی‌شده از دید اسکنرها حذف شدند، اما در واقعیت تنها ۱۰٪ آن‌ها کاملاً پاکسازی شده بودند. بین ۵۷٪ تا ۷۱٪ موارد، «اصلاحات فریب‌دهنده» بودند؛ یعنی اسکنر سبز می‌شد اما حفره امنیتی همچنان باز می‌ماند. این شواهد نیاز به یک گردش‌کار حلقه-بسته را به جای تکیه بر اعتمادبه‌نفس مدل ثابت می‌کند.
اجرای گردش‌کار حلقه-بسته
برای کاهش این ریسک‌ها، بستر کدهای صریح باید به یک توالی سخت‌گیرانه حلقه-بسته تغذیه شود؛ جایی که هر شکست، عامل را به مرحله تولید بازگرداند و هرگز اجازه ندهد مستقیماً به مرحله اجرا (Apply) برود:
۱. درخواست زبان طبیعی $\rightrightarrows$ محرک اولیه برای شروع فرآیند.
۲. جمع‌آوری زمینه $\rightrightarrows$ استخراج طرح ارائه‌دهنده و مستندات ماژول‌ها از طریق پروتکل زمینه مدل (MCP).
۳. تولید $\rightrightarrows$ ساخت کد HCL.
۴. اعتبارسنجی فنی $\rightrightarrows$ اجرای دستورات fmt ، validate و plan. اگر تفاوت‌های (diff) پلان با خطا مواجه شد، بازگشت به مرحله ۳.
۵. حاکمیت سیاست‌ها $\rightrightarrows$ اجرای اسکن‌های سیاستی با ابزارهایی مثل Checkov، tfsec، OPA یا Conftest. در صورت تخلف، بازگشت به مرحله ۳.
۶. بهینه‌سازی $\rightrightarrows$ اجرای تخمین‌های هزینه برای بررسی بهینه بودن.
۷. تایید $\rightrightarrows$ اجرای تست‌های دوده‌ای (Smoke Tests) در یک محیط موقت (Ephemeral).
۸. استقرار $\rightrightarrows$ اجرای نهایی (Apply) تنها پس از بازبینی و تایید انسانی.
Pulumi یک استثنای جالب در این میان است. این ابزار اکثر بستر طرح‌های AWS را (با پل زدن به ارائه‌دهندگان Terraform) حفظ می‌کند، اما HCL را با یک زبان برنامه‌نویسی واقعی جایگزین می‌کند. این کار به عامل یک کامپایلر و سیستم تایپینگ می‌دهد که مانند یک پیش‌گوی (Oracle) اضافی عمل می‌کند. اما ریسک آن دقیقاً تصویر Conversely قدرت آن است: زبان‌های واقعی به عامل‌ها اجازه می‌دهند «بیش از حد باهوش» عمل کنند، که این امر نیاز به تکیه شدیدتر بر پیش‌نمایش‌ها، سیاست‌گذاری به‌صورت کد (Policy-as-code) و تست‌ها دارد تا روح سیستم صریح و Declarative باقی بماند.
چرا این یک پیروزی مطلق برای AWS نیست
این تحول به معنای پیروزی AWS در سهولت استفاده نیست. راه‌اندازی یک محیط AWS همچنان کندتر از استفاده از یک پلتفرم با محدوده تعریف‌شده (Tightly Scoped) است. CI/CD به سیم‌کشی بیشتری نیاز دارد، کنترل هزینه‌ها دشوارتر است و سطح تماس به‌طور قابل توجهی بیشتر است — یعنی IAM بیشتر، سیاست‌های بیشتر و راه‌های بیشتر برای اشتباه کردن.
اما برای توسعه انسانی، این صراحت اغلب به عنوان یک «کندی» یا Drag احساس می‌شد. برای توسعه عامل‌محور، این صراحت به‌طور فزاینده‌ای به عنوان یک «اهرم» (Leverage) احساس می‌شود. زیرساختی که انسان‌ها سعی می‌کردند از مدل‌ها پنهان کنند، اکنون همان چیزی است که مدل‌ها برای اثرگذاری به آن نیاز دارند. برای سیستم‌های سطح سازمانی و نیازمندی‌های پیچیده، ترکیب HCL و AWS را به‌سختی می‌توان شکست داد، زیرا سیستم را به‌صورت کد قابل بازرسی (Inspectable) نگه می‌دارد. پلتفرم‌های کدر و غیرشفاف زمانی مفید بودند که عامل‌ها محدود به زمینه بودند؛ اما اکنون که عامل‌ها «غنی از زمینه» هستند، زیرساخت صریح یک ضرورت است.
گام بعدی شما
- اگر از زیرساخت‌های انتزاعی استفاده می‌کنید، بررسی کنید آیا عامل شما به دلیل نبود جزئیات، دچار توهم (Hallucination) — شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شود یا خیر.
- برای پروژه‌های حساس، گردش‌کار را از حالت «تولید و اجرا» به حالت «تولید $\rightrightarrows$ اعتبارسنجی $\rightrightarrows$ سیاست‌گذاری $\rightrightarrows$ اجرا» تغییر دهید.
- در صورت استفاده از Terraform، از MCP برای تغذية مستقیم طرح‌های به‌روز ارائه‌دهنده به مدل استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو