تئاتر مهندسی: کدی که فقط ادای مهندسی درمیاره
هوش مصنوعیخلاصهٔ کاملتر
نویسنده از روی اصطلاح آشنای innovation theatre (یعنی وقتی یه شرکت کارهایی میکنه که فقط شکل نوآوری داره، مثل هکاتون بیهدف یا دادن عنوان «مدیر نوآوری» به یه نفر) اصطلاح تازهای ساخته: تئاتر مهندسی. به گفتهٔ او این الگو رو بیشتر تو پروژههایی میبینه که عمدتاً با هوش مصنوعی نوشته شدن و کسی که بالاسرشونه عملاً کار مهندسی رو واگذار کرده.
مثالهایی که میزنه ملموسه: تستی که هیچ چیز معناداری رو نمیسنجه ولی هست چون «مهندس خوب تست مینویسه»، کامنتی که چیزی به فهم اضافه نمیکنه ولی هست چون «کد باید مستند باشه»، فانکشنهای یکخطی که فقط ظاهر ساختار دارن، و README پونصد خطی پر از متن و ایموجی. هیچکدوم ذاتاً بد نیستن؛ چیزی که تبدیلشون میکنه به تئاتر اینه که فقط برای تیک خوردن یه چکلیست تولید شدن.
نویسنده دلیلش رو تو نحوهٔ آموزش مدلها میدونه. ایجنتهای کدنویسی الگوها رو تکرار میکنن و توی دادهای که باهاش آموزش دیدن پر از تست و کامنت و اصطلاحات رایجه. کپی مستقیم نمیکنن، ولی همون الگوها رو با تمایل شدید به «اضافه کردن» روی پروژهٔ تو پیاده میکنن. ساختن نمونهٔ آموزشی که پاداشش «کنار تغییرت یه کامنت و یه تست بذار» باشه خیلی راحتتره، و توصیهٔ کلی سیستمپرامپتها هم بهناچار همینقدر سطحبالاست.
راهحلی که پیشنهاد میده حذف ابزار نیست، دقیقتر کردن قواعده. خودش چند گایدلاین دستنویس ساده جمع کرده:
- پیشفرض: بدون کامنت. کامنت جدید باید از یه سد بلند رد شه.
- فرض کن خواننده یه توسعهدهندهٔ بلده؛ چیزی که خود کد میگه رو تکرار نکن.
- معیار تست: «اگه امروز هیچ تستی نداشتیم، این یکی رو اضافه میکردیم؟»
- ادغام چند تست تو تعداد کمتر ولی محکمتر، نتیجهٔ خوبیه.
- تست و کامنت باید همیشهسبز باشن، نه توجیه یه تصمیم یا روایتسازی.
ولی خودش تأکید میکنه مهمتر از خود این قاعدهها، فرایندیه که بهشون رسیده: لازم نیست تکتک خطهای کد رو بخونی، ولی الگوها و رفتار سیستم رو نگاه کن، هرجا چیزی عجیب یا زیادی بهنظر رسید سؤال کن و بپرس سادهتر هم میشه یا نه، بعد مشاهدهت رو بنویس و روش بساز.
طرف دیگهٔ ماجرا اینه که سطح مهندسی باید با پروژه جور باشه. برای یه سایت الکی و دورانداختنی اصلاً اشکالی نداره کمتر سخت بگیری و بذاری ایجنت هر تست و کامنت بیفایدهای دلش خواست بنویسه، چون هزینهٔ اضافهش جواب نمیده. ولی به گفتهٔ نویسنده اگه چیزی میسازی که قراره دست بقیه بیفته یا حتی بابتش پول بگیری، استانداردت باید بالاتر بره؛ حتی وقتی بیشتر کد رو AI مینویسه، کار ساختن نرمافزار خوب سر جاش هست.
نکات کلیدی:
- «تئاتر مهندسی» یعنی کاری که شکل مهندسی داره ولی فقط برای تیکزدن چکلیست انجام شده
- چهار نشانهٔ رایجش: تست بیخاصیت، کامنت بدون اطلاعات، فانکشن یکخطی تزئینی و README پونصد خطی
- ریشهاش رفتار پیشفرض LLMهاست: بایاس قوی به اضافه کردن کامنت و تست کنار هر تغییر
- معیار پیشنهادی برای تست: «اگه امروز صفر تست داشتیم، این یکی رو اضافه میکردیم؟»
- کامنت پیشفرض نداشته باش؛ کامنت جدید باید سد بلندی رو رد کنه
- سطح مهندسی باید با پروژه جور باشه: پروژهٔ دورانداختنی استاندارد پایینتری میطلبه تا محصولی که دیگران استفاده میکنن
