‏وقتی spec خودش محصول می‌شه

Raunak Kathuria، معاون مهندسی Deriv، می‌گه بحث کدنویسی AI دیگه جای جالب ماجرا نیست: ایجنت‌ها کامپوننت می‌سازن، API پیاده می‌کنن، باگ فیکس می‌کنن، تست می‌نویسن و pull request باز می‌کنن. سؤال مهم اینه که وقتی تولید کد این‌قدر ارزون شد، چی گرون می‌مونه؟ جواب نویسنده «نیت» هست: این‌که دقیقاً چی می‌سازیم، برای کی، تحت چه محدودیت رگولاتوری، و کدوم قواعد کسب‌وکار غیرقابل‌تغییرن.

به گفتهٔ نویسنده گلوگاه واقعی تایپ کردن نیست، صفه: انتظار، هماهنگی، ابهام، ریویو، تحویل‌دهی و بازسازی کانتکست. یه فیچر از یه گفت‌وگو شروع می‌شه، تبدیل به تیکت می‌شه، یکی دیگه دیزاینش رو می‌کشه، و آخرش ریویوئر باید نیت اولیه رو از روی خودِ پیاده‌سازی حدس بزنه. مدل پیشنهادی این مسیر رو شبیه یه خط تولید خودکار می‌کنه: آدم تعریف و تأیید می‌کنه، سیستم پلن می‌ریزه، می‌سازه، وریفای و تست می‌کنه.

هستهٔ ماجرا یه product specification نسخه‌دار و زنده‌ست — یعنی سندی که بعد از شروع توسعه بایگانی نمی‌شه. هر فیچر به‌صورت یه delta بیان می‌شه: چی اضافه، تغییر یا حذف می‌شه، به‌علاوهٔ پروپوزال و دیزاین و تسک‌هاش؛ بعد از شیپ هم اون delta تو spec اصلی تا می‌خوره. چون delta یه پایهٔ مشخص داره، سیستم می‌تونه قبل از پیاده‌سازی وابستگی‌ها، سطوح تحت‌تأثیر، قواعد متناقض و شعاع تأثیر رو حساب کنه.

نکتهٔ ظریفش اینه که کدبیس تاریخچه‌ست، نه لزوماً نیت: کد قدیمی ممکنه تصمیم‌های منسوخ رو نگه داشته باشه یا دو پیاده‌سازی با هم تناقض داشته باشن، و مدل راهی نداره بفهمه کدوم معتبره. پس بزرگ‌ترین context window دنیا هم مسئلهٔ مرجعیت رو حل نمی‌کنه. تو معماری پیشنهادی، کار خودکار سه نقش داره: Planner که delta رو به تسک می‌شکنه، Builder که کد و PR می‌سازه، و Verifier مستقل که از روی خود spec بازسازی می‌کنه محصول باید چی کار کنه و با چیزی که ساخته شده مقایسه‌ش می‌کنه.

نویسنده فرق verification و تست رو هم پررنگ می‌کنه: تست می‌پرسه پیاده‌سازی طبق رفتار مورد انتظار کار می‌کنه یا نه، ولی verification می‌پرسه اصلاً چیز درستی ساخته شده یا نه. اگه Builder یه فلوی سه‌مرحله‌ای رو دومرحله‌ای بفهمه و تستش رو هم برای همون دومرحله‌ای بنویسه، تست‌ها پاس می‌شن و کاوریج هم عالیه، ولی محصول غلطه. آدم‌ها هم فقط دو گیت دارن: تأیید تغییر spec قبل از شروع، و تصمیم دیپلوی روی پروداکشن.

نکات کلیدی:

• هر فیچر یه delta روی یه product specification نسخه‌دار و زنده‌ست و بعد از شیپ توش ادغام می‌شه.
• زنجیرهٔ ردیابی: نیت محصول ← spec delta ← issue ← تسک‌ها ← pull requestها ← verification ← خروجی دیپلوی‌شده.
• Planner و Builder کانتکست کسب‌وکار رو شریکن ولی سشن مشترک ندارن، و Verifier فرضیات اون‌ها رو به ارث نمی‌بره.
• فقط دو گیت انسانی می‌مونه: تأیید تغییر spec قبل از پیاده‌سازی، و تصمیم دیپلوی پروداکشن.
• «کد دورریختنی» یعنی کد تنها نمایندهٔ ماندگار محصول نیست، نه این‌که کیفیت و معماری اهمیت نداره.