تصور کنید یک مخزن گیت‌هاب، آینهٔ تمام‌نمای وسواس‌های یک برنامه‌نویس باشد؛ از شب‌زنده‌داری‌های ساعت ۳ صبح تا ماه‌هایی از سکوت مطلق. Commit Chronicles — پروژه‌ای که توسط توسعه‌دهنده‌ای به نام anchildress1 در ۱۲ ژوئیه ۲۰۲۶ منتشر شد — این ردپای خامِ کامیت‌ها را به کارت‌های روایتی تبدیل می‌کند که می‌توان آن‌ها را مستقیماً در فایل README پروژه قرار داد.
برای اکثر توسعه‌دهندگان، نمودار مشارکت‌ها (Contribution Graph) تنها یک دفتر حسابداری است که نشان می‌دهد کاری انجام شده، اما نمی‌گوید واقعاً چه اتفاقی افتاده است. در حالی که ابزارهای رایج هوش مصنوعی صرفاً یک سال کامیت را به یک خلاصه کلی و شبیه به پست‌های لینکدین تبدیل می‌کنند، این سیستم با تاریخچه کامیت‌ها مانند یک پروندهٔ کارآگاهانه برخورد می‌کند. هدف این است که ثابت شود یک مدل می‌تواند حقیقت را در تاریخچه بیابد، بدون اینکه اجازه داشته باشد واقعیت‌ها را اختراع کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جداسازی لایه‌ی تصمیم‌گیری از لایه‌ی تولید متن، کلید کاهش خطاهاست. در این سیستم نیز، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تصمیم نمی‌گیرد چه داستانی روایت شود؛ بلکه یک پرس‌وجوی SQL ساده در انبار داده‌های Snowflake این مسیر را تعیین می‌کند.
طبق مستندات این پروژه در وب‌سایت dev.to، شش «شناسگر خط داستانی» به صورت SQL View اجرا می‌شوند تا قوس تکاملی پروژه را تشخیص دهند:
- Nocturne (شبانه): فعال می‌شود اگر ۵۰٪ یا بیشتر کامیت‌ها بین ساعت ۲۲:۰۰ تا ۰۴:۵۹ ثبت شده باشند.
- Relapse (بازگشت): شکافی ۳۰ روزه یا بیشتر را شناسایی می‌کند که پس از آن توسعه‌دهنده بازگشته است.
- Binge (پُرکاری): رده‌های فعالیت متوالی ۷ روزه یا بیشتر را می‌یابد.
- Collapse (فروپاشی): دوره‌ای از فعالیت شدید را که با سکوت مطلق دنبال شده، شناسایی می‌کند.
- Silent (سکوت): زمانی رخ می‌دهد که پس از یک جهش فعالیت، ۹۰ روز بی‌تحرکی وجود داشته باشد.
- Fight (نبرد): تلاش برای حل یک باگ خاص را شناسایی می‌کند (۴ بار بازگشت یا Revert در ۷ روز).
به گزارش سازنده، برای حفظ پایداری پروژه، محدودیت‌های شدیدی برای جلوگیری از تخلیه بودجه توسط «مونو-ریپوزیتوری‌ها» (Monorepos) اعمال شده است. سیستم دریافت داده‌ها را به ۵۰۰ کامیت محدود کرده و حجم شواهدی که به مدل ارسال می‌شود را بین ۲۰ تا ۱۴۰ خط نگه می‌دارد؛ یعنی تقریباً ۲۵٪ از خطوط واقعی کامیت‌های مخزن.
سرویس Snowflake Cortex و به‌طور خاص مدل Claude-Sonnet-4.5 به عنوان یک تابع SQL (CHRONICLE_CARD) فراخوانی می‌شود. مدل هرگز کل مخزن را نمی‌بیند و فقط رشته‌ی متنی خاصی را دریافت می‌کند که توسط شناسگر SQL انتخاب شده است. برای تضمین دقت، مدل صراحتاً از تولید اعداد منع شده است. تمامی آمارها — مثل تعداد کل کامیت‌ها و برچسب‌های زمانی — توسط SQL محاسبه شده و به صورت جداگانه به رندرکننده ارسال می‌شوند تا توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — در اعداد رخ ندهد.
به دلیل استفاده از دمای (Temperature) ۰.۴ برای جلوگیری از خشک بودن متن، سیستم از ۱۳ بررسی SQLمحور برای اعتبارسنجی خروجی استفاده می‌کند. اگر هوش مصنوعی یک عدد را به طور غیرقانونی در متن شاعرانه بگنجاند یا نام خط داستانی را عیناً تکرار کند، کارت رد شده و به جای نمایش یک دروغ، با خطا مواجه می‌شود.
خروجی نهایی یک شیء JSON ساختاریافته شامل یک «کیکر»، عنوان و یک رنگ تاکیدی است. این JSON به Cloud Run ارسال می‌شود تا یک تصویر PNG با ابعاد ۱۲۰۰ در ۶۳۰ پیکسل خلق کند. رنگ‌ها تصادفی نیستند؛ Cortex بر اساس قوس احساسی مخزن، کد رنگ را انتخاب می‌کند؛ مثلاً برای پروژه‌هایی که در تاریکی توسعه یافته‌اند (روایت Nocturne)، از طیف‌های رنگی آسمان استفاده می‌کند.
این رویکرد، گذاری از «خلاصه‌سازی» به «سنتز» است. با استفاده از SQL به عنوان یک ویراستار سخت‌گیر و مدل زبانی به عنوان یک سبک‌پرداز، این ابزار مشکل «محتوای بی‌کیفیت» (Slop) در پروفایل‌های توسعه‌دهندگان را حل می‌کند. در واقع LLM دیگر تصمیم‌گیرنده نیست، بلکه قطعه‌ای تخصصی در یک خط لوله استنتاج (Inference) — یعنی همان لحظه تولید جواب، شبیه خودِ آشپزی نه دوره آموزش آن — است.
برای جامعه توسعه‌دهندگان، این یک نقشه راه برای «هوش مصنوعی قابل‌راستی‌آزمایی» است. وقتی هزینه توکن (Token) — تکه‌های کوچک متن شبیه برش‌های کیک — بالا و هزینه توهمات بالاتر است، مقاوم‌ترین معماری آن است که در آن AI آخرین گام فرآیند باشد، نه اولین گام. در اینجا انبار داده ویراستار است و مدل، تنها کاتب.
گام بعدی شما
- اگر پروژه جانبی (Side Project) دارید، آن را در وب‌سایت commitchronicles.anchildress1.dev تست کنید تا ببینید الگوی توسعه شما «پُرکاری» بوده یا «فروپاشی».
- در معماری پروژه‌های خود، سعی کنید منطق تصمیم‌گیری را به SQL یا کد قطعی منتقل کنید و از LLM فقط برای پرداخت نهایی متن استفاده نمایید.
- بررسی کنید که آیا می‌توانید با استفاده از توابع SQL در Snowflake، تحلیل‌های رفتاری مشابهی روی داده‌های کسب‌وکار خود پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو