وقتی کد دیگه مهم نیست: مهندسی نرمافزار در عصر LLM
هوش مصنوعیخلاصهٔ کاملتر
اگه یه سازمان بهصورت رسمی تصمیم بگیره که از LLMها برای تولید کد استفاده کنه و زمان کدنویسی دستی رو به حداقل برسونه، این یه محدودیت جدیده که میشه باهاش کار کرد. نویسنده استدلال میکنه که در این حالت، کد تولیدشده توسط هوش مصنوعی میتونه مثل اسمبلی یا bytecode باشه — چیزی که مستقیم باهاش کار نمیکنیم، بلکه ابزارها تولیدش میکنن.
مشکل اینجاست که LLMها خروجی غیرقطعی دارن و کد رو خیلی سریعتر از اینکه بشه خوندش تولید میکنن. پس بررسی و تأیید هر diff بهصورت جدی دیگه ممکن نیست. اما این به معنی بیدقتی نیست؛ یعنی باید دقت رو جای دیگهای اعمال کرد.
نکته مهم اینه که این تغییر نمیتونه یه تصمیم فردی یا تیمی باشه — باید کل سازمان تغییر کنه. به خاطر قانون آمدال (Amdahl's Law)، اگه فقط سرعت تولید کد رو بالا ببریم بدون اینکه ساختارهای سازمانی رو تغییر بدیم، هیچ سود واقعی در بهرهوری نخواهیم داشت. نمیشه یه نفر روزانه ۲۰ هزار خط کد تولید کنه و انتظار داشت بقیه تیم همهاش رو بخونن و تأیید کنن.
در عوض، باید گلوگاههای انسانی، هماهنگیهای اضافه، بروکراسی و تأیید دروازهای رو حذف کرد. برنامهنویسها باید نقشی شبیه به طراح محصول پیدا کنن — صاحب کامل یه جریان کاری باشن و بتونن تصمیمهای مستقل بگیرن. چون بازنویسی تقریباً رایگانه، نیازی نیست انرژی زیادی صرف پیشگیری از کارهای اشتباه بشه.
پس دقت مهندسی باید به مشخصات (Specification) و تستها منتقل بشه. نویسنده پیشنهاد میکنه یه فایل Markdown استاندارد بهعنوان واحد اصلی دانش پروژه تعریف بشه. Product Owner و برنامهنویسها روی این spec و روی test caseهای مربوط به قوانین کسبوکار همکاری میکنن. این فایلها کنار کد در مخازن پروژه نگهداری میشن و بررسیهای خودکار pull request تأیید میکنن که کد با spec مطابقت داره.
در این مدل، spec چیزیه که تیم باید بفهمه، بررسی کنه و مسئولیتش رو بپذیره — نه کدی که LLM تولید کرده. این رویکرد مسئولیتپذیری رو حفظ میکنه، ولی آن رو به لایهای منتقل میکنه که انسانها واقعاً میتونن کنترلش کنن.
نکات کلیدی:
- LLM کد رو سریعتر از اون تولید میکنه که بشه خوندش، پس بررسی خطبهخط دیگه واقعبینانه نیست
- این تغییر باید یه تصمیم سازمانی باشه، نه فردی، چون بدون تغییر ساختار سازمانی سود واقعی نداریم
- دقت مهندسی باید از کد به مشخصات (spec) و تستها منتقل بشه
- برنامهنویسها باید نقش طراح محصول و مالک جریان کاری رو پیدا کنن
- spec استاندارد Markdown واحد اصلی دانش پروژه میشه و باید کنار کد در مخزن نگهداری بشه
