تصور کنید برنامه‌نویسی هستید که وظیفه دارد یک اپلیکیشن تولیدشده توسط هوش مصنوعی را به سطح صنعتی (Production) برساند، اما در میانه راه متوجه می‌شوید کدی که به‌راحتی خوانده می‌شود، لزوماً منطقی قابل‌فهم ندارد. در گزارشی که در سپتامبر ۲۰۲۶ منتشر شد، ایو هابچی (Yves Habchy) جزئیات بازسازی یک پلتفرم آموزشی را شرح داد که با ابزار Lovable ساخته شده بود؛ جایی که کدها از نظر سینتکس و ساختاری بی‌نقص بودند، اما استدلال‌های تجاری (Business Reasoning) پشت آن‌ها کاملاً محو شده بود.
این پدیده همزمان با ظهور Vibe Coding رخ می‌دهد؛ تمرینی که در آن بنیان‌گذاران غیرفنی از عامل‌های هوش مصنوعی سطح بالا استفاده می‌کنند تا از طریق زبان طبیعی، اپلیکیشن‌های کاربردی بسازند. این رویکرد به یک میان‌بر تبدیل شده است. در حالی که این ابزارها می‌توانند به‌سرعت یک نمونه اولیه (Prototype) از محصول را خلق کنند، اما اغلب مستندات دقیق و قصد معماری (Architectural Intent) را که برنامه‌نویسان انسانی برای نگهداری نرم‌افزار در طول زمان به آن نیاز دارند، نادیده می‌گیرند. اپلیکیشن مورد بحث طی ۶ ماه ساخته شده بود و تیم هابچی تنها ۵ هفته فرصت داشت تا آن را برای تاریخ یک اجرای آزمایشی (Pilot) با ضرب‌الاجل ثابت، آماده کند.
فروپاشی زیرساختی
اولین چالش هابچی، به‌سادگیِ اجرای برنامه در محیط محلی بود. پروژه برای بخش بک‌اند و احراز هویت به Supabase و برای فرانت‌اند به React متکی بود. او با تاریخچه‌ای آشفته از ۱۳۲ فایل مهاجرت (Migration) مواجه شد که بسیاری از آن‌ها متناقض یا خراب بودند.
- تداخل افزونه‌ها: دومین مهاجرت به‌دلیل فراخوانی تابعی از یک افزونه (Extension) که نصب نشده بود، شکست خورد. پس از نصب افزونه، مهاجرت سی و پنجم شکست خورد؛ زیرا برخی مهاجرت‌های قبلی از یک پیشوند طرح‌واره (Schema Prefix) برای آن تابع استفاده کرده بودند و برخی دیگر نه. هیچ مکان نصبی وجود نداشت که هر دو حالت را ارضا کند. حل این مشکل، یک تغییر دو خطی شامل جابجایی افزونه و گسترش مسیر جستجوی پایگاه داده بود که تقریباً کل بعدازظهر را گرفت.
- جداول شبح: یک مهاجرت سعی داشت سیاست دسترسی (Access Policy) را از جدولی حذف کند که هیچ‌گاه در هیچ‌کدام از مراحل مهاجرت ساخته نشده بود. این جدول نه در فایل‌های خروجی (Export) وجود داشت و نه در محیط عملیاتی (Production).
- خطاهای تریگر: مهاجرتی سعی داشت تریگری (Trigger) بسازد که یک مهاجرت قبلی پیش‌تر ایجاد کرده بود. از آنجایی که Postgres عبارت 'if-not-exists' برای تریگرها ندارد، تلاش دوم صرفاً با خطا مواجه شد.
پس از برقراری طرح‌واره، برنامه همچنان خراب بود. ۶۶ جدول از ۷۰ جدول موجود، هیچ دسترسی برای نقش‌های اپلیکیشن نداشتند و هر درخواست با خطای «عدم دسترسی» (Permission Denied) مواجه می‌شد. این دسترسی‌ها در طول ۶ ماه ساخت به‌صورت دستی و خاموش اعمال شده بودند و هیچ ردی از مدل امنیتی در کدها وجود نداشت تا مشخص شود مدل امنیتی در واقع چگونه پیکربندی شده است.
شکاف در حسابرسی امنیتی
برای ارزیابی ریسک، هابچی از یک فرآیند حسابرسی دو مرحله‌ای با استفاده از هوش مصنوعی استفاده کرد. در مرحله اول، یک بررسی سریع توسط یک عامل (Agent) ساده، ۱۰۸ مورد را شناسایی کرد که ۲۳ مورد آن آسیب‌پذیری‌های بحرانی بودند. این موارد شامل موارد زیر بود:
- یک نقطه اتصال (Endpoint) برای تنظیمات که یک مدیر پلتفرم می‌ساخت و رمز عبور را برمی‌گرداند، در حالی که قبل از آن هیچ بررسی احرازی یا محدودیت تعداد درخواست (Rate Limiter) وجود نداشت.
- یک نقطه اتصال گزارشات بدون احراز هویت که اگر کاربر شناسه دانش‌آموز را می‌دانست، نمرات روزانه کودک و خلاصه مربوط به والدین را تحویل می‌داد.
- تابعی برای حذف کل یک مدرسه که تنها با یک هدر مجوز (Authorization Header) محافظت می‌شد؛ هدرى که کلید ناشناس (Anonymous Key) موجود در بسته مرورگر (Browser Bundle) آن را برآورده می‌کرد.
سپس او یک سیستم «هماهنگ‌کننده» (Orchestrator) دقیق‌تر به کار گرفت. این سیستم کدها را به کوچک‌ترین واحدهای قابل بررسی تقسیم کرد و آن‌ها را به‌طور موازی و کورکورانه به دو مدل پیشرو (Frontier Models) مختلف فرستاد، به‌طوری که مدل‌ها از وجود یکدیگر بی‌خبر بودند. اگر مدل‌ها اختلاف نظر داشتند یا رتبه‌بندی متفاوتی برای یک یافته قائل می‌شدند، دور دوم آغاز می‌شد؛ در این مرحله یافته‌های هر مدل به دیگری نشان داده می‌شد تا با ارائه شواهد، تایید، اصلاح یا رد کنند. هر موردی که پس از سه دور همچنان مورد مناقشه بود، به هماهنگ‌کننده ارجاع می‌شد تا بر اساس خطوط کد ذکر شده تصمیم نهایی را بگیرد. این فرآیند جامع، صحت کد، امنیت و آمادگی برای محیط عملیاتی را پوشش می‌داد.
این فرآیند سنگین ۳۱۹ مورد را کشف کرد، از جمله ۱۸ مورد بحرانی که در دور اول دیده نشده بود. یک نقص بزرگ به مدیران مدارس اجازه می‌داد خود را به مدیر کل پلتفرم (Superadmin) ارتقا دهند، زیرا سیاست امنیتی چک می‌کرد کاربر کیست، اما هرگز چک نمی‌کرد که کاربر اجازه دارد به چه جایگاهی تبدیل شود. حتی پس از این‌ها، تست‌های دستی نشان داد هر کاربر وارد شده — حتی یک دانش‌آموز — می‌تواند یک مدرسه بسازد و خودش را مدیر آن کند.
خلأ استدلال
فراتر از امنیت، هابچی با «ویژگی‌های شبح» مواجه شد؛ توابعی کاملاً متصل و سیم‌کشی شده که از هیچ‌جای برنامه فراخوانی نمی‌شدند. یکی از این توابع یادداشت‌های تایپ شده معلم را به یک مدل زبانی می‌فرستاد تا تشخیص دهد چه کسی غایب است. این تابع کاملاً ساخته شده، بررسی دسترسی‌اش انجام شده و به یک حساب پولی AI متصل بود، اما در رابط کاربری هیچ کاربردی نداشت. هابچی مجبور شد در طول مرحله امنیتی، این تابع را طوری مقاوم‌سازی کند که انگار یک تابع فعال است، در حالی که نمی‌دانست آیا این ویژگی بازنشسته شده یا هرگز به رابط کاربری متصل نشده است.
او همچنین صفحه‌ای یافت که معلمان داده‌ها را ردی به ردی وارد می‌کردند. یک کامنت در کد اشاره کرده بود که کنترل دسته‌جمعی (Bulk Control) به‌دلیل ایجاد خطا حذف شده است، اما هیچ مستندی درباره ماهیت این خطا در جای دیگری وجود نداشت. این یعنی برنامه‌نویس نمی‌توانست بفهمد خطا چه بود یا آیا هنوز وجود دارد یا خیر.
بحرانی‌ترین شکست در منطق امتیازدهی بود. اپلیکیشن نمره روزانه دانش‌آموزان را بر اساس تلاش (Effort) به جای نتایج آزمون محاسبه می‌کند و این نمره به عنوان یک رتبه حروفی به والدین گزارش می‌شود. این عدد، محصول اصلی است که مدارس برای آن پول می‌پردازند. با این حال، چهار محاسبه‌گر مختلف — روزانه، هفتگی، کلی و دسته‌ای — همگی در یک فیلد از یک ردیف می‌نوشتند و هر کدام که آخر اجرا می‌شد، برنده می‌شد و مقدار قبلی را پاک می‌کرد.
این محاسبه‌گرها با هم توافق نداشتند:
- محاسبه‌گرهای روزانه و هفتگی امتیاز را از اهداف تکمیل‌شده (Goals Completed) استخراج می‌کردند.
- محاسبه‌گرهای کلی و دسته‌ای ترکیبی از تلاش، تسلط (Mastery) و قابلیت اطمینان را در بازه‌های غلتان دو هفته‌ای و یک ماهه می‌سنجیدند.
- وزن‌دهی در محاسبه‌گر کلی ۶۰/۴۰ بود، اما در محاسبه‌گر دسته‌ای ۴۰/۳۰/۳۰ بود.
- مرزهای نمرات حروفی در ۵ جای مختلف از کد نوشته شده بود.
- محاسبه‌گر روزانه از یک برچسب نسخه (Version Label) برای خروجی خود استفاده می‌کرد، در حالی که دو محاسبه‌گر دیگر از برچسب متفاوتی استفاده می‌کردند.
هزینه استنتاج
هابچی تابعی برای پاک‌سازی رکوردهای «شهروندی» (Citizenship) یافت. تابع رکوردها را بر اساس دانش‌آموز و روز گروه‌بندی می‌کرد، اولین برچسب را مقایسه می‌کرد و بقیه را حذف می‌کرد؛ به این معنی که می‌توانست رکوردهایی را حذف کند که واقعاً تکراری نبودند. او می‌توانست کد را از ابتدا تا انتها بخواند، اما کلمه «شهروندی» در هیچ‌کدام از مستندات، طرح‌واره‌ها یا توضیحات محصول مشتری تعریف نشده بود.
او مجبور شد معنای آن را از روی ردیف‌های داده استنتاج (Inference) کند. داده‌ها شامل برچسب‌هایی مثل «اخطار»، «درخواست خروج» و «امتیازات شخصیتی» بود. به نظر می‌رسید این‌ها یادداشت‌های رفتاری ثبت شده توسط معلم هستند که چند امتیاز در نمره روزانه دانش‌آموز دارند. او در نهایت تغییرات را اعمال کرد بدون اینکه هرگز مطمئن شود «شهروندی» در بستر تجاری این برنامه دقیقاً چه معنایی دارد.
این یک شکل جدید از بدهی فنی است. در نرم‌افزارهای سنتی، بدهی اغلب به معنای کد کثیف و نامرتب است. در نرم‌افزارهای Vibe-Coded، کد تمیز است اما «چرایی» (Why) گم شده است. برنامه‌نویس باید قوانین تجاری را حدس بزند و هر حدس غلط، نتیجه را برای کاربر نهایی — در اینجا نمره یک کودک — تغییر می‌دهد. از آنجایی که تست‌های نرم‌افزاری صرفاً هر پاسخی را که برنامه‌نویس حدس زده بود کدگذاری می‌کردند، هیچ راهی برای خروج از این مشکل از طریق تست وجود نداشت.
برای مالکان کسب‌وکار، سرعت تولید AI یک وام با نرخ بهره بسیار بالاست. لحظه‌ای که یک انسان بخواهد منطق را تغییر دهد یا سیستم را مقیاس‌پذیر کند، باید «مالیات استدلال» (Reasoning Tax) را بپردازد و توهمات مدل درباره منطق تجاری را مهندسی معکوس کند. برای جلوگیری از این وضعیت، تیم‌ها باید از عامل‌های AI بخواهند که در کنار کد، یک «دفترچه تصمیمات» (Decision Log) ایجاد کنند. این دفترچه باید نه فقط «چه چیزی» تغییر کرده، بلکه «چرا» یک مسیر منطقی خاص نسبت به مسیر دیگر انتخاب شده است را ثبت کند تا استدلال‌ها در هنگام انتقال پروژه از عامل هوش مصنوعی به انسان باقی بمانند.
گام بعدی شما
- از عامل‌های AI بخواهید در کنار کد، یک «دفترچه تصمیمات» (Decision Log) ایجاد کنند که نه فقط «چه چیزی»، بلکه «چرا» یک مسیر منطقی انتخاب شده را ثبت کند.
- برای اپلیکیشن‌های تولیدشده توسط AI، حسابرسی‌های امنیتی را به‌جای یک دور، در قالب سیستم‌های هماهنگ‌کننده (Orchestrator) با مدل‌های متضاد اجرا کنید.
- هرگز بر اساس «خوانایی کد» در ابزارهای No-code/AI قضاوت نکنید؛ منطق تجاری را در مستندات جداگانه اعتبارسنجی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو