تصور کنید میخواهید یک اتاق را بازسازی کنید در حالی که هنوز در آن زندگی میکنید؛ یک اشتباه کوچک در تخریب دیوارها میتواند کل خانه را روی سرتان خراب کند. این دقیقاً همان چالشی است که توسعهدهندگان هنگام سپردن تغییرات کد به هوش مصنوعی با آن روبرuent هستند. سوال اصلی این بود: «آیا یک مدل زبانی بزرگ (LLM) رایگان و مبتنی بر وب میتواند ویژگیهای کاملاً جدیدی را به یک کد پایتون موجود اضافه کند، بدون اینکه باعث شکست سیستماتیک شود؟»
در ۲۸ سپتامبر ۲۰۲۶، یک توسعهدهنده با استفاده از Gemini 3.1 Pro توانست حرکات پیچیده زیستی را در یک شبیهساز محیطی (Terrarium) ساخته شده با Pygame پیاده کند. این پروژه برخلاف بسیاری از تستهای آزمایشگاهی، روی یک کد واقعی و «کثیف» اجرا شد. نکته قابل توجه این بود که این پیادهسازی به هیچ اشتراک ماهانه گرانقیمتی نیاز نداشت و تنها بر پایه یک چتبات رایگان مرورگر، یک افزونه VS Code و مقدار زیادی آزمون و خطا بنا شده بود. این رویکرد تکیه بر ابزارهای رایگان، یادآور برخی باورهای غلط درباره استکهای رایگان هوش مصنوعی است که در شرایط استقرار واقعی میتوانند منجر به شکست شوند.
همانطور که در تحلیل قبلی ما دربارهی Gemini 3.7 Flash و دقت بالای آن در بنچمارکهای تحلیلی اشاره کردیم، این تجربه تمرکز را از اعداد خشکِ بنچمارک به کاربرد عملی در دنیای واقعی منتقل میکند. در اینجا، هدف اضافه کردن رفتار دقیق زیستی کرمها (شامل منطق انقباضات بدنی یا Peristalsis و لنگر انداختن در محیط) به یک کد موجود بود، بدون اینکه کل سیستم از هم بپاشد.
برای مدیریت کدها، نویسنده از ReptClip استفاده کرد؛ یک افزونه اختصاصی برای VS Code که زمینه (Context) را بستهبندی کرده و تغییرات (Diff) تولید شده توسط چتباتها را اعمال میکند. طبق گزارش توسعهدهنده، اولین تلاش با شکست مواجه شد؛ او سعی کرد کل کد ۶۴ هزار توکنی — شامل فایل README.md، فایل requirements.txt و تکتک فایلهای پایتون — را یکباره در Google AI Studio بریزد. نتیجه این «تراکم بیش از حد»، بروز توهم (Hallucination) — شبیه به دوستی که با اطمینان خاطری خاطرهای را اشتباه تعریف میکند — و شکست در اعمال تغییرات بود.
بر اساس بررسیهای این پروژه، رابط کاربری gemini.google.com یک نقص جدی دارد: این محیط متون طولانی را بدون هیچ هشدار یا اعلانی قطع (Truncate) میکند. برای دور زدن این مشکل، توسعهدهنده از قابلیت ReptClip استفاده کرد تا خروجیها را مستقیماً در فایلها بنویسد و سپس آنها را آپلود کند. با این حال، حتی با آپلود موفق، رویکرد «همه چیز را بفرست» باز هم شکست خورد. مدل یک تغییر ۱۰۸ خطی تولید کرد، اما به دلیل حجم زیاد دادههای نامرتبط، دچار توهم شد. با وجود اینکه ReptClip از قابلیت تطبیق تقریبی (Fuzzy Matching) در بلوکهای SEARCH پشتیبانی میکند، توهمات مدل چنان شدید بود که افزونه نتوانست هیچ تطابقی برای جایگذاری کد پیدا کند.
در نهایت، موفقیت از طریق یک استراتژی سختگیرانه در مدیریت پنجره زمینه (Context Window) — که مثل میز کاری است که فقط جای چند ورق دارد، نه کل کتابخانه — حاصل شد:
- فاز اول (Initial Phase): ارسال تنها ساختار پروژه، فایل README و فایل requirements.txt.
- فاز انتخاب (Selection Phase): اجازه دادن به مدل برای درخواست فایلهای خاصی که برای پیادهسازی ویژگی جدید نیاز دارد.
- فاز اجرا (Execution Phase): ارسال تنها همان فایلهای درخواستی برای تولید کد نهایی (Diff).
با این روش، یک مدل کوچک Flash توانست در تلاش دوم، یک ویژگی ساده را با تغییراتی در ۱۶۵ خط کد بهطور کامل اجرا کند و این تغییرات تنها با یک تطبیق تقریبی بهطور تمیز اعمال شد. اما برای شبیهسازی پیچیده زیستی، قدرت Gemini Pro لازم بود.
شروع کار با Gemini Pro ناامیدکننده بود. مدل با وجود استفاده از اصطلاحات تخصصی زیستشناسی و تولید تغییراتی در ۲۶۵ خط کد که دو فایل مختلف را تغییر میداد، شبیهسازی «خالی» تولید کرد؛ یعنی کرمها در محیط نامرئی بودند. توسعهدهنده حتی سرعت شبیهسازی را ۸ برابر کرد و «روزها» (در زمان شبیهسازی) منتظر ماند، اما هیچ چیزی ظاهر نشد. حتی قابلیت Extended Thinking گوگل که ادعا میکرد باگ دقیق را پیدا کرده است، در نهایت نتوانست کرمهای قابل مشاهدهای تولید کند.
بر اساس مستندات این تجربه، موفقیت نهایی زمانی رخ داد که فایل ant.py به عنوان مرجعی برای منطقهای موجود به مدل داده شد. این کار به هوش مصنوعی اجازه داد تا تغییراتی تولید کند که واقعاً رندر شوند. نتیجه نهایی، شبیهسازی دقیق انقباضات (Peristalsis)، لنگر انداختن (Anchoring) و رفتارهای تجمعی (Bunching) کرمها بود، هرچند که نویسنده اشاره کرد این مسیر با آزمون و خطاهای متعددی همراه بود.
این آزمایش ثابت میکند که گلوگاه برنامهنویسی با هوش مصنوعی، لزوماً هوش مدل نیست، بلکه توانایی توسعهدهنده در گلچین کردن زمینه است. وقتی مدل با فایلهای نامرتبط بمباران شود، توهم میزند؛ اما وقتی دسترسی جراحیگونه به مراجع داشته باشد، از پس منطقهای پیچیده برمیآید.
برای یک برنامهنویس معمولی، این یعنی رویکرد «کپی-پیستِ همه چیز» یک ریسک و نقطه ضعف است. مهارت واقعی اکنون به «مهندسی زمینه» (Context Engineering) تغییر یافته است؛ یعنی بدانید دقیقاً مدل چه چیزی را باید ببیند تا کد را خراب نکند.
توسعهدهندگان اکنون باید بهجای آپلودهای انبوه، با پرامپتهای تکرارشونده برای درخواست فایلها آزمایش کنند تا ببینند آیا نرخ موفقیت آنها در اعمال تغییرات پیچیده (Complex Diffs) بهبود مییابد یا خیر.
گام بعدی شما
- بهجای آپلود انبوه کدها، از پرامپتهای «درخواستی» استفاده کنید و از مدل بخواهید فایلهای مورد نیازش را نام ببرد.
- برای تغییرات در کدهای بزرگ، ابتدا ساختار درختی پروژه را به مدل معرفی کنید تا نقشه کلی را درک کند.
- در صورت بروز توهم در مدلهای بزرگ، یک فایل نمونه (Reference) از بخشهای مشابه کد را به عنوان الگو ارسال کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو