Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

Эта память не используется, не выделяется, она просто утекает. Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад.

Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.

Для нас стали нормой программные ошибки такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Числа, о которых предпочитают молчать

Я мониторил метрики качества ПО в течение трёх лет и могу сказать, что деградируют они не постепенно, а экспоненциально.

Потребление памяти утратило всякую значимость:

• VS Code: утечка 96 ГБ через SSH-подключения.

• Microsoft Teams: 100% загрузка процессора на машинах с 32 ГБ памяти.

• Chrome: расход 16 ГБ на 50 вкладок теперь «норма».

• Discord: потребление 32 ГБ RAM в результате 60 секунд демонстрации экрана.

• Spotify: потребление 79 ГБ в macOS.

И это не функциональные требования. Всё это утечки памяти, которые никто не стал заморачиваться устранять.

Сбои системного уровня стали рутиной:

• обновления Windows 11 регулярно приводят к отказу меню «Пуск»,

• инструмент macOS Spotlight за ночь записал на SSD 26 ТБ (на 52 000% больше нормы),

• приложение Messages в iOS 18 падало при обращении к нему через циферблат Apple Watch и удаляло истории бесед,

• Android 15 был выпущен с 75+ известными критическими уязвимостями.

То есть паттерн налицо: поставим кривое, исправим потом. Может быть.

Схема катастрофы ценой в $10 миллиардов

Инцидент с CrowdStrike, произошедший 19 июля 2024 года, является прекрасным примером некомпетентности, ставшей нормой.

Отсутствие одной проверки выхода за границу массива в одном файле конфигурации привело к падению 8,5 миллионов ПК под управлением Windows по всему миру. Это, в свою очередь, вызвало сбой в работе аварийных служб, экстренную посадку самолётов и отмену операций в больницах.

Общий экономический ущерб составил минимум 10 миллиардов долларов.

В чём была причина? В программе ожидалось 21 поле, а было получено 20.

Одно. Недостающее. Поле.

И ведь ничего сложного. Просто не была реализована базовая обработка ошибок. Причём это ПО прошло весь пайплайн развёртывания.

Когда ИИ стал усилителем некомпетентности

К моменту появления ИИ-ассистентов качество ПО уже летело вниз, так что последующее развитие событий предсказать было несложно.

Инцидент с Replit в июле 2025 года окончательно подтвердил угрозу:

1.   Джейсон Лемкин дал ИИ прямое указание: «НИКАКИХ ИЗМЕНЕНИЙ без разрешения».

2.   ИИ встретил то, что ему показалось пустыми запросами к базе данных, после чего…

3.   «Запаниковал» (с его собственных слов) и выполнил деструктивные команды.

4.   Удалил всю базу данных рабочей среды SaaStr (1 206 руководителей, 1 196 компаний).

5.   Сфабриковал 4 000 левых профилей пользователей, чтобы скрыть удаление.

6.   Соврал, что восстановление «невозможно» (хотя было не так).

Позже ИИ признал: «Это была катастрофическая ошибка с моей стороны. Я нарушил прямые инструкции, уничтожил месяцы работы и сломал систему в период заморозки кода». Источник: The Register

Генеральный директор Replit назвал это «неприемлемым». Средний годовой доход компании составляет 100+ миллионов долларов.

Но реальный паттерн ещё более пугающий. Один исследователь выяснил, что:

• сгенерированный ИИ код содержит на 322% больше уязвимостей безопасности.

• 45% всего сгенерированного ИИ кода включает эксплуатабельные дыры.

• джуниоры при использовании ИИ в 4 раза быстрее наносят вред, чем без него.

• 70% рекрутёров доверяют выдаче ИИ больше, чем коду, написанному джуниором.

Мы создали прекрасный контекст для катастрофы: инструменты, которые усиливают некомпетентность, используемые разработчиками, которые не могут оценить их выдачу, и проверяемые менеджерами, которые доверяют машине больше, чем людям.

Физические следствия упадка качества

Отмечу факт, который лидеры индустрии разработки не хотят признавать: у программного обеспечения есть физические ограничения, и мы упираемся в них все одновременно.

Издержки абстрагирования растут экспоненциально

Современное ПО создаётся на основе абстракций, каждая из которых «упрощает» процесс за счёт лишних издержек:

Вот вам реальная цепочка разработки: React → Electron → Chromium → Docker → Kubernetes → VM → управляемая DB → API-шлюзы.

Каждый слой привносит «всего-то 20–30%». Наложите поверх друг друга несколько таких, и вы получите в 2–6 раз больше издержек на реализацию того же самого поведения.

Именно из-за этого возникла утечка в калькуляторе 32 ГБ. Не потому, что кто-то так захотел, а потому, что никто не замечал накопления издержек, пока пользователи не начали жаловаться.

Энергетический кризис уже наступил

Мы притворялись, что электричество бесконечно. Но это не так.

Программная расточительность оказывает реальное влияние на физический мир:

• Дата-центры уже потребляют 200 ТВт-ч ежегодно — больше, чем целые страны.

• Каждое 10-кратное увеличение размера модели требует в 10 раз больше энергии.

• Требования к охлаждению с каждым поколением аппаратных устройств удваиваются.

• Электросети не успевают расширяться — новые подключения занимают от 2-х до 4-х лет.

Суровая реальность такова, что мы пишем ПО, которое требует больше электричества, чем мы можем генерировать. Прогнозируется, что к 2027 году 40% дата-центров столкнутся с ограничениями возможностей электросетей. И тогда уже будет неважно, какой там у вас венчурный капитал.

Скачать дополнительное электричество не получится.

Псевдо-решение за $364 миллиарда

Вместо того, чтобы решать фундаментальные проблемы с качеством ПО, представители бигтеха решили пойти самым дорогим путём: вбросить деньги в инфраструктуру.

Вот суммы только за этот год:

• Microsoft: $89 миллиардов.

• Amazon: $100 миллиардов.

• Google: $85 миллиардов.

• Meta: $72 миллиардов.

Они тратят 30% своего дохода на развитие инфраструктуры (традиционно эта доля составляла 12,5%). Тем временем рост облачной доходности замедляется.

И это не инвестиция, это капитуляция.

Когда вам требуется вложить $364 миллиарда в железо, чтобы использовать ПО, которое и так должно работать на имеющихся машинах, вы уже не масштабируете — вы компенсируете фундаментальные инженерные ошибки.

Удручающий паттерн

Спустя 12 лет управления разработкой, я выделил безошибочный паттерн:

Этап 1: Отрицание (2018–2020) «Память дешёвая, оптимизация дорогая».

Этап 2: Нормализация (2020–2022) «Всё современное ПО использует эти ресурсы».

Этап 3: Ускорение (2022–2024) «ИИ решит наши проблемы продуктивности».

Этап 4: Капитуляция (2024–2025) «Мы просто построим больше дата-центров».

Этап 5: Коллапс (не за горами). Физические ограничения не перекрыть венчурным капиталом.

Неудобные вопросы

Любой организации, занятой разработкой, нужно ответить на следующие вопросы:

1. Когда мы согласились, что утечка 32 ГБ памяти в приложении калькулятора — это нормально?

2. Почему мы доверяем коду, сгенерированному ИИ, больше, чем молодым разработчикам?

3. Сколько слоёв абстракции реально необходимо?

4. Что произойдёт, когда мы больше не сможем перекрывать издержки денежными вливаниями?

И ответы на них покажут, создаёте вы устойчивые системы, или же вкладываетесь в эксперимент по проверке того, сколько железа можно бросить на компенсацию плохого кода.

Кризис кадровых конвейеров, который никто не хочет признавать

Вот вам самое разрушительное долгосрочное последствие: мы избавимся от конвейера подготовки джуниоров.

Компании уже замещают позиции джуниоров инструментами ИИ, но ведь сеньоры не падают с небес. Они как раз вырастают из джуниоров, которые:

• отлаживают сбои в 2 ночи,

• узнают, почему эта «грамотная» оптимизация всё ломает,

• начинают понимать системную архитектуру, изначально допуская ошибки при её создании,

• вырабатывают интуицию на тысячах мелких сбоев.

Если джуниорам негде будет получать реальный опыт, откуда должно вырасти следующее поколение старших разработчиков? ИИ не может учиться на своих ошибках — он не понимает, почему что-то дало сбой. Он лишь делает сопоставление с известными ему паттернами обучающих данных.

Мы создаём потерянное поколение разработчиков, которые могут писать промпты, но не умеют делать отладку; которые способны генерировать, но не проектировать; которые могут создавать, но не могут обслуживать.

И выводы очевидны: уберём джуниоров сегодня = лишимся сеньоров завтра = некому будет исправлять то, что сломает ИИ.

Возможный выход (если мы его хотим)

Решение здесь не такое уж сложное, просто неудобное.

Нужно принять, что качество важнее скорости. Выпускайте продукты медленнее, но рабочими. Гораздо дешевле сделать сразу как следует, чем исправлять крупные сбои в продакшене.

Оценивайте фактическое потребление ресурсов, а не реализованную функциональность. Если ваше приложение использует в 10 раз больше ресурсов, чем в прошлом году при той же функциональности, то это регресс, а не прогресс.

Мотивируйте сотрудников на эффективность. Награждайте тех, кто сокращает потребление ресурсов, и штрафуйте тех, кто делает обратное без внесения соответствующей ценности.

Прекратите прятаться за слоями абстракций. Каждый слой между вашим кодом и железом может украсть до 20–30% производительности. Делайте выбор вдумчиво.

Напоминайте сотрудникам о фундаментальных принципах разработки. Проверка на выход за границы массива, управление памятью, алгоритмическая сложность — всё это нисколько не устарело и до сих пор является основой.

Выводы

Мы проживаем величайший программный кризис за всю историю вычислительной техники: приложение калькулятора допускает утечку 32 ГБ памяти, ИИ-ассистенты удаляют целые базы данных в продакшене, а компании при этом тратят бешеные суммы в миллиардах долларов, лишь бы не исправлять фундаментальные проблемы.

Так продолжаться не может. Физика не идёт на компромиссы. Энергия конечна. У оборудования есть предел возможностей.

И выживут в итоге не те, кто планирует перекрыть этот кризис деньгами, а те, кто ещё помнит, как правильно вести разработку.

Если вам эта статья откликается, отправьте её руководителям отделов разработки, для которых эта информация важна. Порой избежание реальной проблемы является самым дорогим решением.