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

بر اساس بخش هوش مصنوعی نظرسنجی توسعه‌دهندگان Stack Overflow در سال 2025، 46 درصد پاسخ‌دهندگان به دقت ابزارهای هوش مصنوعی بی‌اعتماد بودند و 33 درصد به آن اعتماد داشتند. در همان گزارش، 87 درصد درباره دقت و 81 درصد درباره امنیت و حریم خصوصی عامل‌ها ابراز نگرانی کردند. این اعداد نشان می‌دهد سرعت تولید خروجی هنوز معادل اطمینان از نتیجه نیست.

کار مکانیکی کمتر، مسئولیت فنی بیشتر

وظایفی با مرز روشن—مانند افزودن تست برای رفتار موجود، به‌روزرسانی یک API در چند فایل، ساخت اسکریپت کوچک یا خلاصه کردن log—نامزد خوبی برای همکاری با عامل‌اند. در مقابل، تصمیم معماری، امنیت، مدل داده و اثر تغییر بر محصول همچنان به شناخت زمینه و مسئولیت‌پذیری انسان وابسته است.

حتی وقتی عامل کد درست تولید می‌کند، کسی باید نیاز را دقیق تعریف کند، diff را بخواند، تست مناسب را تشخیص دهد و پیامدهای جانبی را بسنجد. بنابراین ارزش بازار از «سرعت تایپ کد» به سمت «توان تعریف مسئله و اثبات درستی راه‌حل» حرکت می‌کند.

پنج مهارتی که مهم‌تر می‌شوند

1. تعریف مسئله: تبدیل درخواست مبهم به هدف، محدودیت و معیار پذیرش.
2. خواندن و بازبینی کد: تشخیص تغییر اضافه، رفتار پنهان و بدهی نگهداری.
3. طراحی تست: ساخت شواهدی که درستی رفتار را مستقل از ادعای مدل نشان دهد.
4. امنیت و حریم خصوصی: تعیین داده مجاز، سطح دسترسی و دستورهای نیازمند تأیید.
5. شناخت محصول: سنجش اینکه تغییر فنی واقعاً مسئله کاربر را حل می‌کند یا نه.

این مهارت‌ها پیش از هوش مصنوعی نیز مهم بودند، اما با ارزان شدن تولید کد، کمبود آن‌ها آشکارتر می‌شود.

نیروی تازه‌کار چه می‌شود؟

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

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

سازمان‌ها چگونه بهره‌وری را بسنجند؟

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

GapCode یک نمونه داخلی از ابزارهای عامل‌محور خط فرمان است؛ اما هر سازمان، مستقل از نام ابزار، باید همان کنترل نسخه، تست، بازبینی انسانی و اصل حداقل دسترسی را حفظ کند.

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

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

"این مطلب تبلیغاتی است"