کدنویسی حل نشد

سلب مسئولیت: شما در شرف خواندن نظرات زیادی هستید، بسیاری از آنها دارای ارجاع هستند، اما برخی از آنها نتیجه تجربه شخصی من در ساختن با هوش مصنوعی و ساختن سیستم های هوش مصنوعی در 4 سال گذشته است. صرفنظر از این، مراقب اشتباه مرد کاهی باشید: فقط به این دلیل که یک استدلال با سیستم اعتقادی شما مطابقت ندارد، به این معنی نیست که بقیه بی اعتبار هستند. همچنین باید از قبل بگویم که من ضد هوش مصنوعی نیستم. اگر کار من را دنبال می‌کردید، می‌دانید که من نه تنها از ابزارهای کدنویسی مبتنی بر LLM استفاده می‌کردم، بلکه برای ساختن مهار خودم، آموزش این موضوعات و ساخت محصولات مبتنی بر LLM استفاده می‌کردم.

این در مورد ترس از هوش مصنوعی نیست، بلکه به چالش کشیدن روایت مرگ مغزی است که ادعا می کند "کد نویسی حل شده است" و مهندسی اکنون در مورد "طعم" است.

به من بگو که نرم افزار را بدون استفاده واقعی از آن کلمات نمی فهمی!!!

افرادی که ادعا می کنند "LLM ها می توانند کد مناسب بنویسند" نمی دانند کد چگونه کار می کند. مطمئنا، ایجاد بسیار ارزان‌تر است، اما هرکسی که نرم‌افزار را در مقیاس تولید اجرا کرده باشد، می‌داند که تعمیر و نگهداری، قابلیت اطمینان، امنیت، مقیاس‌پذیری و غیره بیشتر هزینه است. اینها معمولا به عنوان NFR (الزامات غیر عملکردی) شناخته می شوند.

در تجربه من حتی نیازهای عملکردی (آنچه کد قرار است انجام دهد) هنوز مشکلی حل نشده است. در جایی که افرادی که خروجی را نمی خوانند، کمی از اثر دانینگ-کروگر وجود دارد.

به‌عنوان یک توسعه‌دهنده کهنه کار که دارای ۲ مدرک مهندسی (مهندسی سخت‌افزار و سیستم) است، می‌توانم ۳ نوع محصول را لیست کنم که نیازی به خواندن کد ندارند:

نرم افزار شخصی: خارش، اتوماسیون، تکه های DIY و غیره.

POC (اثبات مفهوم): نشان دادن امکان سنجی فنی و دوام محصول

هوش مصنوعی تسلیحاتی شده: خطر را بپذیرید و عمدا آن را به سمت هدف بگیرید تا آسیب ایجاد کنید.

به وجه اشتراک توجه کنید: 2 مورد اول دارای تحمل ریسک بالایی هستند در حالی که آخرین مورد خطر ذاتی را مسلح می کند.

اکثر نرم افزارهایی که نیاز به استخدام و پرداخت هزینه مهندسان نرم افزار دارند، تحمل ریسک پایینی دارند:

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

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

شما نمی توانید مسئول آنچه نمی توانید کنترل کنید نیز باشید. این درک برای استدلال در مورد رفتار سیستم و رفع آن در زمانی که هوش مصنوعی به طور اجتناب ناپذیری از کار می افتد، کلیدی است.

اگر در حال بازی کردن هستید، LLM ها کار بسیار خوبی انجام می دهند. به همین دلیل است که برخی از تهاجمی‌ترین حامیان روایت «کدگذاری حل شد» چیزی برای نشان دادن ندارند. Anthropic به طور تصادفی Claude Code را درز کرد (که در بررسی های بیشتر مشخص شد که نقص های زیادی دارد) و صفحه وضعیت آنها نشان می دهد که نارنجی سبز جدید است!

بر خلاف روایت رایج، کدنویسی در واقع یکی از آخرین حوزه هایی است که نسل فعلی LLM ها آن را به دست می گیرند!!!

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

دلیل موفقیت LLM ها در نوشتن کد این است که ما یک حلقه بازخورد ایجاد کرده ایم که خطاهای نحوی/ زمان اجرا را به LLM برمی گرداند و تا زمانی که اکثر خطاها حل یا پنهان شوند، حلقه می شود.

LLM ها می توانند آن را برای کارهایی که به زبان طبیعی مرتبط هستند (مانند نوشتن پست های رسانه های اجتماعی، گزارش ها، مقاله ها و غیره) کمک کنند، اما وقتی نوبت به کد می شود، همان موتوری که برای شمارش تعداد R در «رزبری» تلاش می کند یا راه رفتن به کارواش را پیشنهاد می کند، مغالطه های منطقی دیگری را نیز آشکار می کند.

LLM ها تصادفی و احتمالی هستند. تنها راهی که می‌توانیم حتی از راه دور به منطقی کردن آنها نزدیک شویم این است که آنها را در کدهای سنتی (معروف به مهار)، اجرای آزمایش‌ها و تعدادی تکنیک دیگر (مانند CoT) قرار دهیم، اما مشکل اصلی همچنان باقی است: LLM ها با منطق و حجم درگیر هستند (هرچه ورودی بزرگتر باشد و پنجره زمینه بیشتر استفاده شود، دقت کمتری دارند).

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

کسانی که ادعا می‌کنند نرم‌افزار تولید شده توسط LLM به اندازه کافی خوب است: ❌ در سال‌ها کد ننوشته‌اند ❌ نمی‌توانند تشخیص دهند که کدشان به صورت مجازی ۶ انگشت داشته باشد! ❌ نوار پایینی برای ظاهر خوب داشته باشید ❌ به کیفیت یا NFR اهمیتی ندهید ❌ در درک منحنی S مشکل دارید ✅ صادق باشید: هوش مصنوعی واقعا کد بهتری از آنها می نویسد

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

من اینجا نیستم که گردش کار یا جعبه ابزار کسی را تغییر دهم. نمیتونستم اهمیت بدم

چیزی که من اهمیت می‌دهم این است که خدماتی که برای آن‌ها پول می‌دهم (با نگاه کردن به شما در Google و GitHub) با اشکالات احمقانه‌ای رو به زوال است که اگر قابلیت اطمینان و مسئولیت‌پذیری را بر سرعت اولویت دهیم، می‌توان از آنها اجتناب کرد.

بوریس چرنی از آنتروپیک یکی از سرسخت ترین طرفداران روایت «کدگذاری حل شد» است. بر اساس بسیاری از گزارشات، کد ابری تجلی ایدئولوژی او است:

نصب کننده باینری Claude Code CLI پس از نصب بی سر و صدا خود را حذف می کند

هزینه استفاده اضافی علیرغم ظرفیت طرح موجود + خطاهای محدودیت نرخ نادرست شارژ می شود

یادآوری: Anthropic مدل (Claude)، مهار (Claude Code)، اعلان (نسخه‌های فاش شده را ببینید) و زمان اجرا (Bun) را کنترل می‌کند.

اگر در موقعیت رهبری هستید، لطفا به توسعه دهندگان [در غیر این صورت باهوش] خود فشار نیاورید تا هوش مصنوعی را به هر سطح ممکن و جریان کاری وادار کنند.

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

از تکرار روایت های نیمه کاره فروشندگان توکن در مورد اغراق در قابلیت های هوش مصنوعی خودداری کنید زیرا ما، مصرف کنندگان، هزینه نهایی را می پردازیم.

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

من نمی‌خواهم با استفاده از هارنس، مهارت‌ها، AGENTS-md، MCP، A2A، ACP، RLM، OKF، MoE، MoA، خوددرمانی، و زمان‌های مختلف اجرا، کوانتیزه‌سازی‌ها، بهینه‌سازی‌ها، معماری‌ها و تکنیک‌های حافظه، چقدر پیشرفت کرده‌ایم.

اینها رویکردهای عملگرایانه عالی برای رفع کاستی های LLM هستند و احتمالا موارد بیشتری در راه است.

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

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

ارتباط بلند مدت خود را فدای سرعت کوتاه مدت نکنید.

تحمل شما برای اختلاف نظر و گفتمان مدنی صفر است.

شما اجازه می دهید هوش مصنوعی زندگی شما را اداره کند و به فروشندگان هوش مصنوعی با چیزهایی اعتماد می کنید که تا چند سال پیش غیرقابل تصور بود.

برای چیزهایی که از نظر شناختی کمی چالش برانگیز هستند، به سراغ هوش مصنوعی می روید.

شما ساده لوحی و تنبلی خود را به عنوان خوش بینی در نظر می گیرید و فکر می کنید اگر اوضاع بد شود، دولت می تواند شما را نجات دهد.

شما خواندن متن طولانی را متوقف کرده اید: کتاب، مقاله، حتی ایمیل های طولانی.

شما زمان بیشتری را با هوش مصنوعی می گذرانید تا با انسان های دیگر یا به هوش مصنوعی اجازه می دهید شما را در برابر تعامل واقعی انسانی محافظت کند.

و یک امتیاز اضافی: شما لاغری. آیا به شماره 5 توجه کردید؟ 😄

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

"شما می توانید یک مشخصات کامل از قبل ایجاد کنید". اگر شما آنقدر ساده لوح هستید، من مردی را با ون سفید می شناسم که بستنی رایگان می دهد! اجازه دهید حدس بزنم، شما همچنین معتقدید تخمین های نرم افزاری دقیق هستند و بابانوئل واقعی است. هر کسی با چند سال تجربه در صنعت می‌داند که تعیین دقیق نرم‌افزار از قبل غیرممکن است (مگر اینکه خیلی پیش پا افتاده باشد).

"انگلیسی زبان برنامه نویسی جدید است". زبان انسان مبهم و متضاد است. این دلیل اصلی ایجاد زبان های برنامه نویسی است. یک کامپایلر یا تایپ چک کننده برخی از این تضادها را علامت گذاری می کند. چگونه می توانید مطمئن باشید که یک بخش از دستورالعمل های NL شما با دیگری در تضاد نیست؟ با بررسی‌های نحوی، کمکی دریافت می‌کنیم. در حالی که ممکن است به یک LLM دیگر تکلیف شود تا دستورالعمل‌ها و دلایل مربوط به آن تضادها را مطالعه کند، مطمئن‌ترین راه برای کشف این تفاوت‌ها این است که از نماینده خود بخواهید آنچه را که خواسته‌اید بسازد. اما این بسیار گرانتر از لینتر یا کامپایلر است.

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

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

"اهرم به سلیقه تغییر کرده است". آره، این دروغی است که سرآشپزهای بازنشسته به خودشان می گویند. فقط به این دلیل که یک ربات در آشپزخانه وجود دارد به این معنی نیست که شما باید در رستوران در قسمت مشتری بنشینید! "طعم" آنقدر که شما می خواهید قابل پرداخت نیست! همه ذوق کردند! من این را به عنوان کسی می گویم که بخش بزرگی از حرفه ام را در Frontend و UX land گذرانده ام. هر کسی و سگش نظر و سلیقه ای دارد. می دانم منظور شما چیست: طعم == تجربه.

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

"هوش مصنوعی یک اکولایزر است. خلاقیت (نوشتن، کدنویسی، ساخت موسیقی، ویدئو و غیره) را قابل دسترس تر می کند." هوش مصنوعی یک ضریب است: به افراد احمق و باهوش بال می دهد. من اینجا نیستم که قضاوت کنم، اما تلاش های بیهوده زیادی از پست های رسانه های اجتماعی گرفته تا وبلاگ ها، میم ها و غیره دیده ام. من همچنین استفاده خوبی از هوش مصنوعی را دیده‌ام که در آن واقعا کار با کیفیتی با سرعت و کسری از هزینه ایجاد می‌کند. تفاوت اصلی در مشارکت انسان، تکرار و عمق دانش است که منجر به حلقه‌های بازخورد قوی‌تر می‌شود.

دومی به زمان و تلاش بیشتری نیاز دارد تا جایی که برخی از کارها واقعا ارزان‌تر و سریع‌تر انجام می‌شوند (مثلا روز قبل آزمایشی را انجام دادم و به نماینده خود وظیفه داشتم تا وابستگی‌های 5 npm را به‌روزرسانی کند، همه وصله‌های منتشر شده. این کار 12 دقیقه و 72 مرحله طول کشید. من می‌توانم آن را در کمتر از یک دقیقه انجام دهم.) ابزارهایی مانند ارزان‌تر از آن را دوست داشتنی‌تر می‌کنند. روزهایی که یک وب سایت صیقلی به معنای مهارت یا حداقل یک جیب عمیق بود، گذشته است. هوش مصنوعی یک ضرب کننده نیرو است، اما جهت بردار نیرو مهم تر است!

"Agent کامپایلر جدید است". آه دوباره اون یکی! مطمئنا! اگر واقعیت شما این است، من به این میم اجازه می دهم کار را انجام دهد.

Pssst! آیا می خواهید یک ترفند قدیمی برای برتری فوری کدهای تولید شده توسط LLM بدانید؟

چندین عامل را به صورت موازی اجرا کنید! حجم انبوه کد باعث می‌شود بررسی آن از نظر انسانی غیرممکن/گران باشد و شما تسلیم شوید!

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

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

ما دقیقا به هوش مصنوعی اعتماد نداریم، اما مجبوریم به این دلیل که جایگزین (با خواندن خروجی) برای برخی افراد بسیار سخت است! در عوض آنها به رسانه های اجتماعی می آیند و ادعا می کنند که از آنجایی که UAT (تست پذیرش کاربر) قبول می شود، کد "به اندازه کافی خوب" است. سپس آن را برای من و شما ارسال کنید تا بقیه آزمایشات را انجام دهید.

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

هنگام صحبت در مورد هوش مصنوعی (نه فقط LLM)، 2 جنبه وجود دارد که عدم جبرگرایی اهمیت دارد:

در طول توسعه: به عنوان مثال توسعه با کمک LLM

در طول زمان اجرا: به عنوان مثال ساختن یک سیستم که در آن یک یا چند جزء از هوش مصنوعی استفاده می کنند

ابتدا توسعه را در نظر بگیریم. یک گردش کار توسعه معمولی با کمک هوش مصنوعی به شکل زیر است:

می‌توان بخشی از مسئولیت انسان را با LLM دیگری (که به عنوان "مهندسی حلقه" نیز شناخته می‌شود) جایگزین کرد، اما در حال حاضر اجازه دهید انسان را برای سادگی حفظ کنیم.

خروجی LLM از چندین دروازه عبور می کند که هر کدام خطاها یا نکاتی را برای تصحیح کد ارائه می دهند. این حلقه بازخورد اغلب در داخل یک مهار پنهان می شود (همراه با فراخوانی ابزار، سیستم حافظه، تعامل مدل، تایید، تعامل کاربر و غیره)

هر خط آبی یا قرمز نشان دهنده خطر سوء تفاهم یا دستورالعمل های متناقض است. به عنوان مثال، مهارت متضاد در مقابل مشخصات یا ابهامی که بخشی از NL (زبان طبیعی) است.

ما به درستی می دانیم که حتی پیچیده ترین LLM ها به طور کامل قادر به "عقل سلیم" نیستند. از طرف دیگر انسان ها:

ارتباطات غیر کلامی و مقاصد بیان نشده را بهتر از LLM ها درک کنید

به طور طبیعی تا زمانی که تفاهم متقابل حاصل شود عقب نشینی کنید.

وقتی اشتباه می کنند، به طور مداوم اشتباه می کنند، به این معنی که آنها "هوش ناهموار" ندارند.

وقتی درست باشد، [معمولا] درست می‌گویند و در سطح مورد انتظار به کار خود ادامه می‌دهند (تا زمانی که خستگی رخ دهد، اما این با تلنگر هوش مصنوعی بین موفقیت/شکست متفاوت است).

بله، من می‌توانم «اما» و «چه می‌شد اگر» و «صبر کن، فراموش کردی»... در بین مخاطبان، اما خواندن آن نکات با مکث و تأمل بر اساس تجربه‌ات چطور است؟

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

این تفاوت بین انسان و این ابزارها است. یک انسان می تواند به طور مداوم اشتباه کند، اما یک مدل ممکن است در مورد چیزی که درست بوده اشتباه کند و بالعکس.

با توجه به همان ورودی (شامل متغیرهای محیطی، زمان، داده ها و غیره):

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

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

فکر نمی کنم نیازی به توضیح بیشتر در این مورد داشته باشید. کافی است به نزدیکترین محصول مجهز به هوش مصنوعی خود برسید و خروجی آنها را برای همان درخواست متفاوت کنید.

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

از یک طرف، ما افرادی را داریم که ادعا می‌کنند «کارخانه‌های نرم‌افزار» و تنظیمات چند عاملی را اجرا می‌کنند و برنامه‌ها را از طریق درخواست‌ها ایجاد می‌کنند.

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

مدل را پرایم کنید: افزودن SKILLs، AGENTS.md، ابزارها و غیره و تأیید

خروجی را مرور کنید: گذر از تفاوت های عظیم

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

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

اما وقتی یک لایه عمیق تر نگاه می کنم، یک الگو ظاهر می شود. هرچه افراد کمتر در مورد پیچیدگی ها و موارد لبه یک کار اطلاعات داشته باشند، احتمال بیشتری دارد که به خروجی هوش مصنوعی اعتماد کنند. این اثر هوش مصنوعی Dunning-Kruger نام دارد، اما مقداری گوشت نیز در آن وجود دارد. استدلال اولیه به این صورت است:

مدیران پیش از این به تفویض وظایف به مهندسان متکی بودند. اکنون آنها این کار را می کنند اما با هوش مصنوعی.

تا حدی این درست است (اگر فرض کنیم مدیر به اندازه کافی فنی است که به طور مؤثر و کارآمد عوامل را مدیریت کند). من هنوز معتقدم که بسیاری از روش‌های مهندسی نرم‌افزار که به رام کردن ماشین‌ها کمک می‌کنند، در عصر هوش مصنوعی مرتبط‌تر هستند.

مدیرانی که مردم را مجبور به استفاده از هوش مصنوعی کردند، اکنون با آنچه ما در تمام این مدت گفته‌ایم بیدار شده‌اند:

شما نمی توانید در قبال چیزی که درک نمی کنید پاسخگو باشید.

توبی لوتکه، مدیر عامل Shopify را به عنوان مثال در نظر بگیرید. یک سال پیش او پیش از موعد به کارمندانش گفت که از هوش مصنوعی استفاده کنند:

سپس چند روز پیش او اصطلاح "نارنجک های شیبدار" را برای توصیف نتیجه ابداع کرد:

"مسئولیت" کد تولید شده توسط هوش مصنوعی؟ البته نه!

هوش مصنوعی می تواند آن را برای شما توضیح دهد اما نمی تواند آن را برای شما درک کند. این درک جنبه کلیدی مالکیت است.

همانطور که من آن را قاب می کنم (لینک در نظرات)، مالکیت دارای 3 رکن است:

1️⃣ دانش: شما می دانید که چه مشکلی را حل می کنید (مشکلات محصول)، و توانایی های فنی، محدودیت ها و نحوه عملکرد آن.

2️⃣ مأموریت: نیازی نیست برای درخواست اجازه بدوید. به شما اعتماد و اختیار تصمیم گیری داده شده است.

3️⃣ مسئولیت پذیری: اگر به دلیل اینکه نمی دانستید چه کار می کنید یا از ماموریت خود یا هر چیز دیگری سوء استفاده کرده اید به طرفدار ضربه بزند، این شما هستید که در حال تماس هستید.

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

هر یک از این 3 عنصر را بردارید و با مالکیت شکسته سروکار دارید.

LLM ها در تولید کد بسیار سریع هستند. اما اکثر نرم افزارهایی که ارزش استخدام یک مهندس را دارند، نیاز به درک دارند. این درک زمان می برد.

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

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

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

مهندسان خوب کنجکاو هستند و به محصول فکر می کنند. آنها سعی می کنند قبل از رسیدن به HOW (راه حل فنی) دلیل (مشکل چیست و چرا یک مشکل) را درک کنند.

دقیقا به همین دلیل است که قبیله «مشخصات کد است» کوتاه می‌آید: تعیین تمام جنبه‌های مشکل از قبل بسیار سخت (اگر نه کاملا غیرممکن) است.

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

کوچک کردن شغل مهندس به کدنویسی مانند کوچک کردن شغل یک سرآشپز به برش است. این بخشی از کار است، اما هرگز پایان کار نبوده است. اکنون ابزارهای خوبی در اختیار داریم.

حتی اگر کد تولید شده توسط هوش مصنوعی دارای NFR (مقیاس‌پذیری، امنیت، قابلیت اطمینان و غیره) باشد، و حتی اگر مهندسان آن را کاملا درک کرده باشند، هنوز یک جنبه مهم وجود دارد که ما در مورد آن صحبت نکردیم: اقتصادی بودن کار.

بگویید کد تولید شده توسط هوش مصنوعی 2 برابر بدتر است. تعیین کمیت کیفیت دشوار است (SLI مفید است) اما با من بمانید.