چرا اتوماسیون نرمافزار اونقدرها ساده نیست
هوش مصنوعیخلاصهٔ کاملتر
این پست رو silentbob نوشته، کسی که نزدیک ۱۵ سال برنامهنویسی کرده و با Github Copilot و Claude Code هم بهصورت شخصی و هم کاری کار کرده. نویسنده میگه agentهای کدنویسی از پارسال یه جهش بزرگ داشتن و خیلی کارها که قبلاً ممکن نبود رو الان شدنی کردن، ولی یه فاصلهٔ بزرگ بین اینکه مردم فکر میکنن این ابزارها باید چقدر صنعت نرمافزار رو زیر و رو کنن و اون چیزی که واقعاً داره اتفاق میافته وجود داره. حرف اصلیش اینه که این برتری برای فرد یا تیم کوچیک درسته ولی برای سازمان بزرگ نه.
به گفتهٔ نویسنده بزرگترین گلوگاه contextـه. آدمها کلی دانش پسزمینه دارن که خودشون هم لزوماً بهش آگاه نیستن (چیزی که بهش میگه «unknown knowns») و دقیقاً وقتی لازم بشه تو ذهنشون حاضر میشه. context یه LLM با کلمه نوشته میشه، ولی context آدم بیشتر شبیه بردارهای embeddingـه؛ کلمهها بازنمایی خوبی نیستن و هرچی بخوای ظرافت بیشتری توشون بذاری، حجمشون منفجر میشه. خیلی از اطلاعات اصلاً تو خود کد نیست: دلیل یه تصمیم، چیزی که تو یه جلسهٔ حضوری گفته شده، یا محدودیتهایی که آدمها بهمرور یاد میگیرن.
نکتهٔ دیگهای که نویسنده روش تأکید میکنه non-functional requirementsـه. آدمها معمولاً نیازمندیهای کارکردی رو تو prompt مینویسن، ولی چیزایی مثل performance، دسترسیپذیری، UX و محدودیتهای امنیتی رو که فازیان و نیاز به trade-off دارن، جا میندازن. agent هم اونقدر context نداره که خودش این تصمیمها رو خوب بگیره و اگه هی بپرسه، سرعت کلاً میخوابه.
به نظر نویسنده agentها ذاتاً مجبورن کلی فرض بزنن، وگرنه اگه سر هر چیزی بخوان تأیید بگیرن، اصلاً کاری پیش نمیره. این جهشزدن به نتیجه یه ویژگیه نه یه باگ، ولی همین گاهی باعث فرضهای غلط میشه که وقت زیادی رو هدر میده. این مشکل بهنظرش راهحل کامل نداره چون یه trade-off بنیادیه.
نویسنده میگه تکیهٔ زیاد روی این agentها بدهی فنی جمع میکنه و مهندسها «theory of the code» خودشون رو از دست میدن. agentها مشکلها رو با حدس و تصویر ناقص حل میکنن و بهجای راهحل تمیز، وصلهٔ موضعی میزنن. حالا که هر developer چند instance از agent رو روی یه codebase میفرسته، این آشفتگی چند برابر میشه. نگرانی جدیترش افت شناختیه: آدم میتونه مسئلهٔ سخت رو بدون فهمیدنش حل کنه و کمکم اون مهارت فهمیدن رو از دست بده؛ بعضیها وقتی بدون agent کار میکنن یهجور «brain fog» رو گزارش کردن.
نکتهٔ اقتصادیش هم جالبه: نویسنده معتقده سرعت بیشتر لزوماً به درآمد بیشتر ترجمه نمیشه. یه شرکت با ۲۰ میلیون دلار ARR که سرعت توسعهش رو ۵ برابر کنه، معلوم نیست حتی ذرهای ARRش بالا بره. خروجی بیشتر برای بقیه (بازبینی کد، باگ، پشتیبانی، سازگاری) کار میسازه، و سرعت بالا کیفیت تصمیمهای استراتژیک رو پایین میاره چون بازخورد بازار هنوز با سرعت انسانی میاد.
نویسنده «bull case» رو هم منصفانه طرح میکنه: شاید پنجرههای context بزرگتر بشن، continual learning حل بشه، بازنویسی کد ارزونتر بشه و startupهایی که از اول با مستندسازی استاندارد و کانالهای ارتباطی LLM-friendly ساخته میشن، سازمانهای قدیمی رو شکست بدن. ولی جمعبندیش اینه که این چالشها غیرقابلحل نیستن اما واقعیان، و خیلی از سازمانها دارن روی این فرض که agentها سریعتر از انباشت مشکلات پیشرفت میکنن، قمار بزرگی میکنن.
نکات کلیدی:
- برتری agentهای کدنویسی برای فرد و تیم کوچیک واقعیه ولی تو سازمان بزرگ کمرنگ میشه
- گلوگاه اصلی context و الزامات نانوشتهست که آدمها دارن و LLM نداره
- فرضزدن agentها یه trade-off بنیادیه، نه باگی که لبها زود حلش کنن
- تکیهٔ زیاد، بدهی فنی جمع میکنه و توان فهم مهندسها رو پایین میاره
- سرعت بیشتر لزوماً درآمد بیشتر نیست؛ کیفیت تصمیم استراتژیک مهمتره
