مهندسی پلتفرم با ایجنتها بیارزش نشده
هوش مصنوعیخلاصهٔ کاملتر
این پست از یه گفتوگوی نویسنده، اوان میگر، با دوستش شروع میشه که تو شرکتش یه پروژهٔ کلاسیک پلتفرمی رو جلو برده بود: یه سیستم قابلاستفادهٔ مجدد برای مشکلی که چند تیم مختلف باهاش درگیر بودن. پروژه خوب راه افتاده بود و حداقل یه تیم هم سوار شده بود، ولی اون دوست بلندبلند فکر میکرد که با وجود ابزارهای کدنویسی ایجنتی، تیمها هنوز همونقدر انگیزه دارن سراغ کامپوننتهای پلتفرم برن؟ اگه تولید کد مجانی باشه، بازاستفاده دیگه چه ارزشی داره؟
نویسنده میگه جالبه که هوش مصنوعی هم بهعنوان دلیل موافق بازاستفاده به کار میره و هم مخالفش؛ یکی میگه «از این فریمورک متنباز استفاده کنیم چون Claude همهٔ بهترین شیوههاش رو بلده» و اون یکی میگه «میتونم به Claude بگم یه راهحل اختصاصی بنویسه و اصلاً درگیر فریمورک نشم». به اعتقاد او وقتشه جملهٔ «هزینهٔ نوشتن کد داره به صفر میل میکنه» رو کنار بذاریم: هزینه خیلی کم شده، ولی یاد گرفتیم توکن پول واقعی خرج میکنه و پول هم منبع محدودیه.
استدلال اصلی مقاله اینه که هوش مصنوعی بهجای اینکه نیروی کالاییسازی باشه و ارزش کد رو صفر کنه، خودش منبعیه که به سازمان اهرم میده. نویسنده میگه همیشه میشه از ایجنت خواست کل استک یه قابلیت رو بنویسه، ولی این کار همیشه گرونتر از اینه که فقط لایههای بالایی رو ازش بخوای و لایههای پایین رو از کامپوننتهای خوشساختِ موجود برداری. به گفتهٔ او این اهرم شصت ساله که پایهٔ مهندسی نرمافزاره و با یه پله بالا رفتنِ سطح انتزاع از بین نمیره.
خودش صادقانه اضافه میکنه که بخش زیادی از حرفهش تو تیمهای پلتفرم گذشته و طبیعتاً گرایش پررنگی به بازاستفاده داره، پس دفاع از مهندسی پلتفرم یهجور دفاع از موضع خودشه. در عین حال به مقالهٔ مارتین فاولر دربارهٔ منطق اقتصادی refactoring اشاره میکنه که همین استدلال رو میسازه: هدف از بازآرایی یه کدبیس ایجنتی اینه که الان توکن خرج کنی تا مصرف توکنِ کارهای بعدی کمتر بشه.
نکات کلیدی:
- سؤال اصلی اینه که با ارزونشدن تولید کد، بازاستفاده از پلتفرم داخلی هنوز میارزه یا نه
- به گفتهٔ نویسنده جملهٔ «هزینهٔ کد به صفر میرسه» باید بازنشسته بشه؛ توکن هزینهٔ واقعیه
- خواستن کل استک از ایجنت همیشه گرونتر از ساختن روی لایههای آمادهٔ پلتفرمه
- اهرم شصت ساله که پایهٔ مهندسی نرمافزاره و با ایجنتیشدنِ برنامهنویسی عوض نشده
- مارتین فاولر هم با همین منطق از refactoring دفاع کرده: خرج توکن حالا، صرفهجویی بعداً
