تصور کنید یک توسعهدهنده مستقل (Indie Hacker) برای صرفهجویی در هزینه، از یک ترکیب ساده شامل SQLite، یک کرونجاب (cron job) و کمی صبر استفاده میکند، اما عامل کدنویس او تا ساعت ۱۱ شب، نیمی از مسیر پرداخت را بازنویسی میکند تا Redis، وبهوکهای Stripe و یک Worker برای صف (Queue Worker) را به پروژه اضافه کند. این وضعیت یک تنش و مشکل رو به رشد را نشان میدهد: مدلهای هوش مصنوعی تمایل دارند سکوتِ مستندات را با حدسهای زیرساختی محبوب اما گرانقیمت پر کنند که معمولاً حول محور کشها، صفها و APIهای پولی میچرخند.
برای کسانی که سرعت را پاداش اصلی میدانند، سرعت بدون حصار منجر به نشت مالی فوری میشود. طبق گزارشهای منتشر شده، اکثر عاملهای کدنویس مانند «پیمانکاران تازهکار» عمل میکنند؛ آنها رایجترین الگوهای صنعتی را پیاده میکنند بدون اینکه بررسی کنند آیا بودجه پروژه اجازه چنین هزینهای را میدهد یا خیر. صورتحساب این سرویسهای «ابداعی» پس از ادغام کد (Merge) میرسد، نه پیش از آن. این وضعیت شبیه به گذاشتن یک فرم سفارش خرید خالی در کف انبار است؛ هر کسی میتواند لیفتراک سفارش دهد اگر فرم خالی بماند. این چالش مدیریت هزینهها در مقیاس کوچک، یادآور تلاشهای مشابه برای بهینهسازی بودجه در کسبوکارهای خرد است، مشابه آنچه در کاهش هزینههای تولید کیت تبلیغاتی برای کسبوکارهای کوچک مشاهده کردیم.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کنترل دسترسیها کلید پایداری است. برای حل این مشکل، مکانیسم جدیدی به نام «سیستم منشور» (Charter System) معرفی شده است. در این رویکرد، عامل هوش مصنوعی مانند پیمانکاری است که باید پیش از نوشتن حتی یک خط کد، تمام فرضیات زیرساختی خود را در یک دفتر ثبت (Ledger) لیست کند. یک فرم پر شده باعث میشود اقلام گرانقیمت در همان ابتدا دیده شوند. اگر حدسی با منشور مطابقت نداشته باشد، کد مسدود میشود، نه دست توسعهدهنده.
مکانیسم منشور و دفتر ثبت
هسته این سیستم یک فایل به نام charter.json است. این فایل مانند یک سند سیاستی خشک اما سختگیرانه عمل میکند که مرزهای پروژه را تعریف میکند. استفاده از فایلهای سیاستی ساده به این دلیل است که اینها در برابر خستگی شبهای جمعه دوام میآورند، در حالی که موتورهای سیاستی پرزرقوبرق معمولاً شکست میخورند.
این منشور شامل محدودیتهای بسیار مشخصی است:
- allowed_deps: فهرستی سختگیرانه از کتابخانههای مجاز (مثلاً
flaskیاsqlite3). - forbidden_substrings: لیست سیاهی از توکنهای گرانقیمت مانند
stripe،redis،sqs،rds،openaiیاmongodb+srv. - max_files_touched: محدودیتی (مثلاً ۶ فایل) برای جلوگیری از اینکه عامل در یک مرحله کل معماری پروژه را دگرگون کند.
- allowed_paths: دایرکتوریهای خاصی که عامل اجازه تغییر آنها را دارد، مانند
app.py،templates/**،static/**وlib/**. - allowed_env: متغیرهای محیطی مجاز مانند
DATABASE_PATHوPUBLIC_BASE_URL.
بر اساس مستندات این روش، عامل پیش از تولید تغییرات (Diff)، باید یک فایل assumption_ledger.json تولید کند. این دفتر ثبت از فرمت JSON استفاده میکند و برای هر حدس، یک شیء میسازد. مدل باید هر ادعای زیرساختی را در دو دسته «تأیید شده» (verified) یا «مسدود شده» (blocked) قرار دهد.
برای مثال، یک دفتر ثبت ممکن است حاوی این ادعای تأیید شده باشد که «بخش پرداخت میتواند سبدهای خرید را در SQLite محلی ذخیره کند»، زیرا app.py از قبل DATABASE_PATH را باز کرده است. در مقابل، ادعایی مبنی بر اینکه «شارژ کارتها به یک Worker برای وبهوک Stripe نیاز دارد»، به دلیل ممنوعیت Stripe در منشور، «مسدود» میشود. این مسدود شدن یک ویژگی است، نه شکست؛ زیرا وسوسه مدل را با زبان ساده ثبت میکند تا توسعهدهنده بعداً آگاهانه هزینه آن را بپذیرد.
اجرای خودکار و نظارت
برای اینکه عامل نتواند صورتحسابها را بهصورت پنهانی در کد جای دهد (Smuggle)، یک اسکریپت بازبینی با زبان پایتون به کار گرفته میشود. این اسکریپت برای حفظ سادگی، تنها از کتابخانههای استاندارد پایتون برای خواندن منشور، دفتر ثبت و تغییرات کد استفاده میکند.
پرامپت داده شده به عامل کوتاه و سختگیرانه است و کدنویسی را تا زمان اعتبارسنجی دفتر ثبت ممنوع میکند. به عامل گفته میشود: «پیش از ابداع زیرساخت، charter.json را بخوان. ابتدا assumption_ledger.json و سپس unified diff را خروجی بده. هیچ وابستگی خارج از allowed_deps اضافه نکن».
این اسکریپت بازبینی، اعتبارسنجیهای بسیار دقیقی انجام میدهد:
- اعتبارسنجی مسیر: بررسی میکند که تعداد فایلهای تغییر یافته از
max_files_touchedبیشتر نشود و اطمینان حاصل میکند تمام مسیرها با الگوهای (globs) موجود درallowed_pathsمطابقت دارند. - همگامسازی دفتر: تأیید میکند فایلهای لیست شده در دفتر ثبت دقیقاً با فایلهای موجود در Diff یکی باشند.
- بررسی وابستگیها: اطمینان حاصل میکند هرگونه
new_depsدر لیستallowed_depsباشند و تمام Importها را برای یافتن موارد غیرمجاز اسکن میکند (به جز کتابخانههای استاندارد مانندjson،os،re،sys،pathlibوtyping). - اسکن توکنها: خطوط اضافه شده در Diff را برای یافتن هر یک از
forbidden_substringsجستوجو میکند. - تأیید منطق: بررسی میکند که هر فرض «تأیید شده» شواهد همراه داشته باشد و هیچ ادعای «مسدود شدهای» در کد نهایی نفوذ نکرده باشد.
اگر اسکریپت تخلفی پیدا کند، با وضعیت غیرصفر (non-zero status) خارج میشود. توسعهدهنده میتواند کارایی این بازبین را با تست دو Diff بسنجد: یکی که در محدوده SQLite میماند (که پیام charter ok چاپ میکند) و دیگری که سعی میکند یک Import مربوط به Stripe را در lib/cart.py بگنجاند (که با کد ۱ خارج شده و به stripe اشاره میکند).
مقیاسپذیری با دروازه بازبینی
برای توسعهدهندگانی که میخواهند این روند را خودکارتر کنند، این بازبین میتواند روی یک سرور کوچک و رایگان میزبانی شود. در این حالت، توسعهدهنده میتواند یک Payload حاوی دفتر ثبت و Diff را از طریق یک فراخوانی curl به نقطه پایانی /check ارسال کند.
اگر سرور خطای ۴۲۲ برگرداند، تغییرات رد میشود. این یک «دروازه بازبینی» (Review Gate) ایجاد میکند که به برنامهنویس اجازه میدهد بدون نگرانی از اینکه مدل در پسزمینه در حال سفارش «لیفتراکهای دیجیتال» است، از صفحه نمایش فاصله بگیرد و لپتاپ خود را ببندد.
برخی توسعهدهندگان این بازبین را در کنار مدلهای رایگان کدنویسی قرار میدهند. برای مثال، MonkeyCode دسترسی رایگان به مدل و یک گزینه سرور رایگان را برای پشتیبانی از این چرخه فراهم میکند. در این ساختار، مدل پیشنویس دفتر ثبت و Diff را تهیه میکند، در حالی که سرور صرفاً آنها را بر اساس منشور امتیازدهی میکند.
محدودیتها و موازنه ها
این روش عمداً سطحی طراحی شده است و جایگزین بازبینیهای امنیتی حرفهای نمیشود. نویسنده به چند نقطه ضعف بحرانی اشاره میکند:
- پولشویی توکنها (Token Laundering): یک مدل مصمم میتواند با تغییر نام Importها یا استفاده از URLهای کدگذاری شده برای پنهان کردن یک سرویس، محدودیتهای متنی را دور بزند.
- شواهد جعلی: وضعیت «تأیید شده» در دفتر ثبت بر اساس متن تولید شده توسط خود مدل است، نه بر اساس اجرای واقعی، تستهای دیتابیس یا بررسی فایلهای باز شده.
- کهنگی لیستها (List Rot): لیست توکنهای ممنوعه باید ماهانه پاکسازی و بهروز شود، زیرا فروشندگان نام محصولات خود را تغییر میدهند. یک منشور قدیمی تبدیل به یک «تئاتر گرانقیمت» میشود که کاربرد واقعی ندارد.
این رویکرد برای تیمهایی که نیاز به استانداردهای PCI، HIPAA یا SOC دارند طراحی نشده است، و همچنین برای پروژههایی که واقعاً به یک صف (Queue) پولی نیاز دارند مناسب نیست. در این موارد، منشور مانع از طراحی درست میشود. راهکار این است که منشور در روز روشن (با آگاهی کامل) ویرایش شود و سپس کد تولید گردد.
چرخش در گردشکارهای عاملمحور
در حالی که صنعت اکنون در ستایش حلقههای خودمختار بزرگتر است، این حلقهها اغلب منجر به خریدهای خاموش و ناخواسته میشوند. این روش مبتنی بر منشور، استدلال میکند که باید حلقههای کوچکتر و کنترلشدهتری داشت. با اجبار مدل به اینکه تنها پس از قابلرویت شدن حدسهایش در JSON تایپ کند، توسعهدهنده کارت اعتباری خود را در کشو نگه میدارد.
این تغییر، تمرکز را از مهندسی پرامپت (Prompt Engineering) — که شبیه هنر سؤال درست پرسیدن از یک مشاور است — به «مهندسی سیاست» (Policy Engineering) منتقل میکند. بهجای امید به اینکه مدل بهینه بماند، توسعهدهنده مرزی سخت تعریف میکند که مدل نمیتواند نادیده بگیرد. دفتر ثبت همان تابلوی ایست است که تضمین میکند توسعهدهنده صبح روز بعد با یک زیرساخت غیرقابل پرداخت بیدار نشود.
گام بعدی شما
- یک فایل
charter.jsonساده برای پروژههای کوچک خود بسازید و توکنهای گرانقیمت ابری را در آن ممنوع کنید. - از اسکریپتهای بازبینی محلی برای چک کردن Diffهای تولید شده توسط عاملها استفاده کنید تا از نشت هزینه جلوگیری شود.
- اگر از مدلهای رایگان استفاده میکنید، یک نقطه پایانی
/checkساده برای اتوماسیون بازبینیها راهاندازی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو