تصور کنید در آینده‌ای هستیم که انسان‌ها دیگر اکثریت کد یک پروژه را نمی‌نویسند. در این مرحله از برنامه‌نویسی، خوزه والیم (José Valim)، خالق زبان Elixir، معتقد است ارگونومی‌های سنتی زبان — مانند سینتکس‌های ساده‌ساز (Syntactic Sugar) یا زنجیره‌سازی اختیاری (Optional Chaining) — عملاً بی‌معنی می‌شوند، زیرا کاربران اصلی این زبان‌ها دیگر انسان نیستند، بلکه عامل‌های هوش مصنوعی (AI Agents) هستند.
این گذار زمانی رخ می‌دهد که عامل‌های کدنویس از ابزارهای ساده‌ی تکمیل خودکار به موجوداتی خودمختار تبدیل شوند که قادر به مدیریت کل چرخه حیات نرم‌افزار هستند. برای دهه‌ها، تکامل زبان‌ها بر «خوشحالی برنامه‌نویس» و کاهش کدهای تکراری (Boilerplate) متمرکز بود. اما عامل‌ها از تکرار و کارهای کسالت‌بار خسته نمی‌شوند؛ آن‌ها بر اساس توکن‌های ورودی و خروجی (Tokens-in and Tokens-out) عمل می‌کنند و بنابراین سینتکس‌های انسان‌محور به یک دغدغه‌ی ثانویه تبدیل می‌شود.
به نقل از تحلیل فنی منتشر شده در وب‌سایت dashbit.co در ۲۴ سپتامبر ۲۰۲۶، صنعت اکنون باید به جای ترجیحات انسان، محدودیت‌های عامل‌ها را بهینه کند. این امر مستلزم بازنگری بنیادین در نحوه ساخت اکوسیستم‌ها، کامپایلرها و ابزارهای توسعه است. والیم اشاره می‌کند که اگرچه میزان این تغییر هنوز موضوعی بحث‌برانگیز است، اما برای بسیاری از توسعه‌دهندگان و تیم‌ها به یک واقعیت تبدیل شده است. این تحول در راستای ۸ چرخش مهندسی در سال ۲۰۲۶ است که کل فرآیند توسعه نرم‌افزار را بازتعریف می‌کنند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن و تغییر نقش توسعه‌دهنده اشاره کردیم، ابزارهایی که برای چشم انسان طراحی شده‌اند، لزوماً برای منطق ماشین بهینه نیستند.
فرسایش جوامع برنامه‌نویسی
والیم خاطرنشان می‌کند که جوامع برنامه‌نویسی به‌طور سنتی حول محور حساسیت‌های مشترک شکل می‌گیرند. برای مثال، پایتون بر «یک راه بدیهی و واضح برای انجام هر کار» تأکید دارد. زبان روبی سال‌هاست که قدردانی از «خوشحالی برنامه‌نویس» را در فرهنگ خود پرورش داده است. جوامع زبان Lisp نیز به‌طور سنتی توانایی تغییر شکل دادن خودِ زبان را جشن گرفته‌اند. اما وقتی عامل‌ها کد می‌نویسند، این «چسب اجتماعی» که جوامع را به هم متصل می‌کند ممکن است از بین برود. این موضوع پرسش‌های عمیقی را ایجاد می‌کند: در آینده چه چیزی این گروه‌ها را متحد خواهد کرد و این تغییر چگونه بر حس تعلق ما به یک جامعه‌ی فنی تأثیر می‌گذارد؟
اکوسیستم‌ها — که ما آن‌ها را برای حل مسائل سخت از طریق انتزاع‌های مشترک مانند فریم‌ورک‌های وب، کتابخانه‌های تنسور، ابزارهای رابط کاربری (GUI) و خط لوله‌های پردازش داده می‌سازیم — ممکن است تحت تأثیر دو نیروی متضاد قرار گیرند:
- کاهش شکاف بین زبان‌ها: عامل‌ها می‌توانند به‌سرعت پیاده‌سازی‌های موجود را بین زبان‌های مختلف منتقل کنند، ایده‌های مقالات پژوهشی را ترجمه کنند یا الگوریتم‌های شناخته‌شده را پیاده‌سازی نمایند. این امر به جوامع کوچک‌تر اجازه می‌دهد تا با کاهش زمان و تلاش مورد نیاز برای ساخت این فریم‌ورک‌ها، بسیار سریع‌تر به سطح جوامع بزرگ برسند.
- کاهش همکاری: اگر پیاده‌سازی یک راهکار به‌اندازه کافی ارزان و سریع شود، انگیزه برای تلاش مشترک روی یک راهکار واحد ضعیف می‌شود. اگر یک توسعه‌دهنده برای حل «مسئله X» به یک کتابخانه نیاز داشته باشد، ممکن است به‌جای مشارکت در یک پروژه متن‌باز، صرفاً از یک عامل بخواهد دقیقاً همان چیزی را که نیاز دارد برایش بسازد.
این وضعیت تضادی ایجاد می‌کند که در آن عامل‌ها هزینه ساخت یک اکوسیستم را کاهش می‌دهند، اما هم‌زمان نیروهایی را که باعث شکل‌گیری اولیه آن اکوسیستم‌ها می‌شدند، تضعیف می‌کنند.
بی‌اهمیتی ارگونومی
در دهه گذشته، بسیاری از زبان‌ها عملگرهای زنجیره‌سازی اختیاری (Optional Chaining) را برای جایگزینی بررسی‌های صریح null اضافه کردند. در حالی که این ویژگی‌ها برای انسان‌ها دلپذیرتر است، عامل‌ها با کدهای تکراری (Boilerplate) مشکلی ندارند. والیم استدلال می‌کند که «بهینگی توکن‌ها» (Token Efficiency) در انتهای فهرست چیزهایی است که باید برای آن‌ها بهینه‌سازی کنیم، به‌ویژه با گسترش پنجره‌های بافت (Context Windows) و ارزان‌تر و کارآمدتر شدن مدل‌ها.
او نسبت به هر زبان جدیدی که ادعا می‌کند «برای عامل‌های کدنویس» ساخته شده اما تمرکزش را صرفاً بر سینتکس گذاشته است، هشدار می‌دهد. او معتقد است ساختن زبان بر اساس سینتکس، در واقع ساختن بر اساس محدودیت‌های امروز است. بر اساس تجربه او در استفاده از عامل‌ها برای نوشتن HTML, CSS, JavaScript, Elixir, Rust و Lean، تفاوت‌های سینتکسی که برای انسان‌ها عظیم به نظر می‌رسد، برای عامل‌ها اهمیت بسیار کمی دارد. از دیدگاه آن‌ها، همه چیز صرفاً توکن‌های ورودی و خروجی است.
فراتر از بحث کامپایلرها
یک نظریه رایج وجود دارد که عامل‌ها در نهایت با نوشتن مستقیم کد اسمبلی، جایگزین کامپایلرها می‌شوند. والیم این نظریه را رد می‌کند و به نیاز مبرم به «نمایش‌های مستقل از معماری» (Architecture-independent representations) اشاره می‌کند. اگر شما در حال ساخت یک اپلیکیشن دسکتاپ هستید، نمی‌خواهید برای هر معماری سخت‌افزاری مورد پشتیبانی، پیاده‌سازی‌های اسمبلی متفاوتی را نگهداری کنید؛ شما همچنان به راهی نیاز دارید تا یک نمایش سطح بالا را به ماشین هدف تبدیل کنید. در واقع، نوشتن مستقیم اسمبلی صرفاً بازاختراع بخشی از یک کامپایلر و یک زبان سطح بالا خواهد بود، حتی اگر آن زبان هرگز برای انسان طراحی نشده باشد.
علاوه بر این، هیچ مدل محاسباتی واحدی در همه زمینه‌ها برتر نیست. ما همچنان به زبان‌های تخصصی نیاز داریم زیرا آن‌ها معناشناسی (Semantics) و تضمین‌های متفاوتی را کدگذاری می‌کنند:
- زبان‌های برنامه‌نویسی سیستم برای کنترل سطح پایین حافظه و سخت‌افزار.
- اثبات‌کننده‌های قضیه (Theorem Provers) برای تأیید رسمی (Formal Verification).
- زبان‌های هم‌روند و تاب‌آور (مانند Erlang یا Elixir) برای نرم‌افزارهای توزیع‌شده.
- زبان‌های پرس‌وجو (Query Languages) و زبان‌های توصیف سخت‌افزار برای دامنه‌های خاص.
این غیرمنطقی است که انتظار داشته باشیم یک زبان سطح پایین واحد، تمام این انتزاع‌های متنوع را یکپارچه کند. بنابراین، پرسش این نیست که آیا به زبان‌ها نیاز داریم یا خیر، بلکه این است که اگر دیگر برای انسان‌هایی که کد می‌نویسند بهینه‌سازی نکنیم، باید آن‌ها را برای چه چیزی بهینه کنیم؟
چرخش به سمت تضمین‌های قوی‌تر
اگر ارگونومی دیگر مهم نیست، زبان‌ها باید برای «بیان‌گری» (Expressiveness) و «تضمین‌ها» (Guarantees) بهینه شوند. والیم پیشنهاد می‌کند اولویت را از استنتاج نوع (Type Inference) — که به انسان‌ها کمک می‌کند از تکرار بگریزند — به سمت انواع صریح (Explicit Types) و نیات مشخص تغییر دهیم. این کار اطلاعات بسیار بیشتری را برای کامپایلر، سایر عامل‌ها و انسان‌ها فراهم می‌کند. از آنجایی که زبان‌هایی با انواع کاملاً استنتاج‌پذیر عموماً زیرمجموعه‌ای از زبان‌هایی هستند که انواعشان قابل بررسی است، بهینه‌سازی برای استنتاج می‌تواند در واقع تضمین‌هایی را که یک سیستم نوع (Type System) ارائه می‌دهد، محدود کند. والیم می‌پرسد چرا باید این محدودیت‌ها را بر عامل‌هایی تحمیل کنیم که همین حالا قادر به نوشتن اثبات‌ها در سیستم‌های بسیار پیچیده‌تر هستند؟
او یک رویکرد چهارلایه برای استحکام نرم‌افزار پیشنهاد می‌کند و اشاره می‌کند که اگرچه نمی‌توانیم تمام نرم‌افزارها را به‌صورت رسمی تأیید کنیم، اما می‌توانیم این تکنیک‌ها را ترکیب کنیم:
- صحیح در ساختار (Correct by construction): زبان به‌گونه‌ای طراحی شود که بیان حالت‌ها یا برنامه‌های نامعتبر را سخت یا غیرممکن کند.
- تثبیت‌شده استاتیک: استفاده از انواع، اثبات‌ها و تحلیل استاتیک برای تعیین ویژگی‌های برنامه پیش از اجرا.
- اجرای اجباری در زمان اجرا (Runtime-enforced): استفاده از مدیریت حافظه، ایزولاسیون، مرزهای قابلیت (Capability Boundaries) و Garbage Collection. برای مثال، Erlang/Elixir بر فرآیندهای ایزوله و تبادل پیام تکیه می‌کنند تا بخشی از بیان‌گری را فدای ایزولاسیون قوی‌تر و تحمل خطای بیشتر کنند. اگرچه هر الگوریتم هم‌روندی به‌طور بهینه با این مدل سازگار نیست، اما آن‌هایی که هستند، این تضمین‌های مفید را به ارث می‌برند.
- تأیید تجربی: اعتبارسنجی برنامه از طریق تست‌ها، تست‌های مبتنی بر ویژگی (Property-based testing) و Fuzzing.
والیم معتقد است نحوه ترکیب این تکنیک‌ها توسط زبان‌ها برای جابجایی مرز بین بیان‌گری و تضمین‌ها، به‌طور فزاینده‌ای آن‌ها را از هم متمایز کرده و عامل پذیرش آن‌ها خواهد بود. او همچنین اشاره می‌کند که فریم‌ورک‌ها نیز باید این رویه‌ها را در سطح انتزاع خود به کار بگیرند.
جایگزینی LSP با پایگاه‌داده‌های برنامه‌ای
یکی از ملموس‌ترین تغییرات، پیش‌بینی مرگ پروتکل سرور زبان (LSP) است. LSPها بر اساس مفاهیمی مانند اسناد، خطوط و ستون‌ها طراحی شده‌اند؛ مفاهیمی که عامل‌ها به‌دقت آن‌ها را دنبال نمی‌کنند. والیم در تجربه ساخت Tidewave دریافت که عامل‌ها ترجیح می‌دهند بپرسند «مستندات تابع foo_bar کجاست؟» یا «BarBaz کجا تعریف شده است؟» به‌جای اینکه یک ارجاع دقیق به یک خط خاص در یک فایل منبع ارائه دهند.
او به‌جای LSP، پایگاه‌داده‌های برنامه‌ای (Program Databases) را پیشنهاد می‌کند. عامل‌ها به‌جای پرش بین فایل‌ها به‌صورت تک‌تک، باید از یک زبان پرس‌وجو (مانند SQLite، Datalog یا یک DSL سفارشی) استفاده کنند تا سوالات پیچیده‌ای بپرسند:
- «تمام توابع عمومی را پیدا کن که در نهایت این تابع را فراخوانی می‌کنند.»
- «تمام مسیرهایی را در برنامه شناسایی کن که در آن یک مقدار خاص می‌تواند nil شود.»
در حالی که درخواست از یک توسعه‌دهنده انسان برای نوشتن یک پرس‌وجو جهت یافتن ارجاع به یک تابع غیرمنطقی است، برای یک عامل، نوشتن یک پرس‌وجوی برنامه‌ای دقیقاً به اندازه فراخوانی یک ابزار CLI یا LSP تلاش می‌طلبد. این پایگاه‌داده‌ها همچنین می‌توانند به‌عنوان Linter عمل کنند تا از عامل‌ها در برابر رویه‌های نامطلوب محافظت کنند. این تغییرات در واقع بخشی از نقشه عملیاتی استک توسعه AI در سال ۲۰۲۶ هستند که معماری‌های لایه‌ای جدیدی را برای ابزارهای توسعه معرفی می‌کنند.
این تغییر مستلزم حرکت به دور از ویژگی‌های «عمل در فاصله» (Action at a distance) است. در پایگاه‌های کد بزرگ، «موضعی بودن» (Locality) اهمیت بسیار زیادی پیدا می‌کند. ویژگی‌هایی مانند Monkey-patching، قلاب‌های ضمنی (Implicit Hooks) و بازتعریف پویا (Dynamic Rebinding)، ردیابی رفتار کد را حتی برای یک پایگاه‌داده برنامه‌ای سخت می‌کنند، زیرا کد در یک مکان می‌تواند بر کل سیستم تأثیر بگذارد.
از دیباگرها به مشاهده‌پذیری زمان اجرا
دیباگرهای سنتی با نقاط توقف (Breakpoints) و اجرای گام‌به‌گام، برای سرعت شناختی انسان طراحی شده‌اند. عامل‌ها می‌توانند کدها را ابزارگذاری کنند، ردپاها (Traces) را جمع‌آوری نمایند و اطلاعات را بسیار سریع‌تر از هر انسانی همبسته کنند. والیم پیشنهاد می‌کند عامل‌ها باید مسئولیت‌های بیشتری را در کل چرخه حیات توسعه نرم‌افزار بر عهده بگیرند، از جمله نظارت و تشخیص زنده سیستم‌های عملیاتی (Production) به‌جای تکیه بر لاگ‌های استاتیک و داشبوردها.
ران‌تایم‌ها باید وضعیت داخلی خود را به‌صورت برنامه‌ریزی‌شده افشا کنند. او ماشین مجازی Erlang را نمونه‌ای برتر از سیستمی می‌داند که در حال حاضر در این زمینه عالی است و اجازه بازرسی موارد زیر را می‌دهد:
- فرآیندها و سوکت‌ها
- اپلیکیشن‌ها و ناظران (Supervisors)
- جداول ETS و صف‌های پیام
شکاف باقی‌مانده این است که این قابلیت‌ها به‌صورت ایمن از طریق یک Sandbox، یک زبان پرس‌وجو یا مجموعه‌ای از ابزارها در اختیار عامل‌ها قرار گیرد. این امر به عامل‌ها یک رابط مشترک می‌دهد تا شکست‌ها را تشخیص دهند، مسائل مربوط به قابلیت اطمینان را شناسایی کنند و گلوگاه‌ها را به‌صورت زنده در تمام محیط‌ها ردیابی نمایند.
این تکامل، فرض اصلی این حوزه را تغییر می‌دهد: «تجربه توسعه‌دهنده» (DX) دیگر فقط درباره انسانی نیست که پشت کیبورد نشسته است، بلکه درباره سطح API است که در اختیار عاملی قرار می‌گیرد که سیستم را مدیریت می‌کند.
همان‌طور که به سمت این معماری «عامل-محور» حرکت می‌کنیم، مزیت رقابتی یک زبان دیگر این نخواهد بود که یادگیری آن چقدر آسان است، بلکه این خواهد بود که اجرای آن برای یک عامل خودمختار چقدر قابل تأیید (Verifiable) و مشاهده‌پذیر (Observable) است.
گام بعدی شما
- بررسی ابزارهای تحلیل استاتیک که خروجی‌های ساختاریافته (JSON/Graph) برای مدل‌های زبانی ارائه می‌دهند.
- مطالعه معماری ماشین مجازی Erlang برای درک نحوه افشای وضعیت داخلی سیستم (Introspection).
- ارزیابی مجدد استراتژی‌های تست نرم‌افزار با تمرکز بر Property-based testing برای اعتبارسنجی خروجی‌های عامل‌ها.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و بهینه‌سازی استنتاج در لبه مراجعه کنید.
گفتگو