تصور کنید نمرهٔ پایان ترم شما توسط چهار حسابدار مختلف محاسبه شود که هر کدام فرمول خاص خود را دارند و هر کس هر چه خواست در پرونده‌تان می‌نویسد. این کابوس منطقی، واقعیتِ پشت‌پردهٔ اپلیکیشنی است که قرار بود با کمک هوش مصنوعی «سریع و بهینه» ساخته شود.
این وضعیت در ۱۳ سپتامبر ۲۰۲۶ توسط توسعه‌ده‌دهنده‌ای افشا شد که برای تبدیل یک نمونهٔ اولیه (Prototype) به محصول نهایی استخدام شده بود. این پلتفرم آموزشی با استفاده از Lovable، React/Vite و Supabase ساخته شده بود و در ظاهر کاملاً درست کار می‌کرد، اما در باطن فاقد هرگونه مستندات یا استدلال ساختاری بود.
این اتفاق نتیجهٔ رواج Vibe Coding (Vibe Coding) است؛ یعنی ساخت اپلیکیشن تنها از طریق پرامپت‌ها و بدون نظارت دستی روی کد. این روش شبیه ساخت خانه‌ای است که از بیرون عالی به نظر می‌رسد، اما در زیرزمین چهار سیستم لوله‌کشی مختلف دارند که همگی برای تخلیه در یک چاه مبارزه می‌کنند. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، سرعت در تولید کد نباید جایگزین دقت در معماری شود.
به گزارش وب‌سایت dev.to، بررسی‌های اولیه توسط یک عامل (Agent) — شبیه دستیاری هوشمند که می‌تواند به‌جای ما کدها را بخواند و تحلیل کند — ۳۱۹ مورد نقص را شناسایی کرد که ۲۹ مورد آن حفره‌های امنیتی بحرانی بودند. یکی از این نقص‌ها به هر دانشجویی اجازه می‌داد مدرسه خودش را بسازد و دسترسی مدیر (Admin) بگیرد.
اما فاجعهٔ اصلی در منطق نمره‌دهی بود:
- چهار موتور مجزا برای محاسبهٔ امتیاز روزانه دانشجویان فعال بودند.
- دو موتور از وزن‌های متضاد (۶۰/۴۰ در برابر ۴۰/۳۰/۳۰) برای یک امتیاز واحد استفاده می‌کردند.
- هر چهار موتور نتایج را در یک فیلد دیتابیس می‌نوشتند؛ یعنی نمرهٔ دانشجو بسته به اینکه کدام موتور آخرین بار اجرا شده بود، تغییر می‌کرد.
این وضعیت یک «شکست خاموش» ایجاد می‌کند. چون کد از نظر نحوی درست است و خطایی (Error) نمی‌دهد، کسب‌وکار با داده‌های غلط پیش می‌رود بدون اینکه متوجه شود. برای شما به عنوان کاربر یا مدیر محصول، این یعنی کدهای تولیدشده توسط هوش مصنوعی می‌توانند «خوانا» باشند اما از نظر منطقی کاملاً متناقض.
شرکت‌هایی که روی نمونه‌های اولیهٔ AI تکیه می‌کنند، اکنون باید پیش از مقیاس‌پذیری، ممیزی‌های سخت‌گیرانهٔ انسانی را اجرا کنند. باید منتظر ظهور ابزارهای ممیزی «AI-native» باشیم که بتوانند تضادهای منطقی را در ماژول‌های مختلف شناسایی کنند.
گام بعدی شما
- اگر از ابزارهای No-code AI استفاده می‌کنید، هرگز بدون ممیزی دستیِ منطق (Logic Audit) کدها را به محیط عملیاتی نبرید.
- برای پروژه‌های حساس، از مدل‌های استدلالی برای بررسی تضادهای احتمالی در توابع مختلف استفاده کنید.
- مستندات معماری را هم‌زمان با تولید کد توسط AI بخواهید تا از پراکندگی منطق جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو