پستون‌ واکینگ دولوپمنت: سبک جدید مدیریت پروژه با LLM!

فعلا در روی پاشنه ی AI داره می‌چرخه ، هوش مصنوعی و مدل‌های زبانی بزرگ (LLMها) این روزها نقل هر مجلسی هستن. مدیرها و توسعه‌دهنده‌ها با شور و هیجان از “تحول دیجیتال با AI” حرف می‌زنن و بعضی پروژه‌ها بدون اینکه نیاز واقعی داشته باشن، چپ و راست چت‌بات و LLM به خودشون می‌بندن.

من اسم این سبک پیشرفت پروژه رو میذارم “پستون واکینگ دولوپمنت” ! یعنی پروژه تبدیل می‌شه به موجودی عجیب و غریب، درست مثل گاوی که روی پستون‌هاش داره راه می‌ره، ظاهراً در حال حرکته، اما واقعاً ناجور و ناپایدار! آمارها هم این جوّ زدگی رو تأیید می‌کنن؛ چیزی حدود ۷۰ تا ۸۵ درصد پروژه‌های AI به اهداف مورد انتظارشون نمی‌رسند که خیلی بیشتر از نرخ شکست پروژه‌های معمولی فناوریه. این یعنی خیلی از ما فقط به خاطر مد و موج، سراغ AI می‌ریم و اصل کار یادمون میره.

هرجا قطعیت لازمه ، لطفا بذار رو پاش راه بره!

یکی از آفت‌های معمول، استفاده از LLM در قسمت‌هایی از پروژه ست که اصلاً نیازی به هوش مصنوعی نداره و خروجی ۱۰۰٪ قطعی و قابل اتکا می‌خواد. مثلا فکر کن برای یک محاسبه ساده یا یه منطق تجاری سرراست (چیزی که راحت با چند خط کد یا یک تابع شرطی حل می‌شه) بیاییم یک مدل زبانی رو صدا بزنیم. مدل زبانی بر پایه احتمالات و حدس‌های زبانی جواب میده، نه منطق قطعی. نتیجه ممکنه هر بار فرق کنه یا حتی اشتباه باشه. به قول معروف، وقتی چکش دستته همه‌چیزو میخ می‌بینی ! این‌روزها هم انگار بعضی‌ها وقتی LLM دستشونه، همه مسائل رو مسئله زبان طبیعی می‌بینن. پروژه‌ای که باید محکم و استوار باشه، با این کار روی یک پایه ناپایدار قرار می‌گیره.

جایی که دقت و قطعیت لازم داریم، نباید کار رو بسپریم دست یه مدل زبانی. وقتی یه قسمت سیستم نیاز داره همیشه جواب ثابت و درست بده (مثلا تبدیل واحد پول، محاسبه مالیات، اعتبارسنجی رمزعبور و از این قبیل)، استفاده از LLM اشتباهی مهلکه. چون LLM ممکنه همون سوال یا ورودی رو یک بار درست جواب بده و دفعه بعد غلط! خود ChatGPT هم اگر دقت کنید، وقتی با یه مسأله کاملاً ریاضی مواجه می‌شه، ممکنه بره یه کد پایتون یا فرمول بده که یعنی “خودم نمی‌تونم مستقیم حساب کنم، بزار با کدنویسی حلش کنیم!”. دلیلش اینه که ساختار LLM برای فهم زبان و الگوهای متنیه، نه محاسبات عددی دقیق. برای چنین کارهایی راه‌حل اصولی‌تر و مطمئن‌تر استفاده از الگوریتم‌های کلاسیک برنامه‌نویسی یا روش‌های قطعی خودمونه، نه یه مدل زبان‌محور که هر لحظه ممکنه حال و هوای دیگه‌ای داشته باشه.

پیش‌بینی آماری با شعر و شاعری؟

فرض کنید می‌خوایم قیمت یک کالا رو برای هفته آینده پیش‌بینی کنیم. راه حل منطقی چیه؟ استفاده از مدل‌های آماری یا ML مثل رگرسیون، شبکه عصبی تخصصی زمان-سری و … که با داده‌های تاریخی آموزش دیدن. ولی بعضی‌ها میان به جای این کار، یک LLM مثل ChatGPT رو صدا می‌زنن: “قیمت طلا هفته بعد چند می‌شه؟”. خوب ChatGPT شاید یه عددی بده، ولی این عدد روی هواست؛ چون LLM نه داده‌ی زمان-سری شما رو دیده، نه مدلش برای این کار ساخته شده. دفعه بعد هم دوباره همون سوالو بپرسی ممکنه یه جواب دیگه بده. هیچ دقت آماری و قطعیتی نداره و عملاً داری پیش‌بینی رو تبدیل به رمل و اسطرلاب می‌کنی.جایی که باید از یادگیری ماشین (Machine Learning) یا محاسبه ی آماری واقعی استفاده بشه، اما اشتباهاً LLM رو به کار می‌گیری.

جایگزین کردن الگوریتم‌های ریاضی کلاسیک با LLMها در وظایف محاسباتی (مثل پیش‌بینی سری‌های زمانی) نه تنها لازم نیست، بلکه ریسکه. مدل‌های تخصصی آماری هنوز هم تو کارهای عددی و تحلیلی حرف اول رو می‌زنن و باید به اون‌ها رجوع کنیم. پس به جای اینکه بخش‌های Data Science پروژه‌مون رو بدیم دست یک مدل زبانی که مثل شعر گفتن می‌مونه برای حل مسأله آماری! ، بهتره از مدل‌هایML استاندارد یا روش‌های آماری استفاده کنیم.

کدی که خودت هم نمی‌فهمی از کجا اومده!

یکی از وسوسه‌های بزرگ برای برنامه‌نویس‌ها، استفاده از ChatGPT و امثال اون برای تولید کل کده. قبول داریم که LLMها توی تولید قطعه‌کد و کمک به برنامه‌نویسی فوق‌العاده پیشرفت کردند؛ اما مشکل از جایی شروع می‌شه که توسعه‌دهنده کدی رو که AI نوشته، بدون درک عمیق همون‌طور وارد پروژه کنه. در نگاه اول، کدی که یک LLM تولید می‌کنه خیلی تمیز و وسوسه‌انگیزه: اسم متغیرها معرکه، کامنت‌ها مرتب، ساختار منطقی و خوانا. همین ظاهر عالی ممکنه ما رو گول بزنه و حس امنیت کاذب ایجاد کنه که “به‌به، چه کد تمیزی، پس حتماً درسته”. در حالی که ممکنه همون کد تمیز، یه جای منطقش ایراد اساسی داشته باشه که نه خطای کامپایلر می‌ده نه چیز دیگه ، ولی نتیجه ی اشتباه تحویل می‌ده. اگر ندونیم دقیقاً کد چی می‌گه، چطور می‌تونیم این ایرادهای مخفی رو پیدا کنیم؟

برنامه‌نویسی که منطقی که AI نوشته رو نشناسه، مثل کسیه که یک گاو نر رو بندازه وسط فروشگاه ظروف چینی! هر لحظه باید منتظر شکستن یه چیزی باشه!

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

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

از خشت اول تا ثریا ، منطق پروژه با LLM

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

یه خطر دیگه اینه که LLM گاهی با اطمینان کامل راه‌حل غلط می‌ده. شما می‌بینی ChatGPT گفته این معماری “best practice” هست و چون خیلی هم با اعتماد به نفس توضیح داده، ممکنه شک نکنید. اما AI ممکنه صرفاً چیزهایی که خونده رو کنار هم چیده باشه بدون اینکه تضمینی برای درست کار کردنش در شرایط شما باشه. حتی اگه جوابش منطقی به نظر برسه، عدم درک زمینه و نیازمندی‌های خاص پروژه می‌تونه فاجعه به بار بیاره. طراحی سیستم چیزیه که به دانش ضمنی، تجربه و خلاقیت نیاز داره؛ در حالی که مدل زبانی خلاقیتش محدوده به همون الگوهای موجود در دیتاست عظیمش و ممکنه نوآوری یا ملاحظات ظریف رو درک نکنه. برای همین اگه ما کورکورانه معماری یا منطق اصلی رو از چت‌بات بگیریم، انگار که اسکلت ساختمون رو با مقوا بسازیم. در ظاهر سرپاست ولی با یک باد تند ممکنه فرو بریزه.

استفاده از LLM می‌تونه برای ایده‌گرفتن یا بررسی گزینه‌ها مفید باشه، ولی در نهایت آدمیزاد باید تصمیم نهایی طراحی رو بگیره و صحت‌سنجی کنه. LLM هیچ وقت جایگزین تجربه مهندسی و تفکر انتقادی ما نمی‌شه. پس به جای اینکه افسار پروژه رو کامل بدیم دست AI، بهتره AI رو یه مشاور ببینیم که حرف میزنه اما رانندگی رو خودمون باید انجام بدیم!

دو باگ فیکس کن، سه تای دیگه بزا!

اگه توسعه نرم‌افزار را تجربه کرده باشید، می‌دونید که رفع باگ یک هنر حساسه. حالا تصور کنید کد اصلی رو AI نوشته یا بخش بزرگی از منطق رو هر بار با پرس‌وجو از مدل زبانی تغییر می‌دید. ممکنه اول کار سریع جلو بره (معروف به توسعه به سبک «وایب کدینگ» با AI)، اما به زودی پروژه میوفته تو یه دور باطل: هر تغییری که با کمک AI می‌دید، دو جای دیگه رو خراب می‌کنه! چون مدل زبانی دید سراسری و درک کامل از کل کدبیس شما نداره. حافظه محدودی داره و اگر قطعه‌ای رو جداگانه بهش بدید، تغییراتی پیشنهاد می‌کنه که شاید جای دیگه ناسازگاری ایجاد کنه. همین باعث می‌شه باگ‌گیری بشه بازی موش و گربه.

“من تا حالا ندیدم یه اپلیکیشن که کدش رو LLM تولید کرده باشه، بعد از چند دور اصلاحات از هم نپاشه!”

این مدل‌ها بعد از چند بار iterating مدام تو loop میفتن و یک چیز رو هی اضافه و حذف می‌کنن یا روی یک خطای ساده گیر می‌کنن. آخرسر مجبور میشی خودت دست به کار بشی و فیچر جدید رو مستقیماً کدنویسی کنی، چون حتی اگر LLM بتونه کاری انجام بده، هزینه و زمان تلف‌شده بابت چرخیدن‌های بی‌حاصل ارزششو نداره. خلاصه تا بیای یک باگ رو با AI حل کنی، سه تای دیگه برات میزاد و اصلاح اون‌ها دوباره مدل رو گیج می‌کنه.

پس اگه نمی‌خواید پروژه‌تون مثل هیدرا (اژدهایی که هر سرش رو بزنی دو تا جایگزین در میاره) بشه، در فرآیند توسعه با AI حتماً کنترل کیفی و تست مداوم رو فراموش نکنید. هر خروجی AI رو مثل کد یک برنامه‌نویس جونیور در نظر بگیرید که نیاز به بازبینی ارشد داره. هر تغییر رو در context بزرگ‌تر برنامه بررسی کنید. شاید حتی لازم باشه گاهی به AI بگید “بسه! برو کنار بذار خودم انجام بدم” تا از لوپ باطل خارج بشید.

هزینه‌های پنهان و مدیرانی که فریب می‌خورند

مسئله فقط فنی نیست؛ مدیریت و هزینه هم مطرحه. اضافه کردن بی‌دلیل AI به یه محصول یا پروژه می‌تونه هزینه‌های سرویس ابری و API رو بالا ببره، زمان توسعه رو بیشتر کنه و تازه رضایت کاربر نهایی رو هم کاهش بده.

این مدت خیلی دیدم که تصمیم‌گیرنده‌ها چقدر محصول ناقص AI-محور رو به بهونه نوآوری توجیه می‌کنن. غافل از اینکه چنین تجربه بدی برای کاربر مساوی ضربه به اعتبار محصول و هزینه‌های مالی (پشتیبانی، از دست دادن مشتریان) و … میشه!

از اون طرف، طبق آمارها خیلی از پروژه‌های پر سروصدای AI عملاً ارزش افزوده محسوسی ایجاد نمی‌کنن و منابع شرکت رو می‌سوزونن. دلیلش اینه که یا جای درستی به کار نرفتن، یا زیرساخت داده مناسبی نداشتن، یا اساساً مشکل نیازمند AI نبوده ولی بخاطر جوّ، مدیر ها اصرار کردن که یه AI توش بچپونن. این سندرم “ما هم از قافله عقب نمونیم” در بین مدیران خیلی شایع شده. طرف می‌بینه بقیه شعار AI می‌دن، احساس می‌کنه اگه تو محصولش یه هوش مصنوعی چیزی نچپونه از دنیا عقبه. غافل از اینکه AI مثل هر فناوری دیگه دو لبه است: استفاده آگاهانه و به‌جا می‌تونه بهره‌وری رو بالا ببره، اما استفاده نابجا فقط هزینه و پیچیدگی اضافه می‌کنه.

هر چیزی به جای خود!

هوش مصنوعی و به‌خصوص مدل‌های زبانی بزرگ ابزارهای فوق‌العاده قدرتمندی هستند که در جای درست خودشان معجزه می‌کنن. اما همون‌طور که یک گاو برای راه رفتن به چهار تا پای سالم نیاز داره، یک پروژه هم برای موفقیت به پایه‌های فنی درست و تصمیمات سنجیده نیازمنده. اگر بی‌محابا هر مشکلی رو با چکش LLM بکوبیم، خیلی زود متوجه می‌شیم که پروژه‌مون تعادل نداره و داره روی پستون‌هاش قدم برمی‌داره!

برای جلوگیری از این وضعیت:

• نیازسنجی دقیق انجام بدیم و ببینیم آیا واقعاً AI لازم داریم یا نه. اگه راه حل ساده‌تر و مطمئن‌تری هست، اول همونو اجرا کنیم.

• متخصص رو با LLM جایگزین نکنیم، هوش مصنوعی باید کمک‌کننده باشه نه جای تفکر مهندسی رو بگیره.

• صحت‌سنجی و آزمایش رو فراموش نکنیم. هر خروجی AI چند بار باید آزمون خودش رو پس بده قبل از اینکه وارد محصول بشه.

• داده و زمینه رو جدی بگیریم. اگر قراره مدلی رو جایی استفاده کنیم، مطمئن بشیم داده‌های کافی و باکیفیت و زیرساخت پشتیبان وجود داره

• منتقد و شکاک باشیم. هر چی ChatGPT با اطمینان گفت لزوماً صحیح یا بهینه نیست. خودمون رو عادت بدیم که خروجی‌های AI رو به چالش بکشیم و تحقیق مکمل انجام بدیم.

در نهایت، قرار نیست با شنیدن این حرف‌ها از AI فرار کنیم؛ اتفاقاً باید یاد بگیریم چطور هوشمندانه و به‌اندازه ازش بهره ببریم. مدیر پروژه موفق اونیه که می‌دونه کجاها باید قدرت هوش مصنوعی رو به کار بگیره و کجاها نباید. ترکیب نیروی انسانی خبره و ابزار مناسب AI قوی‌ترین ترکیبه، به شرطی که برای پروژه پا طراحی کنیم که با اونا راه بره ، افسار گاو رو هم بگیریم دست خودمون!