چرا ایجنت‌های هوش مصنوعی، جاوااسکریپت و تایپ‌اسکریپت را به پادشاهان جدید دنیای برنامه‌نویسی تبدیل کردند؟

با گسترش ایجنت‌های هوش مصنوعی، انتخاب زبان برنامه‌نویسی دیگر تنها یک تصمیم فنی نیست، بلکه رقابتی برای تسلط بر داده‌های آموزشی مدل‌هاست. این مقاله بررسی می‌کند که چگونه این چرخه باعث رشد بی‌سابقه تایپ‌اسکریپت و تغییر ماهیت شغل توسعه‌دهندگان از «کدنویس» به «بازبین کد» شده است.

در اوت ۲۰۲۵، تایپ‌اسکریپت (TypeScript) به پرکاربردترین زبان برنامه‌نویسی در گیت‌هاب تبدیل شد. این رویداد، بزرگ‌ترین تحول در رتبه‌بندی زبان‌ها در گیت‌هاب طی یک دهه اخیر محسوب می‌شود و دقیقاً در دوره‌ای رخ داد که پذیرش «ایجنت‌های هوش مصنوعی برنامه‌نویسی» (Coding AI agents) با بیشترین سرعت خود همراه بود.

پیش از این پیش‌بینی می‌شد که ایجنت‌های هوش مصنوعی، اهمیت انتخاب زبان برنامه‌نویسی را کاهش دهند. تصور بر این بود که سازمان‌ها دیگر به پشته‌ی فناوری خاصی وابسته نخواهند بود (Stack-agnostic) و صرفاً بر اساس نیازهای تجاری خود، تکنولوژی مورد نظر را انتخاب می‌کنند؛ بدون اینکه نگران محدودیت‌های بازار جذب نیروی متخصص باشند. اما برخلاف این انتظار، تنها دو سال پس از پذیرش گسترده ابزارهای هوش مصنوعی در کدنویسی، بازار به نظر محدودتر می‌آید. تنوع زبان‌های برنامه‌نویسی به‌سرعت در حال کاهش است و تمرکز اصلی بر یک خانواده‌ی واحد از زبان‌ها معطوف شده است.

تحلیل تغییرات

گزارش اکتبر ۲۰۲۵ «اکتوورس» (Octoverse) گیت‌هاب، مشارکت‌کنندگان در TypeScript را مورد بررسی قرار داد. تعداد مشارکت‌کنندگان ماهانه این زبان به ۲.۶۴ میلیون نفر رسید که نشان‌دهنده رشدی ۶۶ درصدی نسبت به سال گذشته است. طی سال ۲۰۲۵، بیش از یک میلیون توسعه‌دهنده برای نخستین بار کدهای TypeScript خود را در گیت‌هاب ثبت کردند.

این رشد در کنار جایگاه بسیار قدرتمند فعلی این زبان اتفاق افتاده است. در سال ۲۰۲۵، Stack Overflow نظرسنجی‌ای میان توسعه‌دهندگان انجام داد که بیش از ۴۹,۰۰۰ پاسخ دریافت کرد. از این میان، ۶۶ درصد اعلام کردند که از جاوااسکریپت (JavaScript) استفاده می‌کنند. تقریباً از سال ۲۰۱۱ تاکنون، جاوااسکریپت در این جایگاه مسلط بوده است. در نتیجه می‌توان گفت خانواده‌ی جاوااسکریپت هم پرکاربردترین و هم سریع‌ترین رشد را در گیت‌هاب داشته است.

لازم است اشاره کوتاهی به مسئله‌ی روش شمارش گیت‌هاب داشته باشیم؛ فعالیت‌های ثبت‌شده در گیت‌هاب، در واقع بازتابی از فعالیت‌های درون خود این پلتفرم است که می‌تواند نوعی «تضاد منافع» ایجاد کند، چرا که آن‌ها ممکن است مایل باشند آمارها را مثبت‌تر نشان دهند. همچنین، ترندهای مد روز بر نوع اطلاعاتی که در مخازن عمومی (public repositories) قرار می‌گیرد تأثیر می‌گذارند. با این حال، شاخص‌های موجود همچنان با داده‌های نظرسنجی همسو هستند که با توجه به ابعاد این روند، امری منطقی است.

مدل‌ها در زبان‌هایی بهتر می‌نویسند که بیشتر دیده‌اند

روند کار بسیار ساده است: مدل‌های هوش مصنوعی از کدهای منتشر شده یاد می‌گیرند و بخش اعظم کدهای منتشر شده به زبان‌های JavaScript و TypeScript نوشته شده‌اند. در واقع، بخش بزرگی از این کدها حول محور React متمرکز هستند.

این موضوع شکاف قابل‌توجهی را در خروجی ایجنت‌هایی که توسعه‌دهندگان استفاده می‌کنند ایجاد می‌کند؛ به‌طوری که تنها یک روز پس از تغییر پشته‌ی فناوری (stack)، این تفاوت خود را نشان می‌دهد. اگر از یک ایجنت هوش مصنوعی بخواهید یک کامپوننت تایپ‌شده‌ی React تولید کند، خروجی معمولاً بدون خطا کامپایل می‌شود، با استانداردهای کد موجود مطابقت دارد و نیاز به ویرایش بسیار کمی دارد. در مقابل، وقتی همان ایجنت را برای تولید کد در فریم‌ورک‌هایی مثل Svelte، Solid یا فریم‌ورک‌های بک‌اند (backend) کمتر محبوب درخواست می‌کنید، خروجی بسیار ضعیف‌تر خواهد بود. همچنین با APIهای ساختگی مواجه می‌شوید و ساختار اولیه کد (scaffolding) پیش از اجرا، نیاز به اصلاحات زیادی دارد.

در نتیجه، این مسئله در حال تغییر دادن نحوه‌ی انتخاب پشته‌های فناوری توسط تیم‌هاست. دیگر بحث تنها بر سر انتخاب اینکه کدام فریم‌ورک کارآمدتر یا ساده‌تر است نیست؛ بلکه مسئله اصلی این است که کدام فریم‌ورک با ابزارهای تیم سازگاری بیشتری دارد. چرا که شکاف بهره‌وری در خروجی‌های قابل استفاده‌ی ایجنت‌ها در طول یک چرخه توسعه‌ی طولانی، به شدت تشدید می‌شود. وقتی آن تیم کدی تولید می‌کند، آن کد منتشر شده، توسط ربات‌ها جمع‌آوری (scrape) و در مراحل بعدی آموزش مدل‌ها گنجانده می‌شود و همین امر شکاف بهره‌وری را بیش از پیش گسترش می‌دهد.

هیچ‌کدام از این موارد به معنای برتری فنی نیست. فریم‌ورک‌های Solid و Svelte بسیار خوب هستند و چندین فریم‌ورک مدرن‌تر نیز در سرعت خالص عملکرد، از React پیشی می‌گیرند؛ اما بازار به سمت گزینه‌ای متمایل شد که مدل‌ها پیش‌تر با آن آشنایی داشتند.

مدل‌ها با Python ساخته می‌شوند، اما محصولات نهایی با JavaScript عرضه می‌گردند.

یک پاسخ معتبر به نکات فوق این است که توسعه هوش مصنوعی در پایتون (Python) انجام می‌شود. آموزش مدل، ارزیابی و اکثر ابزارهای پژوهشی در پایتون اجرا می‌شوند و این موضوع تغییری نکرده است.

با این حال، بخش بسیار کمی از آنچه مشتری با آن تعامل دارد به زبان پایتون نوشته شده است. در واقع، رابط کاربری (Front-end) یک محصول هوش مصنوعی اساساً پنجره‌ای است که توکن‌ها را به‌صورت جریانی (stream) نمایش می‌دهد. همچنین این محصولات به دکمه‌هایی برای اجرای ابزارها، مرحله تأیید برای هر اقدامی که می‌تواند پیامد منفی داشته باشد و توضیحی درباره عملکرد سیستم و دلیل آن نیاز دارند. تمام این موارد، صرف‌نظر از اینکه مدل از OpenAI، Anthropic یا یک مدل با وزن باز (open-weight) که شرکت روی سخت‌افزار خود میزبانی می‌کند، تهیه شده باشد، با جاوااسکریپت و تایپ‌اسکریپت انجام می‌شود.

تا پایان سال ۲۰۲۵، گیت‌هاب گزارش داده است که بیش از ۱.۱ میلیون مخزن عمومی (repository) از SDK مدل‌های زبانی بزرگ (LLM) استفاده می‌کنند که افزشی ۱۷۸ درصدی نسبت به سال قبل داشته است. این افزایش عمدتاً ناشی از توسعه اپلیکیشن بوده است، نه توسعه مدل. هر پروژه آزمایشی سازمانی که از مرحله دمو فراتر می‌رود، نیازمند کسی است که بخش رابط کاربری کاربر را بسازد و ابزارهای استاندارد صنعت برای این کار، فریم‌ورک‌های جاوااسکریپت هستند.

سیستم‌های تایپینگ به نرده‌های حفاظتی برای کدهای تولیدشده تبدیل شدند

دیدگاه گیت‌هاب این است که این تغییر به معنای حرکت توسعه‌دهندگان به سمت زبان‌های دارای تایپ (typed languages) بوده است، زیرا سیستم‌های تایپینگ، توسعه به کمک عامل‌های هوشمند (agent-assisted development) را ایمن‌تر می‌کنند. کدهای تولیدشده نوع خاصی از خطا دارند؛ آن‌ها خوانا هستند و ساختار خوبی دارند و حتی در زبان‌های پویا (dynamic languages) به‌خوبی اجرا می‌شوند، اما ممکن است چند مرحله بعد از فراخوانی، به دلیل عدم تطابق ساختار داده‌ها (shape mismatches) با خطا مواجه شوند و متوقف گردند. چک‌کننده‌های تایپ (Type checkers) بخش بزرگی از این خطاها را پیش از اجرای کد شناسایی می‌کنند.

این نظریه در عمل ثابت شده است. در سال ۲۰۲۶، استفاده از تایپ‌اسکریپت توسط توسعه‌دهندگان حرفه‌ای به ۷۸ درصد رسید که نسبت به ۶۹ درصد در دو سال قبل، افزایش یافته است. تقریباً ۴۰ درصد از توسعه‌دهندگان منحصراً با تایپ‌اسکریپت کدنویسی می‌کنند و تنها ۶ درصد نیز منحصراً از جاوااسکریپت خام استفاده می‌کنند.

انواع خطاهایی که یک کامپایلر پیدا می‌کند، معمولاً همان خطاهایی هستند که یک بازبین انسانی هنگام مواجهه با ۴۰۰ خط کد منطقی، از آن‌ها چشم‌پوشی می‌کند:

● فراخوانی یک تابع با شیئی (object) که یکی از فیلدهای مورد نیاز را ندارد.

● وجود فرضی در کد مبنی بر وجود یک مقدار، که منجر به ارسال مقدار null یا undefined می‌شود.

● تغییر ساختار پاسخ یک API و استفاده‌ی هندلرِ تولیدشده از ساختار قدیمی.

تغییر گلوگاه از نوشتن کد به تأیید کد

گزارش میدانی OpenAI در مورد استفاده از عامل‌های برنامه‌نویسی (coding agents) در محاسبات علمی در جولای ۲۰۲۶، محدودیت را بسیار صریح بیان کرد: برخلاف تولید کد، اکنون «تأیید کردن» (verification) به عامل محدودکننده تبدیل شده است. اگرچه این یک شرکت است که محصول خود را بررسی می‌کند و باید با احتیاط به آن نگریست، اما این نتیجه با آنچه بسیاری از تیم‌های مهندسی، به‌ویژه خارج از حوزه پژوهش، در سال گذشته مشاهده کرده‌اند، همخوانی دارد.

وقتی یک رابط کاربری توانمند به‌جای سه هفته، تنها در یک بعدازظهر ساخته می‌شود، کندترین بخش فرآیند به تعیین این موضوع تبدیل می‌شود که آیا هر آنچه روی صفحه ظاهر شده، صحیح، امن و قابل نگهداری است یا خیر. این امر انتظارات از یک توسعه‌دهنده جاوااسکریپت را تغییر می‌دهد. سرعت در کدنویسی هرگز ارزش واقعی این شغل نبوده است، اما در فرآیند استخدام به عنوان معیاری تقریبی برای سنجش مهارت استفاده می‌شد. کدهای تولیدشده این معیار را از میان برده‌اند و تنها «قضاوت» را باقی گذاشته‌اند.

انتظار می‌رود که یک `React effect` در طول فرآیند توسعه، دو بار اجرا شود و برنامه‌نویسی که از این موضوع بی‌اطلاع است، ممکن است تمام روز خود را صرف بررسی چیزی کند که به دلیل فراخوانی تکراری `API` تصور می‌کند یک باگ است. یک کوئری (`Query`) تولید شده ممکن است در محیط توسعه با داده‌های نمونه خوب به نظر برسد، اما هنگام استفاده در محیط عملیاتی (`Production`)، ممکن است منجر به اسکن کردن کل یک جدول شود. یک بررسی احراز هویت (`Auth check`) می‌تواند در هر جای یک کامپوننت قرار گیرد و بی‌اثر باشد؛ این امر ممکن است توهم امنیت را ایجاد کند، اما این توهم زمانی از بین می‌رود که کسی واقعاً آن را آزمایش کند.

یک عدم هم‌راستایی وجود دارد که تیم‌ها معمولاً نادیده می‌گیرند. ظرفیت تولید کد تقریباً بی‌نهایت است و با اضافه شدن هر عامل (`Agent`) جدید یا اشتراک جدید، افزایش می‌یابد. در مقابل، ظرفیت بازبینی (`Review capacity`) توسط تعداد مهندسانی محدود می‌شود که به اندازه کافی بر سیستم مسلط هستند تا بتوانند یک خطای احتمالی را شناسایی کنند. احتمال اینکه این تعداد با همان سرعتِ تولید کد افزایش یابد، بسیار کم است. افزودن ظرفیت بیشتر برای تولید کد به تیمی که در حال حاضر در مرز حداکثر ظرفیت بازبینی خود قرار دارد، نرخ تحویل پروژه را افزایش نمی‌دهد؛ بلکه صرفاً گلوگاه (`Bottleneck`) را از مرحله «نوشتن» به مرحله «بازبینی» منتقل می‌کند. یک تیم می‌تواند ظرفیت تولید کد خود را در عرض یک هفته دو برابر کند، اما این کار تعداد افراد موجود برای بازبینی را تغییر نخواهد داد. به همین دلیل است که محدودیت‌ها تغییر کرده‌اند و ابزارهای اضافی لزوماً راه حل مشکل نیستند.

همین موضوع در مورد روش‌های استخدام نیز صدق نمی‌کند. بیشتر فرآیندهای غربالگری همچنان ارزیابی می‌کنند که آیا کاندیدا می‌تواند به یک راه حل عملی برسد یا خیر؛ یعنی همان بخشی که ابزارها در حال حاضر در آن کمک می‌کنند. برخی شرکت‌ها شروع به ارزیابی مهارت معکوس کرده‌اند. آن‌ها بلوک‌های کد تولید شده توسط هوش مصنوعی را که حاوی یک خطا هستند به کاندیداها ارائه می‌دهند و مشاهده می‌کنند که چقدر طول می‌کشد تا آن خطا شناسایی و رفع شود.

شرکت‌های کاریابی نیز در همین مسیر حرکت کرده‌اند. به عنوان مثال، شرکت Full Scale اکنون مهندسان جاوااسکریپت خود را به‌جای تمرکز بر تعداد خطوط کد نوشته شده، با ویژگی‌هایی چون تسلط بر ابزارهای هوش مصنوعی و داشتن «درک محصول» (`Product sense`) معرفی می‌کند. شرکتی که قصد استخدام یک توسعه‌دهنده اختصاصی جاوااسکریپت را دارد، اکنون در حال کسب ظرفیت بازبینی به همان اندازه ساخت ظرفیت تولید است. این موضوع تا زمانی که یک جریان ورود (`Login flow`) تولید شده توسط هوش مصنوعی، بدون مداخله انسانی وارد محیط عملیاتی شود، تغییر کوچکی به نظر می‌رسد.

تمرکز هزینه‌بر است

بازاری که برای آنچه مدل‌ها از قبل می‌دانند ارزش قائل است، معرفی هر چیز جدیدی را دشوار می‌کند. یک فریم‌ورک (`Framework`) جدید که امسال منتشر شده است، هیچ مجموعه داده آموزشی (`Corpus`) پیشینی ندارد؛ این موضوع کار با آن را برای عامل‌های هوش مصنوعی دشوار کرده، تیم‌ها را از استفاده از آن باز می‌دارد و در نهایت منجر به سناریویی می‌شود که هیچ مجموعه داده‌ای تولید نمی‌شود. زمان معمول برای رسیدن به مرحله جذب سرمایه (`Time-to-funding`) برای راهکارهای مبتنی بر شایستگی جهت شکستن این چرخه کافی نیست. فریم‌ورک‌هایی که پیش از سال ۲۰۲۳ به نقاط عطف خود دست یافته‌اند، اکنون مزیتی دارند که هیچ ارتباطی با کیفیت طراحی آن‌ها ندارد.

این ریسک برای یک شرکت واحد محدودتر است. کسب‌وکاری که محصول، ابزارها و فرآیند استخدامش همگی حول محور یک خانواده زبانی واحد می‌چرخد، سه بار شرط‌بندی مشابهی را انجام داده است. تا زمانی که آن خانواده زبانی سلطه خود را حفظ کند، این وضعیت آرامش‌بخش است، اما اگر دچار لغزش شود، بسیار پرهزینه خواهد بود.

اولین پیش‌بینی تا حدودی درست بود. هوش مصنوعی واقعاً بخش زیادی از هزینه نوشتن کد به زبانی را که هیچ‌کس در تیم آن را نمی‌فهمید، از بین برده است. با این حال، هزینه‌های مربوط به «درک» (`Comprehension`) و «مالکیت» (`Ownership`) همچنان پابرجا هستند و برای اکثر تیم‌ها، این همان هزینه اصلی است که تعیین‌کننده پشته تکنولوژی (`Technology stack`) آن‌هاست.