چند سالی است که با هر جهش بزرگ در مدل‌های زبانی، یک سؤال قدیمی دوباره با صدای بلندتری پرسیده می‌شود:

«آیا برنامه‌نویسی در حال مرگ است؟»

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

مسئله این نیست که آیا برنامه‌نویسی می‌میرد یا نه؛مسئله این است که برنامه‌نویسی دقیقاً چه چیزی بوده و حالا در حال تبدیل شدن به چه چیزی است.

برنامه‌نویسی هیچ‌وقت فقط «نوشتن کد» نبود

در تاریخ مهندسی نرم‌افزار، کدنویسی همیشه سطحی‌ترین لایه از کار بوده است.

حتی پیش از ظهور هوش مصنوعی:

• بهترین مهندسان، سریع‌ترین تایپیست‌ها نبودند
• ارزش واقعی در درک مسئله، طراحی راه‌حل، و تصمیم‌گیری‌های معماری بود
• کد، صرفاً زبان بیان این تصمیم‌ها بود

مدل‌های زبانی بزرگ (LLMs) دقیقاً به همین لایه‌ی سطحی حمله کرده‌اند:

تبدیل ایده‌ی شفاف → کد قابل اجرا.

و این اتفاق، اگر صادق باشیم، نه فاجعه است و نه معجزه؛ بلکه افشای یک واقعیت قدیمی است:

بخش بزرگی از کدنویسی، کار مکانیکی بوده است.

LLMها چه چیزی را واقعاً خودکار کرده‌اند؟

مدل‌های زبانی در سه حوزه عملکرد درخشانی دارند:

1. تولید کد بر اساس الگوها

CRUD، APIها، glue code، تست‌های تکراری، migrationها

1. تبدیل زبان طبیعی به ساختار فنی

توصیف → تابع، توضیح → کلاس، نیازمندی → اسکلت سیستم

1. افزایش سرعت iteration

ایده → prototype → بازنویسی → refactor در زمان بسیار کوتاه

اما دقیقاً در کجاها هنوز ضعیف‌اند؟

• فهم عمیق context سازمانی
• trade-offهای معماری بلندمدت
• مسئولیت‌پذیری در تصمیم‌های پرریسک
• تشخیص «کدی که نباید نوشته شود»

به بیان ساده:

LLMها کدنویس‌های خوبی هستند، اما مهندس نیستند.

تغییر نقش: از «نویسنده کد» به «طراح سیستم»

در عصر مدل‌های زبانی بزرگ، نقش برنامه‌نویس در حال تغییر بنیادین است:

۱. برنامه‌نویس = معمار تصمیم

سؤال‌های کلیدی دیگر این نیستند:

• این تابع چطور نوشته شود؟

بلکه:

• آیا اصلاً باید نوشته شود؟
• این abstraction هزینه‌اش در آینده چیست؟
• failure modeهای این سیستم کجاست؟

۲. برنامه‌نویس = مربی هوش مصنوعی

توانایی کار با LLMها به یک مهارت اصلی تبدیل شده است:

• prompt engineering
• محدود کردن دامنه تصمیم‌گیری مدل
• بازبینی خروجی‌ها با نگاه انتقادی

در واقع، برنامه‌نویس خوب کسی است که بداند چه چیزی را به ماشین بسپارد و چه چیزی را نه.

۳. برنامه‌نویس = مسئول کیفیت

وقتی تولید کد ارزان می‌شود،کیفیت، خوانایی، امنیت و پایداری گران می‌شوند.

در آینده:

• کد بیشتر نوشته می‌شود
• اما کد خوب، نایاب‌تر خواهد بود

آیا این به معنی حذف شغل‌هاست؟

پاسخ کوتاه: برخی نقش‌ها بله، کل حرفه نه.

نقش‌هایی که بیشترین ریسک را دارند:

• juniorهایی که فقط syntax بلدند
• نقش‌هایی که ارزششان در سرعت تایپ بود
• تیم‌هایی بدون ownership واقعی

اما نقش‌هایی که تقویت می‌شوند:

• مهندسان سیستم
• متخصصان domain
• افرادی که business و تکنولوژی را هم‌زمان می‌فهمند
• کسانی که می‌توانند با AI کار تیمی داشته باشند

همان‌طور که اکسل حسابداران را حذف نکرد،

و اتوکمپایلر برنامه‌نویسان را بیکار نکرد،

LLMها هم مهندسی نرم‌افزار را نابود نمی‌کنند —

بلکه آن را حرفه‌ای‌تر می‌کنند.

خطر واقعی کجاست؟

خطر اصلی نه در خود LLMها،بلکه در توهم درک است.وقتی کدی «کار می‌کند»،خیلی‌ها تصور می‌کنند آن را فهمیده‌اند.

اما در سیستم‌های بزرگ:

• کدی که امروز کار می‌کند، می‌تواند فردا فاجعه باشد
• debt به‌صورت نامرئی جمع می‌شود
• و AI debt از technical debt خطرناک‌تر است

اگر سازمان‌ها تفکر مهندسی را فدای سرعت تولید کنند،

مدل‌های زبانی به‌جای leverage، به liability تبدیل می‌شوند.

برنامه‌نویسی به کجا می‌رود؟

چند پیش‌بینی محتاطانه:

• کدنویسی سطح پایین commoditize می‌شود
• design، architecture و reasoning ارزشمندتر می‌شوند
• فاصله‌ی بین مهندس ضعیف و قوی بیشتر می‌شود
• مهارت «فکر کردن» از مهارت «نوشتن» مهم‌تر می‌شود

و شاید مهم‌تر از همه:

برنامه‌نویسی بیش از همیشه انسانی می‌شود.چون تصمیم، قضاوت، مسئولیت و اخلاق چیزهایی نیستند که بتوان به‌راحتی آن‌ها را outsource کرد.

جمع‌بندی

اگر بخواهیم صادق باشیم: برنامه‌نویسی نمرده است؛

تصویر ساده‌انگارانه ما از برنامه‌نویسی مرده است.

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