ویرگول
ورودثبت نام
علی فخاران قمی نژاد
علی فخاران قمی نژاد
علی فخاران قمی نژاد
علی فخاران قمی نژاد
خواندن ۶ دقیقه·۲ ماه پیش

بهترین برنامه‌نویس دیگه کسی نیست که بهترین کد رو می‌نویسه

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

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

اصلاً چرا این تحول در حال وقوع است؟ چرا نقش ما در حال تغییر است؟

پس از تأمل و تجربه‌ی مداوم، به نتیجه‌ای رسیدم که در ابتدا برایم ناخوشایند بود، اما هرچه بیشتر کار کردم، درستی‌اش روشن‌تر شد:

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

گلوگاه جابه‌جا شده، نه حذف شده

جمله‌ای هست که از وقتی به آن رسیدم، از ذهنم بیرون نرفته:

«همه‌ی تست‌ها پاس شدند» با «این دقیقاً همان چیزی است که من می‌خواستم» یکی نیست.

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

استعاره‌ای که برایم جا افتاده این است: ما از «کارگری که آجر را دستی می‌چیند» در حال تبدیل شدن به «معماری هستیم که نقشه می‌کشد و بر ساخت نظارت می‌کند». ما مشخصات (spec) می‌نویسیم، AI کد را تولید می‌کند، و ما امضای تأیید فنی نهایی را می‌گذاریم.

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

پس چرا حس می‌کنیم کندتر شده‌ایم؟

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

در سیستم‌های پیچیده، AI گاه بیشتر وقت‌گیر است تا وقت‌آزادکن. باید context بدهی، خروجی را با دقت بخوانی، خطاها را پیدا کنی، و در نهایت مسئولیتش را بپذیری.

نکته‌ی دیگری نیز ذهنم را مشغول کرده: بسیاری از توسعه‌دهندگان هم‌زمان از hallucinationهای مکرر AI و اعتماد پایین به کد تولیدی‌اش سخن می‌گویند، در حالی که سهم قابل‌توجهی از کد production را همین ابزارها می‌نویسند. این شکاف میان «میزان سپردن کار به AI» و «میزان اعتماد به آن»، دقیقاً همان جایی است که بدهی تأیید متولد می‌شود.

قانونی که برای خودم وضع کرده‌ام ساده است:

کدی را commit نکن که نمی‌توانی توضیحش بدهی.

این جمله بدیهی به نظر می‌رسد، تا وقتی ببینی چقدر آسان می‌شود سیصد خط کدی را که «خوب به نظر می‌رسد» و تست‌ها را پاس می‌کند، پذیرفت.

مهارت‌هایی که ارزش‌شان در حال افزایش است

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

مهارت‌هایی که در حال صعودند:

  • تفکر معماری — طراحی مرزهای سیستم و تصمیم‌هایی که agent به تنهایی اتخاذ نمی‌کند

  • دقت در نیازمندی‌ها — تبدیل «می‌خواهیم کار کند» به مشخصاتی دقیق و قابل‌آزمون

  • قضاوت و سلیقه — تشخیص اینکه یک نتیجه واقعاً خوب است، نه فقط از نظر فنی صحیح

  • مهندسی context — ارائه‌ی context درست در لحظه‌ی درست به agent

  • ارکستراسیون agentها — هماهنگ کردن چندین نمونه‌ی موازی که روی بخش‌های مختلف کار می‌کنند

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

  • نوشتن boilerplate

  • ترجمه‌ی دستی نیازمندی به کد

  • دیباگ خط‌به‌خط

  • حفظ کردن syntax و API

نکته‌ی مهم این است که مهارت‌های قدیمی بی‌فایده نمی‌شوند. بدون آن‌ها نمی‌توانی خروجی agent را ارزیابی کنی. فقط دیگر مزیت رقابتی اصلی نیستند.

هزینه‌ی روانی که نباید نادیده گرفته شود

موضوعی هست که در بحث‌های فنی کمتر به آن پرداخته می‌شود و به نظرم بسیار مهم است: هزینه‌ی روانی این تغییر واقعی است و نشانه‌ی ضعف نیست.

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

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

برای تیم‌ها این به معنای آن است که رهبری که فرهنگ یادگیری می‌سازد، مقاومت را کاهش می‌دهد؛ رهبری که صرفاً فشار می‌آورد، مقاومت را افزایش می‌دهد.

این اولین بار نیست (و این خبر خوبی است)

هر لایه‌ی انتزاعی در تاریخ برنامه‌نویسی با پیش‌بینی «پایان برنامه‌نویس» متولد شد و هر بار این پیش‌بینی اشتباه از آب درآمد.

کامپایلرها قرار بود به تحلیلگران کسب‌وکار امکان نوشتن برنامه بدهند. زبان‌های نسل چهارم و ابزارهای CASE وعده‌ی تولید مستقیم اپلیکیشن از مشخصات را می‌دادند. DevOps قرار بود نقش مدیر پایگاه داده را حذف کند.

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

کامپایلرها برنامه‌نویس‌ها را حذف نکردند؛ نیاز به نوشتن دستی assembly را حذف کردند و سطح کار را ارتقا دادند. نقش مدیر پایگاه داده با ظهور DevOps ناپدید نشد؛ به مهندس پلتفرم تبدیل شد.

پس چه باید کرد؟

اگر بخواهم جمع‌بندی کنم:

برای خودت:

  • کدی را merge نکن که نمی‌توانی توضیحش بدهی

  • زمان آزادشده را به خواندن عمیق، نوشتن و یادگیری اختصاص بده، نه به کار بیشتر

  • روی تفکر معماری، دقت در نیازمندی‌ها و مهارت قضاوت سرمایه‌گذاری کن

برای تیمت:

  • سیاست صریح استفاده از AI داشته باش

  • کدهای حیاتی و امنیتی را اجباری بازبینی کن

  • دسته‌های کوچک و حلقه‌های بازخورد سریع بساز

  • کیفیت spec را ارزیابی کن، نه تعداد خطوط کد

  • «روزهای بدون AI» در نظر بگیر تا مهارت‌های پایه زنگ نزنند

  • فرهنگ یادگیری بساز، نه صرفاً دستور استفاده

حرف آخر

جمله‌ای از اریک هوفر هست که به نظرم بهترین جمع‌بندی این وضعیت است:

«در زمان‌های تغییر، یادگیرندگان زمین را به ارث می‌برند، در حالی که دانندگان خود را زیبا مجهز به دنیایی می‌یابند که دیگر وجود ندارد.»

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

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

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

کدمزیت رقابتیهوش مصنوعیبرنامه نویسی
۲
۰
علی فخاران قمی نژاد
علی فخاران قمی نژاد
شاید از این پست‌ها خوشتان بیاید