تجربه‌ی ۶ ماهه‌ی کدنویسی صفر: وقتی مهندس به ارکستراتور تبدیل می‌شود

تصور کنید یک مهندس ارشد تصمیم بگیرد برای ۱۸۰ روز، حتی یک خط کد را با دست ننویسد. این اتفاق در شرکت exe.dev رخ داد؛ جایی که یک برنامه‌نویس از فوریه تا اوت ۲۰۲۶، نقش خود را از یک تایپیست به یک ارکستراتور (orkestrator) تغییر داد تا با مدیریت ۲۰ عامل هوش مصنوعی موازی، چرخه‌ی عرضه محصول را به شدت تسریع کند.

این تغییر رویکرد در حالی رخ می‌دهد که هزینه‌ی هوش مصنوعی به شدت در حال کاهش است. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش ۵۶ برابری هزینه‌ی استنتاج در ۶ ماه اشاره کردیم، اکنون سد هزینه‌ای برای اجرای گردش‌های کاری گسترده و موازی از میان رفته است. برای اکثر توسعه‌دهندگان، چالش دیگر قیمت هر توکن (Token) — مثل برش‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — نیست، بلکه فشار ذهنی برای بازبینی خروجی‌هاست. در همین راستا، برخی توسعه‌دهندگان برای بهینه‌سازی بیشتر، از سیستم‌های هارنس برای کاهش هزینه‌های مدل‌های زبانی گران‌قیمت استفاده کرده‌اند تا بهره‌وری را افزایش دهند.

گذار به گردش‌های کاری عامل‌محور

به نقل از این مهندس، در دوران پیش از هوش مصنوعی، «ابرقدرت» یک برنامه‌نویس داشتن مدل ذهنی عمیق از کل سیستم بود. آن‌ها می‌توانستند دقیقاً بگویند کدام خط کد باعث باگ شده است و مفروضات نانوشته‌ای که پشت تصمیمات عجیب معماری وجود داشت را به یاد بیاورند. این دانش طی ماه‌ها و سال‌ها کار روی کدبیس به دست آمده بود؛ دانشی گران‌بها که اجازه می‌داد ویژگی‌های جدید به‌سرعت و با امنیت بالا ساخته شوند.

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

سفر به سوی اتوماسیون با ابزارهایی مثل GitHub Copilot و Cursor شروع شد. قابلیت تکمیل خودکار Copilot، کامنت‌های مستندات را به پیش‌نویس‌های اولیه تبدیل می‌کرد — که اغلب غلط بودند، اما باز هم بهتر از یک فایل خالی بودند — در حالی که قابلیت Tab-complete در Cursor این فرآیند را سرعت بخشید. اما نقطه عطف واقعی با Claude Code رخ داد؛ ابزاری که اجازه می‌داد تغییرات را یک‌بار توصیف کنید و یک عامل، چندین فایل را به‌طور هم‌زمان ویرایش کند.

با عرضه GPT-5.3 و Opus 4.6 در فوریه ۲۰۲۶، قابلیت‌های استدلالی لازم برای مدیریت تغییرات بزرگ با کمترین میزان هدایت فراهم شد. این مهندس قانونی سختگیرانه وضع کرد: هیچ کدی با دست نوشته نشود. اگر یک عامل (Agent) — شبیه دستیاری که ابزارهای مختلف را برای رسیدن به هدف به کار می‌گیرد — گیر می‌کرد، او حق نداشت کد را خودش کامل کند. در عوض، باید می‌فهمید چه چیزی کم است؛ آیا مشکل از پرامپت بود، یا ابزارها یا محیط اجرا؟ او باید دوباره تلاش می‌کرد.

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

مقیاس‌پذیری با عامل‌های موازی

با افزایش سرعت عامل‌ها، مهندس با «بازه های زمانی آزاد» مواجه شد در حالی که منتظر تکمیل تسک‌ها بود. برای پر کردن این شکاف، او شروع به اجرای چندین عامل به‌طور هم‌زمان کرد. این ساختار موازی در ابتدا شبیه به یک محیط توسعه مشترک و پر هرج‌ومرج بود که در آن همکاران با هم صحبت نمی‌کنند، و این منجر به چندین مانع زیرساختی شد:

• تداخل منابع: عامل‌ها بر سر پورت‌ها می‌جنگیدند، وابستگی‌های متضاد نصب می‌کردند و بر سر وضعیت Git و پروسه‌های در حال اجرا با هم تداخل داشتند. توسعه‌دهنده اغلب خود را در وضعیتی می‌دید که باید منتظر طولانی‌ترین عامل بماند تا بقیه بتوانند پیش بروند، که این خود روش جدیدی برای منتظر ماندن بود.
• محدودیت‌های Worktree: استفاده از Git worktrees تداخل کد را با دادن یک Checkout و برنچ مجزا به هر عامل حل کرد، اما آن‌ها همچنان دیتابیس‌ها و سایر منابع ماشین را به صورت مشترک استفاده می‌کردند.
• شکست AGENTS.md: توسعه‌دهندگان سعی کردند از فایلی به نام AGENTS.md استفاده کنند تا به عامل‌ها دستور دهند از پورت‌های تصادفی و دیتابیس‌های موقت استفاده کنند. این روش شکست خورد، چون عامل‌ها بیش از حد از پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — برای درک اینکه چگونه روی پای هم نروند استفاده می‌کردند، به جای اینکه روی انجام تسک تمرکز کنند.
• نشت کانتینرها: کانتینرها پورت‌ها و وضعیت محلی مجزایی فراهم می‌کردند، اما مرز آن‌ها نشت داشت. هر چیزی که لپ‌تاپ می‌توانست به آن دسترسی داشته باشد، کانتینر هم می‌توانست؛ به این معنی که «شعاع تخریب» یک دستور اشتباه همچنان بسیار بالا بود. علاوه بر این، لپ‌تاپ باید روشن می‌ماند؛ اگر درب لپ‌تاپ بسته می‌شد، کار متوقف می‌شد.

برای حل این مشکل، او از exe.dev استفاده کرد تا عامل‌ها را به ماشین‌های مجازی (VM) لینوکسی ایزوله منتقل کند که در چند ثانیه بوت می‌شدند و SSH و HTTPS آن‌ها از پیش پیکربندی شده بود. این کار اجازه داد حتی با بسته شدن لپ‌تاپ، کار ادامه یابد. برای اتوماسیون این تنظیمات، او از کلود خواست یک اسکریپت راه‌اندازی بنویسد. به عامل دستور داده شد که در یک حلقه تکرار شود تا زمانی که همه چیز کار کند: ابزارهای لازم را نصب کند، مخازن را کلون کند و Claude Code و Codex را پیکربندی نماید. سپس عامل یک حلقه اعتبارسنجی را اجرا کرد — یک ماشین جدید بالا می‌آورد، اسکریپت را اجرا می‌کرد، می‌دید چه چیزی خراب شده و اسکریپت را اصلاح می‌کرد — تا زمانی که محیط کاملاً پایدار شود.

ظهور و سقوط botd

مدیریت ده‌ها پنجره ترمینال و نشست‌های tmux غیرممکن شد و منجر به ساخت botd شد؛ ابزاری سفارشی برای مدیریت عامل‌ها که از سه قانون سختگیرانه پیروی می‌کرد:

۱. اجرای خارج از لپ‌تاپ: باید به‌طور مستقل اجرا می‌شد تا وقتی لپ‌تاپ بسته است، عامل‌ها به کار خود ادامه دهند.
۲. طراحی موبایل‌محور: مدیریت عامل‌ها نباید مستلزم نشستن پشت یک ترمینال باشد.
۳. حفظ گفتگوها: هر تعامل باید ذخیره می‌شد تا مشخص شود عامل‌ها کجا گیر کرده‌اند و کدام دستورات موثر بوده‌اند.

از آنجایی که هر عامل در یک VM یک‌بار مصرف زندگی می‌کرد، توسعه‌دهنده «حالت YOLO» را فعال کرد؛ یعنی عامل‌ها می‌توانستند دستورات Bash را اجرا کرده و پکیج‌ها را بدون تایید دستی نصب کنند. تخریب یک محیط هیچ هزینه‌ای جز هزینه خود VM نداشت. برای مدیریت امنیت و اجتناب از «سه‌گانه مرگبار» (داده‌های خصوصی، محتوای غیرقابل اعتماد و ارتباطات خارجی)، از یک پروکسی استفاده شد. این پروکسی اعتبارنامه‌ها (Credentials) را به درخواست‌ها اضافه می‌کرد تا عامل‌ها هرگز رمزهای واقعی را نبینند و دسترسی نوشتن فقط به محیط‌های تست محدود شود، جایی که بدترین حالت ممکن، فاسد شدن داده‌های تست بود.

اما در اوت ۲۰۲۶، botd زیر فشار خودش فروپاشید. دلیلش این بود که این ابزار با روش Vibe Coding (کدنویسی بر اساس حس و بدون نقشه معماری دقیق) ساخته شده بود و خودش به یک کد قدیمی و پیچیده (Legacy Codebase) تبدیل شد. مشکل اصلی در مدیریت خانواده‌های مختلف مدل‌ها (مثل Claude Code و Codex) از طریق رابط‌های بومی در حالی که تفاوت‌های آن‌ها پنهان شود، نیازمند سطحی از معماری بود که توسعه‌دهنده از آن غافل شده بود. ابزار از رده خارج شد، اما داده‌های زیربنایی در SQLite باقی ماند. این به توسعه‌دهنده اجازه داد تا تاریخچه خود را کوئری بزند و ببیند چگونه سوالاتش معماری سیستم را به طور مادی تغییر داده است و درخواست‌های اولیه، اعتراضات و کامیت‌های نهایی هر نشست را بازیابی کند. در برخی تجربه‌های مشابه، برای کنترل دقیق‌تر این فرآیندها از معماری‌های جدیدی مانند مدل‌های ۴ بیتی کوانتیده برای ارکستراسیون PRها استفاده شده است تا پیچیدگی مدیریت مدل‌های مختلف کاهش یابد.

فراتر از تولید کد

این آزمایش ثابت کرد عامل‌ها وقتی به جای «کدنویس»، به عنوان «ابزار تخصصی» عمل کنند، موثرترند. یک عامل صرفاً مدلی در یک حلقه است که به ابزارها دسترسی دارد؛ و این ابزارها هستند که قابلیت‌های عامل را تعریف می‌کنند. او سه نقش متمایز تعریف کرد:

۱. تحقیق: استفاده از گزارشات کلمه-به-کلمه مشتریان برای کوئری زدن در لاگ‌های ClickHouse. با اجتناب از خلاصه‌سازی، عامل از نقاط کور ذهنی توسعه‌دهنده دوری می‌کرد و وقایع را بر اساس شواهد بازسازی می‌کرد نه حدس زدن از روی یک گزارش باگ. این به توسعه‌دهنده اجازه می‌داد بر اساس شواهد تصمیم بگیرد که آیا راه حل در کد است، یا در مستندات و یا یک ایمیل.
۲. حمله: یک عامل تیم قرمز (Red-team) که وظیفه داشت به سیستم‌ها نفوذ کند. این عامل با موفقیت مسیرهای شبکه بازی را پیدا کرد که تصور می‌شد محدود شده‌اند و به تیم اجازه داد قبل از کشف توسط عوامل خارجی، آن‌ها را وصله کنند. این عامل مفروضات را در برابر سیستم در حال اجرا تست کرد و آن‌ها را رد کرد.
۳. ناظر: عاملی به نام Athena که استقرارها (Deployments) را در لحظه رصد می‌کرد. آتنا می‌توانست تفاوت بین شکست‌های زیرساختی و باگ‌های کد را تشخیص دهد؛ در یک مورد، متوجه شد که شکست مربوط به زیرساخت است و به جای متوقف کردن کل استقرار، عملیات را برای سایر ماشین‌ها ادامه داد. توسعه‌دهنده اشاره کرد که آتنا سخت‌کوش‌تر، خستگی‌ناپذیرتر و کمتر از انسان دچار حواس‌پرتی می‌شود.

پارادایم جدید مهندسی

اکنون عرضه کد تقریباً رایگان شده است، اما تصمیم‌گیری درباره اینکه «چه چیزی» عرضه شود، گلوگاه اصلی است. توسعه‌دهنده دریافت که اگرچه عامل‌ها می‌توانند تست‌ها را پاس کنند و اسکرین‌شات بفرستند، اما نمی‌توانند تشخیص دهند که آیا یک ویژگی، پیچیدگی غیرضروری اضافه می‌کند یا راه دومی برای انجام کاری ایجاد می‌کند که قبلاً پشتیبانی می‌شد. این موضوع توسط قانون هایرام (Hyrum’s Law) حاکم است: وقتی سیستمی کاربران کافی دارد، هر رفتار قابل مشاهده تبدیل به یک قرارداد می‌شود که نمی‌توان به راحتی تغییرش داد. حذف یک ویژگی (Unshipping) سخت‌تر از اضافه کردن آن است.

این منجر به ظهور «مهندسی عامل‌محور» شده است؛ جایی که تمرکز روی معماری، رابط‌ها (Interfaces) و محدودیت‌هاست، پیش از آنکه حتی یک خط کد تولید شود. در این مدل، بازبینی کد (Code Review) توسط همکاران تقریباً مرده است؛ بازبینی حیاتی در مرحله طراحی رخ می‌دهد. برای مثال، هنگام ساخت ابزارهای ناهمگام (Asynchronous) برای عامل Shelley، توسعه‌دهنده طراحی اولیه‌ای را که مسئولیت پیش‌بینی تسک‌های پس‌زمینه را به عهده عامل می‌گذاشت رد کرد و در عوض طراحی‌ای را انتخاب کرد که در آن هر دستور بعد از ۶۰ ثانیه به طور خودکار به پس‌زمینه منتقل شود. با این حال، برخی شرکت‌ها به دلیل همین چالش‌های کیفی، دوباره به کدنویسی دستی در سیستم‌های Human-AI OS بازگشته‌اند تا بتوانند از سد باگ‌های پیچیده هوش مصنوعی عبور کنند.

بهداشت مهندسی (Engineering Hygiene) اکنون حیاتی‌تر از همیشه است. چون عامل‌ها الگوهای موجود را کپی می‌کنند، یک الگوی بد در کدبیس ۱۰۰ برابر تکثیر می‌شود. راه حل، ساخت Linterهای سفارشی برای کدگذاری درس‌های آموخته شده است تا اشتباهات خاص را غیرممکن کند، چرا که هزینه نهایی ساخت یک ابزار سفارشی به شدت کاهش یافته است.

مدیریت ریسک و اعتبارسنجی

در اوج آزمایش، ۲۰ ماشین مجازی هم‌زمان در حال کار بودند. این مقیاس، اعتبارسنجی دستی را غیرممکن می‌کرد. برای مدیریت این وضعیت، عامل‌ها موظف به تضمین کیفیت (QA) خودشان شدند:

• تایید خودکار: عامل‌ها تست‌ها را اجرا می‌کردند، مجموعه‌های کامل CI را فعال می‌کردند، اپلیکیشن را بالا می‌آوردند و آن را از طریق مرورگر هدایت می‌کردند و اسکرین‌شات‌های کار تکمیل شده را برای مهندس می‌فرستادند.
• مشکل نمره‌دهی: چون عامل‌ها «کار خودشان را نمره می‌دادند»، می‌توانستند با اطمینان کامل گزارش موفقیت بدهند حتی اگر درخواست اصلی را اشتباه فهمیده باشند. این موضوع باعث شد توانایی باز کردن محیط در حال اجرا و هدایت UI از ابتدا تا انتها برای تایید انسانی ضروری شود.
• بازبینی عامل‌محور: استفاده از عامل‌های دیگر برای بازبینی کد برای یافتن باگ‌های واقعی به طرز شگفت‌آوری خوب عمل کرد، هرچند توسعه‌دهنده تاکید داشت که همچنان مسئول هر خط کدی است که Merge می‌شود.

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

گام بعدی شما

• به جای تمرکز بر یادگیری سینتکس زبان‌های جدید، روی یادگیری طراحی سیستم و تعریف محدودیت‌های سخت‌گیرانه تمرکز کنید.
• ابزارهای ایزوله (مانند Docker یا VMهای ابری) را برای اجرای عامل‌های هوش مصنوعی به کار بگیرید تا «شعاع تخریب» دستورات اشتباه محدود شود.
• برای پروژه‌های خود، یک عامل «تیم قرمز» تعریف کنید که هدفش پیدا کردن نقاط ضعف در معماری شما باشد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.