اگر دهه گذشته را صرف تسلط بر هنر نوشتن کدهای تمیز کرده‌اید، باید بدانید مزیت رقابتی اصلی شما همین حالا فروپاشید. تصور کنید برنامه‌نویسی که سال‌ها برای بهینه‌سازی یک حلقه تکرار جنگیده، حالا می‌بیند یک مدل زبانی در چند ثانیه کدی می‌نویسد که از نظر فنی بی‌نقص است.
به نقل از مقاله‌ای که در ۱۷ ژوئن ۲۰۲۶ در پلتفرم dev.to منتشر شد، بحرانی در حال شکل‌گیری است: مهندسان می‌بینند مهارت‌هایی مثل عیب‌یابی، تخصص در دامنه و معماری، برای هر کسی که به یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — دسترسی دارد، در دسترس شده است.
تله‌ی پیاده‌سازی
برای چندین دهه، صنعت نرم‌افزار «پیاده‌سازی» — یعنی تبدیل یک راهکار تصمیم‌گرفته‌شده به کد — را با «مهندسی» اشتباه گرفت. این اشتباه به این دلیل بود که نوشتن کد، فرآیندی گران و کند بود. اما اکنون هزینه این کار در حال سقوط به سمت صفر است.
وقتی یک توسعه‌دهنده از LLM می‌خواهد یک API بنویسد، تست‌ها را تولید کند یا زیرساخت بسازد، مدل معمولاً نتیجه‌ای شگفت‌انگیز می‌دهد. این موضوع ثابت می‌کند بخش بزرگی از آنچه «کار مهندسی» می‌نامیدیم، در واقع یک «کار ترجمه» بود؛ یعنی ترجمه نیاز بیزینسی به زبان ماشین.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی جایگزینی مشاغل توسط AI اشاره کردیم، در محیطی که یک توسعه‌دهنده می‌تواند کل یک API یا یک کد قدیمی را در چند ثانیه بازنویسی کند، دیگر «توان عملیاتی» یا سرعت ساخت، یک عامل تمایز نیست.
ماهیت شکست‌ها
طبق گزارش dev.to، سخت‌ترین مشکلات در محیط عملیاتی به‌ندرت خطاهای پیاده‌سازی هستند. شما تقریباً هرگز شاهد سقوط یک سیستم بزرگ به دلیل یک حلقه for بد نوشته‌شده نخواهید بود. در عوض، شکست‌ها از «مشکلات تعریف» ریشه می‌گیرند.
این بحران‌ها زمانی رخ می‌دهند که تیم‌ها بر سر منطق بنیادی بیزینس توافق ندارند؛ مثلاً اینکه دقیقاً چه کسی «مشتری فعال» محسوب می‌شود. دشواری واقعی، نوشتن کد پس از یافتن پاسخ نیست، بلکه کشف خودِ پاسخ است. این یعنی پرسیدن این سوالات: چرا دو سیستم با هم اختلاف دارند؟ چه قانون بیزینسی را می‌خواهیم اجرا کنیم؟ وقتی نیازها با هم تضاد دارند چه اتفاقی می‌افتد؟
مهندسی از کجا شروع می‌شود؟
مهندسی واقعی درست از جایی شروع می‌شود که LLM متوقف می‌شود. یک مدل می‌تواند حقایق مربوط به سیستم‌های تسویه، حراج‌های تبلیغاتی یا قوانین بهداشتی را از اسناد یاد بگیرد، اما نمی‌تواند تشخیص دهد کجا یک دامنه متناقض، ناقص یا تعریف‌نشده است.
مهندسی واقعی یعنی خلق مدلی از یک دامنه که آن‌قدر دقیق باشد که کامپیوتر بتواند آن را اجرا کند. این فرآیند شامل موارد زیر است:
- شناسایی نیازهای متناقض (مثلاً درک اینکه ۲۰ نیاز مختلف نمی‌توانند هم‌زمان درست باشند).
- شناسایی پیش‌فرض‌های فراموش‌شده، پیش از آنکه حتی یک خط کد نوشته شود.
- تشخیص تصمیمات بیزینسی که هنوز هیچ‌کس متوجه نشده باید گرفته شوند.
- ایجاد توازن‌های حساس وقتی دو قانون بیزینسی با هم در تضادند.
- ساخت مدل‌های دقیق از دامنه‌های آشفته برای اجرای ماشین.
یک LLM می‌تواند یک حوزه را خلاصه کند، اما هنوز نمی‌تواند پاسخ‌هایی را که اصلاً وجود ندارند، کشف کند یا وقتی ذینفعان اختلاف نظر دارند، تصمیم بگیرد چه چیزی «درست» است.
چرخش به سمت قضاوت
این تغییر، شکافی در نیروی کار ایجاد می‌کند. مهندسانی که هویت خود را بر پایه سرعت پیاده‌سازی و حجم خروجی ساخته‌اند، باید نگران باشند. اما کسانی که بر درک سیستم‌های پیچیده و طراحی انتزاع‌ها تمرکز می‌کنند، باید هیجان‌زده باشند.
«قضاوت» اهرم جدید قدرت است. توانایی تعریف محدودیت‌هایی که جلوی دسته‌های کاملی از شکست‌ها را می‌گیرد، اکنون باارزش‌تر از توانایی نوشتن کدی است که آن محدودیت‌ها را اجرا می‌کند. تمایز اصلی اکنون این است: آیا می‌توانید مشکل واقعی را شناسایی کنید و سیستمی طراحی کنید که سال‌ها بعد هم قابل فهم باقی بماند؟
در نهایت، هوش مصنوعی مهندسی را حذف نمی‌کند، بلکه «کارهای ساختمانی» آن را حذف می‌کند. این وضعیت ما را مجبور می‌کند بپذیریم مهندسی یعنی تبدیل ابهام به یک سیستم، نه فقط تایپ کردن کاراکترها در یک محیط کدنویسی.
برای بقا در این گذار، ارزش خود را با تعداد خطوط کد یا تیکت‌های بسته شده نسنجید. آن را با تعداد تضادهایی بسنجید که پیش از شروع پیاده‌سازی، حل کرده‌اید.
گام بعدی شما
- تمرکز خود را از یادگیری سینتکس‌های جدید به سمت یادگیری «مدل‌سازی دامنه» (Domain Modeling) ببرید.
- در جلسات طراحی، به‌جای تمرکز بر «چطور پیاده کنیم»، روی «کدام نیازها با هم متناقض‌اند» تمرکز کنید.
- یاد بگیرید چگونه ابهام‌های بیزینسی را به مدل‌های منطقی تبدیل کنید که برای AI قابل فهم باشد.
با ظهور «معماران هوش مصنوعی» که تخصصشان مدل‌سازی است و نه کدنویسی، صنعت از رویکرد خروجی‌محور به سمت نقش‌های قضاوت‌محور حرکت می‌کند؛ اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو