#AI_Software_Engineering
یه چیزی که این روزها بیشتر از خود AI ذهنم رو درگیر کرده، اینه که هزینه‌ی تغییر دادن کد داره به‌شدت کم میشه.
قبلاً وقتی می‌خواستی یک تغییر نسبتاً بزرگ روی یک سیستم انجام بدی، اول باید با خودت کنار می‌اومدی که:
چند روز باید Codebase رو بخونم؟
کدوم قسمت‌ها تحت تأثیر قرار میگیرن؟
چقدر Refactor لازمه؟
چندتا Test ممکنه بشکنه؟
و اصلاً ارزشش رو داره یا نه؟
همین هزینه باعث می‌شد خیلی از تغییرها اتفاق نیفتن.
نه لزوماً چون تصمیم اشتباهی بودن.
چون هزینه‌ی بررسی و انجامشون زیاد بود.
الان اما یه Codebase بزرگ رو میدی به یک Agent و میگی:
«این بخش رو بررسی کن، Dependencyهاش رو پیدا کن، این تغییر رو اعمال کن و Testها رو هم درست کن.»
چند دقیقه بعد، یک PR آماده داری.
و به نظرم اینجا یک خطر جدید به وجود میاد.
قبلاً یکی از سؤال‌های اصلی این بود:
«آیا واقعاً می‌تونیم این تغییر رو انجام بدیم؟»
الان بیشتر باید بپرسیم:
«آیا واقعاً باید این تغییر رو انجام بدیم؟»
چون وقتی هزینه‌ی تغییر پایین میاد، وسوسه‌ی تغییر دادن همه‌چیز بالا میره.
این روزها ممکنه یک نفر یک هفته صرف Refactor چیزی کنه که:
هیچ Bugی نداشت.
هیچ Performance Problemی نداشت.
کسی از پیچیدگیش شکایت نداشت.
و هیچ نیازی هم قرار نبود در آینده حل کنه.
فقط چون:
«الان AI می‌تونه سریع انجامش بده.»
ولی سریع انجام شدن، به معنی ارزشمند بودن نیست.
اتفاقاً فکر می‌کنم هرچقدر AI بهتر بشه، نقش Engineering Judgment مهم‌تر می‌شه.
چون احتمالاً بخش زیادی از «چطور انجام بدیم؟» رو ابزارها جواب میدن.
اما هنوز یک سؤال باقی میمونه:
«اصلاً چرا داریم انجامش میدیم؟»
و شاید این همون جایی باشه که تفاوت یک Developer خوب با کسی که فقط میتونه از ابزارها استفاده کنه، بیشتر خودش رو نشون بده. AI می‌تونه بهت کمک کنه یک Refactor بزرگ رو در یک ساعت انجام بدی.
اما هنوز باید یک نفر تصمیم بگیره که:
آیا این یک ساعت، بهترین جایی بود که میشد خرجش کرد یا نه؟
هرچقدر ساختن و تغییر دادن ارزان‌تر میشه،
به نظرم توانایی «انجام ندادن کار اشتباه» ارزشمندتر میشه.
شاید در آینده، مهارت مهم مهندس‌ها این نباشه که چقدر سریع کد میزنن.
بلکه این باشه که بین هزار کاری که AI میتونه انجام بده،
تشخیص بدن کدومش واقعاً ارزش انجام دادن داره.