تیترهای خبری مدام به ما میگویند که هوش مصنوعی توسعهدهندگان نرمافزار را منسوخ خواهد کرد. من این را باور نمیکنم. خطر واقعی این نیست که ماشینها مهندسی را از آن خود کنند. خطر این است که مهندسان از انجام کار سختِ «فکر کردن» دست بکشند.
نرمافزار هرگز درباره تایپ کردن سینتکس (syntax) نبوده است. همیشه درباره درک پیچیدگیها در ذهن، فهم حالتهای شکست (failure modes) و انجام سبکسنگین کردنها (trade-offs) در شرایطی بوده که هیچ گزینهای بینقص نیست. هوش مصنوعی سرعت تولید کد را تغییر داده است، اما دلیل نیاز ما به حضور انسان در چرخه (human in the loop) را تغییر نداده است. اگر قرار باشد چیزی تغییر کند، آن چیز این است که تفکر شفاف، ارزشمندتر و کمیابتر شده است.
پیشنویس اول، مهندسی نیست
من شاهد هستم که تعداد رو به افزایشی از توسعهدهندگان جونیور (junior developers)، با ChatGPT یا Claude طوری رفتار میکنند که انگار مهندس ارشدی (senior engineer) است که روی صندلی بغلی نشسته است. آنها توضیحات یک تیکت را کپی میکنند، پاسخ را برمیدارند، تستها را اجرا میکنند و کامیت (commit) میکنند. اگر کد کامپایل شود، کار تمام است. این چرخه سریع، بدون اصطکاک و خطرناک است.
استفاده از هوش مصنوعی مشکل نیست. من از آن استفاده میکنم. اکثر مهندسان بهرهور که میشناسم از آن استفاده میکنند. مشکل زمانی شروع میشود که هوش مصنوعی تنها مهندسِ حاضر در اتاق باشد. پذیرفتن اولین راه حل صرفاً به این دلیل که کار میکند، مهندسی نیست. این برونسپاریِ قضاوت به مدلی است که نه کاربران شما را میشناسد، نه محدودیتهای تجاری شما را درک میکند و نه میداند آخرین بار چه زمانی در ساعت ۲ صبح، کل استک (stack) شما از کار افتاد.
مدلهای زبانی بزرگ، پاسخها را با اعتمادبهنفسی نگرانکننده ارائه میدهند، حتی زمانی که کاملاً اشتباه هستند. مهندسی از یک هوش مصنوعی خواست تا یک معماری مقیاسپذیر طراحی کند. مدل یک پیشنهاد دقیق و مقتدرانه ارائه داد که تماماً حول ویژگیای ساخته شده بود که در محصول واقعی وجود نداشت. به نظر درست میآمد. از نظر منطقی منسجم بود. اما در عین حال بیفایده بود. خطر فقط این نیست که هوش مصنوعی دچار توهم (hallucination) میشود؛ خطر این است که اکنون افراد زیادی به آن توهمات اعتماد میکنند، چون دیگر زمینه (context) لازم برای تشخیص دروغ را ندارند.
شما از اصطکاک یاد میگیرید
وقتی به این فکر میکنم که چه چیزی مرا از یک توسعهدهنده جونیور به کسی تبدیل کرد که میتواند مالکیت یک سیستم را بر عهده بگیرد، سینتکسهایی را که حفظ کرده بودم به یاد نمیآورم. من قطعیهای سیستم (outages) را به یاد میآورم. کوئریهای کندی را به یاد میآورم که مجبور بودم دستی ردیابیشان کنم، شرایط رقابتی (race conditions) که فقط زیر بارِ محیط عملیاتی (production load) ظاهر میشدند، و استقرارها (deployments) که شکست میخوردند چون محیط محلی من هیچ شباهتی به دنیای واقعی نداشت.
دیباگ کردن (Debugging) همان جایی است که یادگیری اتفاق میافتد. وقتی کد را به صورت دستی مرحلهبهمرحله جلو میبرید، میبینید که سیستمها واقعاً چرا شکست میخورند. کشف میکنید که گلوگاهها (bottlenecks) کجا ظاهر میشوند. یاد میگیرید که یک معماری وقتی از یک دموی ۱۰ نفره به یک سیستم عملیاتی با ۱۰ هزار درخواست همزمان تغییر میکند، چگونه رفتار میکند. شما در تار و پود وجودتان جذب میکنید که محیط عملیاتی چه تفاوتی با یک دموی خوشساخت و سناریونویسیشده دارد.
هیچکدام از این دانشها از پذیرفتن یک پاسخ تولیدشده به دست نمیآید. بلکه از کلنجار رفتن با مسئله حاصل میشود. اگر هوش مصنوعی هرگونه سختی را از بین ببرد، اگر کد را بنویسد، باگها را اصلاح کند و شکستها را توجیه کند، نسل بعدی توسعهدهندگان دقیقاً چگونه به جایگاه ارشد (seniority) برسند؟ تجربه، گواهنامهای نیست که دانلود کنید؛ بلکه بافتِ زخمهایی است که از حوادث محیط عملیاتی و استقرارهای شکستخورده در خود میسازید. اگر اصطکاک را حذف کنید، رشد را هم حذف کردهاید.
قضاوت بر تولید برتری دارد
برای مدتی، صنعت با مهندسی پرامپت (prompt engineering) به عنوان مهارت جدید و جذابی که باید در رزومه نوشته شود برخورد کرد. این نگاه کاملاً هدف اصلی را نادیده گرفت. ارزشمندترین توانایی در محیطی اشباعشده از هوش مصنوعی، تولید گزینهها نیست؛ بلکه دانستن این است که کدام پیشنهادها را باید رد کرد.
بهترین مهندسانی که با آنها کار میکنم، بیشترین پرامپتها را نمینویسند. آنها سختترین سوالات را میپرسند. آنها میدانند چه زمانی یک بازنویسی کد (refactor) یک وابستگی (dependency) پنهان ایجاد میکند. آنها تشخیص میدهند چه زمانی یک تستِ تولیدشده، فقط مسیر اصلی (happy path) را پوشش میدهد اما حالتهای خاص (edge case) را که باعث فساد دادههای مشتری میشود، نادیده میگیرد. آنها میتوانند به یک کد کاملاً معتبر نگاه کنند و بگویند: «این کد درست است، اما معماری آن غلط است.»
این جمله آخر، مرز بین دو فرهنگ بسیار متفاوت است. مهندسیِ کمکگرفته از هوش مصنوعی یعنی از ماشین برای طراحی ساختار اولیه (scaffolding)، بررسی الگوها یا خودکارسازی کدهای تکراری (boilerplate) استفاده کنید، در حالی که مغز شما تصمیمات را مدیریت میکند. اما مهندسیِ وابسته به هوش مصنوعی یعنی به ماشین اعتماد کنید تا رانندگی کند. بسیاری از سازمانها بیصدا به سمت وابستگی سوق پیدا میکنند، چون در کوتاهمدت سریعتر به نظر میرسد. اما سریع بودن با درست بودن یکی نیست.
کارهایی که هنوز متعلق به انسانهاست
هوش مصنوعی میتواند تقریباً تمام بخشهای چرخه حیات توسعه را تسریع کند، با این حال، برخی از شیوههای اصلی باید کاملاً در اختیار انسان باقی بمانند. طراحی سیستم مستلزم ایجاد تعادل میان محدودیتهای متضاد است: هزینه، تأخیر، قابلیت اطمینان و قابلیت نگهداری در آینده. بازبینیهای معماری به حافظه سازمانی و توانایی پیشبینی اثرات درجه دوم بستگی دارند. مربیگری نیازمند کسی است که واقعاً با حالتهای شکستی که دربارهشان به شما هشدار میدهد، دستوپنجه نرم کرده باشد. درک عمیق محصول از طریق گفتگو با کاربران و مشاهده رفتار آنها در دنیای واقعی به دست میآید، نه از طریق خواندن دادههای آموزشی.
قضاوت مهندسی، حاصل جمع آن تجربیات است. این همان صدای آرامی است که به شما میگوید یک مهاجرت (migration) برای اجرا در عصر جمعه بسیار پرخطر است، حتی اگر بازبینی کد با موفقیت انجام شده باشد. این همان شهودی است که میگوید یک بهینهسازی عملکرد در حال حاضر، ممکن است بعداً یک حفره امنیتی ایجاد کند. یک LLM فاقد شهود است. این مدلها الگوها را میشناسند. الگوها مفید هستند، اما قضاوت نیستند.
شرکتهایی که در حال حاضر در حال استخدام هستند، باید از بهینهسازی برای افرادی که صرفاً در استفاده از ابزارهای هوش مصنوعی مهارت دارند، دست بردارند. افرادی را استخدام کنید که بتوانند هوش مصنوعی را به چالش بکشند. به دنبال کاندیداهایی باشید که مکث کنند، خروجی تولید شده را با دقت بخوانند و توضیح دهند که چرا با آن مخالف هستند. اینها همان مهندسانی هستند که وقتی کد تولید شده با واقعیتهای پیچیده محیط عملیاتی (production) روبرو میشود، سلامت سیستمهای شما را حفظ خواهند کرد.
شتاب بدون قطبنما
هوش مصنوعی را مانند پدال گاز تصور کنید. در خودرویی با یک