اگر امروز کدنویسی خود را به هوش مصنوعی سپردهاید، احتمالاً متوجه شدهاید که کدها در ابتدا درست به نظر میرسند اما بهمرور زمان، انسجام داخلی پروژه را میخورند. این فرسایش خاموش، خطرناکترین بخش همکاری با مدلهای زاینده است چون کد همچنان اجرا میشود، اما معماری سیستم را تخریب میکند.
برگیتا بوکلر (Birgitta Boeckeler) استدلال میکند که بدون وجود محدودیتهای سخت، دستیارهای هوش مصنوعی قراردادهای کدنویسی را فراموش کرده و اشتباهات را تکرار میکنند. نتیجه این است که کدها تستها را پاس میکنند، اما با هدف معماری پروژه در تضاد هستند. این تخریب به دلیل ماهیت آرامش، برای نگهداری بلندمدت سیستمها بهشدت خطرناک است.
همانطور که در تحلیل قبلی ما دربارهی شکست عاملهای هوش مصنوعی در مقیاس واقعی اشاره کردیم، راهکار این مشکل در پرامپتهای بهتر نیست، بلکه در ایجاد یک «هارنس» یا مهار ساختاری است. این رویکرد با مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — برخورد میکند؛ به این صورت که به جای اعتماد به مدل یا برنامهنویس، خروجی را بهطور مداوم با استانداردهای مشخص میسنجد.
یک هارنس درست، شبیه به سیستمهای تست خودکار عمل میکند؛ اما بهجای بررسی عملکرد (که آیا کد کار میکند یا نه)، بررسی میکند که آیا کد هنوز از تصمیمات معماری، قوانین نامگذاری، محدودیتهای امنیتی و قواعد ساختاری که تیم بر سر آنها توافق کرده است، پیروی میکند یا خیر. تستهای عملکردی ضروری هستند، اما برای حفظ سلامت کلی معماری کافی نیستند. در واقع، برای تضمین کیفیت، باید رویکرد تستها را از اعتبارسنجی صرف کد به سمت ارزیابی رفتار عاملها تغییر داد تا نقاط کور معماری شناسایی شوند. طبق گزارشی که در ۲۷ اوت ۲۰۲۶ در habitat-thinking.github.io منتشر شد، مهندسی هارنس از سه رکن اصلی برای مقابله با آنتروپی تشکیل شده است:
مهندسی زمینه (Context Engineering)
دستیارهای هوش مصنوعی فقط در محدوده دانستههایشان عمل میکنند. اگر مدل از یک کتابخانه خاص برای ثبت وقایع (Logging) یا ممنوعیت استفاده از متغیرهای سراسری تغییرپذیر (Mutable Global State) مطلع نباشد، راه خودش را اختراع میکند یا لایههای انتزاعی را دور میزند. برای مثال، اگر مدل نداند تمام نوشتنها در پایگاهداده باید حتماً از یک لایه انتزاعی خاص عبور کنند، برای راحتی کار و سرعت بیشتر، آن لایه را نادیده میگیرد.
مهندسی زمینه این مشکل را با ایجاد یک پایگاه دانش اختصاصی، مثلاً فایلی به نام HARNESS.md حل میکند. برخلاف فایلهای README که برای انسانهاست و هدف پروژه را میگوید، این سند مجموعهای از دستورات سختگیرانه برای عامل (Agent) است که دقیقاً میگوید چه کاری مجاز است و چه کاری ممنوع، و دلیل (Rationale) هر قانون چیست. این یک پایگاه دانش برای هوش مصنوعی است که باید دقیق، مشخص و بهروز نگه داشته شود.
محدودیتهای معماری (Architectural Constraints)
دانستن قوانین با اجرای آنها متفاوت است. چون مدلهای زبانی سیستمهایی احتمالی هستند و روی «محتملترین جواب» (Plausibility) بهینه شدهاند، حتی با وجود مستندات کامل، باز هم قوانین را نقض میکنند. مهندسی زمینه میزان تخلفات را کاهش میدهد، اما آنها را کاملاً حذف نمیکند.
برای توقف این روند، هارنس از «شکافهای تأیید» (Verification Slots) استفاده میکند؛ نقاط تعریفشدهای در جریان توسعه که در آن بررسیها اجرا شده و یا اجازه پیشروی میدهند یا مسیر را میبندند. این بررسیها به دو دسته تقسیم میشوند:
- ابزارهای قطعی (Deterministic Tools): ابزارهایی مثل Linterها، بررسیهای Regex، تأیید ساختار فایلها یا اسکریپتهایی که بدون قضاوت، جواب صفر و یکی (پاس یا فیل) میدهند. اینها سریع، ارزان و در محدوده مشخصات خود کاملاً قابل اعتماد هستند. هرگاه بتوان محدودیتی را بهصورت دقیق بیان کرد، این ابزارها ترجیح داده میشوند.
- بازبینیهای عاملمحور (Agent-Based Reviews): مدلهایی که کد را بر اساس الگوهای معنایی، قصد نویسنده یا محدودیتهایی میسنجند که اسکریپتها قادر به تشخیص آن نیستند. این روش گرانتر و کمتر قطعی است، اما خطاهایی را میبیند که هیچ قانون مکانیکی نمیتواند پیدا کند.
جمعآوری زباله (Garbage Collection)
کدهای برنامهنویسی سیستمهای زندهای هستند که در آنها آنتروپی فارغ از کیفیت اولیه، جمع میشود. کدهای مرده رشد میکنند، یادداشتهای TODO ماهها باقی میمانند، وابستگیها قدیمی میشوند و انتزاعهایی که زمانی منطقی بودند، تبدیل به مانع میشوند. قراردادهای اولیه اغلب زمانی که دشوار میشوند، بهطور خاموش کنار گذاشته میشوند.
در مهندسی هارنس، «جمعآوری زباله» (GC) یک فرآیند زمانبندی شده است. برخلاف بخشهای دیگر که هنگام تولید کد یا بازبینی فعال میشوند، GC بر اساس یک تایمر اجرا میشود چون عامل آن «گذشت زمان» است. این سیستم با استفاده از تعاریف صریح از اینکه «کد تمیز» چیست، عاملها یا اسکریپتها را به کار میگیرد تا مشکلات سیستمیک را قبل از بحرانی شدن گزارش کند. خروجی این مرحله، نه یک خطا برای متوقف کردن Pull Request، بلکه گزارشی است که توجه تیم را به انحرافات سیستمیک جلب میکند.
هارنس زنده و پلههای سختسازی
یک هارنس خوب ایستا نیست. چون کد تکامل مییابد و دستههای جدیدی از اشتباهات هوش مصنوعی ظاهر میشوند، هارنس باید خودارجاع باشد. فایل HARNESS.md فقط محدودیتها را توصیف نمیکند، بلکه وضعیت هر محدودیت را ردیابی میکند: آیا در حال حاضر تأیید نشده است، تحت بازبینی عامل است یا بهصورت قطعی اجرا میشود؟
این ساختار یک حلقه بازخورد ایجاد میکند که در آن سند هم به عنوان یک مشخصات (Specification) و هم به عنوان یک سابقه سلامت (Health Record) عمل میکند. یک عامل «ممیز هارنس» (Harness Auditor) که زمانبندی شده است، نتایج بررسیها را میخواند و وضعیتها را در HARNESS.md بهروز میکند تا با واقعیت مطابقت داشته باشد. این کار باعث میشود غفلت از هارنس بهجای نامرئی بودن، کاملاً نمایان شود. کاربران میتوانند دستور /harness-sync را اجرا کنند تا منطق تشخیص ممیز فعال شده و یک جدول انحراف (Drift Table) یکپارچه را ببینند که عدم تطابق بین هارنس اعلامشده و واقعیت را نشان میدهد.
این ساختار یک «نردبان سختسازی تدریجی» ایجاد میکند تا قوانین به بلوغ برسند. این نردبان یکی از محورهای بلوغ است، در حالی که «برد» (Reach) — یعنی اینکه آیا بررسی روی هر PR الزامی است یا «در صورت وجود تکمیل شود» — محور دیگر است. فیلد اجرا (Enforcement) برد را ثبت نمیکند:
۱. تأییدنشده (Unverified): قانون در سند ثبت شده است. تیم معتقد است این قانون مهم است، اما هنوز مکانیزمی برای چک کردن آن وجود ندارد. این یک حسابرسی صادقانه و تعهدی برای ساخت سیستم تأیید است.
۲. عاملمحور (Agent): یک پرامپت LLM در زمان بازبینی PR یا بازرسیهای زمانبندی شده، قانون را چک میکند. این روش اکثر خطاها را میگیرد اما نیاز به نظارت انسانی بر خروجی عامل دارد.
۳. قطعی (Deterministic): قانون به یک اسکریپت CI، قانون Linter یا بررسی ساختاری تبدیل شده است. اکنون این یک مانع سخت برای ادغام کد است و هیچ قضاوتی در آن دخیل نیست.
هدف نهایی همیشه رسیدن به حالت قطعی است. وقتی یک عامل بارها یک نوع خطای مشابه را میگیرد، یعنی آن الگو به اندازه کافی شناخته شده است تا اتوماتیک شود. این استراتژی از دو شکست احتمالی جلوگیری میکند: تلاش برای قطعی کردن همه چیز از ابتدا، و پذیرفتن بازبینیهای گران و غیرقطعی عاملمحور به عنوان یک وضعیت دائمی.
پیادهسازی در سه حلقه
برای اینکه سرعت توسعه کم نشود، این سیستم در سه بازه زمانی و با تلرانسهای مختلف برای مثبتهای کاذب (False Positives) اجرا میشود:
- حلقه داخلی (Inner Loop): بررسیهای مشورتی در لحظه ویرایش کد (مثلاً هنگام ذخیره فایل یا اتمام یک جلسه). اینها پیشنهاداتی ارائه میدهند بدون اینکه جریان کار را متوقف کنند و برای اصطکاک کم بهینه شدهاند تا هوش مصنوعی در لحظه مطلع بماند.
- حلقه میانی (Middle Loop): بررسیهای سختگیرانه در مرحله Pull Request. این حلقه اختیار دارد ادغام کد را متوقف کند و نقطه اصلی اجرای محدودیتهای معماری است. خطاها در اینجا باید قبل از ورود کد به شاخه اصلی حل شوند.
- حلقه خارجی (Outer Loop): بررسیهای تحقیقی زمانبندی شده (روزانه، هفتگی یا در صورت نیاز). این حلقه جمعآوری زباله، توابع تناسب (Fitness Functions) و ممیزی هارنس را مدیریت کرده و بهجای مسدود کردن، گزارش تولید میکند.
در این ساختار، عاملها با «اعتماد محدود» عمل میکنند. هیچ عاملی اجازه تغییر یکجانبه کد تولیدی یا ادغام تغییرات را ندارد؛ آنها فقط بازبینی، پیشنهاد و پرچمگذاری میکنند و تصمیم نهایی با انسان است. هارنس قضاوت انسانی را تقویت میکند، نه اینکه جایگزین آن شود.
ابعاد خودبهبودی
نسخههای مدرن هارنس از یک حلقه بازخورد استفاده میکنند که در آن هارنس از عملیات خود یاد میگیرد. با استفاده از دستور /reflect بعد از یک جلسه کدنویسی، سیستم ثبت میکند چه چیزی خوب پیش رفت، چه چیزی شکست خورد و چه الگوهای جدیدی ظاهر شد. این تاملات در یک «لاگ یادگیری» ذخیره میشوند که عاملها برای بازبینیهای آینده از آن استفاده میکنند.
تشخیص رگرسیون (Regression Detection) نیز در همین مسیر عمل میکند. عامل ممیز هارنس تاریخچه تخلفات را بررسی میکند تا الگوها را شناسایی کند. اگر محدودیتهای یکسانی مکرراً نقض شوند، این سیگنالی است که یا مکانیزم اجرا نیاز به تقویت دارد، یا دلیل قانون در سند زمینه نامشخص است، یا خود قانون اشتباه است.
علاوه بر این، فرآیند harness-init میتواند کدهای موجود را بخواند تا محدودیتهایی را که در حال حاضر وجود دارند اما اعلام نشدهاند، استخراج کند و فایل HARNESS.md را بر اساس الگوهای مشاهده شده بسازد. این فرآیند پذیرش تدریجی را ممکن میکند و به تیمها اجازه میدهد مهندسی زمینه، محدودیتها، جمعآوری زباله، CI و مشاهدهپذیری را یکییکی پیکربندی کنند در حالی که تنظیمات فعلی حفظ میشود. این یعنی یک تیم میتواند فقط با زمینه و محدودیتها شروع کند، ارزش آن را ثابت کند و سپس GC و اجرای CI را اضافه کند. این رویکرد در واقع گامی است به سوی جایگزینی عاملهای ساده با کارخانههای نرمافزاری که در آن کنترل دقیق بر خروجی، جایگزین امید به شانس میشود.
مبانی مفهومی
چارچوب این رویکرد بر پایه چندین فلسفه مهندسی کلیدی بنا شده است:
- مدل بوکلر: مرجع اصلی برای مدل سهجزئی و چارچوب «شکاف تأیید» از کارهای برگیتا بوکلر در martinfowler.com است.
- مهندسی هارنس عامل: تمایز بین مدل و هارنس، و همچنین انضباط «به دست آوردن هر خط کد» (Every line earned)، توسط کارهای ادی عثمانی (Addy Osmani) تقویت شده است.
- چارچوب دیاتاکسیس (Diataxis): ساختار مستندات و نحوه ارائه اطلاعات از دستورالعملهای diataxis.fr پیروی میکند.
این تغییر، فرض بنیادی توسعه با هوش مصنوعی را عوض میکند. ما از امید به اینکه مدل «خودبهخود درست بنویسد»، به سمتی میرویم که هارنس منبع حقیقت است و هوش مصنوعی صرفاً موتوری است که کاندیداهایی برای تأیید توسط هارنس تولید میکند.
برای توسعهدهندگان، این یعنی ارزش یک مهندس ارشد از «نوشتن کد» به «طراحی هارنسی» تغییر میکند که تضمین کند هوش مصنوعی کد را درست مینویسد.
گام بعدی شما
- ایجاد یک فایل
HARNESS.mdساده برای پروژهتان و ثبت سه قانون معماری که هوش مصنوعی مدام آنها را نقض میکند. - تبدیل یکی از بازبینیهای دستی تکراری در PRها به یک اسکریپت قطعی (Linter یا Regex).
- تعریف یک بازه زمانی ماهانه برای «جمعآوری زباله» و شناسایی کدهای مردهای که توسط AI تولید شدهاند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو