شیائومی بیشتر با گوشی و لوازم هوشمند شناخته می‌شه — ولی از اوایل ۲۰۲۶ یه سری مدل زبانی با برند MiMo منتشر کرده که توی جامعه‌ی مدل‌های open-weight سروصدا کرده. نسل فعلی شامل MiMo-V2، V2-Pro، V2-Flash، و جدیدترین V2.5 می‌شه — با نسخه‌های Mixture-of-Experts که تعداد پارامترهاشون توی نسخه‌های Pro به یه تریلیون پارامتر می‌رسه.

قبل از هر چیز، یه تجربه‌ی مستقیم:

تست فارسی: جایی که انتظارش نداشتم

یه چیزی که موقع تست ترجمه به فارسی مشخص شد اینه که MiMo توی فارسی‌نویسی خیلی طبیعی‌تر از اکثر مدل‌هایی که امتحان کردم عمل می‌کنه. نه ترجمه‌ی تحت‌اللفظی که هر جمله‌اش بوی ماشین می‌ده — نثر روان، ساختار جمله درست، و انتخاب کلمه که به فارسی محاوره‌ای امروز نزدیکه.

این برای یه مدل چینی که احتمالاً داده‌ی فارسی کمتری در pretraining داشته، قابل توجهه.

ولی یه محدودیت هم پیدا کردم که مهمه: context window اسماً ۲۵۶K توکن داره، ولی بعد از حدود ۳۰ دقیقه کار یا session طولانی، مدل شروع می‌کنه به فراموش کردن جزئیاتی که اول گفتی. کار رو انجام می‌ده، ولی اون constraint خاصی که گذاشتی یا اون قالب که مشخص کردی ممکنه رعایت نشه. این همون مشکلیه که توی خیلی از مدل‌ها با context window بلند وجود داره: داشتن یه window بزرگ با attention یکنواخت روی همه‌ی اون window فرق داره.

پس برای task های کوتاه‌تر — ترجمه، تحلیل متن، دستورات مشخص — عالیه. برای agentic task های طولانی‌مدت که ساعت‌ها طول می‌کشه، باید حواست باشه.

چی خوبه

استدلال و کدنویسی: توی benchmark هایی مثل AIME، نسخه‌های V2.5 نمره‌هایی می‌گیرن که با مدل‌های top رقیبه. جامعه‌ی LocalLLaMA و Artificial Analysis هر دو از این مدل‌ها توی رتبه‌بندی‌های agentic بالا می‌آورن. کدنویسی، شبیه‌سازی وب، و multi-step task ها جایی‌ان که MiMo معمولاً خوب عمل می‌کنه.

سرعت: نسخه‌های UltraSpeed به بیش از هزار توکن در ثانیه می‌رسن و بعضی تست‌ها سه هزار توکن در ثانیه رو هم گزارش کردن. برای agentic loop هایی که زمان پاسخ مهمه، این عدد فرق محسوسی می‌کنه.

ارزش: نسخه‌ی non-Pro از نظر هزینه خیلی رقابتیه. Artificial Analysis اون رو با Intelligence Index حدود ۴۹ رتبه‌بندی می‌کنه — که در همون محدوده‌ی مدل‌های proprietary گران‌تره، با قیمت خیلی کمتر. کاربرهای زیادی از Reddit و LocalLLaMA از اون به‌عنوان «بهترین ارزش الان» یاد می‌کنن.

tool use: در مقایسه با بعضی رقبا مثل Gemini، follow-through بهتری در task های چندمرحله‌ای داره و hallucination کمتری گزارش شده.

چی ضعیف‌تره

نوشتن خلاقانه: اینجاست که مدل‌هایی مثل Claude هنوز جلوترن. اگه می‌خوای متنی بنویسی که ظرافت داشته باشه یا سبک خاصی داشته باشه، MiMo معمولاً نتیجه‌ی معمولی‌تری می‌ده. برای ترجمه خوبه، ولی برای خلق محتوای خلاقانه‌ی فارسی همون ضعفی که اکثر مدل‌ها دارن رو داره.

context طولانی: همون‌طور که گفتم، روی session های بلند focus ضعیف می‌شه. نه به‌خاطر اینکه context window کوچیکه — بلکه به‌خاطر اینکه attention روی اطلاعات اول session با پیشرفت مکالمه کمرنگ‌تر می‌شه.

در دسترس بودن: روی همه‌ی platform های غربی به‌راحتی host نشده. بعضی کاربرها از محدودیت‌های استفاده در تیرهای Pro شکایت دارن.

نسخه‌های اولیه: V1 و V2 اولیه مشکلاتی داشتن که V2.5 خیلی‌شون رو بهتر کرده. اگه چند ماه پیش امتحان کردی و نتیجه خوبی نگرفتی، ارزش داره دوباره V2.5 رو تست کنی.

کدوم نسخه برای چی

V2.5 non-Pro: برای اکثر کاربردهای روزانه — کدنویسی، ترجمه، تحلیل، task های متوسط. بهترین نسبت هزینه به کیفیت الان.

V2-Flash: وقتی سرعت مهم‌ترین چیزه و می‌تونی کمی کیفیت بدی. برای agentic loop هایی که باید خیلی سریع iterate کنن.

V2-Pro / V2.5-Pro: برای task های خیلی سنگین با نیاز به reasoning عمیق. ولی باید بسنجی که آیا هزینه‌ی اضافه‌اش نسبت به non-Pro توجیه داره — بعضی تست‌ها می‌گن در کاربردهای روزانه فرق محسوسی نیست.

جمع‌بندی

MiMo یه رقیب جدی توی فضای open-weight است — نه به‌خاطر اینکه در همه چیز بهترینه، بلکه چون نسبت هزینه به کیفیتش جذابه و توی task های خاص (کدنویسی، ترجمه، agentic کوتاه‌مدت) نتایج واقعاً خوبی می‌ده.

اگه با فارسی کار می‌کنی یا دنبال یه مدل ارزون برای workflow های برنامه‌نویسی هستی، V2.5 non-Pro ارزش امتحان کردن داره. فقط انتظار نداشته باش که روی task های خلاقانه‌ی پیچیده یا session های خیلی بلند همون نتیجه رو بده.

یه کار که تقریباً هر پروژه‌ی Laravel ای در یه نقطه‌ای بهش نیاز داره اینه که تصویر آپلودشده رو resize کنه، فرمتش رو عوض کنه، یا یه thumbnail ازش بسازه. تا الان برای این کار حتماً باید یه package جداگانه نصب می‌کردی — معمولاً intervention/image — و بعد خودت wrapper می‌نوشتی. Laravel 13.20 که ۱۴ جولای ۲۰۲۶ منتشر شد، این کار رو داخل خود فریم‌ورک آورده.

Image facade: پردازش تصویر first-party

یه Image facade جدید اضافه شده که یه API immutable برای تبدیل تصاویر داره. immutable یعنی هر transformation یه instance جدید برمی‌گردونه — یعنی می‌تونی از یه تصویر چند variant مختلف بسازی بدون اینکه مشکل side effect داشته باشی.

رایج‌ترین حالت استفاده اینه که مستقیم از request بگیری:

$request->image('avatar')
    ->cover(200, 200)
    ->toWebp()
    ->store('avatars');

ولی می‌تونی از هر جایی image بسازی:

Image::fromPath('/path/to/photo.jpg');
Image::fromUrl('https://example.com/photo.jpg');
Image::fromBytes($bytes);
Image::fromStorage('photos/avatar.jpg', 's3');
Storage::disk('s3')->image('photos/avatar.jpg');

transformationهایی که در دسترسن:

$image->cover(200, 200);    // crop و resize با هم
$image->contain(800, 600);  // resize بدون crop
$image->crop(200, 200);
$image->resize(1024, 768);
$image->scale(1200, 800);
$image->rotate(90);
$image->blur(10);
$image->sharpen(10);
$image->grayscale();
$image->flip();
$image->flop();
$image->orient();           // EXIF rotation رو اعمال می‌کنه

برای output هم:

$image->toWebp();
$image->toJpg()->quality(80);
$image->optimize();          // WebP با quality 70
$image->optimize('jpg', 85);

چون immutable هست، ساختن چند variant از یه عکس تمیزه:

$image = $request->image('photo');

$image->cover(200, 200)->toWebp()->store('thumbnails');
$image->grayscale()->toWebp()->store('grayscale');

دو driver داره — GD و Imagick — و می‌تونی per-image هم انتخاب کنی:

$image->usingGd();
$image->usingImagick();

یه نکته‌ی مهم: خود intervention/image به‌عنوان suggested dependency اضافه شده، نه required. یعنی باید خودت نصبش کنی:

composer require intervention/image

ویژگی WithoutMiddleware

یه attribute جدید اضافه شده که counterpart ویژگی #[Middleware] هست. تا الان می‌تونستی روی کل controller یه middleware بذاری و برای بعضی method ها استثنا بدی. حالا این کار رو می‌تونی با attribute بکنی:

#[Middleware(EnsureTokenIsValid::class)]
class UserController
{
    public function index()
    {
        // middleware اینجا اعمال میشه
    }

    #[WithoutMiddleware(EnsureTokenIsValid::class)]
    public function profile()
    {
        // اینجا اعمال نمیشه
    }
}

یه نکته‌ی ظریف: از ReflectionAttribute::IS_INSTANCEOF استفاده می‌کنه، یعنی subclass های اون middleware هم automatically exclude می‌شن.

پیشوند جداگانه برای Session در Redis

اگه هم SESSION_DRIVER و هم CACHE_STORE هر دو به Redis اشاره می‌کنن، تا الان session ها از همون prefix که برای cache تنظیم کردی استفاده می‌کردن. این debug کردن Redis keyspace رو مشکل می‌کرد.

حالا می‌تونی توی config/session.php یه prefix جداگانه بذاری:

'prefix' => env('SESSION_PREFIX', Str::slug(env('APP_NAME', 'laravel')).'-session-'),

cache store قبل از اعمال session prefix کلون می‌شه، پس این تغییر روی cache key ها تاثیر نمی‌ذاره.

incrementEachQuietly و decrementEachQuietly

Eloquent قبلاً incrementQuietly() و decrementQuietly() داشت که یه column رو بدون trigger کردن model event تغییر می‌دادن. این نسخه نسخه‌ی multi-column اینا رو اضافه کرده:

$user->incrementEachQuietly(['posts_count' => 1, 'points' => 10]);
$user->decrementEachQuietly(['credits' => 3, 'tokens' => 2]);

وقتی داری یه batch operation انجام می‌دی و نمی‌خوای event هایی مثل saved یا updated fire بشن، این دقیقاً چیزیه که می‌خوای.

Enum به‌عنوان کلید WithoutOverlapping

WithoutOverlapping middleware برای queue jobs الان مستقیم enum قبول می‌کنه:

public function middleware(): array
{
    return [new WithoutOverlapping($this->category)];
}

قبلاً باید enum رو به string تبدیل می‌کردی. این تغییر backward compatible هست.

بقیه چیزهای کوچیک ولی مفید

چند چیز دیگه که کمتر headline می‌گیرن ولی در عمل کاربرد دارن:

make:migration حالا timestamp prefix هایی می‌سازه که collision-free و مرتب هستن — مشکل قدیمی که دو migration همزمان ساخته‌شده اسم تکراری می‌گرفتن.

#[SensitiveParameter] به parameter هایی که secret حمل می‌کنن اضافه شده، یعنی password ها و token ها دیگه توی stack trace نمایش داده نمی‌شن.

Storage::assertEmpty() اضافه شده که توی test ها مفیده.

Str::containsAll() دیگه برای آرایه‌ی خالی true برنمی‌گردونه — یه bug قدیمی که رفتار غیرمنطقی داشت.

Number::forHumans() دیگه برای عددهای خیلی کوچیک منفی، -0 برنمی‌گردونه.

upgrade کردن

تغییر breaking ای وجود نداره. اگه می‌خوای از Image facade استفاده کنی، فقط intervention/image رو نصب کن. بقیه‌ی تغییرات opt-in هستن یا bug fix.

یه سوال جدی هست که بیشتر و بیشتر آدم‌ها می‌پرسن — خصوصاً کسایی که تازه شروع کردن: الان که Claude Code یه component کامل React رو توی ده ثانیه می‌نویسه، الان که GPT یه API endpoint رو با تمام error handling‌اش تحویل می‌ده، واقعاً باید بشینم data structure یاد بگیرم؟ باید algorithm بفهمم؟ باید بدونم HTTP دقیقاً چطور کار می‌کنه؟

جواب صادقانه: بله. ولی نه به همون دلیلی که فکر می‌کنی.

مدل کد می‌نویسه، تو تصمیم می‌گیری

یه چیزی که توی استفاده از AI coding tools خیلی زود مشخص می‌شه اینه که کیفیت خروجی مستقیماً به کیفیت input تو وابسته‌ست. اگه ندونی چی می‌خوای، مدل هم نمی‌دونه. اگه ندونی معماری درست چیه، خروجی مدل ممکنه technically بی‌نقص باشه ولی برای پروژه‌ات کاملاً اشتباه.

یه مثال ساده: از Claude Code می‌خوای یه caching layer بسازه. اگه ندونی فرق Redis و یه in-memory cache ساده چیه، نمی‌دونی کِی از کدوم بخوای. اگه ندونی race condition یعنی چی، نمی‌فهمی که خروجی مدل این مشکل رو داره یا نه. اگه ندونی TTL چطور کار می‌کنه، نمی‌تونی بگی آیا مدل اون رو درست تنظیم کرده یا نه.

مدل کد می‌نویسه. تو تصمیم می‌گیری این کد چیه و چرا.

review کردن بدون فهمیدن ممکن نیست

یه اشتباه رایج اینه که فکر می‌کنیم «می‌خونیم» کد AI رو. ولی خوندن بدون درک، review نیست — یه نگاه انداختنه که حس خوبی می‌ده ولی هیچ چیزی رو تضمین نمی‌کنه.

وقتی AI یه function می‌نویسه که O(n²) complexity داره و تو نمی‌دونی این یعنی چی، می‌گی «خوبه، merge می‌کنم» — و شاید واقعاً هم خوب باشه. ولی وقتی data ات از ده هزار record به یه میلیون رکورد می‌رسه، اون function سرور رو می‌خوابونه. این اتفاق نه به‌خاطر اینه که مدل اشتباه کرد — مدل چیزی نوشت که برای context ای که داشت معقول بود. اشتباه اینجا بود که کسی که review کرد نفهمید مشکل کجاست.

debugging جایی‌ه که اصول واقعاً مهم می‌شن

هر چیزی که AI می‌نویسه، در یه لحظه‌ای اشتباه می‌کنه — یا مدل اشتباه می‌کنه، یا کد توی production با شرایطی مواجه می‌شه که مدل پیش‌بینی نکرده بود. اون لحظه، تنها کسی که می‌تونه مشکل رو پیدا کنه و درستش کنه توئی.

debugging یه مهارتیه که بدون فهمیدن اصول ممکن نیست. نمی‌تونی race condition پیدا کنی اگه ندونی thread یعنی چی. نمی‌تونی memory leak رو trace کنی اگه lifecycle object ها رو نفهمی. نمی‌تونی بفهمی چرا request تایم‌اوت می‌شه اگه ندونی TCP handshake چطور کار می‌کنه.

AI توی debugging هم کمک می‌کنه — ولی فقط اگه بدونی چه اطلاعاتی بهش بدی. اگه ندونی دنبال چی می‌گردی، error log رو copy می‌کنی توی chat و امیدوار می‌شی مدل جواب بده. گاهی می‌ده. ولی این یه روش قابل اعتماد نیست.

یه نقطه‌ی ظریف درباره‌ی سرعت

یه غلط‌فهمی وجود داره که «اصول یاد گرفتن» یعنی زمان زیادی می‌بره و در آخر هم مستقیماً استفاده نمی‌شه. ولی اصول قراره چیزی باشن که دیگه بهشون فکر نمی‌کنی — اتوماتیک تبدیل می‌شن به شهود.

وقتی یه توسعه‌دهنده باتجربه یه codebase جدید رو می‌بینه، می‌فهمه مشکل architecture کجاست — نه به‌خاطر اینکه یه checklist داره، بلکه چون دیده‌ها و تجربه‌هاش به یه حس تبدیل شدن. این همون چیزیه که با AI codingهای سطحی از دست می‌ره.

هرچقدر اصول قوی‌تر باشن، از AI هم بهتر استفاده می‌کنی. چون prompt های بهتری می‌نویسی، خروجی رو بهتر ارزیابی می‌کنی، و زودتر می‌فهمی کِی باید از مدل کمک بخوای و کِی باید خودت فکر کنی.

اصول چه چیزی نیستن

اینجا یه تفاوت مهم هست که باید مشخص بشه: یاد گرفتن اصول با حفظ کردن syntax یه زبان یا دونستن تمام APIهای یه فریم‌ورک فرق داره. دومی رو الان واقعاً AI بهتر از تو می‌دونه. اگه نمی‌دونی Array.reduce چطور کار می‌کنه، بپرس. اگه نمی‌دونی کدوم CSS property برای این استفاده می‌شه، بپرس.

ولی اینکه چرا state management پیچیده می‌شه، چرا database query ات کند شده، چرا این race condition فقط توی production اتفاق می‌افته — اینا رو باید بفهمی. اینا قراره بخشی از طرز فکر تو بشن، نه اینکه هر بار از صفر از مدل بپرسی.

جواب سوال اول

پس چرا باید اصول یاد بگیری؟

نه برای اینکه AI کدت رو بنویسه و تو باید بدونی که نوشته. نه برای اینکه شاید یه روز AI نباشه — هست و بیشتر هم می‌شه.

بلکه چون کار یه توسعه‌دهنده همیشه بیشتر از نوشتن کد بوده. طراحی سیستم، تصمیم‌گیری، تشخیص مشکل، ارزیابی trade-off ها — اینا هنوز جایی هستن که ابزار جایگزین فکر نمی‌شه. AI سرعت رو بالا می‌بره، ولی اگه نقطه‌ی شروع ضعیف باشه، فقط سریع‌تر به جای اشتباه می‌رسی.

اصول یاد می‌گیری تا بتونی از AI درست استفاده کنی — نه به‌رغم اینکه AI هست.

یک چیزی هست که کمتر کسی درباره‌اش حرف می‌زنه: AI coding tools می‌تونن به همون اندازه که کمک کنن، اگه باهاشون درست کار نکنی، اوضاع رو بدتر کنن. نه چون بد هستن — بلکه چون وقتی یه ابزار خیلی قوی داری و هنوز ندونی کِی ازش استفاده کنی، ممکنه در نهایت بیشتر وقتت صرف debug کردن چیزی بشه که خودت می‌تونستی سریع‌تر بنویسیش.

۲۰۲۶ از یه نظر نقطه‌ی عجیبیه. ابزارها از هر زمان دیگه‌ای بهترن، ولی noise هم از همیشه بیشتره. هر هفته یه agent جدید، یه model جدید، یه ادعای جدید که «این بار متفاوته». وسط این سروصدا، یه workflow سالم ربطی به اینکه از کدوم tool استفاده کنی نداره — ربط داره به اینکه چطور باهاشون فکر کنی.

اشتباه اول: context دادن به‌جای فکر کردن

آدم‌ها یه عادت دارن که بلافاصله وقتی به مشکل می‌خورن، می‌رن سراغ AI. این بد نیست — ولی مشکل اینه که اگه قبلش پنج دقیقه با خودت فکر نکرده باشی، مدل هم نمی‌دونه دقیقاً دنبال چی هستی. نتیجه یه جواب generic می‌شه که یا کامل نیست یا با context پروژه‌ات جور نیست.

یه قانون ساده: قبل از اینکه سراغ AI بری، یه جمله بنویس که مشکل رو توصیف کنه. فقط یه جمله. اگه نتونستی، یعنی هنوز نمی‌دونی مشکل چیه — و مدل هم نخواهد دونست.

اشتباه دوم: agent بدون context

agentها — Hermes، Claude Code، Codex — وقتی می‌دونن پروژه چیه، قبلاً چی شده، و چه محدودیت‌هایی وجود داره، خیلی بهتر کار می‌کنن. ولی بدون این context، حتی یه agent خوب هم می‌تونه چیزی بسازه که technically درسته ولی با معماری پروژه‌ات جور نیست.

راه‌حل‌هایی مثل skill file ها برای همین اومدن: به‌جای اینکه هر بار از اول توضیح بدی، یه بار درست توضیح می‌دی و می‌ذاریش جایی که agent هر وقت لازم بود بخونتش. این ساده‌ترین روشیه که workflow ات رو از «هر بار از صفر» به «agent می‌دونه کجاست» تبدیل می‌کنه.

اشتباه سوم: باور کردن خروجی بدون review

این شاید از همه‌شون خطرناک‌تره. مدل‌ها اشتباه می‌کنن — و اشتباهاتشون معمولاً خیلی مطمئن به نظر می‌رسن. کدی که مدل نوشته رو نخونده commit نکن. نه به‌خاطر اینکه کد بد باشه — بلکه چون review کردن کد همونی هست که باعث می‌شه تو بفهمی چی ساخته شده. اگه این رو skip کنی، چند هفته دیگه یه codebase داری که نمی‌دونی داخلش چیه.

این یه قانون نیست که هر خط رو خودت بنویسی. قانون اینه که هر خطی رو که merge می‌کنی، بدونی چیکار می‌کنه.

یه workflow که در عمل کار می‌کنه

یه الگوی ساده که در عمل جواب داده:

برای کارهای کوچیک (یه function، یه refactor کوچیک، یه bug): مستقیم از chat استفاده کن. context لازم نیست زیاد باشه، نتیجه سریعه، و راحت review می‌شه.

برای کارهای متوسط (یه feature جدید، یه سرویس): یه prompt با جزئیات کافی بنویس — معماری، محدودیت‌ها، output مورد انتظار. بعد خروجی رو بگیر و review کن. اگه چیزی جا افتاده یا جور نیست، iteration کن.

برای کارهای بزرگ و پیچیده: اینجاست که agent ها معنی پیدا می‌کنن. یه agent مثل Hermes یا Claude Code می‌تونه یه task چندمرحله‌ای رو مدیریت کنه — ولی فقط اگه بهش context کافی بدی، skill های مرتبط بهش دادی، و حواست به کارش باشه. «بذار agent همه چیز رو بسازه و من بعداً نگاه کنم» یه workflow نیست — یه روش برای ساختن چیزیه که نمی‌فهمیش.

درباره‌ی دسترسی و مرزها

یه چیزی که از تجربه‌ی مستقیم یاد گرفتم: به agent هایی که به filesystem دسترسی دارن، sudo ندید. نه به‌خاطر اینکه agent بد نیت داره — بلکه چون وقتی یه task پیچیده انجام می‌ده و اشتباه می‌کنه، sudo یعنی اشتباهش جبران‌ناپذیره. یه دیتابیس محلی پاک می‌شه. یه پوشه حذف می‌شه. این چیزیه که «بعید نیست» — اتفاق می‌افته.

محدود کردن دسترسی یه لایه‌ی safety net هست، نه بی‌اعتمادی به ابزار.

درباره‌ی مدل‌ها و هزینه

اکثر کارهای روزانه‌ی یه توسعه‌دهنده‌ی معمولی به بهترین و گران‌ترین مدل نیاز ندارن. توضیح یه مفهوم، بررسی یه کد، نوشتن یه test، refactor کوچیک — اینا رو مدل‌های ارزون‌تر هم خوب انجام می‌دن.

جاهایی که مدل قوی‌تر فرق می‌کنه: وقتی task پیچیده‌ست و نیاز به چندین مرحله reasoning داره، وقتی context بزرگه، یا وقتی agent باید خودش تصمیم بگیره چه مرحله‌ای بعدی باشه. برای بقیه، مدل ارزان‌تر کافیه — و ترکیب ابزارهایی مثل 9Router با agentها می‌تونه هزینه رو به حداقل برسونه.

یه جمله خلاصه

workflow سالم با AI یعنی تو هنوز توسعه‌دهنده‌ای — ابزار هم بیشتر شده. یعنی هنوز می‌فهمی چی می‌سازی، هنوز review می‌کنی، و هنوز تصمیم می‌گیری. AI سرعت رو بالا می‌بره — ولی اگه فقط سرعت بالا بره بدون اینکه بفهمی داری کجا می‌ری، سریع‌تر گم می‌شی.