اگر چند سال پیش به یک برنامهنویس میگفتید ممکنه روزی برسد که برای ساختن یک نرمافزار، بخش بزرگی از کد را خودش ننویسد، احتمالاً اول از همه درباره کیفیت کد و امنیت و معماری پروژه سؤال میکرد.
اما حالا خودِ DHH، کسی که یکی از تأثیرگذارترین فریمورکهای تاریخ وب یعنی Ruby on Rails را ساخته، روی صحنه آمده و حرفی بسیار بزرگتر میزند:
شاید اصلاً قرار نیست در آینده شغل ما «کدنویسی» باشد.
در سخنرانی افتتاحیه Rails World 2026، DHH درباره آیندهای حرف میزند که در آن Agentها کد مینویسند، تست میکنند، باگها را پیدا میکنند، نرمافزارهای Native میسازند و حتی سراغ زبانهایی مثل Rust میروند؛ در حالی که انسان بیشتر نقش کسی را دارد که میداند چه چیزی باید ساخته شود.
اما ماجرا فقط این نیست که AI قرار است برنامهنویسها را سریعتر کند.
اگر هزینه تولید نرمافزار واقعاً بهشدت پایین بیاید، ممکن است چیزهای خیلی بیشتری تغییر کنند:
معماری نرمافزار، مفهوم Abstraction، نحوه Integration بین سرویسها، آینده اپلیکیشنهای Native، اهمیت CLI، اندازه نرمافزارها و حتی اینکه اصلاً یک Programmer را چطور تعریف میکنیم.
DHH حتی میگوید خودش عملاً از برنامهنویسی به معنای سنتی آن بازنشسته شده؛ اما نه از ساختن نرمافزار.
و شاید همین تفاوت، مهمترین نکته کل این سخنرانی باشد.
پس بیایید ببینیم وقتی خالق Rails به آینده توسعه نرمافزار نگاه میکند، دقیقاً چه چیزی میبیند.
۱. چیزی شبیه لحظهای که دوربین، نقاشها را غافلگیر کرد
DHH برای توضیح اتفاقی که امروز با AI داره میافته، یه تشبیه خیلی جالب داره.
فرض کنید برگشتیم به قرن هجدهم یا نوزدهم و شما یک نقاش پرترهاید. برای کشیدن تصویر یک آدم ممکنه ماهها وقت بذارید. مهارتی دارید که هر کسی از پسش برنمیاد و طبیعتاً همین باعث میشه کارتون ارزش اقتصادی بالایی داشته باشه.
حالا یکدفعه دوربین عکاسی از راه میرسه.
دیگه برای ثبت تصویر یک نفر لازم نیست ماهها آموزش ببینید و چند هفته وقت بذارید. یک دوربین میتونه در چند لحظه کاری رو انجام بده که قبلاً ساعتها و روزها زمان میبرد.
اما نکته اینجاست که دوربین باعث نشد هنر از بین بره.
نقاشی نابود نشد؛ فقط جایگاهش عوض شد.
نقاشها کمکم رفتند سراغ چیزهایی که دوربین نمیتونست به این راحتی انجام بده؛ سبکهای جدید، برداشتهای شخصیتر، تجربههای متفاوت و راههای تازهای برای بیان کردن یک ایده.
DHH میگه اتفاقی که امروز برای نرمافزار داره میافته، خیلی شبیه همینه.
تا همین چند وقت پیش، ساختن یک نرمافزار اصطکاک خیلی زیادی داشت. باید:
یک یا چند زبان برنامهنویسی بلد میبودید؛
فریمورک یاد میگرفتید؛
با APIها و ابزارهای مختلف سر و کله میزدید؛
ساعتها و گاهی روزها کد مینوشتید؛
باگ پیدا میکردید و رفعشون میکردید؛
تست مینوشتید؛
و در نهایت امیدوار میشدید چیزی که ساختهاید واقعاً درست کار کنه!
حالا AI داره یکییکی این اصطکاکها رو کم میکنه.و درواقع چیزی که الان میبینیم هنوز اول ماجراست.
۲. نقطه عطف واقعی: عصر Agentها
DHH توی روایت خودش، ۲۴ نوامبر ۲۰۲۵ و عرضه Opus 4.5 رو یک نقطه عطف مهم میدونه؛ تاریخی که به نظرش میشه شروع جدی عصر Agentها رو از اونجا حساب کرد.
چرا؟
چون از اون به بعد، AI دیگه فقط یه autocomplete خیلی خفن نبود که کنارت بشینه و حدس بزنه خط بعدی کدت چی باید باشه.
قبلاً ممکن بود به AI بگید:
«این تابع رو برام بنویس.»
اما حالا میتونستید مسئله رو براش توضیح بدید و بگید:
«من همچین چیزی میخوام. برو بسازش.»
همین تفاوت ساده، در واقع خیلی بزرگه.
چون دیگه موضوع فقط تولید کد نیست؛ موضوع اینه که AI بتونه یک مسئله رو بفهمه، راهحل پیدا کنه، کد بزنه، تست کنه، خطاهاش رو برطرف کنه و در نهایت یه خروجی قابل استفاده تحویل بده.
بعد از اون هم مدلهای جدیدتر یکییکی از راه رسیدن و توانایی Agentها باز هم بیشتر شد.
نتیجه؟
فاصله بین:
«من یه ایده دارم»
و
«من یه نرمافزار قابل استفاده دارم»
به شکل عجیبی کمتر شد.
و دقیقاً همینجاست که مفهوم Agent اهمیت پیدا میکنه.
دیگه با یک ابزار طرف نیستیم که فقط به ما توی کدنویسی کمک کنه؛ با چیزی طرفیم که میتونه بخشی از خودِ فرایند ساخت نرمافزار رو به عهده بگیره.
۳. از برنامهنویس 10x به برنامهنویس 1000x
سالهاست توی دنیای نرمافزار درباره چیزی به اسم 10x Developer صحبت میکنیم.
یعنی برنامهنویسی که به دلایل مختلف میتونه چند برابر یک برنامهنویس معمولی خروجی داشته باشه؛ سریعتر مسئله حل میکنه، تصمیمهای بهتری میگیره و در نهایت نرمافزار بیشتری تولید میکنه.
اما DHH میگه این مقیاس دیگه برای دنیای امروز جواب نمیده.
از نظر اون، فاصله بین یک برنامهنویسی که بدون ابزارهای AI کار میکنه و کسی که به شکل جدی از Agentها استفاده میکنه، میتونه به 100 برابر یا حتی 1000 برابر برسه.
و برای این حرفش هم یک مثال جالب از شرکت خودش، 37signals، داره.
اونها یک تصمیم خیلی جدی گرفتهاند:
Pencils Down
«قلمها رو زمین بذارید.»
منظورشون اینه که کدنویسی دستی دیگه روش اصلی کار نیست.
DHH میگه خودش توی پنج ماه گذشته تقریباً هیچ کدی رو با دست ننوشته.
حتی جالبتر اینکه از نگاه اون، اگر امروز یک برنامهنویس مجبور بشه برای انجام کاری خودش بشینه و کد بنویسه، این لزوماً اتفاق خوبی نیست.
ممکنه اصلاً یک علامت هشدار باشه.
تقریباً مثل وقتی که Sentry به شما یک خطای عجیب گزارش میده و میفهمید یه جای سیستم مشکل داره.
اینجا هم اگر Agent نتونسته کاری رو انجام بده، شاید راهحل این نباشه که:
«خب، خودم مینویسمش.»
شاید باید از خودمون بپرسیم:
چرا Agent نتونست این کار رو انجام بده؟
آیا پرامپت درست نبوده؟
آیا معماری پروژه مناسب نیست؟
آیا ابزارهای لازم رو در اختیارش نذاشتیم؟
یا اصلاً فرایند کاریمون برای کار با Agentها درست طراحی نشده؟
یعنی به جای اینکه هر بار خودمون بریم وسط و کد بنویسیم، باید کمکم یاد بگیریم سیستمی بسازیم که Agentها بتونن بهتر و بیشتر کار کنن.
این دقیقاً یکی از تغییرات ذهنی مهمیـه که DHH درباره عصر جدید توسعه نرمافزار مطرح میکنه.
۴. سلام بر Native!
یکی دیگه از بخشهای جالب حرفهای DHH درباره اپلیکیشنهای Nativeـه.
سالهاست تیمهای کوچک یه دوراهی همیشگی دارن:
یا کیفیت بالاتر، یا هزینه و زمان کمتر.
فرض کنید بخواید برای یک سرویس، شش اپلیکیشن Native جداگانه برای پلتفرمهای مختلف بسازید. خب طبیعتاً توسعه و نگهداری این تعداد اپلیکیشن برای یک تیم کوچک کار راحتی نیست.
برای همین خیلی از تیمها رفتن سراغ راهحلهایی مثل:
Web App
React Native
Flutter
Hotwire Native
و ابزارهای مشابه
منطقش هم کاملاً مشخصه؛ وقتی تیم کوچیکه، نمیتونید برای هر پلتفرم یک تیم جدا داشته باشید.
اما حالا یه سؤال جالب پیش میاد:
اگر هزینه تولید کد تقریباً به صفر نزدیک بشه، چی؟
DHH میگه در پروژه Hey Next دقیقاً همین اتفاق افتاده.
اونها به جای اینکه صرفاً یک Web App داشته باشن، تونستن در حدود یک هفته، با کمک Agentها، شش اپلیکیشن کاملاً Native بسازن.
و قسمت عجیب ماجرا اینجاست:
حتی یک خط از کد رو هم دستی ننوشتهاند.
یعنی کاری که تا همین چند وقت پیش برای یک تیم کوچک از نظر زمان و هزینه تقریباً غیرمنطقی بود، حالا میتونه کاملاً عملی باشه.
این یعنی اگر هزینه تولید نرمافزار واقعاً تا این حد پایین بیاد، خیلی از تصمیمهایی که قبلاً صرفاً به خاطر محدودیت منابع میگرفتیم، دیگه لزوماً منطقی نیستن.
شاید دوباره برگردیم به دنیایی که برای هر پلتفرم، اپلیکیشن Native واقعی خودش رو داشته باشیم.
۵. هم دردی و هم درمان!
این شاید بامزهترین قسمت کل سخنرانی باشه.
DHH خیلی رک و راست میگه:
«من از Rust متنفرم!»
حتی کد Rust رو از نظر ظاهری خیلی زشت میدونه و میگه نگاه کردن بهش برای آدم میتونه واقعاً عذابآور باشه.
اما اینجا یه اتفاق جالب میافته:
Agentها Rust رو دوست دارن!
و از اونجایی که DHH دیگه لازم نیست خودش بشینه کد Rust رو بخونه یا بنویسه، میگه:
«خب، پس Rust رو میکنم یه Black Box.»
یعنی چی؟
یعنی اصلاً مهم نیست داخل این جعبه چه خبره؛ مهم اینه که خروجی خوبی بهمون میده.
اگر Agent میتونه با Rust خیلی خوب کار کنه و در عین حال Rust برای اجرای نرمافزار خروجی سریع و کممصرفی میده، چرا نباید ازش استفاده کنیم؟
نتیجه هم برای Hey واقعاً جالب بوده.
طبق چیزی که DHH توی سخنرانی میگه، بعد از اینکه بخشهایی از Backend سرویس Hey رو با کمک Agentها به Rust منتقل کردن:
مصرف CPU حدود ۹۹٪ کمتر شده.
مصرف RAM حدود ۹۵٪ کمتر شده.
حتی میگه ترافیک Peak سرویس Hey رو میشه روی یک Raspberry Pi اجرا کرد!
یعنی AI فقط باعث نشده سریعتر نرمافزار بسازیم؛ یه اتفاق جالب دیگه هم افتاده:
حالا میتونیم کارهایی رو انجام بدیم که قبلاً از نظر زمانی اصلاً نمیصرفید.
مثلاً یک انسان ممکنه حاضر نباشه چند روز یا چند هفته وقت بذاره تا یک سرویس رو از نظر مصرف CPU و RAM دهها برابر بهینه کنه.
اما Agent میتونه ساعتها و حتی شب تا صبح روی همین مسئله کار کنه.
و این شاید یکی از مهمترین تغییرات عصر AI باشه:
وقتی هزینه تولید و بهینهسازی نرمافزار شدیداً پایین بیاد، کارهایی که قبلاً «ارزش وقت گذاشتن نداشتن»، دوباره اقتصادی میشن.
۶. پس تکلیف Rails چی میشه؟
اینجا احتمالاً یه سؤال مهم براتون پیش میاد:
اگه AI قراره همهچی رو بسازه، پس اصلاً Rails دیگه به چه دردی میخوره؟
DHH اتفاقاً جوابش کاملاً برعکسه.
از نظر اون، Rails نهتنها قرار نیست کنار بره، بلکه اتفاقاً برای عصر Agentها خیلی هم مناسبه.
یکی از دلایلش همون فلسفه قدیمی Railsه:
Convention over Configuration
یعنی به جای اینکه برای هر قسمت پروژه مجبور باشید دهها تصمیم مختلف بگیرید و همهچیز رو از صفر پیکربندی کنید، Rails یه مسیر مشخص و استاندارد جلوی پاتون میذاره.
این موضوع برای Agentها خیلی مهمه.
هرچی ساختار پروژه قابل پیشبینیتر و استانداردتر باشه، Agent راحتتر میفهمه با چه چیزی طرفه و برای پیدا کردن مسیر درست، به Token و استدلال کمتری نیاز داره.
از طرف دیگه، Rails از همون اول با این ایده ساخته شده که یک توسعهدهنده تنها هم بتونه باهاش یک محصول کامل بسازه.
همون چیزی که DHH ازش با عنوان:
Framework for the solo developer
یاد میکنه.
حالا این ایده رو بذارید کنار Agentها.
یک نفر، به جای اینکه خودش همه کارها رو انجام بده، میتونه چندین Agent داشته باشه که همزمان بخشهای مختلف پروژه رو جلو ببرن.
اینجاست که فلسفه Rails دوباره خیلی معنیدار میشه.
حتی تیم Rails با همکاری Evil Martians شروع کرده عملکرد Agentها رو روی پروژههای واقعی Rails بررسی کنه.
جالب اینجاست که Agentها توی بعضی از این تستها خیلی سریع به نرخ موفقیت حدود ۹۵ درصد رسیدن؛ تا جایی که مجبور شدن تستها رو سختتر کنن.
یعنی از نگاه DHH، Rails قرار نیست قربانی عصر AI بشه.
اتفاقاً ممکنه یکی از فریمورکهایی باشه که خیلی خوب با این عصر جدید جور درمیاد.
۷. بهترین زبان برنامهنویسی
اون میگه طی ۲۱ سال گذشته، بیشتر از نصف کار حرفهایاش شامل نوشتن Ruby بوده. به طور میانگین هم سالی حدود ۳۰ هزار خط کد عملیاتی نوشته.
اما امسال یک اتفاق عجیب افتاده:
سهم Ruby در کار خودش رسیده به حدود ۳ درصد.
در عوض، فقط در ماه آگوست، با کمک Agentها چیزی حدود:
۱۵۰ هزار خط کد
تولید کرده.
یعنی تقریباً ۶۰ برابر میانگین تاریخی خودش.
اما از این آمار به یک نتیجه جالبتر میرسه.
میگه بالاخره یک زبان پیدا کرده که حتی از Ruby هم بیشتر دوستش داره:
English
اینکه بتونید چیزی رو با زبان طبیعی توضیح بدید و ماشین همون توضیح رو تبدیل به یک نرمافزار واقعی کنه، تجربه فوقالعادهایه.
البته یک مشکل واضح وجود داره.
انگلیسی مثل یک زبان برنامهنویسی، دقیق و deterministic نیست. پر از ابهام، برداشتهای مختلف و وابستگی به contextه.
اما اینجاست که Agent وارد ماجرا میشه.
Agent میتونه بخش بزرگی از این ابهام رو مدیریت کنه و از یک توضیح نسبتاً انسانی و مبهم، به یک خروجی فنی و قابل اجرا برسه.
یعنی شاید یکی از مهمترین تغییرات همین باشه:
دیگه لازم نیست همیشه اول فکر خودمون رو به زبان ماشین ترجمه کنیم؛ میتونیم خیلی مستقیمتر چیزی رو که میخوایم به زبان خودمون توضیح بدیم و بذاریم ماشین بخش بزرگی از ترجمه رو انجام بده.
۸. بلخره برنامهنویسا بیکار میشن یا نه ؟
DHH میگه خودش حدود چهار یا پنج ماهه که عملاً از «برنامهنویس حرفهای» به معنای سنتی کلمه بازنشسته شده.
اما این به این معنی نیست که دیگه نرمافزار نمیسازه.
اتفاقاً برعکس.
هنوز داره نرمافزار میسازه، فقط نقشش عوض شده.
ما باید کمکم از:
«کد نوشتن»
به:
«چیز ساختن»
حرکت کنیم.
یعنی هویت حرفهای خودمون رو نباید به یک ابزار خاص گره بزنیم.
اگر تا امروز خودمون رو Programmer میدونستیم، شاید بهتر باشه بیشتر به خودمون به چشم یک:
Professional Maker
نگاه کنیم.
قبلاً ابزار اصلی ما اینها بودن:
Keyboard
IDE
Terminal
Programming Language
اما حالا جعبهابزارمون خیلی بزرگتر شده و میتونه شامل اینها باشه:
زبان طبیعی
Agent
CLI
تست
Git
مدلهای مختلف AI
تفاوت مهم اینجاست که هدف دیگه نوشتن کد نیست.
هدف اینه که چیزی بسازیم که کار کنه.
کد، Agent، زبان برنامهنویسی، IDE و حتی AI همگی ابزارن؛ نه خودِ محصول.
و شاید این یکی از مهمترین تغییرات ذهنی باشه که باید در عصر AI یاد بگیریم:
به جای اینکه خودمون رو با ابزاری که استفاده میکنیم تعریف کنیم، با چیزهایی که میسازیم تعریف کنیم.
۹. کدنویسی ارزون و معماریهای جدید
بخش بزرگی از معماری نرمافزار مدرن بر اساس یک فرض ساده شکل گرفته:
کدنویسی گرونه.
وقتی نوشتن و نگهداری کد هزینه زیادی داشته باشه، طبیعتاً سعی میکنیم تا جای ممکن کد کمتری داشته باشیم.
برای همین میریم سراغ چیزهایی مثل:
DRY کردن کد
Abstraction
استفاده مجدد از کد
ساختن Shared Library
لایهبندی سیستم
جلوگیری از تکرار
و کلی Best Practice دیگه
همه اینها منطقی به نظر میرسن؛ چون فرض اولیه اینه که هر خط کدی که مینویسیم، هزینه دارد.
اما حالا یک سؤال جالب مطرح میشه:
اگر هزینه تولید کد تقریباً به صفر برسه، چی؟
فرض کنید هزاران Agent بتونن همزمان روی بخشهای مختلف یک سیستم کار کنن و تولید کد دیگه گلوگاه اصلی نباشه.
اون موقع ممکنه بعضی از Abstractionهایی که قبلاً برای صرفهجویی در زمان و هزینه ساخته بودیم، خودشون تبدیل به گلوگاه بشن.
مثلاً چیزی که زمانی کمک میکرد چند بخش مختلف سیستم از یک کد مشترک استفاده کنن، ممکنه امروز باعث بشه تغییر دادن یک بخش، چند بخش دیگه رو هم تحت تأثیر قرار بده.
یعنی شاید بعضی وقتها سادهتر باشه که به جای ساختن یک Abstraction پیچیده و قابل استفاده مجدد، اجازه بدیم Agent یک پیادهسازی جداگانه برای هر بخش تولید کنه.
البته DHH نمیگه همه اصولی که تا امروز یاد گرفتیم اشتباه بودهاند.
بحث خیلی بنیادیتر از اینه.
فرض اقتصادی پشت این اصول داره تغییر میکنه.
وقتی هزینه تولید نرمافزار بالا باشه، معماری رو طوری طراحی میکنیم که از کد، زمان و نیروی انسانی حداکثر استفاده رو ببریم.
اما اگر تولید کد تقریباً ارزان بشه، ممکنه بعضی از این تصمیمها دیگه بهترین انتخاب نباشن.
پس شاید مسئله این نباشه که:
«کدوم Best Practice درست و کدوم غلطه؟»
بلکه سؤال جدید این باشه:
«وقتی هزینه تولید نرمافزار تغییر کرده، آیا معماری ما هم باید تغییر کنه؟»
و اینجاست که عصر Agentها فقط روش کدنویسی رو تغییر نمیده؛ ممکنه ما رو مجبور کنه درباره خودِ اصول معماری نرمافزار هم دوباره فکر کنیم.
۱۰. داخل اپلیکیشن Chatbot نسازید؛ CLI بسازید
امروز تقریباً هر اپلیکیشنی که ساخته میشه، یه جایی هم یک Chatbot بهش اضافه میکنه. اما خب بهترین کار این نیست!
ایده اینه که نرمافزارها باید طوری طراحی بشن که Agent بتونه مستقیم باهاشون کار کنه.
یعنی به جای اینکه Agent مجبور باشه مثل یک انسان وارد UI بشه، دکمهها رو پیدا کنه، منوها رو باز کنه و فرمها رو یکییکی پر کنه، بتونه مستقیماً از طریق CLI به نرمافزار دستور بده.
مثلاً چیزی شبیه:
hey search "..."
یا هر دستور استاندارد دیگهای که خود نرمافزار در اختیارش قرار میده.
در این مدل، UI همچنان برای انسان وجود داره، اما Agent مجبور نیست از همون مسیر استفاده کنه.
و این دیدگاه میتونه مفهوم Integration بین نرمافزارها رو هم حسابی تغییر بده.
تا امروز معمولاً وقتی میخواستیم دو نرمافزار رو به هم وصل کنیم، میرفتیم سراغ API و بعد باید یک Integration اختصاصی بین اونها میساختیم.
اما اگر هر نرمافزار یک رابط قابل استفاده برای Agent داشته باشه، شاید در آینده بخش بزرگی از این ارتباطات رو خود Agentها مدیریت کنن.
یعنی به جای اینکه فقط Human → UI → Software داشته باشیم، میتونیم به سمت چیزی شبیه این بریم:
Human → Agent → Software
و این تغییر کوچیک در ظاهر، میتونه معماری ارتباط بین نرمافزارها رو کاملاً متحول کنه.
۱۱. چرا هنوز نرمافزارها اینقدر بزرگاند؟
یکی دیگه از انتقادهای DHH به دنیای نرمافزار امروز، حجم و پیچیدگی بیش از حد اپلیکیشنهاست.
مثلاً وقتی نرمافزاری مثل Spotify به حجم خیلی بزرگی میرسه، بخشی از این ماجرا به یک دلیل ساده برمیگرده:
بهینهسازی دیگه از نظر اقتصادی نمیصرفه.
وقتی زمان یک برنامهنویس گرونه، طبیعیه که کسی نخواد چند روز یا چند هفته وقت بذاره تا یک برنامه رو مثلاً ۳۰ برابر کوچکتر کنه.
ممکنه از نظر فنی شدنی باشه، اما از نظر اقتصادی توجیه نداشته باشه.
اما Agent داستان رو عوض میکنه.
Agent میتونه شب تا صبح روی همین مسئله کار کنه؛ کد رو بررسی کنه، بخشهای اضافی رو پیدا کنه، تغییر بده، Build بگیره، تست کنه و دوباره از اول همین چرخه رو تکرار کنه.
برای همین DHH وقتی میخواسته سخنرانی خودش رو آماده کنه، تصمیم گرفته یک نرمافزار Presentation اختصاصی بسازه:
Hype
یک نرمافزار مبتنی بر Markdown که Binary اون فقط حدود نیم مگابایت حجم داره.
ایده اصلی DHH اینه:
اگر هزینه نیروی انسانی برای ساخت و بهینهسازی نرمافزار پایین بیاد، شاید دوباره بتونیم به سمت نرمافزارهایی برگردیم که:
کوچک باشن
سریع باشن
تخصصی باشن
منابع کمی مصرف کنن
یعنی شاید AI در نهایت فقط باعث نشه نرمافزار بیشتری تولید کنیم؛ بلکه بتونه کمک کنه دوباره نرمافزارهای کوچکتر و بهینهتر بسازیم.
چیزی که قبلاً به خاطر هزینه بالای نیروی انسانی ارزش اقتصادی نداشت، حالا ممکنه دوباره ارزش انجام دادن پیدا کنه.
۱۲. امنیت را نباید شوخی گرفت
البته DHH اصلاً هم نسبت به خطرات AI بیخیال نیست.
امنیت همچنان یک مسئله جدیه.
وقتی Agentها بتونن کد تولید کنن، اون رو تغییر بدن و حتی روی سیستم اجرا کنن، طبیعتاً باید خیلی بیشتر از قبل به Isolation و Sandboxing فکر کنیم.
چون دیگه با ابزاری طرف نیستیم که فقط یک تکه کد پیشنهاد میده؛ Agent میتونه واقعاً وارد چرخه اجرا بشه و روی سیستم کار انجام بده.
DHH در همین زمینه به پروژههایی مثل HotCell در اکوسیستم Rails هم اشاره میکنه که هدفشون فراهم کردن محیطهای ایزوله برای اجرای کد و کاهش ریسکهای این مدل استفاده است.
اما نتیجهگیری DHH این نیست که:
«پس AI خطرناکه و باید متوقفش کنیم.»
بحثش چیز دیگهایه:
ما همونطور که ابزارهای قدرتمندتری برای حمله داریم، ابزارهای قدرتمندتری برای دفاع هم داریم.
یعنی مسئله این نیست که Agentها رو کلاً از سیستم حذف کنیم؛ مسئله اینه که محیط و محدودیتهای درستی برای فعالیتشون طراحی کنیم.
در واقع همون تکنولوژیای که میتونه قدرت حمله رو بیشتر کنه، میتونه برای ساخت سیستمهای دفاعی، تشخیص تهدید و ایمنسازی نرمافزارها هم استفاده بشه.
پس در دنیای Agentها، Sandboxing، Isolation، Permission و کنترل دسترسی دیگه جزئیات جانبی نیستن؛ بخشی از معماری اصلی سیستم محسوب میشن.
۱۳. ATM قرار بود بانکدارها را بیکار کند!
DHH برای توضیح اینکه چرا ارزانتر شدن تولید نرمافزار لزوماً به معنی کمتر شدن کار نرمافزاری نیست، یک مثال تاریخی جالب میزنه:
ATM.
وقتی دستگاههای خودپرداز وارد بانکها شدن، نگرانی بزرگی وجود داشت که تعداد زیادی از کارمندان بانک شغلشون رو از دست بدن.
منطقش هم ساده بود:
وقتی یک دستگاه میتونه بخشی از کارهای یک کارمند رو انجام بده، خب طبیعتاً باید به کارمندهای کمتری نیاز داشته باشیم.
اما اتفاقی که افتاد، کمی متفاوت بود.
ATM باعث شد هزینه اداره شعبههای بانک پایینتر بیاد.
در نتیجه، بانکها تونستن شعبههای بیشتری باز کنن.
و جالبتر اینکه تعداد کارکنان بانک هم برخلاف انتظار، در نهایت افزایش پیدا کرد.
این پدیده به چیزی مربوط میشه که اقتصاددانها بهش میگن:
Jevons Paradox
ایده سادهست:
وقتی یک منبع یا فرایند ارزانتر و کارآمدتر میشه، لزوماً مصرفش کم نمیشه.
گاهی برعکس، چون استفاده از اون ارزونتر شده، تقاضا اونقدر افزایش پیدا میکنه که مصرف کلی حتی بیشتر هم میشه.
DHH معتقده ممکنه اتفاق مشابهی برای نرمافزار و AI هم بیفته.
اگر AI هزینه ساخت نرمافزار رو بهشدت پایین بیاره، شاید نتیجه این نباشه که:
«خب، پس به برنامهنویس کمتری نیاز داریم.»
ممکنه نتیجه این باشه که:
«حالا که ساخت نرمافزار ارزونه، بیایید نرمافزارهای خیلی بیشتری بسازیم.»
محصولاتی که قبلاً به خاطر هزینه بالای توسعه ساخته نمیشدن، حالا میتونن اقتصادی بشن.
نیازهایی که قبلاً ارزش ساختن یک نرمافزار براشون رو نداشتن، ممکنه حالا تبدیل به یک محصول مستقل بشن.
در نتیجه، AI میتونه به جای کوچک کردن بازار نرمافزار، اندازه خودِ بازار نرمافزار رو بزرگتر کنه.
البته این یک الگوی اقتصادی و یک استدلال درباره اثر احتمالی AI است، نه تضمینی برای اینکه دقیقاً همین اتفاق در بازار نرمافزار رخ خواهد داد.
پس از این به بعد چه کار کنیم؟
بعد از شنیدن تمام این حرفها، احتمالاً یک سؤال بیشتر از همه در ذهن میماند:
اگر Agentها قرار است کد بزنند، تست کنند، Debug کنند و حتی نرمافزار کامل بسازند، پس ما برنامهنویسها دقیقاً قرار است چه کار کنیم؟
شاید جواب DHH این نباشد که هیچ کاری نمیکنیم.
اتفاقاً برعکس.
شاید قرار است کارهای بیشتری انجام بدهیم؛ فقط نه لزوماً همان کارهایی که امروز انجام میدهیم.
تا امروز بخش بزرگی از زمان یک برنامهنویس صرف تبدیل یک ایده به کد میشد. باید زبان میدانستیم، APIها را میشناختیم، Frameworkها را یاد میگرفتیم، کد مینوشتیم، تست میکردیم و باگها را یکییکی شکار میکردیم.
اما اگر این بخش از کار بهشدت ارزان و سریع شود، ارزش اصلی کمکم جای دیگری قرار میگیرد:
اینکه چه چیزی بسازیم، چرا بسازیم، چطور مسئله را تعریف کنیم و چطور مطمئن شویم چیزی که ساختهایم واقعاً ارزشمند است.
یعنی شاید در آینده تفاوت بین یک برنامهنویس معمولی و یک برنامهنویس فوقالعاده، دیگر در سرعت تایپ کردن یا حتی تسلط به یک زبان خاص نباشد.
شاید تفاوت اصلی در حل مسئله، طراحی سیستم، درک محصول، معماری، قضاوت مهندسی و توانایی هدایت Agentها باشد.
و این یعنی شاید لازم نباشد از AI بترسیم؛ اما قطعاً باید روش کارمان را با آن تغییر بدهیم.
از طرف دیگر، تمام حرفهای DHH را هم نباید به عنوان یک پیشبینی قطعی درباره آینده در نظر گرفت. بعضی از این ایدهها هنوز در حال آزمایشاند و معلوم نیست همه آنها دقیقاً همانطور که امروز تصور میکنیم عملی شوند.
اما حتی اگر فقط بخشی از این اتفاقها رخ بدهد، یک چیز روشن است:
هزینه ساخت نرمافزار در حال تغییر است.
و وقتی هزینه یک کار تغییر میکند، معمولاً خودِ روش انجام آن کار هم تغییر میکند.
شاید بزرگترین اشتباه ما این باشد که تلاش کنیم با ابزارهای جدید، همان نرمافزارها را با همان معماریها و همان فرایندهای قدیمی بسازیم؛ فقط کمی سریعتر.
شاید باید یک قدم عقبتر برویم و بپرسیم:
وقتی ساختن نرمافزار دیگر مثل گذشته گران نیست، اصلاً چه چیزهایی ارزش ساختن پیدا میکنند که قبلاً نمیتوانستیم بسازیم؟
شاید آینده نرمافزار فقط درباره کد کمتر نباشد.
شاید درباره ساختن چیزهای بیشتر، کوچکتر، تخصصیتر و جسورانهتر باشد.
و شاید در نهایت، آینده متعلق به کسی نباشد که بیشترین کد را مینویسد؛
بلکه متعلق به کسی باشد که بهتر میداند چه چیزی باید ساخته شود.
دیدگاههای کاربران0
ارسال دیدگاه جدید
برای ثبت دیدگاه ابتدا باید وارد حساب کاربری خود شوید.
ورود / ثبتنامهنوز دیدگاهی برای این مقاله ثبت نشده است.
اولین نفری باشید که دیدگاه خود را به اشتراک میگذارد!