تصور کنید برنامهنویسی هستید که هر تغییر کوچک در کدش باید ۱۵ دقیقه منتظر بماند تا سیستم پذیرایش کند، در حالی که یک هوش مصنوعی میتواند همان تغییر را در چند ثانیه بنویسد. این شکاف زمانی، دقیقاً همان نقطهای است که شرکت Scarf را مجبور کرد یکی از محبوبترین زبانهای برنامهنویسی خود را کنار بگذارد.
Scarf در ۱۰ ژوئیه ۲۰۲۶ اعلام کرد که در حال انتقال هستهٔ API خود از زبان Haskell به Python است. این یک شکست فنی نبود، بلکه یک تغییر در اقتصاد توسعه است؛ جایی که کاربر اصلی زبان برنامهنویسی دیگر فقط انسان نیست، بلکه عامل (Agent) هوش مصنوعی است. این گذار سیگنالی از یک واقعیت جدید است: زبانهای برنامهنویسی باید برای ماشینها بهینه شوند، نه فقط برای انسانها.
زمینه و پیشینه این تصمیم
برای درک این تغییر، باید بدانیم که رهبری Scarf در ۱۶ سال گذشته طرفداران پرشور Haskell بودهاند و آن را بدون شک مهمترین زبان برنامهنویسی در زندگی حرفهای خود میدانند. تعهد آنها به این زبان بسیار عمیق بود؛ نویسنده این گزارش نه تنها از این زبان حمایت میکرد، بلکه در هیئتمدیره بنیاد Haskell و کمیته Haskell.org نیز عضو است.
از زمان راهاندازی، بکاند Scarf کاملاً با Haskell ساخته شده بود. APIهای اصلی که اپلیکیشن را تغذیه میکردند، از کتابخانههایی نظیر Servant و Beam استفاده میکردند و بر روی PostgreSQL اجرا میشدند. علاوه بر این، آنها یک سرویس با عملکرد بالا برای Scarf Gateway توسعه دادند. این سرویس که مستقیماً بر روی WAI ساخته شده بود، دقیقاً در مسیر دانلود ترافیک بالای بستههای متنباز قرار داشت.
این سیستمها صرفاً نمونههای اولیه یا پروتوتایپ نبودند؛ آنها الزامات واقعی برای پایداری (Uptime) داشتند و تحت قراردادهای سطح خدمات (SLA) متعهد به عملکرد بودند. برای سالها، شرکت توانست این سیستمها را با موفقیت در محیط عملیاتی مدیریت کند. نتایج ثابت کرد که وعدههای Haskell محقق شده است: کدها قابل اعتماد بودند، سیستم نوعبندی (Type System) باگهای واقعی را شکار میکرد و زبان برنامهنویسی تیم را مجبور میکرد تا در مورد مدلسازی دامنه (Domain Modeling) متفکرانه عمل کند. همچنین دستیابی به کدهای با عملکرد بالا (High-performance) عموماً ساده و مستقیم بود.
با این حال، موفقیت نرمافزاری با هزینههای زیرساختی بالایی همراه بود. تیم مهندسی زمان زیادی را صرف بهینهسازی بیلدها، کشها، Nix، محیطهای توسعه-دهنده و سیستمهای CI (تولید و تست مستمر) میکرد. در حالی که تیم آنها زبان و ابزارها را عمیقاً میشناخت و میتوانست «لبههای تیز» (پیچیدگیهای شدید) Haskell را مدیریت کند، اما با تکامل جریانهای کاری، این ماشین پیچیده به یک بار سنگین تبدیل شد.
چرخش اقتصادی هوش مصنوعی
ظهور مدلهای زبانی بزرگ (LLM) یک مرحله جدید را به چرخه توسعه اضافه کرد: «زمان تولید کد». در گذشته، خطاها در یکی از دو مکان شناسایی میشدند: در زمان کامپایل (Compile-time) یا در زمان اجرا (Runtime). اکنون، مکان سومی اضافه شده است: زمان تولید کد. مدل هوش مصنوعی اغلب میتواند پیش از آنکه کامپایلر کد را ببیند، از بروز اشتباه جلوگیری کند.
همانطور که مدلها پیشرفت میکنند، ارزش نسبیِ شکار هر یک از مسائل در زمان کامپایل تغییر میکند. ایمنی نوع (Type Safety) بیارزش نیست، اما هزینه زمانیِ چک کردن انواع (Type-checking) اکنون اهمیت بسیار بیشتری یافته است. اگر یک LLM بتواند یک پیادهسازی فعال را در عرض چند دقیقه تولید کند، اما مرحله کامپایل به شدت طولانیتر باشد، سیستم بیلد به گلوگاه اصلی در چرخه توسعه تبدیل میشود.
مالیات «راهاندازی سرد» (Cold Start)
طبق گزارش مفصل رهبری شرکت در وبسایت avi.press، معیار حیاتی، طول کل چرخه بازخورد توسعه و بخشی از آن زمان است که در انتظار کامپایلر میگذرد.
وقتی یک انسان یک ساعت زمان صرف نوشتن کد میکند، یک کامپایل ۱۵ دقیقهای صرفاً یک مزاحمت است. اما وقتی یک عامل هوش مصنوعی تغییری پذیرفتنی را در چند ثانیه پیشنویس میکند، انتظار ۱۵ دقیقهای برای بیلد پروژه از حالت «راهاندازی سرد»، کامپایلر را از یک «خراش کوچک» به هزینه غالب کل آن رشته کاری تبدیل میکند.
این وضعیت زمانی غیرقابلتحمل میشود که بخواهید از چندین عامل کدنویس بهصورت موازی استفاده کنید. نویسنده از جریان کاری ایدهآلی صحبت میکند که در آن بتوان:
- چندین Worktree (درخت کاری) را بهسرعت فعال کرد.
- شاخههای مختلفی از کار را فورک (Fork) کرد.
- اجازه داد چندین عامل بهطور همزمان رویکردهای مختلف را امتحان کنند.
- نتایج را بررسی کرد و موارد مفید را نگه داشت.
در این دنیای جدید، زمان راهاندازی سرد همه چیز است. اگر هر ورکتری جدید نیاز به یک بیلد طولانی Haskell، تنظیمات گسترده کش یا مصرف شدید حافظه داشته باشد، هر رشته جدید از کار با یک «مالیات زمانی» شروع میشود. اگر پنج عامل بهصورت موازی پنج شاخه را بررسی کنند، این مالیات ضرب در پنج میشود.
محدودیتهای روشهای کشینگ
افراد در جامعه Haskell اغلب استفاده از کشینگ (Caching)، Nix و بیلدرهای ریموت (Remote Builders) را پیشنهاد میدهند. Scarf از این ابزارها استفاده میکرد، اما نویسنده اشاره میکند که کشینگ هرگز کامل نیست. مقدار تلاشی که لازم است تا کشینگ «به اندازه کافی خوب» به نظر برسد، خود بخشی از مشکل است.
توسعه موازی با کمک هوش مصنوعی نیازمند محیطهای اجرایی ارزان و یکبارمصرف است. جریان کاری ایدهآل این است: فورک کن، تغییر را امتحان کن، تستها را اجرا کن و نتیجه را نشان بده. محیط Haskell برای این سبک از کار به اندازه کافی ارزان نبود. در حالی که یک تغییر کوچک در یک پروژه کششده ممکن است منجر به یک چرخه سریع ۲۰ ثانیهای شود، اما این بهترین حالت ممکن (Best-case) است. به محض اینکه تغییرات به بخشهای عمیقترِ پلان بیلد نفوذ کنند، آن سرعت ناپدید میشود. یک جریان کاری متکی بر عاملها، به حالت «راهاندازی سرد»، حالت «متوسط» و حالات «تغییرات عمیق» وابسته است، نه فقط حالت «کش کامل».
استراتژی مهاجرت
شرکت Scarf برای انتقال، از یک روش پرریسک «تغییر یکباره» (Big Bang) استفاده نکرد، بلکه استراتژی «استقرار موازی» را برای حذف ریسکهای شدید پیاده کرد:
- استقرار موازی: آنها یک سرور API پایتونی را در کنار سرور Haskell مستقر کردند.
- مسیریابی درخواستها: درخواستها بر اساس قابلیت (Feature) مورد نیاز، به سرور مناسب هدایت میشوند.
- مهاجرت تدریجی: مسیرهای API جدید مستقیماً در پایتون نوشته میشوند؛ کدهای موجود در Haskell تا زمانی که نیاز به تغییر داشته باشند، به اجرای خود ادامه میدهند.
- کاهش ردپای Haskell: با گذشت زمان، سرور پایتون به مسیر اصلی تبدیل شد و ردپای Haskell کوچک و کوچکتر شد.
این فرآیند مستلزم پیادهسازی مجدد اجزای اصلی بود، از جمله: سیستم احراز هویت، دسترسی به پایگاه داده، مدلهای مشترک، ایمیجهای استقرار، تستها و چسبهای عملیاتی (Operational Glue). اگرچه این کارهای زیرساختی در گذشته گران به نظر میرسیدند، اما LLMها آنها را ساده کردند. پورت کردن کدهای موجود از یک زبان به زبان دیگر، اکنون تسکی است که مدلهای امروزی با سهولت کامل انجام میدهند.
نتیجه: سرعت عملیاتی
با انتخاب پایتون، Scarf ایمنی مطلق نوع (Type Safety) را با چابکی بیسابقهای trade-off کرد. زمانی که پیشتر صرف کلنجار رفتن با ابزارهای زنجیره توسعه (Toolchain) میشد، اکنون به عرضه قابلیتهای جدید و تستهای جامع اختصاص یافته است. هرچند هوش مصنوعی ممکن است کدهای «آشغال» و تستهای جعلی بنویسد، اما چرخه بازخورد آنقدر سریع است که این معامله بهتر از حد انتظار عمل میکند.
تغییر بهرهوری در شکل خروجیهای آنها مشهود است. اگرچه معیارهای نویزی مثل حجم کامیتها، تعداد خطوط کد یا تعداد PRها (که به دلیل پیشنمایشها و زیرساختها مخدوش شدهاند) تمام داستان را نمیگویند، اما سرعت حل مسائل به شدت جهش کرده است. تیم اکنون میتواند از یک تماس با مشتری به یک تیکت، سپس به یک PR، بررسی و استقرار برسد؛ به این معنا که اصلاح باگها میتواند پیش از آنکه نویسنده تماس تلفنی با مشتری را قطع کند، آنلاین شود.
آنها هنوز متوجه افزایش چشمگیر باگها نشدهاند، با وجود اینکه سختگیریهای Haskell را از دست دادهاند. این عمدتاً به این دلیل است که پوشش تستهای آنها هرگز تا این حد خوب نبوده است. وقتی باگی میگریزد، آنها میتوانند با سرعتی که پیش از این هرگز دیده نشده بود، آن را اصلاح کنند (Hotfix)؛ اصلاحات اکنون «تحتاللفظی تنها یک پیام در Slack فاصله دارند».
هشداری به اکوسیستم Haskell
این چرخش، در واقع نقدی بر جامعه گستردهتر Haskell است. نویسنده که همچنان از طریق بنیاد Haskell (HF) در رهبری زبان حضور دارد، هشدار میدهد که این اکوسیستم در خطر واقعی است. شکاف در حال گسترش است: مهندسان مجهز به AI اکنون میتوانند کارهایی را در چند روز انجام دهند که پیشتر هفتهها یا ماهها زمان میبرد.
از دیدگاه Scarf و تحلیل روندهای متنباز، رشد Haskell در بهترین حالت «متواضعانه» است. در حالی که سایر اکوسیستمهای توسعهدهنده در عصر AI شتاب میگیرند، Haskell اینطور نیست. نویسنده معتقد است جامعه این زبان بیش از حد بر «محدود کردن» متمرکز شده است تا بر «توانمندسازی». در حالی که استانداردها برای کدهای تولید شده با AI منطقی است، اما گروه قدرتمندی وجود دارند که استدلال میکنند «از LLMها استفاده نکنید» یا از پشتیبانی از جریانهای کاری یکپارچه با LLM سرباز میزنند. این دیدگاه، قرار داشتن در «سمت اشتباه تاریخ» تلقی میشود.
تعریف مجدد زبان «عامل-پسند» (Agent-Friendly)
نویسنده استدلال میکند که Haskell برای حفظ جایگاه خود باید عاملهای AI را به عنوان «کاربران درجه یک» بهینهسازی کند. یک اکوسیستمِ AI-enabled باید سوالات متفاوتی بپرسد و اهداف متفاوتی را اولویت دهد:
- چرخههای بازخورد: چگونه زمانهای بیلد سرد و زمان بوتاسترپ پروژه را کاهش دهیم؟
- مستندات: چگونه مستندات کتابخانهای را به جای ارائه صرفاً «تایپهای زیبا»، پر از مثالهای واقعی و قابل کپی-پیست کنیم؟
- پشتیبانی از عامل: چگونه پیامهای خطا را برای عاملها قابلفهمتر کنیم تا بتوانند خودشان کد را تعمیر (Self-repair) کنند؟
- دادههای آموزشی: چگونه نمونههای باکیفیت Haskell بیشتری را وارد دادههای آموزشی مدلها کنیم؟
- مقیاسپذیری: چگونه بازبینیها (Reviews) را مقیاس کنیم و الگوهای رایج صنعتی را برای مدلها بدیهی سازیم؟
ایمنی نوع میتواند یک مزیت عظیم باشد، اگر کامپایلر به عامل کمک کند تا سریعتر به نتیجه برسد، اما این امر مستلزم بهینهسازی برای عاملهاست، نه فقط برای انسانهایی که کد را با دست مینویسند. تولید کد برای عاملها ارزان است، اما توقف آنها (به دلیل انتظار برای کامپایل) بسیار گران است.
توازن استراتژیک
این یک چرخش از مهندسیِ «اول-صحیح» (Correctness-first) به مهندسیِ «اول-سرعت» (Velocity-first) است. نویسنده پیشنهاد میکند که جامعه باید تلاشهای خود را بازتخصیص دهد و شاید حتی برخی حوزههای تحقیقاتی فعلی را رها کند. در حالی که ویژگیهای جدیدی مثل «انواع وابسته» (Dependent Types) جالب هستند، کاربران صنعتی سالهاست از زمانهای کامپایل و اصطکاک اکوسیستم شکایت میکنند. در عصر AI، اینها دیگر مزاحمتهای ساده نیستند، بلکه یک «عدم انطباق بنیادین» هستند.
برای Scarf، این تصمیم منطقی بود. هزینه فرصتِ رکود بیش از حد بالا رفت. شرکت اکنون زمان بسیار کمتری را صرف فکر کردن به زنجیره ابزار توسعه میکند و زمان بیشتری را به بهرهبرداری از مرزهای جدید تکنولوژی میپردازد. آنها همچنان به Haskell احترام میگذارند و آن را در محیط عملیاتی اجرا میکنند، اما برای توسعه محصولات جدید، پایتون سرعت لازم برای بقا در چشمانداز متحولشده توسط AI را فراهم کرد.
این حرکت بازتابدهنده یک روند گستردهتر است که در آن «تجربه توسعهدهنده» (DX) در حال بازتعریف به عنوان «تجربه عامل» (AX) است. زبانهایی که نتوانند چرخههای بازخورد تقریباً لحظهای فراهم کنند، ریسک تبدیل شدن به گوشههای کوچک برای علاقهمندان را دارند، به جای آنکه زیربنای نرمافزارهای صنعتی باشند.
گام بعدی شما
- اگر از زبانهای با کامپایل سنگین استفاده میکنید، بررسی کنید که آیا زمان انتظار شما در برابر سرعت تولید کد توسط AI، یک گلوگاه است یا خیر.
- برای بهبود تجربهٔ عاملها، مستندات پروژههای خود را با مثالهای کاربردی و جامع بهروز کنید.
- استراتژی «استقرار موازی» را برای مهاجرتهای زبانی در مقیاس بزرگ بررسی کنید تا ریسک توقف سرویس کاهش یابد.
اما تأثیر این تغییر بر معماریهای توزیعشده گستردهتر است؛ برای درک مدیریت خطا در مقیاس میلیونی، تحلیل ما درباره سیستمهای توزیعشده را بخوانید.
گفتگو