سختترین بخش توسعهٔ هوش مصنوعی کدنویسی نیست، بلکه داشتن انضباط برای متوقف کردن طراحی معماری و شروع عرضه است. اگر هنوز ساعتها وقت خود را صرف انتخاب کاملترین استک فنی میکنید، احتمالاً در حال ساختن محصولی هستید که هرگز از پوشهٔ محلی (Local Folder) شما خارج نخواهد شد. بسیاری از توسعهدهندگان مستقل بهاشتباه پیچیدگی فنی را با ارزش محصول یکی میدانند. آنها تصور میکنند ارکستراسیون پیشرفتهتر مدلها لزوماً تجربه کاربری بهتری خلق میکند؛ اما در واقعیت، این طرز تفکر شکافی ایجاد میکند که در آن هفتهها صرف زیرساخت میشود در حالی که مشکل واقعی کاربر همچنان حلنشده باقی میماند. همانطور که در تحلیلهای قبلی ما درباره امنیت مدلهای بازمتن اشاره کردیم، تعادل بین کنترل فنی و سرعت عرضه، مرز بین یک ابزار کاربردی و یک پروژه رهاشده است.
به نقل از یادداشتی که در ۱۵ ژوئیه ۲۰۲۶ در پلتفرم dev.to منتشر شد، برای عرضهٔ سه محصول در ۶۰ روز، باید انضباط شدیدی در برابر «تلهٔ معماری» داشت. برای اکثر هکرهای مستقل، وسوسهٔ ساخت یک ابزار «چاقو سوئیسی» (Swiss Army knife) منجر به شکست فوری میشود. توسعهدهنده باید یاد بگیرد که چگونه از این تله بگریزد تا ایدههایش به واقعیت تبدیل شوند. این رویکرد در سه مطالعهٔ موردی بهوضوح دیده میشود:
نخستین پروژه، یک ربات خلاصهساز برای Slack بود. این پروژه ثابت کرد که کاربران به نتایج اهمیت میدهند، نه به نحوهٔ ارکستراسیون. مشکل ساده بود: رشته-گفتگوهای (Threads) طولانی در یک جامعهٔ کاربری دفن میشوند و کاربران از خواندن تاریخچههای ۲۰۰ پیامی اجتناب میکنند. در حالی که «نسخهٔ رویایی» توسعهدهنده شامل یک تولید بازیابیافزا (RAG) — مثل دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — مدلهای تنظیم دقیق (Fine-tuning) و یک سیستم حافظه پیچیده بود، واقعیت این بود که محصول باید در یک آخر هفته آماده میشد.
بهجای سیستمهای حافظه پیچیده، از یک اسکریپت ساده پایتون استفاده شد تا ۵۰ پیام آخر از طریق یک فراخوانی requests.post به مدل gpt-3.5-turbo فرستاده شود که در یک هندلر دستور-اسلش (slash command) در اسلاک قرار داشت. این کار نیاز به پایگاهداده برداری (Vector Database)، جاسازیها (Embeddings) یا LangChain را کاملاً حذف کرد و جریان کاربر را در یک آخر هفته تأیید کرد. این ربات امروز هم فعال است چون کاربر فقط خلاصه را میخواهد، نه چارچوب عاملمحور (Agentic Framework) پشت آن را.
دومین مورد، ربات بررسی PR در GitHub بود که بهدلیل «تورم ویژگیها» (Scope Creep) نزدیک بود شکست بخورد. هدف اولیه یک کامنت ساده روی Pull Requestها بود، اما پروژه به یک نمونه اولیه عظیم تبدیل شد. توسعهدهنده تلاش کرد تا ربات بتواند:
- کل زمینهٔ کدبیس (Codebase Context) را درک کند.
- تغییرات کد مشخصی را پیشنهاد دهد.
- آسیبپذیریهای امنیتی را شناسایی کند.
- برای تغییرات، تست بنویسد.
طبق گزارش توسعهدهنده، پس از دو هفته کار، سیستم چنان پیچیده شد که عرضهٔ آن غیرممکن بود. پروژه تنها زمانی نجات یافت که تمام پیچیدگیها حذف و یک حلقه منطقی ۳۰ خطی با مدل gpt-4o-mini از طریق یک GitHub Action جایگزین شد. پرامپت جدید بهطور مشخص دستور داد که هوش مصنوعی «تنها» روی باگهای بحرانی، آسیبپذیریهای امنیتی و خطاهای منطقی تمرکز کند و ایرادات ظاهری و استایلی (Style Nitpicks) را نادیده بگیرد. این درس حیاتی بود: تورم ویژگیها سریعترین راه برای کشتن یک پروژه جانبی است.
سومین پروژه، یک ابزار جستوجوی پایگاه دانش شخصی بود که هزینهٔ «ایگوی زیرساختی» (Infrastructure Ego) را برملا کرد. هدف این بود که یادداشتها، مقالات و تکههای کد (Code Snippets) ایندکس شوند تا بتوان درباره آنها سوال پرسید. توسعهدهنده سه روز کامل را صرف میزبانی شخصی مدلهای باز با استفاده از llama.cpp، ONNX و کوانتش وزنها (Weight Quantization) روی سرورهای ارزانقیمت ابری کرد.
نتیجه سیستمی کند و ناپایدار بود که زیر فشار کرش میکرد. این تجربه یادآور شد که اجاره واحد پردازش گرافیکی (GPU) — که شبیه پرداخت کرایه یک آشپزخانه صنعتی برای پختن یک غذای ساده است — و عیبیابی خطوط استنتاج (Inference)، اغلب تنها باعث حواسپرتی از حل مشکل واقعی کاربر میشود.
سوییچ به یک API مدیریتشده، مشکل را فوراً حل کرد و دقیقاً ۱۲.۴۷ دلار هزینه داشت تا مفهوم محصول پیش از نوشتن حتی یک خط کد بکاند برای اپلیکیشن وب تأیید شود. این ثابت کرد که زمان توسعهدهنده به مراتب گرانتر از اعتبار API است. برای مدیریت راحتتر و دوری از مدیریت چندین کلید (API Key) و نگرانی برای آپتایم (Uptime)، در نهایت از tai.shadie-oneapi.com استفاده شد؛ یک تجمعیکننده با مدل پرداخت به میزان مصرف (Pay-as-you-go) که درخواستها را به بهترین مدلهای موجود هدایت میکند. این زیرساخت خستهکننده اما قابل اعتماد، به توسعهدهنده اجازه داد تا به جای لولهکشی، روی منطق محصول تمرکز کند.
واقعیت این است که کدنویسیِ AI تنها ۲۰٪ از تلاش لازم برای عرضه است. ۸۰٪ باقیمانده کارهای غیر-AI هستند که اغلب در فاز معماری فراموش میشوند:
- طراحی یک صفحه فرود (Landing Page) کاربردی که ظاهر بدی نداشته باشد.
- پیادهسازی احرازهویت (بهویژه استفاده از Magic Links برای سادگی).
- تعریف طرحهای ساده پایگاهداده با استفاده از Neon یا Supabase.
- اطلاعرسانی واقعی به مردم درباره اینکه چنین محصولی وجود دارد.
میزبانی شخصی و عیبیابی خطوط استنتاج تنها زمانی اولویت دارد که در مقیاس بسیار عظیم فعالیت کنید. برای هر کسی غیر از آنها، این وظایف صرفاً عامل حواسپرتی هستند. وقتی روی «لولهکشی» متمرکز میشوید، تمرکز خود را بر روی درد کاربر از دست میدهید. این چالش در سایر حوزههای عملیاتی نیز تکرار میشود؛ برای مثال، در دنیای تجارت الکترونیک نیز پیچیدگیهای عملیاتی و عدم اتوماسیون زنجیره تأمین میتواند منجر به شکست سریع کسبوکارهای نوپا شود.
این رویکرد، تعریف موفقیت در پروژههای AI را از «ظرافت فنی» به «سودمندی برای کاربر» تغییر میدهد. تکرار روی یک ابزار کوچک، زشت اما کاربردی، دادههای بیشتری نسبت به یک نمونه اولیه بینقص میدهد که هرگز به دست کاربر نمیرسد. مانع عرضه، تکنولوژی نیست، بلکه داشتن انضباط برای اجازه دادن به یک محصول کوچک برای نفس کشیدن است.
وسواس روی انتخاب مدل کامل را کنار بگذارید و با حل یک نقطه درد (Pain Point) اصلی شروع کنید. رقابت واقعی بر سر این نیست که چه کسی بهترین خط لوله RAG را دارد، بلکه بر سر این است که چه کسی محصولی عرضه میکند که مردم واقعاً از آن استفاده کنند.
گام بعدی شما
- اگر در حال طراحی معماری پیچیده هستید، همین امروز آن را کنار بگذارید و با یک API ساده، هسته اصلی مشکل را حل کنید.
- لیست ویژگیهای محصول خود را بررسی کرده و هر چه «تزیین فنی» است را حذف کنید تا فقط یک ارزش کلیدی باقی بماند.
- بهجای میزبانی شخصی مدلها، از تجمعیکنندههای API استفاده کنید تا زمان خود را صرف تجربه کاربر کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو