В Apple Calculator утечка 32 ГБ оперативной памяти.

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

Двадцать лет назад это привело бы к экстренным патчам и пост-мортемам. Сегодня это просто очередной отчёт об ошибке в череде подобных.

Мы довели программные катастрофы до того, что утечка 32 ГБ оперативной памяти из Calculator едва ли попадает в новости. Дело не в ИИ. Кризис качества начался за годы до появления ChatGPT. ИИ просто превратил существующую некомпетентность в оружие.

Цифры, которые никто не хочет обсуждать

Я отслеживаю показатели качества программного обеспечения уже три года. Ухудшение не постепенное, а экспоненциальное.

Потребление памяти потеряло всякий смысл:

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

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

• Chrome: потребление 16 ГБ для 50 вкладок теперь «нормально»

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

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

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

Сбои на системном уровне стали обыденностью:

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

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

• В iOS 18 Сообщения вылетали при ответе на обложку Apple Watch, удаляя историю переписки

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

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

Шаблон катастрофы на 10 миллиардов долларов

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

Отсутствие одной проверки границ массива в одном файле конфигурации привело к сбою 8.5 миллионов компьютеров Windows по всему миру. Службы экстренной помощи оказались неэффективны. Авиакомпании приостановили полеты. Больницы отменили операции.

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

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

Одно. Отсутствующее. Поле.

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

Когда ИИ стал фактором, умножающим некомпетентность

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

Инцидент с Replit в июле 2025 года наглядно продемонстрировал опасность:

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

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

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

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

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

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

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

Генеральный директор Replit назвал это «неприемлемым». У компании $100M+ ARR.

Но реальная картина ещё более тревожная. Наше исследование показало:

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

• 45% всего кода, сгенерированного ИИ, содержит уязвимости, которые можно эксплуатировать

• Junior разработчики, использующие ИИ, наносят ущерб в 4 раза быстрее, чем без него

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

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

Физика краха программного обеспечения

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

Налог на абстракции растёт экспоненциально

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

Сегодняшняя реальная цепочка: React → Electron → Chromium → Docker → Kubernetes → VM → управляемая база данных → API-шлюзы.

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

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

Энергетический кризис уже здесь

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

Неэффективность программного обеспечения имеет реальные физические последствия:

• Центры обработки данных уже потребляют 200 ТВт·ч в год — больше, чем целые страны

• Каждое десятикратное увеличение размера модели требует десятикратного увеличения мощности

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

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

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

Вы не сможете скачать больше электричества.

364 миллиардное нерешение

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

Только в этом году:

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

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

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

• M***: 72 миллиарда долларов

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

Это не инвестиции. Это капит��ляция.

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

Распознавание шаблонов, которое никому не нужно

После 12 лет работы в сфере управления инженерными проектами эта закономерность очевидна:

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

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

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

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

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

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

Каждой инженерной организации необходимо ответить на эти вопросы:

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

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

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

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

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

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

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

Компании заменяют junior позиции ИИ-инструментами, но senior разработчики не появляются из воздуха. Они вырастают из младших разработчиков, которые:

• Отлаживают сбои в продакшене в 2 часа ночи

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

• Понимают архитектуру системы, сначала построив её неправильно

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

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

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

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

Путь вперёд (если мы хотим)

Решение несложное. Оно просто неудобное.

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

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

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

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

Повторите обучение фундаментальным принципам инженерии. Проверка границ массива. Управление памятью. Сложность алгоритмов. Это не устаревшие концепции — это основы инженерии.

Вкратце

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

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

Выживут не те компании, которые смогут превзойти кризис.

Останутся те, кто вспомнит, как работать программистом.