تصور کنید یک کتابخانه قدیمی جاوااسکریپت را که سال‌هاست به‌روز نشده، در کمتر از ۲۴ ساعت به استانداردهای ۲۰۲۵ برسانید. استیون کرس‌ول دقیقاً همین کار را با انتشار نسخه Yadda 3.0.0 انجام داد، اما نه با کدنویسی دستی، بلکه با مدیریت یک نیروی کار مجازی. او برای این کار از Claude Code استفاده کرد؛ ابزاری که به‌جای یک محیط چت ساده، مانند یک مهندس نرم‌افزار در محیط ترمینال عمل می‌کند. استیون کرس‌ول Yadda 3.0.0 را منتشر کرد که یک کتابخانه توسعه مدل‌محور (BDD) است و مشخصات به زبان طبیعی را به کدهای قابل اجرا نگاشت می‌کند.

Yadda یک کتابخانه برای «توسعه مدل‌محور یا BDD» (Behavior-Driven Development) است که مشخصات به زبان طبیعی را به کدهای قابل اجرا تبدیل می‌کند. در واقع BDD — شبیه به نوشتن یک دفترچه راهنمای دقیق برای دستگاهی است که همزمان هم برای انسان قابل خواندن است و هم برای ماشین قابل اجرا — اجازه می‌دهد توسعه‌دهندگان نیازمندی‌ها را به‌گونه‌ای بنویسند که مستقیماً به تست تبدیل شوند. برخلاف ابزاری مانند Cucumber که بسیار تجویزی و سخت‌گیر است، Yadda به‌گونه‌ای طراحی شده که در مورد نحوه نوشتن مشخصات انعطاف بیشتری داشته باشد.

برای مثال، در Cucumber باید از ساختار سخت‌گیرانه «Given/And/When/Then» استفاده کنید، مانند این مورد:
Given a university, The University of Bouvet Island And The University of Bouvet Island offers a degree course in Computer Science with entry requirements of ABB And an A-Level graduate, Steve And Steve has a D in Physics And Steve has a D in Maths When Steve applies to study Computer Science at The University of Bouvet Island Then The University of Bouvet Island rejects the application

اما Yadda اجازه می‌دهد جریان متن طبیعی‌تر و خواناتر باشد:
The University of Bouvet Island offers a degree course in Computer Science The entry requirements for which are ABB Steve is an A-Level graduate With a D in Physics And a D in Maths When Steve applies to study Computer Science at The University of Bouvet Island They reject his application

هر دو مورد مشخصاتی قابل اجرا هستند، اما مورد دوم برای انسان‌ها به‌مراتب راحت‌تر خوانده می‌شود. BDD به‌طور سنتی فرآیندی با اصطکاک بالا بوده است، زیرا نوشتن نیازمندی‌های قابل خواندن برای انسان که همزمان به‌عنوان تست عمل کنند، زمان‌بر است. سال‌هاست که توسعه‌دهندگان بین مزیت مدل‌سازی بهتر دامنه و هزینه نگهداری این مشخصات تعادل ایجاد می‌کنند. این تنش باعث ایجاد یک «بازدهی به تعویق افتاده» شد که اغلب توجیه BDD را در محیط‌های سریع و پرشتاب دشوار می‌کرد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق بر خروجی مدل‌های زبانی برای جلوگیری از خطاهای ساختاری حیاتی است. در Yadda، تفاوت اصلی با ابزارهایی مثل Cucumber در انعطاف‌پذیری است. رویکرد کرس‌ول در Yadda 3.0 این معادله اقتصادی را تغییر می‌دهد؛ او از عامل‌های هوش مصنوعی برای جذب کارهای دستی مربوط به مشخصات و مدرنیزاسیون استفاده کرد. او از Claude Code به همراه مدل Opus 4.8 برای مدیریت بخش اعظم مهاجرت کد، انتقال کتابخانه به محیط Node-only و به‌روزرسانی آن به سینتکس ES6 بهره برد.

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

• حذف قابلیت‌های منسوخ: این مرحله شامل پاک‌سازی موارد تاریخی و قدیمی مانند CasperJS، PhantomJS، Bower و Component بود.
• به‌روزرسانی زنجیره ابزار: مجموعه تست‌ها به node:test منتقل شد و پروژه ابزارهای Biome و lefthook را پذیرفت. این سطح از تعامل با محیط سیستم‌عامل یادآور آن است که چگونه سواد لینوکس می‌تواند به عنوان یک سد ایمنی در برابر خطاهای احتمالی عامل‌های هوش مصنوعی عمل کند.
• فرمت‌بندی مکانیکی: این کار به‌طور جداگانه از تغییرات رفتاری انجام شد تا تاریخچه کامیت‌ها (Commit History) آلوده نشود و شفاف باقی بماند.
• مدرنیزاسیون منبع: کدها به سینتکس ES6 به‌روزرسانی شدند و APIها برای تغییرات احتمالی بررسی شدند.
• مستندات و مثال‌ها: نمونه‌های جدیدی برای Playwright و Puppeteer اضافه شد و بسته اکنون با تعاریف TypeScript عرضه می‌شود.

کرس‌ول یک محدودیت سخت‌گیرانه اعمال کرد: عامل (Agent) — مانند کارمندی که دستورات دقیق را اجرا می‌کند اما نباید در تصمیمات کلان دخالت کند — اجازه نداشت کد تولیدی (Production Code) و تست‌ها را در یک مرحله به‌طور هم‌زمان تغییر دهد. استدلال او این بود که اگر یک عامل هر دو را همزمان تغییر دهد، یک مجموعه تست «سبز» (Pass شده) دیگر دلیل محکمی بر درستی نیست، زیرا عامل آزاد است تا تعریف «درست بودن» را همزمان با پیاده‌سازی تغییر دهد. نگه داشتن این تغییرات به‌صورت مجزا، محدودیت خارجی بسیار محکم‌تری برای Claude ایجاد کرد.

طبق گزارش کرس‌ول، به دلیل اینکه Yadda از قبل دارای یک مجموعه تست جامع بود، هوش مصنوعی خطاهای بسیار کمی داشت. حتی تأثیرگذارتر این بود که مدل توانست برخی لبه‌های حساس (Edge Cases) بسیار ظریف را شناسایی کند که در یک مدرنیزاسیون مکانیکی ساده احتمالاً نادیده گرفته می‌شدند. کرس‌ول در طول کل این فرآیند مداخلات بسیار کمی انجام داد.

اما با پیشرفت پروژه، گلوگاه از توانایی کدنویسی هوش مصنوعی به ظرفیت شناختی انسان تغییر کرد. کرس‌ول اشاره کرد که تنها هفت ماه پیش، آزمایش‌های او با «کدنویسی بر اساس حس» (Vibe Coding) نشان داد که عامل‌هایی که به حال خود رها شوند، تمایل به انحراف معماری (Architectural Drift)، تولید کدهای غیرضروری و ایجاد بدهی عملیاتی دارند. او در آن زمان نتیجه گرفت که نتایج به‌شدت به نحوه استفاده از عامل بستگی دارد؛ یک Claude که به‌طور دقیق محدود و نظارت شده باشد، می‌تواند نتایج بسیار خوبی را با سرعت زیاد تولید کند. این رویکرد نظارتی با استراتژی‌های انتخاب جریان کاری بر اساس پایداری همسو است که تفاوت میان دستیار ساده و عامل‌های مستقل را تبیین می‌کند.

با این حال، قابلیت‌های Opus 4.8 به‌طور چشمگیری رشد کرده است. او برای مقیاس‌پذیری کار، اجرای موازی را با چندین روش آزمایش کرد:

• جلسات متعدد Claude Code: اجرای هم‌زمان چندین نمونه از عامل.
• Git worktrees: اجازه دادن به هر عامل برای کار روی یک کپی ایزوله از کد.
• cmux: برای مدیریت راحت‌تر مجموعه‌ای از جلسات Claude.
• Claude Code Agent View: فراهم کردن راهی برای دیدن اینکه جلسات مختلف چه می‌کنند و کدام یک نیاز به توجه انسان دارند.

او دریافت که در حالی که ماشین می‌تواند تسک‌های موازی بی‌شماری را مدیریت کند، یک هماهنگ‌کننده انسانی معمولاً در ۳ تا ۵ تسک هم‌زمان به سقف توان خود می‌رسد. فراتر از این تعداد، توسعه‌دهنده بافت (Context) تصمیمات گرفته شده را گم می‌کند، نمی‌داند کدام تسک منتظر بازبینی است و چه چیزی باید در مرحله بعد مدیریت شود. در این نقطه، نه مدل و نه سخت‌افزار اشباع نشده‌اند، بلکه گلوگاه، ذهن انسان است که کار را هماهنگ می‌کند.

این تجربه نشان می‌دهد که مرز بعدی مهندسی هوش مصنوعی، نه لزوماً هوشمندی مدل، بلکه لایه‌های ارکستراسیون (Orchestration) است. مارکو، همکار کرس‌ول، در نوشته‌ای با عنوان My AI Engineering Journey پیشرفت مشابهی را توصیف کرد: حرکت از AI به‌عنوان «تکمیل خودکار» (Autocomplete) به «عامل‌های نظارت‌شده» و در نهایت به «عامل‌های موازی» جایی که بار شناختی محدودکننده می‌شود. مارکو در پاسخ به این مشکل، ابزاری به نام Otto ساخت؛ یک رابط کاربری ارکستراسیون حول Claude Code و worktrees، و سپس به سراغ خط لوله‌های عاملی (Agent Pipelines) رفت که پیاده‌سازی، بازبینی، بازخورد و مستندسازی را هماهنگ می‌کنند.

در نهایت، Yadda 3 نشان می‌دهد که BDD در دنیای عامل‌محور، تبدیل به یک «قرارداد» می‌شود. کرس‌ول استدلال می‌کند که BDD به سه دلیل اصلی ارزشمند است:

۱. ثبات دامنه (Domain Consistency): نوشتن نیازمندی‌ها به زبان معمولی، توسعه‌دهنده را مجبور به مفصل کردن دامنه می‌کند. این زبان سپس در نام کلاس‌ها، تعاریف API، شمای دیتابیس و کلاس‌های CSS منتشر می‌شود و انسجامی ایجاد می‌کند که دستی به دست آوردنش دشوار است.
۲. دسترسی‌پذیری (Accessibility): مشخصات اجرایی برای مدیران محصول یا تحلیل‌گران بسیار قابل‌فهم‌تر از یک تست Jest پر از Mockها و Assertionها است. یک متخصص دامنه به‌راحتی می‌تواند سناریویی را بفهمد که در آن «استیو برای دانشگاه درخواست می‌دهد و رد می‌شود».
۳. انتزاع (Abstraction): BDD لایه‌ای فراهم می‌کند که در آن مشخصات، «قصد» (Intent) را توصیف می‌کنند در حالی که پیاده‌سازی، «مکانیسم‌ها» (مانند سلکتورها و ناوبری) را مدیریت می‌کند. این مشابه الگوی Page Object است و تغییرات UI را بدون نشت به صدها تست، جذب می‌کند.

مشخصات اجرایی برای ماشین‌ها ارزشمندتر از انسان‌ها هستند چون بافت مستندی (Grounded Context) فراهم می‌کنند که یک ویکی استاتیک نمی‌تواند. یک ویکی می‌تواند بگوید کسی «فکر می‌کرد» سیستم باید چه کار کند، اما نمی‌تواند تأیید کند که سیستم «واقعاً» آن کار را انجام می‌دهد یا خیر. این اهمیتِ دقت در زبان، مشابه تأثیری است که استانداردهای نگارشی سخت‌گیرانه در صنایع حساس برای کاهش خطاهای مدل‌های زبانی ایجاد می‌کنند.

در یک جریان کاری نظری در آینده، متن جلسات به‌طور خودکار به‌عنوان GitHub Discussions ذخیره می‌شوند، سپس برای به‌روزرسانی ویکی پروژه تحلیل می‌شوند. این نیازمندی‌ها توسط عامل‌ها استخراج شده و به مشخصات BDD تبدیل می‌شوند. این مشخصات سپس به‌عنوان یک قرارداد الزام‌آور عمل می‌کنند:

• عامل‌های پیاده‌ساز از آن‌ها برای درک رفتار مورد نیاز استفاده می‌کنند.
• عامل‌های تست از آن‌ها برای تعیین معیارهای اعتبارسنجی استفاده می‌کنند.
• عامل‌های بازبین از آن‌ها برای به چالش کشیدن پیاده‌سازی استفاده می‌کنند.
• سیستم‌های CI به‌طور مداوم این قرارداد را تأیید می‌کنند.

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

برای ادغام بیشتر در اکوسیستم توسعه، Yadda v3.1.0 پشتیبانی از Markdown مدل GitHub را اضافه کرد. این به مشخصات ویژگی‌ها اجازه می‌دهد به‌طور طبیعی در کنار مستندات پروژه و سایر مصنوعات دانشی زندگی کنند. اکنون یک مشخصات را می‌توان به‌صورت زیر نوشت:

Feature: University applications

Scenario: Applicant does not meet the entry requirements

• The University of Bouvet Island offers a degree course in Computer Science
• The entry requirements for which are ABB
• Steve is an A-Level graduate
• With a D in Physics
• And a D in Maths
• When Steve applies to study Computer Science at The University of Bouvet Island
• They reject his application

این تغییر نشان می‌دهد که BDD، که در ابتدا برای دسترس‌پذیرتر کردن نرم‌افزار برای انسان‌ها طراحی شده بود، اکنون در حال تبدیل شدن به مکانیسم اصلی برای اطمینان از همسویی عامل‌های AI با رفتار سیستم است. Yadda 3 در npm در دسترس است و سورس کد، مستندات و مثال‌های آن در GitHub میزبانی می‌شود.

گام بعدی شما

• اگر پروژه قدیمی دارید، به‌جای بازنویسی دستی، ابتدا یک مجموعه تست جامع (Test Suite) بسازید تا بتوانید از عامل‌های هوش مصنوعی به‌عنوان نیروی اجرایی استفاده کنید.
• ابزارهای مدیریت موازی مانند Git worktrees را برای کاهش تداخل در زمان استفاده از چندین عامل بررسی کنید.
• متدولوژی BDD را نه فقط برای تست، بلکه به‌عنوان روشی برای نوشتن «قراردادهای عملیاتی» برای AI Agents به کار ببرید.

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