اگر تصور کنید عامل‌های هوش مصنوعی می‌توانند استانداردهای طراحی شما را دقیقاً اجرا کنند، باید در محاسبات خود تجدیدنظر کنید. یک پروژه واقعی نشان داد که مدل‌های پیشرفته حتی با وجود دستورالعمل‌های صریح، تمایل دارند قوانین کلی را به نفع تصمیمات لحظه‌ای نادیده بگیرند.
طبق گزارشی که در ۲۱ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک توسعه‌دهنده در کدهای تولیدشده توسط Claude Code، تعداد ۷۹۹ مورد اندازه فونت سخت‌افزاری (Hardcoded) پیدا کرد؛ آن هم در حالی که پروژه دارای یک مقیاس طراحی مستند بود. این کشف، شکاف عمیقی را در نحوه مدیریت سازگاری جهانی توسط عامل‌ها (Agents) — یعنی سیستم‌های هوشی که می‌توانند به‌صورت مستقل کد بنويسند و اجرا کنند — نشان می‌دهد. این چالش با نگاهی به جایگاه مدل‌های زبانی در سطح تکمیل‌کننده کد روشن‌تر می‌شود، جایی که این ابزارها بیشتر شبیه به مهندسان جونیور عمل می‌کنند تا معماران سیستم.
در توسعه مدرن فرانت-اند، از «توکن‌های طراحی» برای حفظ انسجام بصری استفاده می‌شود. به جای نوشتن 13px در تمام صفحات، برنامه‌نویسان از توکن‌هایی مانند text-di-body استفاده می‌کنند. این رویکرد اجازه می‌دهد تغییرات به‌صورت سراسری اعمال شود و از ظاهر «ناپایدار» یا «ناآرام» رابط کاربری جلوگیری کند؛ وضعیتی که در آن برچسب‌های زمانی و عناوین در صفحات مختلف، تنها یک پیکسل با هم تفاوت دارند و این امر باعث کاهش کیفیت بصری محصول می‌شود.
پروژه مورد بحث، یک مولد ETL به نام DI² است که با استفاده از Next.js و PostgreSQL ساخته شده است. این پروژه به‌خوبی شکاف موجود بین دستورات مبتنی بر پرامپت و اجرای سیستماتیک قوانین را به تصویر می‌کشد. توسعه‌دهنده خاطرنشان کرد که در حالی که یک مقیاس شش-توکنه در تنظیمات پیکربندی تعریف شده بود، مدل در حدود ۱٬۱۸۰ مورد این مقیاس را دور زده و از آن استفاده نکرده است.
بر اساس بررسی‌های صورت‌گرفته در ۲۵ ژوئن ۲۰۲۶ روی تمامی فایل‌های src/**/*.tsx، یک سلسله‌مراتب سه-سطحی از خطاها شناسایی شد:
- پیکسل‌های خام: ۷۹۹ مورد مقدار دلخواه مثل
text-[13px]که در ۷۴ فایل پخش شده بود و شامل ۲۵ مقدار پیکسلی متمایز می‌شد. - پیش‌فرض‌های فریم‌ورک: ۳۸۳ مورد استفاده از مقادیر پیش‌فرض Tailwind CSS (مانند
text-sm) که مستقیماً با مقیاس سفارشی پروژه در تضاد بود. - توکن‌های استاندارد: تنها ۲۶۳ مورد از توکن‌های موردنظر
text-di-*استفاده شده بود.
این آمار به این معناست که قراردادهای تعیین‌شده با نسبت تقریبی ۱ به ۴.۵ نادیده گرفته شده‌اند. تکان‌دهنده آنکه در بازبینی مجددی که سه هفته بعد انجام شد، تعداد پیکسل‌های خام از ۷۹۹ به ۸۱۳ رسید. این موضوع ثابت می‌کند «رانش کد» (Drift) حتی در زمانی که برنامه‌ریز در حال برنامه‌ریزی برای پاک‌سازی است، شتاب می‌گیرد.
چرا عامل‌های هوش مصنوعی در آزمون سازگاری شکست می‌خورند؟ گزارش مذکور توضیح می‌دهد که یک تعریف مانند text-[12px] در یک تغییر کد (Git Diff) منفرد، «غلط» نیست؛ زیرا به درستی رندر می‌شود و تست‌های منطقی را پاس می‌کند. از آنجا که این خطا «بین» فایل‌ها رخ می‌دهد و نه «داخل» یک فایل واحد، هیچ بازبین انسانی یا تست رگرسیون بصری متوجه آن نمی‌شود.
عامل‌ها بر اساس اصل «معقول بودن محلی» عمل می‌کنند. در حالی که یک انسان قانون طراحی را از طریق حافظه عضلانی به یاد می‌آورد، یک مدل هوش مصنوعی در هر هفته صدها تصمیم مستقل می‌گیرد. هر بار که مدل تصمیم می‌گیرد 12px برای یک برچسب زمانی «منطقی» یا «مناسب» به نظر برسد، از توکن جهانی فاصله می‌گیرد.
اینجاست که توهم «پرامپت بهتر» شکست می‌خورد. افزایش اصرار در پرامپت‌ها مشکل را حل نمی‌کند. مدل‌های زبانی روی داده‌های عظیم عمومی آموزش دیده‌اند که در آن‌ها text-sm یا text-[12px] رایج‌ترین الگوها برای متون کوچک هستند. یک قانون خاص در فایل CLAUDE.md تنها یک نقطه داده است که باید با وزن آماری میلیون‌ها مثال دیگر رقابت کند.
در حجم بالای تولید کد، هر نرخ توفیقی کمتر از ۱۰۰٪، تضمین‌کننده رانش اندازه‌گیری شده است. قوانین متنی می‌توانند نرخ موفقیت را بالا ببرند، اما نمی‌توانند خطاهای باقی‌مانده‌ای را که در نهایت به یک رابط کاربری تکه‌تکه و ناسازگار منجر می‌شوند، حذف کنند. این عدم دقت در اجرای استانداردها می‌تواند فراتر از مسائل بصری باشد؛ چنان‌که گزارش Veracode نشان می‌دهد بخش قابل توجهی از کدهای تولیدشده توسط هوش مصنوعی دارای آسیب‌پذیری‌های امنیتی هستند.
برای متوقف کردن این رانش، توسعه‌دهنده یک راهکار سیستماتیک سه‌گانه اجرا کرد:
۱. مقیاس سخت‌گیرانه: تعریف یک مقیاس شش-مرحله‌ای ثابت (از ۱۸ پیکسلی di-h1 تا ۱۰ پیکسلی di-label) در فایل tailwind.config.ts به عنوان تنها منبع حقیقت.
۲. نگاشت دسته‌بندی: ایجاد یک فایل قوانین که المان‌ها را به توکن‌ها وصل می‌کند (مثلاً برچسب‌های زمانی همیشه باید di-meta باشند) تا هرگونه قضاوت ذهنی مدل حذف شود.
۳. قانون جذب (Snap Rule): یک مهاجرت مبتنی بر منطق که در آن تمام مقادیر میانی (مثل ۱۱ یا ۱۲ پیکسل) ابتدا بر اساس نقش المان و سپس بر اساس نزدیکی عددی، به نزدیک‌ترین توکن «می‌چسبند».
مرحله نهایی و حیاتی، تبدیل «هشدارها» به «خطاها» بود. یک قانون سفارشی در ESLint تعریف شد تا هرگونه استفاده از اندازه پیکسلی خام یا اندازه پیش‌فرض Tailwind را در محدوده اپلیکیشن شناسایی و علامت‌گذاری کند.
برخلاف هشدار که ممکن است توسط توسعه‌دهنده یا عامل نادیده گرفته شود، یک بررسی در سطح error باعث توقف بیلد (Build) می‌شود. این امر عامل هوش مصنوعی را مجبور می‌کند تا ناسازگاری را فوراً برطرف کند. لینتر به‌گونه‌ای پیکربندی شد که دقیقاً نام توکن جایگزین موردنظر را در پیام خطا ذکر کند تا اصلاح برای عامل در لحظه عملیاتی و ممکن شود.
این الگو فقط محدود به CSS نیست. نویسنده اشاره می‌کند که رانشی مشابه در توسعه SQL نیز رخ می‌دهد؛ جایی که عامل‌ها ممکن است قراردادهای نام‌گذاری جداول یا رویه‌های (Procedures) پایگاه‌داده را به نفع الگوهای آماری رایج‌تر در کدهای عمومی دنیا رها کنند.
نتیجه نهایی برای توسعه‌دهندگان روشن است: هوش مصنوعی سرعت توسعه را بالا می‌برد، اما هم‌زمان سرعت انباشت بدهی فنی (Technical Debt) را نیز افزایش می‌دهد. آنچه یک تیم انسانی ممکن است در دو سال رشد جمع کند، یک عامل هوش مصنوعی می‌تواند در یک فصل تولید کند.
گام بعدی شما
- اگر در حال مقیاس‌دهی به یک کدبیس با کمک هوش مصنوعی هستید، همین امروز با ابزار
ripgrepتوکن‌های طراحی خود را بازرسی کنید تا ببینید آیا مدل‌ها در پشت صحنه مقیاس‌های مخفی خودشان را ابداع کرده‌اند یا خیر. - به جای تکیه بر پرامپت‌های طولانی برای حفظ استانداردهای بصری، قوانین خود را به سطح Linter منتقل کنید تا خطاها متوقف شوند.
- اثرات این رانش را در لایه‌های دیگر مثل نام‌گذاری پایگاه‌داده بررسی کنید.
اما این تنها بخشی از چالش‌های ادغام است؛ بررسی اینکه چگونه مدل‌های استدلالی جدید می‌توانند این رانش را پیش‌بینی کنند، در گزارش بعدی ما خواهد بود.
گفتگو