کوریِ کیفی: چرا برنامه‌نویسان باگ‌های نرم‌افزاری را نمی‌بینند؟

تصور کنید مهندسی هستید که هفته‌ای صدها تا هزاران باگ را می‌بیند، در حالی که اکثر همکارانتان هیچ متوجه آن‌ها نمی‌شوند. برای مدت‌ها، دن لو (Dan Luu) فکر می‌کرد شاید او صرفاً باعث تحریک رفتارهای عجیب و گوشه‌ای (corner-case) می‌شود که کاربران عادی از آن‌ها دوری می‌کنند. اما پس از مشاهده‌ی محصولات متعددی که عرضه شدند و بلافاصله «با صورت به زمین خوردند» چون کاربران دقیقاً با همان مشکلاتی مواجه شدند که او دیده بود، به این نتیجه رسید که اگر محصولی از نظر او به شدت معیوب به نظر می‌رسد، احتمالاً واقعاً همین‌طور است.

لو استدلال می‌کند که بسیاری از توسعه‌دهندگان از «کوری کیفی» (Quality Blindness) رنج می‌برند؛ وضعیتی که در آن سازنده به‌طور ناخودآگاه برای کنار آمدن با نقص‌ها، راهکارهای موقتی می‌سازد تا جایی که باگ‌ها برایش نامرئی شوند. در این حالت، توانایی یک برنامه‌نویس حرفه‌ای در نادیده گرفتن نقص‌های نرم‌افزاری، نه یک مهارت، بلکه یک بدهی و نقطه ضعف خطرناک است.

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

روان‌شناسی کوری

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

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

مکانیسم کاهش عادت‌گونه

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

لو چندین مثال عینی از این رفتار ارائه می‌دهد:

• گوگل داکس (Google Docs): باگی وجود دارد که اگر بلافاصله بعد از باز کردن سند در کادر عنوان تایپ کنید، متن بازنویسی می‌شود. راهکار ناخودآگاه این است که ابتدا یک اقدام دیگر انجام دهید و سپس نام فایل را بنویسید. گری برنهارت (Gary Bernhardt) تجربه مشابهی را ذکر کرد که در آن رابط کاربری (UI) خراب می‌شد و اسکرول به بالا برای خواندن کامنت‌ها غیرممکن می‌شد و بسته به متن، نیاز به راهکارهای خاصی داشت. برنهارت اشاره کرد که اگرچه گوگل داکس را از نظر کیفیت بسیار بالاتر از مایکروسافت ورد، اوپن آفیس یا ویرایشگرهای قدیمی مثل StarOffice و Lotus می‌داند، اما همچنان می‌تواند یک پست ۱۰ هزار کلمه‌ای درباره باگ‌های آن و راهکارهای دور زدنش بنویسد.
• ورود به مایکروسافت: یک مشکل قدیمی که در آن یک سرویس خاص اغلب در هنگام ورود با خطای «در حال حاضر هیچ سرور ورودی برای پاسخ به درخواست ورود در دسترس نیست» شکست می‌خورد. راهکار این بود که قبل از ورود، کلید وای‌فای لپ‌تاپ را روی «خاموش» قرار دهند تا سیستم کلاً بررسی سرور را دور بزند. لو متوجه شد که همکاران دیگرش نیز همین کار را انجام می‌دادند.
• جبران سخت‌افزاری: لو موشی مکانیکی از دوران موس‌های توپک‌دار را به یاد می‌آورد که در آن تجمع آشغال‌ها باعث ردیابی نامنظم می‌شد. او به‌طور ناخودآگاه دستش را «با شدت در همه جای محیط» تکان می‌داد تا نشانگر را در خط مستقیم نگه دارد، بدون اینکه متوجه این جبران شود تا زمانی که یکی از دوستانش متوجه شد استفاده از آن موس غیرممکن است.
• بیدار کردن مک: ام چو (Em Chu) باگی را توصیف کرد که در آن مک با یک صفحه سیاه و یک نشانگر بیدار می‌شود. تنها راه حل، بستن و باز کردن فیزیکی درب لپ‌تاپ است. راهکار عادت‌گونه این است که بعد از روشن شدن صفحه یک ثانیه صبر کنند و قبل از باز کردن قفل، با ترک‌پد تعامل داشته باشند. چو اشاره کرد که این اتفاق بیشتر به‌طور ناخودآگاه رخ می‌دهد، هرچند هنوز چند بار در ماه با این باگ برخورد می‌کنند.
• خروج از اسکرین‌سیور: دنیل گیبسون به عادت استفاده از کلید Shift برای پایان دادن به اسکرین‌سیور اشاره کرد تا مطمئن شود این اتفاق باعث تحریک اثرات ناخواسته در یک برنامه فعال نمی‌شود.
• تعاملات با Codex: دنیل گیبسون همچنین عادتی را توصیف کرد که در آن یک کلید را با حداکثر سرعت فشار می‌دهد تا یک پیام صف‌بندی شده را به Codex ارسال کند و یک فراخوانی ابزار (tool call) را متوقف کند؛ این کار بازه زمانی را کاهش می‌دهد که فراخوانی ابزار تمام شود و کلید Escape کل فرآیند را متوقف کند. گیبسون ذکر کرد که از وصله‌های سفارشی مشابهی برای جریان کاری خود استفاده می‌کند، مانند یک نسخه بهینه شده از ripgrep مخصوص حجم کاری‌اش با یک کامپایلر کد بومی که عبارات منطبق را در رشته‌ای (thread) دیگر کامپایل می‌کند.

این عادت‌ها چنان عمیق می‌شوند که نامرئی می‌گردند. اما برای یک توسعه‌دهنده، این عادت‌ها نیاز به اصلاحات واقعی را ماسک می‌کنند. به همین دلیل است که «استفاده از محصول خود» (Dogfooding) اغلب ناکافی است؛ چون برنامه‌نویسان به‌طور طبیعی در دور زدن نقص‌ها مهارت دارند، به این معنی که ممکن است متوجه یک باگ نشوند صرفلاً چون در اجتناب از آن بهینه شده‌اند.

مطالعات موردی در کوری سازمانی

لو چندین مورد را برجسته می‌کند که در آن باور داخلی به کیفیت با واقعیت عینی در تضاد بود، که اغلب توسط طرفداری یا انکار حرفه‌ای هدایت می‌شد:

آموزش و مدیریت دوره‌های تحصیلی

• بلک‌بورد (Blackboard): زمانی نرم‌افزار غالب مدیریت دوره‌ها بود که به‌طور گسترده توسط دانشجویان و اساتید مورد تنفر بود. ویکی‌پدیا ذکر می‌کند که این شرکت به «یکی از منفورترین — حتی متضادترین — شرکت‌ها در آموزش» تبدیل شد. در دسامبر ۲۰۱۱، فست کمپانی گزارش داد که ۹۳٪ از پاسخ‌دهندگان به نظرسنجی مشتریان Amplicate از این شرکت «متنفرند». با این حال، لو با کارمندی از بلک‌بورد برخورد کرد که از شنیدن اینکه نرم‌افزارشان مورد تنفر است واقعاً گیج شده بود و باور داشت که این محصول به‌طور گسترده محبوب است. آن کارمند باور نمی‌کرد ادعاهای لو درست باشد، که نشان‌دهنده یک گسست کامل بین ادراک توسعه‌دهنده و واقعیت کاربر است.

عملکرد وب و جستجو

• دیسکورس (Discourse): کارکنان این نرم‌افزار تالار گفتگو معتقد بودند عملکردشان عالی است. در واقعیت، نرم‌افزار حاوی کدهایی بود که به‌طور خاص برای کند کردن بارگذاری واقعی صفحات طراحی شده بود تا در معیارهای عملکرد وب مانند Largest Contentful Paint (LCP) «تقلب» کنند. این موضوع از بهینه‌سازی فراتر رفته و به تقلب واقعی تبدیل شده بود که به کاربر آسیب می‌زد. لو اشاره می‌کند برنامه‌نویسانی که این کار را اجرا کردند باید می‌دانستند عملکرد واقعی ضعیف است، اما موانع ذهنی دور این حقیقت ساختند.
• موتورهای جستجو: لو مشاهده کرد که کاربران کاگی (Kagi)، گوگل و بینگ اغلب اصرار داشتند که نتایج جستجو باکیفیت است، حتی زمانی که نتایج به‌طور عینی پر از اسپم‌های SEO و کلاهبرداری بود. برای مثال، یک جستجوی پیش‌بینی فصلی نتوانست یک پیش‌بینی به‌روز برگرداند. برخی کاربران کاگی ادعا کردند نتایج خوب است تنها به این دلیل که گیت‌هاب را در بالای نتایج خود پین کرده بودند، که برای دانلود نرم‌افزار کار می‌کرد اما برای تمام جستجوهای دیگر شکست می‌خورد. لو این را یک مشکل «متوسط» طبقه‌بندی می‌کند؛ یک مشکل «شدید» زمانی است که موتور جستجو نیمی از اوقات خطای ۵۰۰ بدهد یا اکثریت نتایج کلاهبرداری باشند.

خودرو و ورزش

• ولوو (Volvo): لو اشاره می‌کند در حالی که داده‌های قابلیت اطمینان (و تجربه مکانیک‌ها) نشان می‌دهد قابلیت اطمینان ولوو متوسط تا ضعیف است، تالارهای گفتگوی ولوو پر از طرفدارانی است که اصرار دارند این ماشین‌ها جزو قابل‌اطمینان‌ترین‌ها هستند و داده‌ها اشتباه است. او این را به این واقعیت نسبت می‌دهد که ماشین‌ها اکنون به‌طور کلی به اندازه کافی قابل اطمینان هستند که مردم خرابی‌های مکرر را تجربه نکنند و این باعث می‌شود راحت‌تر باور کنند داده‌ها غلط هستند.
• ورزش: لو به یک بازیکن بسکتبال اشاره می‌کند که به‌طور کلی «کثیف‌ترین» بازیکن دوران خود شناخته می‌شود، به‌ویژه برای ضربه زدن به نقاط حساس (اندام تناسلی) بازیکنان دیگر. او اشاره می‌کند که این بازیکن احتمالاً رکورد بیشترین ضربه، لگد یا زانو زدن به اندام تناسلی بازیکنان در این قرن را دارد. طرفداران این بازیکن اغلب این موضوع را نادیده می‌گیرند و از عباراتی مانند «حرکت طبیعی ریباند» یا «حرکت طبیعی شوت‌زنی» برای توجیه این رفتار استفاده می‌کنند.

کوری تبلیغاتی

لو دیدگاهی از مایکل مالیس (بنیان‌گذار و مدیرعامل سابق Freshpaint) را در مورد کوری مشابه در تبلیغات اضافه می‌کند. مالیس اشاره کرد وقتی کمک‌های Freshpaint برای بازاریابی بیمارستان‌ها را توضیح می‌داد، مردم اغلب می‌پرسیدند چرا بیمارستان‌ها اصلاً بازاریابی می‌کنند. در واقعیت، بیمارستان‌ها حجم عظیمی از بازاریابی را انجام می‌دهند و بیلبوردها و تبلیغات اتوبوسی برای UCSF, Sutter Health و Stanford در سان‌فرانسیسکو رایج هستند.

لو می‌افزاید در حالی که برخی معتقدند تبلیغات کار نمی‌کند، تحلیل او از داده‌های A/B تست در شرکت‌های بزرگ خلاف این را نشان می‌دهد. او یک تست A/B بخش‌بندی شده جغرافیایی را توصیف می‌کند — که در سراسر ایالت‌های آمریکا و استان‌های کانادا انجام شد — جایی که در برخی مناطق تبلیغات خریداری شد و در برخی دیگر خیر. علی‌رغم آلودگی احتمالی ناشی از مسافران بین مرزی، بازگشت سرمایه تبلیغاتی (ROAS) از نظر درآمد مستقیم و رشد کاربر بسیار قوی بود.

نقش مدل‌های زبانی در کنترل کیفیت

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

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

هزینه کوری ارادی

وقتی تیم‌ها از کوری کیفی رنج می‌برند، آن‌ها فقط کیفیت را با سرعت معاوضه نمی‌کنند؛ بلکه باور دارند که در حال عرضه کیفیت بالا هستند در حالی که در واقع یک شکست را تحویل می‌دهند. این منجر به محصولاتی می‌شود که در لحظه عرضه «با صورت به زمین می‌خورند» چون فرآیند داخلی «استفاده از محصول خود» شکست خورده است. توسعه‌دهندگان اغلب شکایت‌های کاربران را با توضیح «یک توالی پیچیده از اتفاقات» رد می‌کنند که یک فرد عادی هرگز آن را درک نمی‌کند، یا به دستورالعمل‌هایی اشاره می‌کنند که در صفحه ۴۳ دفترچه راهنما، پس از اجرای مراحلی در پیوست صفحه ۲۶۱ دفن شده است. در برخی ابزارهای جدید، این روند به جای تحلیل سیستماتیک، به حدس‌های احتمالی در کدنویسی تبدیل شده است که می‌تواند ریسک‌های مشابهی ایجاد کند.

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

این تغییر در ادراک، تنها راه عبور از «آشغال‌های انسانی» (Human Slop) در نرم‌افزارهای تولید شده توسط هوش مصنوعی است. بدون توانایی تشخیص اینکه کیفیت می‌تواند بهبود یابد، صنعت با خطر رقابتی روبروست که در آن «کارکردی بودن» بر اساس توانایی توسعه‌دهنده در دور زدن اشتباهات خودش تعریف می‌شود.

گام بعدی شما

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

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