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

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

به نقل از یادداشتی که در ۱۶ سپتامبر ۲۰۲۶ در وبلاگ blog.ploeh.dk منتشر شد، یک توسعه‌دهنده پس از ساخت یک سیستم پیچیده با زبان TypeScript به این نتیجه رسید که «محصولی خلق کرده‌ام که از سطح درک من فراتر رفته است». این اعتراف، نشان‌دهنده شکافی عمیق میان توانایی «تولید کد» و توانایی «مالکیت فنی» آن است.

این تنش در حالی رخ می‌دهد که صنعت به سمت توسعه‌ی کمک‌گرفته از AI می‌رود. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی کسب‌وکارهای AI اشاره کردیم، ابزارهایی مثل Oxlo.ai روی جنبه‌های تجاری و بنچمارک‌های چندزبانه تمرکز دارند، اما در لایه‌ی انسانی، ما با بحران شایستگی روبرو هستیم. برای بسیاری، هوش مصنوعی زاینده (Generative AI) — مثل یک پل جادویی که فاصله میان یک ایده و نمونه‌ی اولیه را می‌گیرد — وسوسه‌انگیز است، اما این پل ممکن است در بدترین زمان ممکن فرو بریزد.

توهم شایستگی

یک توسعه‌دهنده گزارش داده که بدون داشتن پیش‌زمینه رسمی در علوم کامپیوتر، سیستمی قابل توجه شامل PostgreSQL، خط لوله‌های LLM، اتوماسیون پژوهشی و جریان‌های کاری چندمدلی ساخته است. در ابتدا، این فرآیند کاملاً یکپارچه و بدون نقص به نظر می‌رسید. اما در مسیر تبدیل پروژه به یک محصول آماده برای محیط عملیاتی (Production-ready)، «شکاف درک» به شکلی بحرانی ظاهر شد:

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

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

ریسک اقتصادی فرسایش دانش

نویسنده که در اصل اقتصاددان است، استدلال می‌کند که این موضوع تنها یک چالش فنی نیست، بلکه یک ریسک سیستمی است. او معتقد است برنامه‌نویسی ممکن است یکی از نخستین مشاغل یقه سفید باشد که با بیکاری گسترده روبرو شود؛ زیرا تأیید صحت نرم‌افزار (Software Verification) بسیار ساده‌تر از مدیریت سیستم‌های پیچیده انسانی، مانند مدیریت ادعاهای بیمه است.

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

بستر اجتماعی-اقتصادی

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

ترسی مشروع وجود دارد که نرخ بیکاری ۳۰ تا ۴۰ درصدی در میان کارکنان دانشی (Knowledge Workers) بتواند اقتصاد مدرن را بی‌ثبات کند. نویسنده ابراز امیدواری می‌کند که اشتباه کرده باشد، به‌ویژه به خاطر فرزندان جوانش که در ابتدای مسیر زندگی هستند.

دفاعیه «انتزاع»

برخی استدلال می‌کنند که برنامه‌نویسان همیشه روی لایه‌هایی از انتزاع (Abstraction) کار کرده‌اند که درک کاملی از آن‌ها نداشتند. برای مثال، یک توسعه‌دهنده وب به ندرت طراحی کامپایلر را می‌شناسد و یک برنامه‌نویس کامپایلر به ندرت طراحی مدارهای مجتمع (IC) را درک می‌کند.

اما در گذشته، یک قانون سرانگشتی وجود داشت: شما باید لایه دقیقاً زیرین و لایه دقیقاً بالای کار فعلی خود را بشناسید. این درک اجازه می‌داد که عیب‌یابی (Troubleshooting) به صورت مؤثر انجام شود. خطر امروز این است که مدل زبانی بزرگ (LLM) به کاربر اجازه می‌دهد نه تنها یک لایه، بلکه کل پشته‌ی بنیادی شامل ساختارهای داده، معناشناسی زبان (Language Semantics) و سیستم‌عامل را به طور کامل نادیده بگیرد و از آن‌ها بپرد. این تغییر در نحوه ساخت نرم‌افزار، ما را به سمتی می‌برد که پلتفرم‌های گسترش‌پذیر جایگزین محصولات ایستا شوند و مفهوم «نرم‌افزار برای یک نفر» را ممکن سازند.

یادگیری در عصر «مزخرفات»

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

او پیشنهاد می‌کند برای یادگیری از AI به این شکل خاص استفاده کنید:

• از توصیه‌های کلی دوری کنید: هرگز از LLM نپرسید «بعد از این چه یاد بگیرم؟» چون این سوال پاسخی قابل تأیید (Verifiable) تولید نمی‌کند.
• سوالات ابطال‌پذیر بپرسید: مثلاً از مدل بخواهید نسخه کوتاه‌تر و موجزتری از یک عبارت خاص در زبان Haskell ارائه دهد.
• بلافاصله تأیید کنید: تنها خروجی‌هایی را باور کنید که با اجرای کد، درست یا غلط بودنشان ثابت شود. اگر پیشنهادی کوتاه‌تر است و کار می‌کند، آنگاه مفید است.

او خروجی‌های مدل را نه «توهم» (Hallucination)، بلکه «مزخرف» (Bullshit) می‌نامد؛ به این معنا که مدل‌ها ادعاهایی را مطرح می‌کنند بدون اینکه به حقیقت یا عدم حقیقت آن‌ها اهمیتی بدهند، لذا هر ادعای غیرقابل تأییدی از سوی مدل باید با بی‌اعتمادی عمیق پذیرفته شود.

مسیر رسیدن به مالکیت واقعی

نویسنده با بازگشت به سال ۱۹۹۹، تجربه خود را در نوشتن کامپوننت‌های C++ COM تعریف می‌کند. او در آن زمان بدون درک کامل از این ابزارها کد می‌زد و روی «لبه تیغ» حرکت می‌کرد؛ یعنی هم‌زمان با پیش بردن کار، در حین اشتغال یاد می‌گرفت. اما او در نهایت متوجه شد که باید عقب‌نشینی کند و مفاهیم بنیادی را به صورت سیستماتیک بیاموزد تا از «سرهم‌بندی» (Slapping things together) کدها فاصله بگیرد.

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

تکامل یادگیری فنی

مسیر یادگیری نویسنده کند و مبتنی بر آزمون و خطا بود. اولین پروژه‌های بزرگ او شامل محاسبه دیاگرام‌های دوشاخگی (Bifurcation Diagrams) و جذب‌کننده لورنتس (Lorenz Attractor) برای پایان‌نامه ارشد اقتصاد با استفاده از QBasic بود. او از نمونه‌های ارسالی و دوستانش یاد می‌گرفت.

در طول دهه‌های ۹۰ و ۲۰۰۰، روش‌های او تکامل یافت:

• مستندات و مثال‌ها: برای یادگیری گویش‌های مختلف Basic و زبان C#.
• کتاب‌ها: اگرچه او کتاب C++ خود را تمام نکرد، اما کتاب‌ها برای یادگیری F# و Haskell ابزاری حیاتی بودند.
• بررسی کد: امروزه او زبان‌های «معمولی» جدید را با خواندن کدهای موجود و جستجوی نقاط مبهم یاد می‌گیرد.

برای زبان‌های غیرمعمولی مثل APL، او همچنان به آموزش‌ها (Tutorials) متکی است. او اشاره می‌کند که LLMها می‌توانند یادگیری را هدفمندتر کنند، زیرا نیاز به خواندن فصل‌های بی‌ربط کتاب‌ها را از بین می‌برند، اما گلوگاه اصلی، محتوا نیست، بلکه سرعت جذب دانش توسط مغز انسان است.

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

تعمیق شکاف فنی

برای نشان دادن تفاوت درک بنیادی و ساخت با AI، نویسنده محیط RISC-V assembly را مثال می‌زند؛ محیطی که از نظر او بیگانه‌ترین محیط نرم‌افزاری ممکن است. حتی برای یک توسعه‌دهنده با تجربه، سازگاری با چنین محیطی دشوار است. با این حال، نویسنده اشاره می‌کند که خودش برنامه‌های تمرینی کوچک و یک کامپایلر تمرینی که به RISC-V تبدیل می‌شد را نوشته است.

نکته اینجاست: توسعه‌دهنده‌ای با پایه قوی می‌تواند با بهره‌گیری از دانش قبلی خود، در یک محیط جدید سریعاً رشد کند. اما یک مبتدی که تنها به AI وابسته است، هیچ اهرمی (Leverage) برای این یادگیری سریع ندارد.

روان‌شناسی بیزاری از AI

نویسنده رابطه‌ای پیچیده و احساسی با LLMها دارد. او اعتراف می‌کند که تمایل دارد از این تکنولوژی متنفر باشد، حتی در حالی که با آن تجربه می‌کند.

• پارادوکس ناامیدی: وقتی AI عملکرد ضعیفی دارد، نویسنده احساس گرمی و رضایت می‌کند، زیرا باور می‌کند ۳۰ سال یادگیری‌اش هنوز مرتبط و ارزشمند است.
• اوج بیزاری: وقتی AI در بهترین حالت خود است و نتایج خیره‌کننده‌ای می‌دهد، نویسنده بیشترین حس بیزاری را تجربه می‌کند و به شوخی می‌پرسد که برای پیوستن به «جهاد باتلریان» (Butlerian Jihad) کجا باید ثبت‌نام کرد.

خلاصه مکانیسم‌های یادگیری

مقایسه یادگیری در دهه ۹۰ با دهه ۲۰۲۰ نشان می‌دهد که ماهیت تلاش تغییر کرده است. ۳۰ سال پیش، چالش اصلی «یافتن منابع درست» بود؛ توسعه‌دهندگان کتاب‌هایی می‌خریدند به امید اینکه مفید باشند و فصل‌های بی‌ربط را تحمل می‌کردند.

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

گام بعدی شما

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

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