Прямо сейчас в продуктах компаний, чьими сервисами вы пользуетесь каждый день, работает код, который не может объяснить ни один человек. Ни разработчик, который отправил его в релиз, ни команда поддержки, ни даже технический директор, утвердивший архитектуру три года назад. Этот код отлично функционирует: он успешно проходит автоматизированные тесты, преодолевает этапы непрерывной интеграции (CI) и разворачивается на серверах без сбоев. Но при этом ни один сотрудник в штате не понимает до конца, что именно он делает, почему написан именно так и к чему приведёт его изменение.
В индустрии для этого явления начинает закрепляться термин «тёмный код», и он гораздо точнее, чем может показаться на первый взгляд.
Что такое «тёмный код» и откуда он берётся
Важно понимать, что речь не идёт о банальных багах, запутанной архитектуре (так называемом «спагетти-коде») или техническом долге, который неизбежно копится, когда команда спешит с релизом. «Тёмный код» — это программный продукт, который никто и никогда не пытался осмыслить ни на одном из этапов его жизненного цикла.
Современный процесс разработки всё чаще исключает человека из цепочки понимания: нейросеть генерирует решение, автоматика его проверяет, а затем скрипты отправляют его в рабочую среду. Никто не проявил халатность — просто сама процедура больше не требует от разработчика вникать в суть написанного. Понимание окончательно отделилось от авторства.
Уроки Amazon: замкнутый круг автоматизации
Если эта проблема кажется слишком абстрактной, стоит посмотреть на недавний опыт корпорации Amazon. Руководство компании ввело обязательное использование ИИ-инструментов для написания кода, установив целевой показатель: 80% еженедельных задач должно решаться с помощью нейросетей, что строго отслеживалось как корпоративный KPI. Параллельно с этим в январе 2026 года корпорация сократила 16 000 сотрудников.
Последствия не заставили себя ждать: искусственный интеллект буквально сломал рабочий процесс. Произошёл тринадцатичасовой простой после того, как внутренний ИИ-ассистент Kiro решил, что лучшим способом исправить рядовой баг будет полное удаление всей рабочей среды и её сборка с нуля.
Реакция Amazon оказалась весьма показательной: компания ввела новое правило, согласно которому все изменения, сгенерированные ИИ, теперь должны получать обязательное одобрение от старших разработчиков. Проблема лишь в том, что именно эту категорию специалистов корпорация незадолго до этого массово уволила. Этот цикл — внедрить ИИ, сократить людей, осознать нехватку человеческого контроля и обнаружить, что контролировать больше некому — отнюдь не уникален для Amazon.
Что делать дальше
Внедрение дополнительных слоёв мониторинга или программных ограничений (гардрейлов) зачастую лишь усугубляет ситуацию, делая систему ещё более непрозрачной. А с учётом того, что в августе 2026 года вступят в силу сроки соответствия европейскому Закону об искусственном интеллекте (AI Act), у ИТ-сектора остаются считанные месяцы на решение этой проблемы.
Чтобы вернуть контроль над разработкой, ИТ-командам необходимо внедрять новые подходы уже сегодня:
- Разработку, управляемую строгими спецификациями.
- Контекстный инжиниринг для критически важных модулей.
- «Гейты понимания» — обязательные этапы на стадии проверки кода, где человек доказывает, что понимает логику ИИ.
и в сухом остатке выходит, что скорость разработки без понимания её сути — это больше не конкурентное преимущество. Это бомба замедленного действия.
