#engineering #testing
Denis Stetskov у своєму пості розповідає про проблеми з якістю, з якими індустрія стикнулася ще до ШІ. Та як ШІ ці проблеми прискорює та максимізує.
В якийсь момент усім стало важливіше додавати нові фічі, ніж слідкувати за якістю та ефективністю.
🔢 Просто цифри
Сучасним системам не вистачає оперативної памʼяті. Постійно:
• Apple Calculator - 32 Gb
• VS Code - 96 Gb
• Google Chrome - 16 Gb
• MS Teams - 32 Gb
• Discord - 32 Gb (за 60 секунд показу екрану)
• Spotify - 79 Gb
Це витоки памʼяті, які не поспішають фіксити. Взагалі, багато сучасного софту випускається за принципом: релізь зараз, фікси потім. Можливо, коли буде час чи пріорітет.
Приклад CrowdStrike памʼятають усі. В чому була проблема? Система впала, тому що в файлі конфігурації було 21 поле замість 20ти. Автотести цього не помітили.
🤖 А що з приходом ШІ?
ШІ зробила усі наявні проблеми тільки гіршими та швидшими. Й додало нових задачок.
Автор наводить такі приклади:
• ШІ код має 322% більше вразливостей безпеки
• 45% вразливостей в ШІ коді можна використати
• Джуніори з ШІ спричиняють в 4 рази більше проблем ніж без ШІ
• 70% менеджерів довіряють ШІ коду більше, ніж джуніорівському
We've created a perfect storm: tools that amplify incompetence, used by developers who can't evaluate the output, reviewed by managers who trust the machine more than their people.
❗️Чому ми маємо всі ці проблеми?
1. Абстракції (фреймворки) ховають складність та додаткові витрати ресурсів за "легкістю" використання. В реальності ми маємо втрати на кожному рівні з ланцюжку в простому калькуляторі: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways.
2. Софт пишуть так, наче витрати на електроенергію та hardware нескінченні.
3. Замість того, щоб виправляти проблеми в перфомансі, гіганти АйТі просто вкидують гроші в інфраструктуру. Auto-scaling - універсальна відповідь.
Але ніхто не задає важливі запитання. Чому для нас стало прийнятно, що калькулятору треба 32 Gb памʼяті? Що якщо ми не зможемо мати більше цієї памʼяті? Що тоді?
🤓 Додаткові проблеми з джуніорами
З приходом ШІ компанії викреслюють джунів з розробки. Немає джунів сьогодні - немає сіньйорів завтра - нікому буде фіксити, коли ШІ зламає щось. Я писав про це вже не раз у цьому каналі.
"Ми створюємо покоління розробників, які можуть написати промти, але не вміють дебажити; які можуть генерувати, але не можуть проектувати; які можуть доставляти продукти, але не можуть його підтримувати"
⭐️ Чи існує рішення?
Денис пропонує наступне:
• Прийняти, що якість важить більше ніж швидкість релізу.
• Міряти використання ресурсів, а не тільки кількіcть фічей.
• Відзначати інженерів, які зменшують використання ресурсів, а не збільшують.
• Обережно підходити до використання абстракцій (фреймворків)
• Вчити фундаментальні базові концепції з компʼютерних наук.
Рішення слушне. Але чи готова до цього індустрія? Я думаю, що ні.
