LLMها جای نرمافزار رو نمیگیرن؛ فقط جلوش میشینن
خلاصهٔ کاملتر
به گفتهی فدریکو توماستی، این سؤال طبیعیه که «همین بود؟ آیا از این به بعد فقط با کامپیوتر حرف میزنیم و همهچیز خودش ظاهر میشه؟» — ولی جوابش نهست. تو این مقاله اومده که نرمافزار حداقل تو چهار چیز هنوز کارش رو میکنه: داده رو سازماندهی و نرمال میکنه، یکپارچگی و ثبات رو تحمیل میکنه، چیزها رو جوری تصویر میکنه که الگوها دیده بشن، و فرایندها رو قدمبهقدم هدایت میکنه — یعنی سالها دانش انباشته دربارهی «درست انجامدادن یه کار» که به شکل اجراشدنی درومده.
نویسنده برای ملموسشدن بحث سراغ یه CRM میره. یه فرصت فروش یه تکه متن آزاد نیست؛ یه رکورده که به یه شرکت وصله، شرکت مخاطب و شماره و ایمیل داره، فیلد منبع سرنخ داره که به انتساب بازاریابی وصل میشه و زنجیرهای تا قراردادهای قبلی میره. همین ساختاره که اجازه میده بپرسی «کدوم فرصتها از معرفی اومدن و تو شش ماه گذشته بالای ۵۰ هزار یورو بسته شدن؟» و جوابی بگیری که تو چند میلیثانیه بیاد و بشه بهش اعتماد کرد — نه یه پاراگراف که فقط قابلقبول به نظر میرسه.
بخش دوم، تحمیل ثبات و یکپارچگیه: نمیتونی فرصتی بسازی که شرکتش وجود نداره، نمیتونی شرکتی رو پاک کنی که قرارداد باز داره. سیستم جلوت رو میگیره یا حذف رو با ترتیب مشخص تو همهی رکوردهای مرتبط آبشاری میکنه. به گفتهی نویسنده همین قواعد ظاهراً آزاردهنده — مثل «تا وقتی قرارداد پیوست نشده، فرصت رو نمیتونی برنده اعلام کنی» — اصطکاک نیستن، قانونن؛ و همونها هستن که نمیذارن دادهت شش ماه بعد به آشغال تبدیل بشه.
نویسنده یه یادداشت تاریخی هم میذاره: دههی ۱۹۷۰، وقتی دونالد چمبرلین و ریموند بویس تو IBM زبان SQL رو طراحی کردن، بخشی از وعدهشون این بود که غیربرنامهنویسها هم بتونن مستقیم ازش استفاده کنن — مدیر چیزی نزدیک به انگلیسی ساده تایپ کنه و جواب بگیره. پنجاه سال بعد هنوز داریم همون وعده رو دنبال میکنیم و هنوز داریم کشف میکنیم که سختیِ کار هیچوقت فقط «رابط کاربری» نبوده.
پس چرا LLM بهتنهایی جای نرمافزار کسبوکار رو نمیگیره؟ چون دادهش رو کجا نگه میداره؟ هیچجا. مدل نه اسکیما داره، نه کلید خارجی، نه تراکنش، نه محدودیت. تو خیلی از ایجنتها، «حافظه» یه مشت فایل و یادداشته که بین جلسهها خونده و نوشته میشه؛ ولی یادداشت تضمین نمیکنه هر فرصت یه شرکت داشته باشه و تضمین نمیکنه عددی که امروز میگیری با عدد فردا یکی باشه. و اگه جواب از اون یادداشتها قابلاستخراج نباشه، مدل بازم جواب میده — جوابی که قابلقبول به نظر میرسه. نویسنده میگه همین رو ببر به سازمان مالیاتی و ببین چی میشه.
نمونهی واقعیش پروندهی Moffatt v. Air Canada (فوریهی ۲۰۲۴، CRT 149) بود: چتبات شرکت به مسافر گفت بلیت رو کامل بخره و بعداً تخفیف سوگ رو درخواست کنه — درست برخلاف قوانین منتشرشدهی خود شرکت. دفاع ایر کانادا این بود که چتبات مسئول حرفهای خودشه، دادگاه قبول نکرد و شرکت محکوم به پرداخت غرامت شد. به گفتهی نویسنده کل مسئله همینه: یه جدول سیاست قطعی، دقیقاً یه جواب برمیگردوند؛ رابط گفتوگویی که اون جدول رو نداشت، جواب رو بداهه ساخت.
راهحل هم فشردن دیتابیس توی وزنهای مدل نیست، ساختن پل به دیتابیسیه که همین الان وجود داره: اولش با tool calling و حالا با Model Context Protocol — همون چیزی که «USB-C دنیای AI» صداش میکنن. سیلزفورس CRMش رو دوباره به شکل چتبات نساخت، MCP رو به Agentforce اضافه کرد؛ اطلسین هم Jira و Confluence رو تو گفتوگو حل نکرد، یه سرور MCP از راه دور ساخت. جهت حرکت رو ببین: اینها محصولشون رو تو LLM حل نمیکنن، دارن به مدلها راه کنترلشده میدن که به سیستمهای موجود دست بزنن. یعنی LLMها دارن جذب نرمافزار میشن، نه برعکس. جمعبندی نویسنده اینه که نرمافزار جایگزین نمیشه، فقط درِ ورودیش عوض میشه — و تو سیستمهای واقعی کسبوکار، همون حفاظهای قطعی بخش بزرگتر سیستم میمونن و LLM تو یه محدودهی تعریفشده کار میکنه.
نکات کلیدی:
- نرمافزار چهار کار میکنه: نرمالسازی داده، تحمیل یکپارچگی، تصویرسازی و هدایت فرایند — و LLM هیچکدومشو ذاتاً نداره
- مدل زبانی نه اسکیما داره، نه تراکنش، نه تضمین اینکه جواب امروز و فردا یکی باشه
- پروندهی Moffatt v. Air Canada نشون داد جواب بداههی چتبات، مسئولیت حقوقی شرکت رو از بین نمیبره
- MCP و tool calling نشونهی جهت واقعی حرکتن: مدلها به سیستمهای ساختارمند وصل میشن، نه اینکه جاشون رو بگیرن
- کار سخت هنوز همون تحلیل دامنهست: تعریف قواعدی که هیچوقت نباید شکسته بشن و مرزی که بعد از اون میشه به مدل اعتماد کرد




