سه خطای رایج در پیش‌بینی جایگزینی برنامه‌نویسان توسط هوش مصنوعی

تصور کنید یک نرم‌افزار کامل برای بازار عرضه کنید بدون اینکه حتی یک خط کد را شخصاً تایپ کرده باشید. این premise یک آزمایش ۳۰ روزه بود تا مشخص شود آیا عصر برنامه‌نویسی به پایان رسیده است یا خیر؛ آزمایشی که در آن یک توسعه‌دهنده اجازه داد هوش مصنوعی ۱۰۰٪ کد یک اپلیکیشن SaaS تولیدی را بنویسد. نتیجه این تجربه نشان داد که اگرچه هوش مصنوعی می‌تواند حجم عظیمی از تولید کد را مدیریت کند، اما هرگز نمی‌تواند جایگزین قضاوت‌های حیاتی شود؛ همان قضاوت‌هایی که پایداری یک سیستم را زیر فشار دنیای واقعی تضمین می‌کنند.

این آزمایش در حالی رخ می‌دهد که صنعت به دو جبهه افراطی تقسیم شده است. یک سو «ناامیدانی» (doomers) هستند که با هیجان باور دارند برنامه‌نویسان تا کریسمس کاملاً منسوخ و بیکار می‌شوند. در سوی دیگر «شکاکانی» مغرور قرار دارند که AI را صرفاً یک «طوطی احتمالی» (stochastic parrot) می‌بینند که حتی نمی‌تواند تعداد حروف r در کلمه strawberry را به‌درستی بشمارد. برای اکثر متخصصان، بحث بر سر این است که آیا یک مدل می‌تواند از یک بنچمارک (محک) کدنویسی عبور کند یا یک تابع کاربردی را در یک مرحله (single shot) بنویسد.

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

اشتباه اول: اشتباه گرفتن تایپ با مهندسی

بسیاری از استدلال‌ها بر این محور می‌چرخند که آیا AI می‌تواند کد بنویسد یا خیر، اما نویسنده دریافت که نوشتن کد تنها ۲۰٪ از کل شغل است. هوش مصنوعی عملیات‌های CRUD، طرح‌های Zod و ساختارهای کلی (scaffolding) را بسیار سریع‌تر از هر انسانی و به‌طور بی‌نقصی مدیریت کرد. این اتکای شدید به ابزارها در حالی است که بسیاری از برنامه‌نویسان اکنون خود را به‌طور کامل به ابزارهای کدنویسی هوش مصنوعی وابسته می‌بینند و مرز بین مهارت انسانی و خروجی ماشین کمرنگ‌تر شده است.

اما ۸۰٪ باقی‌مانده از کار شامل موارد زیر است:

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

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

اشتباه دوم: تخریب نردبان مهارت‌های جونیور

یک فرض خطرناک وجود دارد که مسیر تبدیل شدن از یک برنامه‌نویس جونیور به سنیور ثابت می‌ماند و AI فقط این فرآیند را شتاب می‌بخشد. خوش‌بین‌ها استدلال می‌کنند که جونیورها به کمک AI به بهره‌وری سنیورها می‌رسند، در حالی که بدبین‌ها معتقدند شغل‌های جونیور در یک «حمام خون» (bloodbath) ناپدید خواهند شد.

هر دو دیدگاه نادیده می‌گیرند که این نردبان از خودِ کار ساخته شده است. نویسنده اشاره می‌کند که تبدیل شدن به یک سنیور نیازمند ۱۰ هزار ساعت تجربه در دقیقاً همان کارهایی است که اکنون AI در حال جذب و حذف آن‌هاست:

• نوشتن کدهای تکراری (boilerplate) و ساختارهای اولیه.
• دست‌وپنجه نرم کردن با پیش‌نویس‌های «با اعتماد به نفس اما غلط».
• یادگیری بی‌اعتمادی به AI از طریق سوختن با اشتباهات آن.

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

اشتباه سوم: شکاف بین «دمو» و «ساعت ۲ صبح»

پیش‌بینی‌ها معمولاً بر اساس دموهای «مسیر خوشحال» (happy path) هستند؛ مثل ساخت یک اپلیکیشن Todo در ۹۰ ثانیه یا تماشای شکست یک مدل در حل یک چیستان. اما محیط عملیاتی (Production) یک اسکرین‌شات نیست. محیط عملیاتی یعنی «ساعت ۲ صبح»؛ یعنی زمانی که یک کاربر واقعی کاری عجیب می‌کند، یک لرزش (blip) در دیتابیس رخ می‌دهد، دکمه‌ای دو بار کلیک می‌شود، یا یک حالت خالی (empty state) رخ می‌دهد که هیچ‌کس برایش طراحی نکرده است.

در این آزمایش ۳۰ روزه، خطرناک‌ترین کدهای تولیدشده توسط AI، کدهایی بودند که در واقعیت اجرا می‌شدند. نویسنده مثالی از Stripe Webhook می‌زند:

• مکانیسم: AI وب‌هوکی نوشت که رویدادها را قبل از ذخیره در دیتابیس تایید (acknowledge) می‌کرد.
• شکست: در محیط واقعی، یک لرزش کوچک دیتابیس باعث می‌شد مشتریی که پول پرداخت کرده، نه دسترسی داشته باشد و نه رکوردی از پرداختش در سیستم بماند.
• نقطه کور: کد تمام تست‌ها را پاس کرد چون مدل، تست‌هایی نوشت که با مدل ذهنی غلط خودش هم‌سو بودند.

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

راهکار ساختاری

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

برای تضمین ایمنی در محیط تولید، نویسنده یک سیستم سه‌لایه پیشنهاد می‌دهد:

• کارگر (Worker): عاملی (Agent) که کار اولیه را انجام داده و کد را تولید می‌کند.
• بازبین (Reviewer): عاملی مجزا که تمام شغلش رد کردن تغییرات (diff) و تلاش برای تخریب کد است، نه تایید و مبارک‌باد آن.
• مالک (Owner): انسانی که روی دکمه Merge است و می‌تواند «شعاع تخریب» (blast radius) را ببیند، چیزی که مدل قادر به درک آن نیست.

این رویکرد ساختاری همان چیزی است که برای xenition پیاده شد. این نتیجه از یک تز علمی یا تئوری نیامد، بلکه حاصل ثبت ۹ مورد خرابی واقعی در یک بیلد بود که در آن مدل، اشتباهات خودش را با اطمینان تایید کرده بود.

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

گام بعدی شما

• تمرکز خود را از یادگیری نحوه نوشتن توابع ساده به یادگیری «نقد کد» و شناسایی لبه‌های شکست (Edge Cases) منتقل کنید.
• در گردش کارهای خود، یک لایه بازبینی (Review) مستقل ایجاد کنید و هرگز اجازه ندهید AI کد خودش را تایید کند.
• روی مهارت‌های معماری سیستم تمرکز کنید تا بتوانید «شعاع تخریب» تغییرات را پیش‌بینی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.