اگر فکر میکنید برای ساخت سامانههای هوش مصنوعی پیشرفته تنها به مهارت نوشتن پرامپت نیاز دارید، احتمالاً در بازار کار آینده حذف خواهید شد. ساخت یک سیستم آماده برای محیط تولید (Production)، نیازمند تغییری بنیادین در رویکرد مهندسی نرمافزار است. این ادعا محوریت چارچوب جدیدی است که اندرو انجی (Andrew Ng)، بنیانگذار کورسرا و مدرس استنفورد، ارائه داده است. او برای شناسایی این مهارتها، تحلیل خود را بر پایه بررسی بیش از ۱۰ هزار آگهی شغلی و مصاحبه با متخصصان هوش مصنوعی، مدیران استخدام و استخدامکنندگان بنا کرده است.
صنعت اکنون از چتباتهای ساده به سمت گردشهای کاری عاملمحور (Agentic Workflows) — شبیه به تیمی از کارمندان مجازی که هر کدام وظیفهای دارند و با هم هماهنگ میشوند — حرکت میکند. همانطور که در تحلیل قبلی ما دربارهی OpenWorker اشاره کردیم، که بر روی خروجیهای خودکار و مستقل تمرکز داشت، این راهنمای جدید مستقیماً مهندسانی را هدف قرار داده که باید این سیستمها را بسازند و نگهداری کنند. این تغییر شبیه به این است که از یک مترجم که فقط یک زبان را میشناسد، به یک معمار تبدیل شوید که میداند چگونه یک شهر را طراحی کند.
مجموعهی مهارتهای کلیدی
به گزارش ZDNET، مهارتهای پیشنهادی انجی شامل چهار حوزه اصلی است:
- استقرار برنامههای هوش مصنوعی: تسلط بر مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — و همچنین تولید بازیابیافزا (RAG) — شبیه دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — و مهندسی زمینه (Context Engineering) و گردشهای کاری عاملمحور. این بخش همچنین شامل تسلط بر یادگیری ماشین (ML) و یادگیری عمیق (Deep Learning) است و بر استفاده از تکنیکهای آماری برای اندازهگیری، هدایت و نظارت بر سیستمها تأکید دارد تا رفتاری پیشبینیپذیرتر داشته باشند.
- اصول مهندسی نرمافزار: درک عمیق معماری، تست و امنیت. انجی هشدار میدهد که این دانش مانع از «کدنویسی حسی» (Vibe Coding) میشود؛ یعنی وضعیتی که برنامهنویس بدون درک تضادها و هزینههای فنی که عامل کدنویس در نظر گرفته، کورکورانه به کدهای تولیدشده توسط هوش مصنوعی اعتماد میکند.
- تسلط بر عوامل کدنویس: ایجاد یک مدل ذهنی از نحوه عملکرد عاملها (Agents) برای درک محدودیتهای آنها. این مهارت به مهندس اجازه میدهد سریعتر آنها را هدایت کند و بداند چه زمانی باید دخالت کند و چه زمانی اجازه دهد مدل بهتنهایی پیش برود تا بدون اتلاف زمان یا توکنهای بیش از حد، نرمافزاری مستحکم بسازد.
- حس محصول: عبور از اجرای صرفِ طرحهای گرافیکی یا پیادهسازی «پیکسل-به-پیکسل». مهندسان دیگر نباید انتظار داشته باشند که یک طرح نهایی به آنها داده شود تا صرفاً آن را اجرا کنند؛ بلکه باید بستر کسبوکار و اهداف مشتری را درک کنند.
نقد «سوگیری سازنده»
با وجود اعتبار این لیست، برخی از پیشکسوتان صنعت معتقدند این چارچوب دچار «سوگیری سازنده» (Builder Bias) است. اندی تورای (Andy Thurai)، مؤسس و مشاور هوش مصنوعی در The Field CTO، مدعی است که دستهبندی انجی صرفاً بر نوآوریهای «روز اول» — یعنی نوشتن کد و به کار انداختن مدل — تمرکز دارد. او این رویکرد را برای سازمانهای بزرگ «بهشدت محدود» میداند؛ زیرا سختترین بخش هوش مصنوعی در محیط واقعی، دیگر ساختن هوش نیست، بلکه هماهنگسازی (Orchestration)، نظارت (Observability) و پرداخت هزینههای آن است.
دیپیکا سیدانا (Deepika Sidana)، مدیر ارشد مهندسی نرمافزار در American Express و مدیر توسعه حرفهای NYSCD در انجمن زنان مهندس، میافزاید که ساخت اپلیکیشن تنها بخشی از چالش است. طبق گفتهی سیدانا، مهندسان اکنون باید ریسک، الزامات انطباق (Compliance) و پیامدهای شکست را در نظر بگیرند. او معتقد است قویترین مهندسان، کسانی هستند که مبانی فنی را با دانش دامنه، قضاوت محصولی، مهارتهای ارتباطی و مسئولیتپذیری در برابر نتایج تجاری قابل اندازهگیری ترکیب میکنند.
شکاف سازمانی و هماهنگسازی
متخصصان میگویند ارزشمندترین مهارتها اکنون خارج از کدنویسی سنتی قرار دارند. نامان آهوجا (Naman Ahuja)، مهندس نرمافزار در Meta، اشاره میکند که تصمیمات زیرساختی اکنون شامل ایجاد تعادل بین قابلیت اطمینان، بازدهی محاسبات، هزینه و تأثیر بر کاربر است، نه صرفاً نوشتن کدی که از نظر فنی درست باشد. او استدلال میکند چون هوش مصنوعی میتواند سریع کد بزند، کار سختتر اکنون تعریف درست مسئله، درک محدودیتهای تجاری، تجزیه سیستمها به اجزای کوچکتر و قضاوت درباره کاربردی بودن خروجی در محیط واقعی است.
برای پر کردن شکاف بین یک نمونه اولیه (Prototype) و یک سیستم تولیدی، تورای و سیدانا بر چند مکانیزم فنی حیاتی تأکید میکنند:
- هماهنگسازی قوی: مدیریت و هماهنگی بین مدلها، ابزارها، دادهها، ارزیابیها، نظارت، تأییدیههای انسانی و مسیرهای جایگزین (Fallback paths) در صورت شکست.
- حکمرانی پیشرفته: بهرهگیری از حکمرانی مهندسی و قطعی (Deterministic)، هماهنگسازی چند-عاملی و داوری بین عاملها (Agent Arbitration).
- اقتصاد عملیاتی: تسلط بر FinOps هوش مصنوعی و اقتصاد زمان اجرا (Runtime Economics) برای مدیریت هزینههای هوش مصنوعی.
- یکپارچگی سیستم: پیادهسازی نظارت عاملمحور (Agentic Observability)، امنیت عاملمحور و یکپارچهسازی سیستمهای اجتماعی-فنی.
کریس متسون (Chris Matteson) از Union.ai هشدار میدهد که بهرهوری حاصل از هوش مصنوعی وقتی مهندسان دلیل نوشتن نرمافزار و نحوه استفاده از آن را نمیدانند، در «شروعهای غلط و بازنویسیهای مکرر» تلف میشود. او میگوید تولید ارزان، نمونهسازی را سریع میکند اما برای تصمیمات استراتژیک، دیدی جامع لازم است تا بدانیم کدام تصمیمات «درهای یکطرفه» (برگشتناپذیر) هستند و معیارهای دور انداختن یک نمونه اولیه چیست. او هشدار میدهد مهندسان مجهز به هوش مصنوعی اغلب نرمافزارهای سطح تولید را «داخل یک حباب» میسازند، در حالی که تعامل با دنیای واقعی است که نرمافزارهای عالی را خلق میکند.
این تنش نشاندهنده شکافی رو به رشد است: تفاوت بین یک «سازنده» (Builder) هوش مصنوعی و یک «مهندس» (Engineer) هوش مصنوعی. در حالی که انجی نقشهای برای سازندگان ارائه داده، صنعت به دنبال مهندسانی است که بتوانند اهداف مبهم تجاری را به سیستمهای امن، قابل اعتماد و مقرونبهصرفه تبدیل کنند. برای رقابتی ماندن، توسعهدهندگان باید فراتر از محیط کدنویسی (IDE) بروند و AI FinOps و نظارت عاملمحور را مطالعه کنند تا مطمئن شوند نمونههای اولیه آنها واقعاً در محیط تولید زنده میمانند.
گام بعدی شما
- فراتر از محیط کدنویسی (IDE) بروید و مفاهیم AI FinOps را برای مدیریت هزینههای مدلها مطالعه کنید.
- روی مهارتهای نظارت بر عملکرد عاملها (Agentic Observability) تمرکز کنید تا بتوانید خطاهای زنجیرهای را ردیابی کنید.
- در پروژههای خود، معیارهای پذیرش محصول را بر اساس «ارزش تجاری» تعریف کنید، نه فقط «صحت فنی» خروجی مدل.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو