چرا مدل‌های زبانی نمی‌توانند هزینه‌ی توسعه نرم‌افزار را به صفر برسانند؟

تصور کنید مدیری هستید که ماهانه ۴۰۰ دلار برای یک ابزار مدیریت تسک می‌پردازد و فکر می‌کند یک مدل زبانی می‌تواند همین ابزار را در چند ثانیه برایش بسازد. این وسوسه برای «ساختن به‌جای خریدن»، تله‌ای است که بسیاری از شرکت‌ها در عصر هوش مصنوعی در آن می‌افتند.

به باور بلیک (Blake)، بنیان‌گذار River، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اگرچه سد ورود به دنیای خلق نرم‌افزار را به‌شدت کاهش داده‌اند، اما هزینه مالکیت آن را به صفر نرسانده‌اند. بلیک استدلال می‌کند که وقتی یک صورت‌حساب ۴۰۰ دلاری ماهانه برای یک ردیاب تسک (Task Tracker) دیگر توجیه ساخت یک کلون AI سفارشی را نمی‌دهد، به این دلیل است که هزینه انسانیِ نگهداری از آن سیستم از قیمت اشتراک ماهانه بیشتر می‌شود.

سال‌ها بود که صنعت نرم‌افزار با یک فرمول ساده پیش می‌رفت: «بخرم یا بسازم؟». طبق گزارش‌های بازاری، ساخت ابزارهای سفارشی به‌دلیل دستمزدهای بالای مهندسی و کمبود متخصصان نابغه، به‌شدت گران و مخاطره‌آمیز بود. پروژه‌ها اغلب با هزینه‌های پیش‌بینی‌نشده بسیار بالا، تخطی از زمان‌بندی‌های مقرر و ریسک سقوط در یک «سوراخ خرگوش» (Rabbit Hole) بی‌انتها همراه می‌شدند. به همین دلیل، شرکت‌ها معمولاً فقط نرم‌افزارهایی را می‌ساختند که مستقیماً با هسته و دامنه اصلی کسب‌وکارشان در ارتباط بود و ابزارهای جانبی و محیطی را به ارائه‌دهندگان SaaS (نرم‌افزار به عنوان سرویس) می‌سپردند؛ مگر در مواردی که شرکت‌ها به چنان اندازه عظیمی رسیده بودند که هزینه حواس‌پرتی‌های کوچک در حاشیه سود آن‌ها ناپدید می‌شد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی اقتصاد مدل‌های بازمتن اشاره کردیم، تغییر قواعد بازی زمانی رخ داد که مدل‌های زبانی توانستند بلوک‌های عظیمی از کد را در چند ثانیه تولید کنند. فرض حاکم بر «عصر AI» این است که هر نرم‌افزاری را می‌توان فوراً با یک بسته داخلی که توسط یک مدل ساخته شده، جایگزین کرد. برخی منتقدان حتی با تعجب می‌پرسند: «آیا دیوانه‌اید؟!» و ادعا می‌کنند هر ویژگی (Feature) که در حال حاضر عرضه شده، می‌تواند فوراً توسط یک بسته داخلیِ ساخته‌شده با LLM جایگزین شود. اما این نگاه، یک نکته حیاتی را نادیده می‌گیرد: «مالیات پنهانِ حضور انسان در حلقه» (Human-in-the-loop).

تلهٔ نگهداری

بر اساس تحلیلی که در ۲۱ ژوئن ۲۰۲۶ توسط brandur.org منتشر شد، سامانه‌های ساخته‌شده با هوش مصنوعی همچنان به یک حلقه بازخورد دائمی نیاز دارند. یک اپراتور باید پرامپت بنویسد، نتایج را بازبینی کند و کد را در ده‌ها تکرار اصلاح کند تا به نسخه‌ای برسد که برای محیط عملیاتی (Production-ready) آماده باشد؛ یعنی رسیدن به یک مصالحه بهینه بین زمان صرف‌شده و کیفیت خروجی. این نیاز به نظارت مستمر، دقیقاً همان نقطه‌ای است که نقش مهندسان ارشد از کدنویسی به قضاوت و بازبینی تغییر می‌کند تا بتوانند کیفیت خروجی‌های AI را تضمین کنند.

نگهداری، یک هزینه نیروی کار دائمی ایجاد می‌کند. باگ‌ها و درخواست‌های جدید برای ویژگی‌ها، فقط چون کد توسط AI نوشته شده، ناپدید نمی‌شوند. گران‌ترین بخش ماجرا، همان نیروی انسانی است که به‌صورت پاره‌وقت باید نتایج را نظارت و تأیید کند. هوش مصنوعی پیاده‌سازی تغییرات را آسان می‌کند، اما آن‌ها را رایگان نمی‌کند. در واقع، چالش اصلی در مقیاس صنعتی، فراتر از کیفیت اولیه مدل است و باید بر روی مدیریت پایداری و حکمرانی این سیستم‌ها تمرکز کرد تا از تبدیل شدن دموهای جذاب به کابوس‌های عملیاتی جلوگیری شود.

ریاضیاتِ تصمیم به «ساخت»

برای درک این موضوع، داستان یکی از کاربران لینکدین را بررسی کنیم که از پرداخت ۴۰۰ دلار ماهانه برای Atlassian Jira احساس ضربه شخصی کرده بود و شاکی بود. او از تیمش خواست تا با کمک Claude یک ردیاب تسک داخلی بسازد تا این هزینه حذف شود. در ظاهر این یک پیروزی بود، اما وقتی اعداد را کمی quantified (کمی‌سازی) کنیم، ریاضیاتِ ماجرا شکست می‌خورد:

• هزینه مهندس: فرض کنید مهندسی سالانه ۲۰۰,۰۰۰ دلار درآمد دارد. با هفته‌ای ۴۰ ساعت کار، هزینه او ماهانه ۱۶,۶۶۶.۶۷ دلار، هفتگی ۳,۸۴۶.۱۵ دلار و ساعتی ۹۶.۱۵ دلار است.
• نقطه سربه-سر: برای اینکه ساخت ابزار به‌صرفه باشد و هزینه ۴۰۰ دلاری ماهانه را خنثی کند، مهندس نباید بیش از ۴.۱۶ ساعت در ماه (۴۰۰ تقسیم بر ۹۶.۱۵) را صرف نوشتن پرامپت برای ویژگی‌ها، رفع باگ یا مدیریت دیتابیس کند.
• واقعیت عملیاتی: این محاسبه، هزینه «تغییر زمینه» یا Context Switching را کاملاً نادیده می‌گیرد. حتی با کمک AI، صرف تنها ۴ ساعت در ماه برای نگهداری یک سیستم فعال، غیرواقعی است.
• دم دراز هزینه: اگر هزینه نگهداری را به‌صورت خوش‌بینانه به ۲ ساعت در ماه کاهش دهیم، باز هم ۳۷ ماه زمان لازم است تا هزینه اولیه دو هفته‌ایِ ساخت ابزار جبران شود. (محاسبه: ۲ * ۳۸۴۶.۱۵ تقسیم بر (۴۰۰ - ۲ * ۹۶.۱۵)).

در مقابل، محصولات گران‌قیمت SaaS اکنون اهداف اصلی برای جایگزینی با AI هستند. برای محصولی مانند Salesforce، گزارش‌های Gemini حاکی از آن است که هزینه یک لایسنس کامل (Fully Loaded Seat) حدود ۵۰۰ دلار در ماه است. در یک استقرار با ۵۰ کاربر، هزینه ماهانه به ۲۵,۰۰۰ دلار می‌رسد.

• مقایسه منابع: با بودجه ۲۵,۰۰۰ دلار در ماه، یک شرکت می‌تواند ۱.۵ مهندس تمام‌وقت (۲۵ هزار تقسیم بر ۱۶.۷ هزار) را استخدام کند که منحصراً روی ساخت یک کلون متمرکز باشند.
• واکنش بازار: این تغییر در بازارهای مالی دیده می‌شود؛ سقوط ۳۰ درصدی ارزش سهام Salesforce از ابتدای سال جاری (YTD) نشان می‌دهد سرمایه‌گذاران معتقدند تصمیم به «ساختن» برای استقرارها در مقیاس بزرگ، جذاب‌تر شده است.

منطقه‌ی بقا

بلیک مفهومی به نام «منطقه‌ی بقا» (Zone of Viability) را برای نرم‌افزارهای قابل فروش پیشنهاد می‌دهد. یک محصول برای بقا در عصر مدل‌های زبانی باید از دو حد افراطی دوری کند: نباید به‌قدر ارزان باشد که بازسازی آن راحت‌تر باشد، و نباید به‌قدر گران باشد که کاربر را به سمت جایگزینی سفارشی سوق دهد. یک محصول در این منطقه دو شرط خاص را برآورده می‌کند:

• نوآوری کافی: نرم‌افزار باید به‌قدر پیچیده باشد که بازسازی آن با LLM بدیهی و ساده نباشد و بار نگهداری مستمری ایجاد کند.
• قیمت‌گذاری معقول: هزینه نباید به‌قدر exorbitant (افراطی) باشد که انگیزه‌ای شدید برای بازسازی توسط AI ایجاد کند.

تا زمانی که قیمت معقول باشد، مجموع مبلغ پرداختی برای لایسنس کمتر از هزینه‌ی تجمعیِ پرامپت‌نویسی اولیه و تداوم بقای نرم‌افزار خواهد بود. پایین‌تر از این منطقه، «حداقل واحد قابل فروش نرم‌افزاری» قرار دارد؛ جایی که تلاش برای خرید یک ابزار شخص ثالث، در واقع بیشتر از تلاش برای درخواست از AI جهت بازسازی آن است.

مدل کسب‌وکار River

پروژه River، که یک صف شغلی (Job Queue) برای Go و Postgres است، سعی می‌کند دقیقاً در این منطقه قرار بگیرد. برای چندین سال، بلیک روی آن به‌عنوان یک کسب‌وکار کوچک کار کرد و اکنون نویسنده به‌صورت تمام‌وقت مدیریت آن را بر عهده گرفته است. اکثر ویژگی‌های آن بازمتن (Open-source) و رایگان هستند، از جمله:

• کارهای دوره‌ای (Periodic jobs)
• کارهای زمان‌بندی شده (Scheduled jobs)
• کارهای منحصربه‌فرد (Unique jobs)
• رابط کاربری وب (Web UI)

با این حال، River قابلیت‌های پیشرفته را برای نسخه Pro نگه داشته است که شامل جریان‌های کاری (Workflows)، کارهای متوالی (Sequential jobs)، کارهای با محدودیت همزمانی (Concurrently-limited jobs) و قابلیت صورت‌حساب (به‌ویژه صورت‌حساب بر اساس فاکتور) است. اگرچه یک AI می‌تواند بالقوه این ویژگی‌ها را شبیه‌سازی کند، اما River شرط‌بندی کرده است که طراحی API خاص و ویژگی‌های عملکردی‌اش به‌قدر نوآورانه‌ای است که رسیدن به دقت و کیفیت مشابه، نیاز به کار سخت و زمان‌بر دارد.

برای ماندن در منطقه‌ی بقا، آن‌ها از مدل قیمت‌گذاری زیرخطی (Sublinear) استفاده می‌کنند که بر اساس اندازه تیم است، نه تعداد نفرات. این قیمت‌گذاری از ۱۲۵ دلار در ماه برای حداکثر ۲۰ توسعه‌دهنده شروع می‌شود و تا ضریبی از این مبلغ برای لایسنس نامحدود سایت (Unlimited site license) بالا می‌رود. برای یک تیم توسعه کوچک تا متوسط، ۱۲۵ دلار در ماه کل هزینه نهایی برای تمام اعضای تیم است.

این چارچوب نشان می‌دهد آینده نرم‌افزارهای مستقل (Indie Software) در رقابت با AI بر سر «خروجی خام» نیست، بلکه مدیریت فاصله بین هزینه اشتراک و نرخ ساعتیِ بازبینی انسانی است. ارزش دیگر در خودِ کد نیست، بلکه در حذف بار نگهداری از دوش مشتری است.

گام بعدی شما

• هنگام تصمیم برای جایگزینی یک ابزار SaaS با نسخه AI، هزینه ساعتی مهندس خود را در برابر هزینه اشتراک قرار دهید و عامل «تغییر زمینه» را لحاظ کنید.
• اگر محصول نرم‌افزاری دارید، قیمت‌گذاری خود را به‌گونه‌ای تنظیم کنید که در «منطقه‌ی بقا» قرار بگیرید؛ نه به‌قدر ارزان که AI جایگزین شما شود و نه به‌قدر گران که ساخت کلون توجیه‌پذیر باشد.
• بر روی ویژگی‌هایی تمرکز کنید که «نوآوری عملکردی» دارند و بازسازی‌شان با پرامپت‌های ساده ممکن نیست.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.