‏harness engineering: مهار کدی که هوش مصنوعی می‌نویسه

تو این مستند اومده که اصطلاح harness engineering از مقاله‌ی Birgitta Boeckeler روی martinfowler.com میاد. مشاهده‌ی اون ساده‌ست: دستیارهای هوش مصنوعی کد قابل‌قبول تحویل می‌دن، ولی اگه محدودشون نکنی کم‌کم دریفت می‌کنن، یعنی قراردادها یادشون می‌ره و انسجام داخلی کدبیس رو آروم آروم می‌خورن. چون کد همچنان کامپایل می‌شه و تست‌ها سبز می‌مونن، این خرابی دیده نمی‌شه. قیاس نویسنده اینه که تست harness هم کد رو درست نمی‌کنه، فقط لحظه‌ای که درست نیست رو لو می‌ده.

بخش اول context engineeringه: مطمئن شو مدل چیزی که باید بدونه رو می‌دونه. تو این پلاگین این کار با فایلی به اسم HARNESS.md انجام می‌شه که استک، تصمیم‌های معماری، قراردادهای نام‌گذاری، محدودیت‌ها و دلیل هرکدوم توش نوشته شده. نویسنده تأکید داره این سند README نیست؛ README می‌گه پروژه چی کار می‌کنه، ولی این یکی به agent می‌گه چی کار بکنه و چی کار نکنه.

بخش دوم architectural constraintsه، چون دونستن قانون با اجرا شدنش فرق داره و مدل یه سیستم احتمالاتیه که دنبال قابل‌قبول بودنه، نه پیروی از قانون. نویسنده به نقطه‌های اجرای این بررسی‌ها می‌گه verification slot: هر جا بشه قانون رو دقیق نوشت، ابزار قطعی مثل linter یا اسکریپت بهتره، و جایی که پای نیت و معنا وسطه، یه agent قضاوت می‌کنه. بخش سوم garbage collectionه که زمان‌بندی‌شده اجرا می‌شه و به‌جای بستن PR فقط گزارش می‌ده کجا کد مرده و TODO تلنبار شده.

نردبون progressive hardening می‌گه هر قید سه حالت داره: unverified یعنی قید رو نوشتی ولی هنوز راهی برای چک کردنش نداری، agent یعنی یه پرامپت داره چکش می‌کنه، و deterministic یعنی به اسکریپت یا رول linter تبدیل شده و تو CI جلوی merge رو می‌گیره. حرکت همیشه به سمت حالت قطعیه: وقتی یه agent مدام یه جور تخلف رو می‌گیره، یعنی اون الگو اونقدر شناخته شده که بشه خودکارش کرد.

پلاگین این بررسی‌ها رو تو سه حلقه چیده: حلقه‌ی داخلی موقع ادیت، سبک و فقط پیشنهاددهنده؛ حلقه‌ی میانی سر PR، سخت‌گیر و با اختیار بلاک کردن merge؛ و حلقه‌ی بیرونی زمان‌بندی‌شده که به‌جای بلاک، گزارش می‌ده. روش اینا یه لایه‌ی خودبهبودی هم اضافه شده: دستور /reflect بعد هر سشن یادگرفته‌ها رو ثبت می‌کنه، harness-audit تاریخچه‌ی تخلف‌ها رو می‌خونه و تکرارها رو علامت می‌زنه، و harness-init از روی خود کد قیدهای موجود رو حدس می‌زنه تا آدم فقط تأییدشون کنه.

نکات کلیدی:

• HARNESS.md علاوه بر خود قیدها، وضعیت هرکدوم رو هم نگه می‌داره: unverified، agent یا deterministic
• حرکت روی نردبون همیشه یه‌طرفه‌ست: از بررسی agentی به سمت بررسی قطعی و اجرا تو CI
• حلقه‌ی داخلی فقط هشدار می‌ده، حلقه‌ی میانی سر PR جلوی merge رو می‌گیره، حلقه‌ی بیرونی روی زمان‌بندی گزارش می‌ده
• هیچ agentی اجازه‌ی تغییر مستقیم کد پروداکشن یا merge نداره؛ تصمیم آخر با آدمه
• دستور /harness-sync اختلاف بین چیزی که سند ادعا کرده و وضعیت واقعی کدبیس رو تو یه جدول نشون می‌ده