اگر یک AI agent هم پیاده‌سازی و هم testها را بنویسد، موفقیت testها فقط نشان می‌دهد این دو با هم سازگارند؛ نه اینکه الزاماً رفتار مورد نظر توسعه‌دهنده را بررسی می‌کنند. آموزش Real Python برای حفظ نقش توسعه‌دهنده در طراحی، گردش کاری مبتنی بر Test-driven development (TDD) پیشنهاد می‌کند: ابتدا رفتار مورد انتظار و test مشخص می‌شود و سپس agent پیاده‌سازی را می‌نویسد.
چرخه معمول TDD شامل نوشتن یک test ناموفق، نوشتن پیاده‌سازی برای موفق‌شدن آن و سپس Refactoring است. حضور AI agent این چرخه را تغییر نمی‌دهد، اما مسئولیت‌ها را تقسیم می‌کند: تصمیم‌های طراحی با توسعه‌دهنده است و agent پیش‌نویس‌ها را تهیه می‌کند.
گردش کار پیشنهادی پنج مرحله دارد. ابتدا توسعه‌دهنده Contract، یعنی تعهد رفتاری قابلیت، را تعریف می‌کند و نخستین test را دستی می‌نویسد. سپس agent با خواندن همین Contract و test اولیه، موردهای بیشتری به همان سبک می‌سازد. در مرحله سوم، توسعه‌دهنده testهای تولیدشده را با Contract تطبیق می‌دهد و حالت‌های مرزی جاافتاده را اضافه می‌کند. پس از آن، agent پیاده‌سازی را تا موفق‌شدن testها پیش می‌برد، در حالی که اجازه نوشتن در مسیر tests/ را ندارد. در پایان، توسعه‌دهنده تغییرات را بازبینی می‌کند و به قابلیت بعدی می‌رود.
نکته مهم، زمان تولید testهاست. در این روش، agent پیش از وجود پیاده‌سازی و با تکیه بر Contract و نمونه اولیه، test می‌نویسد. مقاله هشدار می‌دهد که درخواست test پس از آماده‌شدن پیاده‌سازی ممکن است به توصیف همان رفتار موجود، همراه با bugهایش، منجر شود.
تمرین آموزش، ساخت یک class به نام Version برای مقایسه نسخه‌های Python با عملگرهای < و > است. طبق قواعد نسخه‌بندی مطرح‌شده، 1.0.dev1 پیش از 1.0a1 و آن هم پیش از 1.0 قرار می‌گیرد. مقاله تأکید می‌کند که در محیط production معمولاً از packaging استفاده می‌شود؛ ساخت این نمونه برای تمرین یک Contract واقعی است.
پیش‌نیازها Python 3.11 یا جدیدتر، pytest و یک coding agent با دسترسی خواندن و نوشتن فایل‌های پروژه است. نمونه با Claude Code اجرا می‌شود، اما گردش کار به آن وابسته نیست؛ GitHub Copilot CLI، Antigravity CLI و OpenCode نیز به‌عنوان گزینه‌های دیگر معرفی شده‌اند.
