اگر برای عقب‌نماندن از هوش‌مصنوعی (LLM) هر روز یک Skill جدید نصب می‌کنید، شاید دقیقا دارید عقب می‌مانید.
این روزها خیلی از برنامه‌نویس‌ها یک ترس مشترک دارند: نکند ابزار مهمی را نشناسم؟ نکند پرامپت‌هایم حرفه‌ای نباشد؟ نکند بقیه با ده‌ها Agent و Skill چند برابر سریع‌تر از من کار کنند؟
و بازار هم دقیقا از همین ترس تغذیه می‌کند.
هر روز یک پکیج‌فروش جدید می‌بینیم که توضیح می‌دهد چه فایل‌هایی بسازیم، چطور با هوش‌مصنوعی حرف بزنیم، چه Skillهایی نصب کنیم، چند Agent و Subagent داشته باشیم و چطور چند مدل ضعیف و قوی را به هم متصل کنیم.
انگار برای استفاده از مدلی که قرار است زبان طبیعی ما را بفهمد، باید یک زبان و معماری جدید یاد بگیریم.
درحالی‌که جهت حرکت خود هوش‌مصنوعی دقیقا برعکس این است.
مدل بعدی قرار است برای فهمیدن حرف ما به دستورالعمل کمتری نیاز داشته باشد، نه بیشتر.
مدل‌ها هر نسل در فهم منظور کاربر، مدیریت Context، استدلال و استفاده از ابزارها بهتر می‌شوند. بنابراین اگر امروز برای کارکردن با هوش‌مصنوعی مجبوریم یک پرامپت هزارخطی، ده Skill، چند فایل دستورالعمل و پنج Agent دور مدل بسازیم، نباید فورا نتیجه بگیریم که این «معماری آینده» است.
ممکن است فقط داریم محدودیت مدل امروز را با پیچیدگی جبران می‌کنیم؛ محدودیتی که چند نسخه بعد خود مدل حلش کند.
حتی پیچیدگی بیش از حد می‌تواند علیه خود هوش‌مصنوعی کار کند. وقتی Context را با صدها قانون عمومی، دستورالعمل تکراری، Agentهای متعدد و لایه‌های واسط پر می‌کنیم، مسئله اصلی میان انبوهی از اطلاعات کم‌اهمیت گم می‌شود.
مدلی را که برای فهم زبان طبیعی بهینه شده، مجبور می‌کنیم اول معماری‌ای را که دورش ساخته‌ایم بفهمد و بعد تازه برود سراغ مسئله واقعی.
این به معنی بد بودن Skill، Agent یا Model Routing نیست. همه این‌ها در جای درست می‌توانند بسیار مفید باشند.
مشکل از جایی شروع می‌شود که پیچیدگی به‌عنوان تخصص فروخته می‌شود.
از نظر اقتصادی هم همیشه ارزان‌ترین مدل، اقتصادی‌ترین انتخاب نیست.
گاهی یک مدل ارزان مسئله را خلاصه می‌کند، مدل دوم برنامه می‌نویسد، مدل سوم کد تولید می‌کند و مدل چهارم خروجی بقیه را بررسی می‌کند؛ درحالی‌که ممکن است یک مدل قوی‌تر همان مسئله را با رفت‌وبرگشت کمتر، از دست رفتن Context کمتر و خطای کمتر حل کند.
برای یک مقایسه ساده، در زمان نگارش این متن، Opus 5 در API به‌ازای هر یک میلیون توکن ورودی ۵ دلار و خروجی ۲۵ دلار هزینه دارد. یعنی اگر استفاده روزمره و نسبتا سنگین Claude Code را مستقیماً با API انجام دهید، هزینه می‌تواند خیلی سریع به چند صد دلار در ماه برسد.
در مقابل، Claude Code همین مدل را داخل اشتراک ماهانه ۲۰ دلاری Pro ارائه می‌کند و پلن Max 5x هم با ۱۰۰ دلار ظرفیت پنج برابر بیشتر می‌دهد.
البته Subscription نامحدود نیست و Anthropic هم تعداد ثابت Token یا Session تضمین نمی‌کند؛ اما اصل مقایسه خیلی ساده است:
برای یک برنامه‌نویس که روزانه با Claude Code کار می‌کند، انجام همان حجم کار از طریق Subscription می‌تواند چندده برابر ارزان‌تر از مصرف مستقیم API تمام شود.
یعنی قبل از اینکه برای کاهش هزینه سراغ چند مدل ارزان‌تر، Router، Agent و معماری پیچیده برویم، شاید ساده‌ترین بهینه‌سازی این باشد که اصلا API را برای کاری که Subscription بسیار ارزان‌تر پوشش می‌دهد، استفاده نکنیم.
خیلی وقت‌ها به‌جای اینکه مستقیم یک مدل قوی را برداریم و مسئله‌مان را حل کنیم، وارد دنیایی از API، چند مدل مختلف، Router، Wrapper، Agent، Skill و Integration می‌شویم؛ نه لزوماً چون نتیجه بهتر یا ارزان‌تری می‌دهد، بلکه چون پیچیدگی ناخودآگاه به ما حس «حرفه‌ای‌تر بودن» و کنترل بیشتر می‌دهد.
و دقیقا همین‌جا یک بازار آموزشی هم شکل گرفته که استفاده از هوش‌مصنوعی را شبیه یک تخصص بسیار پیچیده نمایش می‌دهد: این فایل را بساز، آن Skill را نصب کن، این مدل را برای Planning بگذار، آن یکی را برای Coding، یک Agent برای Review و یکی دیگر برای هماهنگ‌کردن بقیه.
من مخالف Agent، Skill یا Model Routing نیستم؛ وقتی واقعا مسئله‌ای را حل میکنند، اتفاقا بسیار ارزشمندند.
نقدم به جایی است که پیچیدگی خودش تبدیل به محصول می‌شود.
به‌نظرم معیار مهم‌تر از قیمت هر Cost per Successful Outcome توکن است؛ یعنی هزینه‌ای که واقعا برای رسیدن به یک نتیجه درست می‌پردازیم.
اگر یک مدل قوی مسئله را در یک رفت‌وبرگشت درست بفهمد ولی سه مدل ارزان‌تر به چند مرحله برنامه‌ریزی، انتقال Context، Retry و Review نیاز داشته باشند، دیگر صرفا مقایسه قیمت توکن تصویر درستی به ما نمی‌دهد.
ارزان‌ترین مدل لزوما ارزان‌ترین راه‌حل مسئله نیست.
گاهی برای ارزان‌تر کردن Token، کل سیستم را گران‌تر می‌کنیم؛ و گاهی برای حرفه‌ای‌تر به‌نظر رسیدن، چیزی را پیچیده می‌کنیم که مزیت اصلی هوش‌مصنوعی دقیقاً ساده‌کردن آن بوده است.
این اولین بار نیست که در صنعت نرم‌افزار یک ابزار یا پترن مفید را به یک قانون عمومی تبدیل می‌کنیم.
یک دوره آن‌قدر درگیر معماری‌های عجیب‌وغریب شدیم که برای یک CRUD ساده، حجم زیادی کد، Abstraction و لایه مختلف تولید می‌کردیم. برای اضافه‌کردن یک فیلد ساده گاهی باید DTO، Command، Handler، Mapper، Repository، Interface و چند تست را تغییر می‌دادیم.
قبل از عصر LLMها، هزینه این تصمیم‌ها را بیشتر در Developer Experience می‌دیدیم: Learning Curve بالاتر، آنبردینگ سخت‌تر، اشکال‌زدایی کندتر و زمان بیشتری که یک برنامه نویس باید صرف فهمیدن مسیر اجرای یک درخواست می‌کرد.
اما حالا همان پیچیدگی یک هزینه جدید هم دارد:
هوش‌مصنوعی هم باید تمام این معماری را بفهمد.
هرچه یک تغییر ساده میان فایل‌ها، Abstractionها و لایه‌های بیشتری پخش شده باشد، مدل برای انجام همان تغییر به Context بیشتری نیاز دارد. Context بیشتر یعنی فایل‌های بیشتری باید خوانده شوند، توکن بیشتری مصرف می‌شود، احتمال گم‌شدن مسئله اصلی میان اطلاعات فرعی بیشتر می‌شود و در نهایت هزینه و زمان انجام تغییر با AI هم افزایش پیدا می‌کند.
یعنی بعضی تصمیم‌های معماری که سال‌ها پیش بیشتر DX را خراب می‌کردند، امروز مستقیما روی هزینه استفاده از هوش‌مصنوعی هم اثر می‌گذارند.
اگر برای اضافه‌کردن یک فیلد، هوش‌مصنوعی مجبور باشد ده فایل را بخواند، طبیعتا تغییر آن گران‌تر از سیستمی است که همان رفتار را با فهمیدن دو یا سه فایل بتواند تغییر دهد. (حتی احتمال دوباره کاری به دلیل نفهمیدن Context را هم افزایش می‌دهد)
این به معنی «کد کمتر همیشه بهتر است» یا «همه Abstractionها را حذف کنیم» نیست. مسئله، نسبت پیچیدگی به ارزشی است که ایجاد می‌کند.
MediatR ابزار خوبی بود؛ تا وقتی که برای یک عملیات ساده مجبور شدیم بین Command، Handler، Behavior و چند فایل حرکت کنیم. میکروسرویس هم راه‌حل قدرتمندی بود؛ تا وقتی که قبل از داشتن مسئله واقعی مقیاس‌پذیری، تمام هزینه‌های یک سیستم توزیع‌شده را وارد پروژه کردیم.
مشکل MediatR یا میکروسرویس نبود.
مشکل از جایی شروع شد که پترن‌ها جای تفکر را گرفت.
و حالا هزینه Over-engineering فقط زمان برنامه‌نویس نیست.
هر خط و لایه اضافی که برای فهم یک تغییر لازم است، بخشی از Context Budget هوش‌مصنوعی هم هست.
فکر می‌کنم در AI Coding هم در خطر تکرار همین اتفاق هستیم؛ با این تفاوت که این بار زمین بازی بسیار سریع‌تر تغییر می‌کند.
ما سال‌ها نرم‌افزار را با ذهنیتی عمدتا Deterministic طراحی کرده‌ایم: ورودی مشخص، قانون مشخص و خروجی قابل‌پیش‌بینی.
حالا داریم این سیستم‌ها را با لایه‌هایی ترکیب می‌کنیم که Non-deterministic هستند و با سرعت عجیبی هم تکامل پیدا میکنند.
مدل بعدی ممکن است دستورالعمل‌ها را بسیار بهتر بفهمد، استفاده از ابزارها بهتر شود، Context بسیار بزرگ‌تر شود یا چیزی که امروز برایش پنج Agent و یک جریان پیچیده ساخته‌ایم، چند ماه دیگر تبدیل به قابلیت عادی خود مدل شود.
از آن طرف، کاملا ممکن است مدل‌های آینده آن‌قدر قوی شوند که همین پیچیدگی و بدهی فنی را هم خودشان تشخیص دهند و اصلاح کنند.
واقعیت این است که نمی‌دانیم.
و دقیقا همین «نمی‌دانیم» برای من مهم است.
استدلال من این نیست که ساده بسازیم چون می‌دانیم آینده چگونه خواهد بود. دقیقا برعکس:
ساده بسازیم چون نمی‌دانیم آینده چگونه خواهد بود.
ممکن است پیچیدگی امروز فردا لازم باشد، ممکن است خود هوش‌مصنوعی آن را حذف کند و ممکن است کاملا بی‌استفاده شود. اما چیزی که امروز می‌دانیم این است که پیچیدگی هزینه دارد، سرعت تغییر را کم می‌کند، نگهداری می‌خواهد و می‌تواند Time-to-Market ما را افزایش دهد.
پس چرا امروز برای آینده‌ای که هنوز نمی‌شناسیم، هزینه قطعی پرداخت کنیم؟
در چنین محیطی Optionality خودش یک مزیت معماری است. مدل باید قابل تعویض باشد، پرامپت بتواند کوچک‌تر یا حتی حذف شود، Agent بدون جراحی کل سیستم کنار گذاشته شود و قابلیت نسل بعدی مدل نیازمند بازنویسی نصف اکوسیستم ما نباشد.
شاید به‌جای تلاش برای ساختن «معماری نهایی AI»، بهتر باشد حداقل معماری لازم برای حل مسئله امروز را بسازیم و فضای کافی برای تکامل پیدا کردن فردا باقی بگذاریم.
هدف کسب‌وکار ما نمایش پیچیدگی معماری نیست.
هدف این است که امروز با هزینه کمتر یاد بگیریم، سریع‌تر وارد بازار شویم و فردا حق انتخاب بیشتری داشته باشیم.
به‌نظرم تحول بزرگ‌تر هوش‌مصنوعی اصلا سریع‌تر کدزدن نیست.
هوش‌مصنوعی دارد مرز میان Business، Product، Design، Engineering، Research و حتی جامعه‌شناسی و روان‌شناسی مشتری را کمرنگ می‌کند. نه به این معنی که این تخصص‌ها حذف می‌شوند، بلکه فاصله و تحویل کار میان آن‌ها کمتر می‌شود.
برنامه‌نویس آینده دیگر نمی‌تواند بگوید: «پروداکت‌منیجر تسک را نوشته بود و من هم همان را پیاده کردم.»
او باید بفهمد این قابلیت چه مسئله‌ای از مشتری را حل می‌کند، چرا این راه‌حل انتخاب شده، رقبا چطور مسئله را حل کرده‌اند، آیا اصلا لازم است چیزی ساخته شود، چطور می‌توان فرضیه را قبل از توسعه کامل آزمایش کرد و بعد از انتشار قرار است چه چیزی از بازار یاد بگیریم و اصلا چطور مسئله را به هوش‌مصنوعی بفهمانیم.
همه برنامه‌نویس‌ها قرار نیست پروداکت‌منیجرشوند؛ اما مهندسی که محصول را نفهمد، به‌تدریج تبدیل به مجری تسک‌هایی می‌شود که هوش‌مصنوعی بهتر و ارزان‌تر از او اجرا می‌کند.
به‌نظرم آینده متعلق به Product Engineerهاست؛ افرادی که مسئولیتشان با Merge شدن Pull Request تمام نمی‌شود و از شناخت مسئله و بازار تا طراحی راه‌حل، معماری، پیاده‌سازی، انتشار و سنجش نتیجه را می‌فهمند.
برای همین استفاده از مدل‌های قوی هم فقط برای تولید کد مهم نیست. هوش‌مصنوعی باید در تحقیقات بازار، تحلیل رقبا، شناخت رفتار مشتری، به چالش کشیدن فرضیات، تصمیم‌گیری و حتی پیدا کردن چیزی که نباید بسازیم به ما کمک کند.
اگر تمام استراتژی هوش‌مصنوعی یک شرکت این باشد که «چطور با ارزان‌ترین مدل Feature بیشتری تولید کنیم؟»، احتمالاً فقط Feature Factory فعلی را سریع‌تر کرده‌ایم.
یک Feature Factory مجهز به هوش‌مصنوعی همچنان Feature Factory است؛ فقط با سرعت بیشتری محصول اشتباه می‌سازد. هوش‌مصنوعی نباید فقط فاصله Requirement تا Code را کوتاه کند. باید فاصله مسئله تا یادگیری معتبر از بازار را کوتاه کند.
به همین دلیل فکر می‌کنم مسئله واقعی شرکت‌ها دیگر فقط خرید یک Coding Assistant، آموزش پرامپت یا نصب چند Agent نیست.
شرکت‌ها به یک AI Operating Model نیاز دارند: بدانند کدام مسئله را به کدام مدل بدهند، کجا استفاده از مدل قوی‌تر اقتصادی‌تر است، کجا واقعا Agent لازم دارند و کجا فقط پیچیدگی اضافه میکنند.
باید بدانند چه قسمت‌هایی از سیستم باید کاملا Deterministic باقی بماند و Non-determinism را کجا و چگونه مدیریت کنند. باید برای Context، Evaluation، Security و Human Review تصمیم آگاهانه داشته باشند و مهم‌تر از همه، هوش‌مصنوعی را وارد Product Discovery کنند، نه اینکه کاربرد آن را به Code Generation محدود کنند. و باید اکوسیستمی بسازند که بتواند همراه مدل‌ها تکامل پیدا کند.
فکر نمی‌کنم تفاوت واقعی شرکت‌ها در چند سال آینده در تعداد Agentهایی باشد که نصب کرده‌اند.
تفاوت در این خواهد بود که چه کسی می‌تواند هوش‌مصنوعی را از یک ابزار تولید کد، به یک سیستم ساخت و یادگیری محصول تبدیل کند.
پس شاید برای عقب‌نماندن از هوش‌مصنوعی لازم نباشد هر روز ابزار جدیدی نصب کنیم.
شاید یکی از مهم‌ترین نشانه‌های بلوغ در AI Engineering این باشد که بدانیم چه چیزهایی را نباید اضافه کنیم.
در نهایت سؤال مهم این نیست که چند Agent داریم، چند Skill نصب کرده‌ایم یا Prompt ما چند خط است.
سؤال این است: آیا با هوش‌مصنوعی فقط سریع‌تر کد تولید می‌کنیم، یا سریع‌تر محصول درست را پیدا می‌کنیم و می‌سازیم؟
نوشته شده توسط بهنام محمدی
