توهمِ ساختن با هوش مصنوعی: چرا هنوز هیچ‌کس به‌تنهایی با AI یک پروژه‌ی بزرگ نمی‌سازد — و چرا برنده‌ی نهایی، مهندسِ کاربلد است

مقاله‌ی تحلیلی · مهندسی نرم‌افزار و هوش مصنوعی

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

۱. مقدمه: وعده‌ی بزرگ و واقعیتِ کوچک

در دو سال گذشته، چیزی شبیه یک رؤیای جمعی در صنعت نرم‌افزار شکل گرفته است: این تصور که با چند جمله دستور به یک هوش مصنوعی، می‌توان یک استارتاپ، یک اپلیکیشن کامل یا یک سیستم بزرگ را از صفر ساخت. ویدیوهای کوتاهی که در آن‌ها کسی «در ۱۰ دقیقه یک اپ ساخت» منتشر می‌شوند، این باور را تقویت می‌کنند که دانشِ فنی دیگر مزیت نیست و هرکسی با ابزار درست می‌تواند برنده باشد.

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

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

۲. توهم از کجا می‌آید؟ شکافِ «دمو تا محصول»

برای فهمِ این توهم، باید بفهمیم چرا دموها این‌قدر فریبنده‌اند. یک دمو، یعنی نمایشِ یک قابلیت در یک مسیرِ خوش‌بینانه و کنترل‌شده. در دمو، داده تمیز است، کاربر دقیقاً همان کاری را می‌کند که انتظار می‌رود، شرایطِ مرزی وجود ندارد، و کسی به امنیت، مقیاس‌پذیری یا نگهداشتِ شش‌ماه‌بعد فکر نمی‌کند.

اما یک محصولِ واقعی برعکس است. بخش بزرگی از کارِ مهندسی نرم‌افزار اصلاً «نوشتنِ کدِ جدید» نیست؛ بلکه فهمیدنِ کدِ موجود، اتصال بخش‌های مختلف به هم، مدیریتِ حالت‌هایی است که هیچ‌کس انتظارشان را ندارد، و اطمینان از این‌که تغییرِ امروز، چیزی را که سال پیش ساخته شده خراب نکند. این همان شکافی است که اَدی اوسمانی، مهندس برجسته‌ی گوگل، آن را «مسئله‌ی ۷۰ درصد» می‌نامد: هوش مصنوعی شما را تا حدود ۷۰٪ راه می‌برد، اما آن ۳۰٪ آخر — یعنی همان چیزی که یک نرم‌افزار را واقعاً قابل‌استفاده می‌کند — سخت‌ترین بخش است و دقیقاً همان‌جایی است که به تخصص نیاز دارید.^[۶]

به بیان ساده: هوش مصنوعی در ساختنِ «نمایش» عالی است، اما در ساختنِ «زیرساخت» ضعیف. و تفاوتِ یک پروژه‌ی کوچک با یک پروژه‌ی بزرگ، دقیقاً در همان زیرساختی است که دیده نمی‌شود اما همه‌چیز را نگه می‌دارد.

یک مثالِ ملموس بزنیم. تصور کنید از هوش مصنوعی می‌خواهید «یک سیستمِ ورودِ کاربر» بسازد. در چند ثانیه یک فرمِ زیبا با نام‌کاربری و رمز عبور تحویل می‌گیرید و همه‌چیز کار می‌کند. اما یک سیستمِ ورودِ واقعی یعنی: بازیابیِ رمزِ فراموش‌شده، محدودکردنِ تلاش‌های ناموفق برای جلوگیری از حمله، ذخیره‌ی امنِ رمز با هش، مدیریتِ نشست‌ها و توکن‌ها، ورودِ دومرحله‌ای، حریمِ خصوصیِ داده، سازگاری با قوانین، و ده‌ها حالتِ مرزی مثل کاربری که هم‌زمان از دو دستگاه وارد می‌شود. آن فرمِ ده‌ثانیه‌ای شاید ۱۰٪ کار باشد؛ آن ۹۰٪ باقی، همان‌جایی است که تجربه و قضاوت لازم می‌شود. کسی که فقط فرم را می‌بیند، گمان می‌کند کار تمام شده — و این، قلبِ همان توهم است.

۳. محدودیت‌های بنیادیِ مدل‌های امروزی

چرا هوش مصنوعی نمی‌تواند خودش آن ۳۰٪ سخت را تمام کند؟ پاسخ، یک ضعفِ گذرا نیست؛ ریشه در شیوه‌ی کارِ این مدل‌ها دارد. پنج محدودیتِ کلیدی را مرور می‌کنیم.

۳-۱. حافظه‌ی محدود و «گم‌شدن در میانه»

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

پژوهشی کلاسیک با عنوان «گم‌شدن در میانه» نشان داد که وقتی اطلاعاتِ مهم در میانه‌ی یک متنِ طولانی قرار می‌گیرد، کارایی مدل به‌شکل چشمگیری افت می‌کند — در برخی آزمون‌ها بیش از ۳۰٪. مدل‌ها اطلاعاتِ ابتدا و انتهای متن را بهتر به‌خاطر می‌سپارند و چیزی را که وسط است، عملاً نادیده می‌گیرند.^[۳] این یعنی حتی اگر کلِ کدِ پروژه را هم به مدل بدهید، تضمینی نیست که ارتباطِ ظریفِ میان دو بخشِ دور از هم را درست بفهمد.

یک مهندسِ انسانی هم همه‌چیز را در ذهن نگه نمی‌دارد، اما او «مدلِ ذهنی» از سیستم می‌سازد: می‌داند کجا را نگاه کند، چه چیزی به چه چیزی وصل است، و چه فرضی ممکن است اشتباه باشد. مدل‌های امروزی این مدلِ ذهنیِ پایدار را ندارند؛ هر بار از نو شروع می‌کنند.

۳-۲. توهم‌زایی: کدی که با اطمینان نوشته می‌شود ولی غلط است

مدل‌های زبانی گاهی چیزهایی می‌سازند که اصلاً وجود ندارند — به این پدیده «توهم» (hallucination) می‌گویند. در برنامه‌نویسی، یکی از خطرناک‌ترین شکل‌های آن، ساختنِ نامِ بسته‌های نرم‌افزاریِ ناموجود است.

یک مطالعه‌ی گسترده با تولیدِ ۵۷۶٬۰۰۰ نمونه‌ی کد نشان داد که حدود ۱۹.۷٪ از بسته‌هایی که مدل‌ها پیشنهاد می‌دهند، اصلاً وجود ندارند. این رقم برای مدل‌های متن‌باز به ۲۱.۷٪ و برای مدل‌های تجاری به حدود ۵.۲٪ می‌رسد. پژوهشگران بیش از ۲۰۵٬۰۰۰ نامِ بسته‌ی ساختگیِ منحصربه‌فرد پیدا کردند.^[۴] این ضعف، یک تهدیدِ امنیتیِ تازه به‌نام «اسلاپ‌اسکواتینگ» (slopsquatting) به‌وجود آورده است: مهاجم یک بسته‌ی مخرب با همان نامِ توهمی منتشر می‌کند، و توسعه‌دهنده‌ای که چشم‌بسته به خروجیِ AI اعتماد می‌کند، آن را نصب می‌کند.

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

۳-۳. کیفیت و نگهداشت‌پذیری: بدهیِ فنیِ پنهان

فرض کنید کد کار هم بکند. آیا کدِ خوبی است؟ شرکتِ تحلیلِ کد، GitClear، با بررسیِ بیش از ۲۱۱ میلیون خط تغییرِ کد نشان داد که با گسترشِ ابزارهای هوش مصنوعی، کیفیتِ کد تحت فشار قرار گرفته است. در سال ۲۰۲۴، فراوانیِ «بلوک‌های کدِ تکراری» حدود هشت برابر شد، و برای نخستین‌بار در تاریخ، حجمِ کدِ «کپی‌-پیست‌شده» از کدِ «بازآرایی‌شده» (refactored) پیشی گرفت.^[۵]

چرا این مهم است؟ چون کپی‌-پیست، دشمنِ خاموشِ پروژه‌های بزرگ است. وقتی یک منطق در ده جای مختلف تکرار شود، هر تغییر کوچک، ریسکِ خطا در ده نقطه ایجاد می‌کند. هوش مصنوعی در «تولیدِ کدِ تازه» خوب است اما در «استفاده‌ی مجدد و بازآراییِ کدِ موجود» ضعیف — و دقیقاً همین، در درازمدت به انباشتِ «بدهیِ فنی» منجر می‌شود؛ یعنی هزینه‌ای که بعداً باید با بهرهٔ سنگین پس داده شود. مطالعاتِ تازه‌تر در سال ۲۰۲۶ هم نشان می‌دهند که هوش مصنوعی در سطحِ «خُرد» (نوشتنِ یک تابع) عالی است اما در سطحِ «کلان» (انسجامِ سیستم و نگهداشتِ بلندمدت) ضعیف باقی مانده است.^[۸]

۳-۴. امنیت: کدِ ناامن با اعتمادبه‌نفسِ بالا

یکی از نگران‌کننده‌ترین یافته‌ها از یک مطالعه‌ی دانشگاه استنفورد می‌آید. پژوهشگران (از جمله دَن بونه، رمزنگارِ سرشناس) دریافتند که شرکت‌کنندگانی که به دستیارِ هوش مصنوعی دسترسی داشتند، کدِ به‌طور معناداری ناامن‌تری نوشتند — به‌ویژه در زمینه‌ی رمزنگاری و تزریقِ SQL. اما بدتر از آن: همین افراد بیشتر باور داشتند که کدشان امن است.^[۲]

این یک ترکیبِ خطرناک است: کیفیتِ پایین‌تر، به‌علاوه‌ی اطمینانِ کاذبِ بالاتر. جالب این‌که پژوهش نشان داد افرادی که کمتر به AI اعتماد کردند و بیشتر به کیفیتِ دستورها و کد دقت کردند، کدِ امن‌تری تولید کردند. یعنی همان قضاوتِ انسانیِ نقادانه، عاملِ تعیین‌کننده بود.

۳-۵. ضعف در نگاهِ سیستمی و معماری

بزرگ‌ترین تصمیم‌ها در یک پروژه، تصمیم‌های معماری‌اند: داده کجا ذخیره شود؟ کدام بخش‌ها از هم جدا باشند؟ سیستم چطور با ده‌برابرشدنِ کاربر کنار بیاید؟ این تصمیم‌ها به «زمینه‌ی کسب‌وکار»، «مصالحه میان گزینه‌ها» و «پیش‌بینیِ آینده» نیاز دارند — چیزهایی که از دلِ داده‌های آموزشی به‌سادگی بیرون نمی‌آیند.

تحلیل‌گرانِ صنعت به یک الگوی تکرارشونده اشاره می‌کنند: ایجنت‌های هوش مصنوعی در آغازِ کار یک «نقشه» می‌سازند، اما همان‌طور که پنجره‌ی کانتکست پر می‌شود، آن نقشه کم‌رنگ می‌شود و گاهی به‌کل فراموش می‌شود. نتیجه، کدی است که در سطحِ تک‌تابع درست به‌نظر می‌رسد اما در سطحِ کلِ سیستم، انسجام ندارد.^[۸] این دقیقاً همان نقطه‌ای است که مهندسِ باتجربه نقشِ «معمار و ممیّز» را بازی می‌کند.

۳-۶. چرا پنجره‌های بزرگ‌تر، مشکل را حل نمی‌کنند

پاسخِ رایج به محدودیتِ حافظه این است: «پنجره‌ی کانتکست را بزرگ‌تر می‌کنیم.» اما شواهد نشان می‌دهند که بزرگ‌ترشدنِ کمیّتِ حافظه، لزوماً کیفیتِ فهم را بالا نمی‌برد. این پدیده را گاهی «پوسیدگیِ کانتکست» (context rot) می‌نامند: هرچه ورودیِ مدل طولانی‌تر شود، دقتِ آن در یافتنِ جزئیاتِ مهم افت می‌کند، حتی اگر آن جزئیات «در دسترس» باشند.

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

۴. شاهدِ علمی: آیا AI واقعاً ما را سریع‌تر می‌کند؟

شاید بگویید: «همه‌ی این‌ها درست، اما دستِ‌کم سرعت را بالا می‌برد.» اینجا یکی از مهم‌ترین شواهدِ علمی وارد می‌شود. مؤسسه‌ی METR در سال ۲۰۲۵ یک کارآزماییِ تصادفیِ کنترل‌شده انجام داد — همان روشی که در آزمایش‌های داروییِ بالینی به‌کار می‌رود و استانداردِ طلاییِ شواهد علمی است.

در این مطالعه، ۱۶ توسعه‌دهنده‌ی باتجربه روی پروژه‌های واقعیِ متن‌بازِ خودشان (که به‌طور میانگین ۵ سال روی آن‌ها کار کرده بودند) مجموعاً ۲۴۶ وظیفه را انجام دادند. هر وظیفه به‌صورت تصادفی یا «اجازه‌ی استفاده از AI» داشت یا نداشت. نتیجه شگفت‌انگیز بود:

یعنی توسعه‌دهندگان با ابزارِ هوش مصنوعی ۱۹٪ کندتر شدند، اما حتی پس از تجربه‌ی این کندی، همچنان فکر می‌کردند سریع‌تر شده‌اند.^[۱] این «شکافِ ادراک» شاید مهم‌ترین یافته‌ی مقاله باشد: احساسِ بهره‌وری با بهره‌وریِ واقعی یکی نیست.

چرا کندتر؟ پژوهشگران چند دلیل برشمردند: زمانِ صرف‌شده برای بازبینی و اصلاحِ خروجیِ AI، استانداردِ کیفیِ بالای این پروژه‌ها که با پیشنهادهای مدل جور درنمی‌آمد، و این واقعیت که در یک کدِ بزرگ و آشنا، توضیح‌دادنِ مسئله به مدل گاهی از خودِ انجامِ کار زمان‌برتر است. توجه کنید: این آزمایش روی افرادِ باتجربه و کدِ بزرگ و واقعی انجام شد — یعنی دقیقاً همان شرایطی که موضوعِ این مقاله است.

۵. «مسئله‌ی ۷۰ درصد»: چرا ۳۰ درصدِ آخر، کلِ بازی است

حال همه‌ی این محدودیت‌ها را کنار هم بگذارید. الگویی که پدیدار می‌شود همان «مسئله‌ی ۷۰ درصد» است. اَدی اوسمانی توضیح می‌دهد که هوش مصنوعی می‌تواند شما را به‌سرعت تا ۷۰٪ راه برساند: یک نمونه‌ی اولیه‌ی کارا، یک ساختارِ کلی، یک نسخه‌ی نمایشی. اما آن ۳۰٪ باقی‌مانده — رسیدگی به حالت‌های مرزی، رفعِ خطاهای عمیق، یکپارچه‌سازی با سیستم‌های واقعی، و تأمینِ امنیت — به‌اندازه‌ی همیشه دشوار باقی مانده است.^[۶]

اوسمانی یک اصطلاحِ گویا دارد: «کدِ خانه‌ی پوشالی» (house of cards code) — کدی که کامل به‌نظر می‌رسد اما زیرِ فشارِ دنیای واقعی فرومی‌ریزد. کسی که تخصص ندارد، آن ۷۰٪ را می‌بیند و گمان می‌کند کار تمام است؛ اما کسی که کاربلد است، می‌داند که ۳۰٪ آخر همان‌جایی است که نرم‌افزارِ واقعی از پروژه‌ی نمایشی جدا می‌شود.

یک «پارادوکسِ دانش» اینجا وجود دارد: مهندسِ ارشد از AI استفاده می‌کند تا کاری را که بلد است سریع‌تر انجام دهد؛ تازه‌کار تلاش می‌کند با AI کاری را که بلد نیست یاد بگیرد یا جا بیندازد. اولی شتاب می‌گیرد، دومی روی شن بنا می‌کند.^[۶]

۶. این فیلم را پیش‌تر دیده‌ایم؟ درسِ موج‌های گذشته

هیجانِ امروز بی‌سابقه نیست. صنعتِ نرم‌افزار پیش‌تر هم موج‌هایی را تجربه کرده که قرار بود «نیاز به برنامه‌نویس را از بین ببرند». در دهه‌های گذشته، ابزارهای «بدونِ کد» (no-code) و «کم‌کد» (low-code) با همین وعده آمدند: «هرکسی بدونِ دانشِ فنی می‌تواند نرم‌افزار بسازد.» موجِ برون‌سپاری (outsourcing) هم با وعده‌ی «کدِ ارزان و سریع» آمد. هیچ‌کدام برنامه‌نویس را حذف نکردند.

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

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

۷. چرا مهندسِ متخصص برنده است

اگر دقت کنید، در همه‌ی شواهدِ بالا یک نخِ مشترک هست: هوش مصنوعی برای کسی که می‌داند چه می‌خواهد و می‌تواند خروجی را قضاوت کند، شتاب‌دهنده است؛ و برای کسی که نمی‌داند، تشدیدکننده‌ی خطاست. همان مطالعاتی که نشان می‌دهند AI می‌تواند کیفیت را پایین بیاورد، نشان می‌دهند که توسعه‌دهندگانی که نقادانه‌تر برخورد کردند، نتیجه‌ی بهتری گرفتند.

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

این تصویر با داده‌های میدانی هم می‌خواند: تحلیل‌گران می‌گویند مهندسانِ ارشد دیگر صرفاً «کدنویس» نیستند، بلکه «معمار و ممیّز»‌اند، و موفقیتِ پایدار از ترکیبِ شتابِ فنی با رهبریِ معماریِ باتجربه به‌دست می‌آید.^[۸] به همین دلیل است که می‌گوییم در این بازی، فردِ فنی که کد را می‌فهمد جایگزین نمی‌شود — بلکه ابزارِ تازه‌ای در دست می‌گیرد که قدرتش را چند برابر می‌کند، درست همان‌طور که ماشین‌حساب، ریاضی‌دان را حذف نکرد بلکه او را تواناتر کرد.

برای آن‌که این تصویر مجرد نماند، یک سناریوی آشنا را در نظر بگیرید. مهندسی از هوش مصنوعی می‌خواهد یک «گزارشِ مالی» به سیستم اضافه کند. مدل به‌سرعت کدی تولید می‌کند که ظاهراً کار می‌کند. اما مهندسِ باتجربه می‌پرسد: اگر داده‌ها ناقص باشند چه؟ اگر دو کاربر هم‌زمان گزارش را تغییر دهند چه؟ این محاسبه روی یک میلیون رکورد هم سریع است یا سیستم را از کار می‌اندازد؟ این عدد با گزارشِ ماهِ گذشته همخوان است یا تناقض دارد؟ هیچ‌کدامِ این سؤال‌ها در «صورت‌مسئله» نوشته نشده بود؛ اما همگی برای یک محصولِ واقعی حیاتی‌اند. مدل به آن‌چه پرسیده شده پاسخ می‌دهد؛ مهندس به آن‌چه باید پرسیده می‌شد فکر می‌کند. این شکاف، همان مرزِ تخصص است.

۸. انصافِ علمی: طرف مقابل چه می‌گوید؟

یک مقاله‌ی علمی باید قوی‌ترین استدلال‌های مخالف را هم بیاورد. در دفاع از دیدگاهِ «هوش مصنوعی همه‌چیز را تغییر می‌دهد»، چند نکته‌ی جدی وجود دارد:

الف) پیشرفت سریع است. عملکردِ مدل‌ها روی بنچ‌مارک‌هایی مثل SWE-bench Verified — مجموعه‌ای از مسائلِ واقعیِ گیت‌هاب — در سال‌های اخیر جهش کرده و بهترین سیستم‌ها در ۲۰۲۶ به نمراتِ بالای ۷۰ تا ۸۰ درصد رسیده‌اند.^[۷] ممکن است محدودیت‌های امروز، مشکلاتِ فردا نباشند.

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

ب) سدِ ورود پایین آمده است. این هم درست و مهم است. امروز یک طراح، یک پژوهشگر یا یک کارآفرینِ غیربرنامه‌نویس می‌تواند ایده‌اش را تا حدِ یک نمونه‌ی کارا پیش ببرد — کاری که پیش‌تر ناممکن بود. این یک دموکراتیزه‌شدنِ واقعیِ ساختن است و نباید دستِ‌کم گرفته شود.

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

ج) بهره‌وری در برخی زمینه‌ها واقعی است. برای کارهای تکراری، کدِ قالبی (boilerplate)، یادگیریِ یک کتابخانه‌ی تازه، یا نوشتنِ آزمون‌های ساده، بسیاری از مهندسان شتابِ واقعی گزارش می‌دهند.

پاسخ: کاملاً موافقیم — و این با تزِ ما در تضاد نیست، بلکه آن را تأیید می‌کند. AI ابزارِ فوق‌العاده‌ای است در دستِ کسی که می‌داند کجا و چطور از آن استفاده کند. سود از آنِ مهندس است، نه جایگزینِ او.

۹. جمع‌بندی و توصیه‌های عملی

بیایید نتیجه را بدون اغراق در هیچ جهتی جمع کنیم. این مقاله نمی‌گوید هوش مصنوعی ضعیف است؛ می‌گوید هوش مصنوعی قدرتمند اما ناقص است، و این نقص دقیقاً در همان لایه‌هایی است که یک پروژه‌ی کوچک را از یک پروژه‌ی بزرگ جدا می‌کند: حافظه و انسجامِ سیستمی، صحت و امنیت، کیفیت و نگهداشت. شواهدِ تجربی — از کارآزماییِ کنترل‌شده‌ی METR تا تحلیلِ صدها میلیون خط کد — همه به یک سمت اشاره می‌کنند: ارزشِ تخصصِ انسانی کم نشده، بلکه جابه‌جا و در مواردی بیشتر شده است.

برای کسی که می‌خواهد در این دوران برنده باشد، توصیه‌ها روشن‌اند:

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

---

منابع

1. METR (۲۰۲۵). «سنجشِ اثرِ هوش مصنوعیِ اوایلِ ۲۰۲۵ بر بهره‌وریِ توسعه‌دهندگانِ باتجربه‌ی متن‌باز» — کارآزماییِ تصادفیِ کنترل‌شده. metr.org · arXiv:2507.09089
2. Perry, Srivastava, Kumar, Boneh — دانشگاه استنفورد. «آیا کاربران با دستیارهای هوش مصنوعی کدِ ناامن‌تری می‌نویسند؟» arXiv:2211.03622
3. Liu et al. «گم‌شدن در میانه: مدل‌های زبانی چگونه از کانتکستِ طولانی استفاده می‌کنند.» arXiv:2307.03172
4. Spracklen et al. «ما یک بسته برایتان داریم! تحلیلِ جامعِ توهمِ بسته در مدل‌های تولیدِ کد.» arXiv:2406.10279 · USENIX
5. GitClear (۲۰۲۵). «کیفیتِ کدِ دستیارِ هوش مصنوعی: داده‌های ۲۰۲۵ و رشدِ چهاربرابریِ کلون‌های کد.» gitclear.com
6. Addy Osmani. «مسئله‌ی ۷۰ درصد: حقایقِ تلخ درباره‌ی کدنویسی با کمکِ هوش مصنوعی.» addyo.substack.com
7. SWE-bench Verified — لیدربوردِ ارزیابی روی مسائلِ واقعیِ گیت‌هاب. Epoch AI · swebench.com
8. تحلیل‌های صنعتیِ ۲۰۲۶ درباره‌ی بدهیِ فنیِ کدِ تولیدشده با هوش مصنوعی و نقشِ معماریِ مهندسانِ ارشد. The Pragmatic Engineer · arXiv:2603.28592

یادداشت: ارقام و یافته‌های این مقاله از مطالعاتِ منتشرشده تا میانه‌ی ۲۰۲۶ برگرفته شده‌اند. حوزه‌ی هوش مصنوعی به‌سرعت تغییر می‌کند؛ پیش از استنادِ رسمی به نسخه‌ی اصلیِ منابع مراجعه کنید.