AI написал 1000 строк кода. Кто теперь будет их поддерживать?

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

Ещё недавно такая работа могла занять несколько часов.

Теперь она занимает минуты.

И вот здесь появляется вопрос, который почему-то обсуждают гораздо реже:

кто будет разбираться во всём этом коде через полгода?

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

Код больше не дефицит

Долгое время скорость разработки упиралась в довольно простую вещь: человек физически не может писать бесконечно быстро.

Нужно придумать решение, написать его, проверить, исправить ошибки, снова проверить.

AI эту модель сломал.

Теперь разработчик может описать задачу словами и получить большую часть реализации почти сразу. Причём речь уже не только об автодополнении отдельных строк. Современные coding agents умеют читать репозиторий, менять несколько файлов, запускать команды, исправлять ошибки и создавать pull request.

Именно поэтому проблема постепенно смещается.

GitLab в исследовании 2026 года опросил 1528 специалистов и выяснил, что 78% сообщили о более высокой скорости написания и коммита кода после внедрения AI-инструментов. При этом 85% согласились с тем, что узкое место сместилось от написания кода к его проверке и валидации.

Получается интересная ситуация.

Производительность человека выросла. Производительность самого процесса разработки - не обязательно.

Потому что после генерации кода начинается всё то, что AI не отменил.

После 1000 строк начинается настоящая работа

Допустим, AI действительно написал тысячу строк.

Что дальше?

Их нужно прочитать.

Понять.

Проверить.

Покрыть тестами.

Понять, как они взаимодействуют с остальной системой.

Посмотреть, не появилась ли лишняя зависимость.

Проверить, не сломалась ли безопасность.

Убедиться, что решение не противоречит архитектуре проекта.

И всё это по-прежнему должен делать человек.

Самое неприятное здесь в том, что тысяча строк кода создаётся гораздо быстрее, чем тысяча строк кода читается.

И это уже не теоретическая проблема.

В исследовании GitLab 85% опрошенных прямо назвали проверку и валидацию новым узким местом разработки. 84% считают главной сложностью не создание AI-кода, а управление тем, что происходит с ним после генерации.

То есть AI ускорил самый видимый этап работы - написание.

Но менее заметные этапы никуда не делись.

Более того, их становится больше.

Самая опасная ошибка - считать плохим только очевидно плохой код

Здесь легко сделать неправильный вывод.

Можно сказать: «Ну и что? Если AI пишет плохой код, просто не принимайте его».

Проблема в том, что плохой код не всегда выглядит плохим.

Он может запускаться.

Может проходить тесты.

Может решать поставленную задачу.

Может даже выглядеть очень аккуратно.

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

Так появляется то, что раньше называли техническим долгом.

Только теперь его можно накапливать значительно быстрее.

Большое исследование 2026 года проанализировало 304 362 подтверждённых AI-коммита из 6275 GitHub-репозиториев. Авторы выявили 484 606 проблем, связанных с качеством, безопасностью и поддерживаемостью кода. Более 15% коммитов от каждого изученного AI-инструмента содержали хотя бы одну такую проблему. При этом 24,2% отслеженных проблем сохранялись в последней версии репозитория.

Это не доказательство того, что AI пишет хуже человека.

И здесь важно не передёргивать.

Другие исследования показывают более сложную картину: AI-код не обязательно быстро исчезает и не обязательно чаще переписывается. В одном исследовании 201 open-source проекта AI-авторский код даже оказался менее склонен к изменениям, чем человеческий. Но характер изменений различался, а исправления всё равно в основном выполняли люди.

И это, пожалуй, важнее спора о том, кто пишет лучше.

AI уже умеет писать код, который остаётся в проекте. Значит, вопрос о его сопровождении становится только важнее.

Самое странное происходит с причиной появления кода

У любого нормального куска программы должна быть история.

Почему он здесь?

Какую проблему решает?

Почему выбрали именно этот подход?

Что сломается, если его удалить?

Обычно разработчик может хотя бы примерно ответить на эти вопросы.

Но с AI появляется другой сценарий.

Код появился потому, что разработчик написал запрос.

AI предложил решение.

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

Через год осталось только последнее звено - код.

Сам контекст потерялся.

В этом смысле AI способен создавать не только технический долг, но и долг контекста.

Код есть.

Причины его существования - уже нет.

И чем больше в проекте таких решений, тем сложнее становится поддержка.

Есть ещё одна проблема: никто не обязан помнить, что именно написал AI

Представим команду из десяти человек.

Один использует Claude Code.

Второй - Cursor.

Третий - Codex.

Четвёртый пишет всё вручную.

Через несколько месяцев код смешивается.

На GitHub не всегда очевидно, какая строка появилась благодаря AI, какая была написана человеком, а какая потом была полностью переработана.

GitLab сообщает, что 43% опрошенных не могут надёжно отличить AI-generated code от написанного человеком в собственной кодовой базе.

Это уже вопрос не только удобства.

Это вопрос ответственности.

Если через год в production появляется серьёзная ошибка, нельзя сказать:

«Это написал AI».

Сервис от этого не восстановится.

И заказчик не станет относиться к инциденту спокойнее.

Ответственным всё равно окажется человек или команда, которая приняла этот код в систему.

AI делает дешёвым именно то, что раньше хотелось делать осторожно

Мне кажется, в этом и находится главный конфликт всей истории.

Раньше дополнительный код имел цену уже в момент создания.

Разработчику нужно было потратить время.

Из-за этого многие решения просто не реализовывали.

Можно было сказать:

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

Теперь стоимость первой попытки иногда стремится к нулю.

AI может сделать её за несколько минут.

И это меняет психологию разработки.

Появляется желание говорить:

«Давайте добавим. Потом посмотрим».

Потом добавляется ещё одна функция.

Потом ещё один обработчик.

Потом небольшой сервис.

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

Каждое отдельное решение выглядит безобидно.

Проблема появляется, когда таких решений становится сотни.

AI может не превратить проект в плохой код. Он может превратить проект в слишком большой код.

И это гораздо интереснее.

В этом есть парадокс AI-разработки

Разработчик давно мечтал о том, чтобы писать код быстрее.

AI эту мечту практически исполнил.

Но оказалось, что скорость написания - не единственное ограничение.

Можно написать программу в десять раз быстрее.

Но нельзя в десять раз быстрее понять сложную архитектуру.

Нельзя в десять раз быстрее провести хорошее ревью.

Нельзя в десять раз быстрее понять, почему система ведёт себя странно в production.

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

В результате возникает то, что в GitLab называют AI paradox: индивидуальная производительность растёт, но весь процесс поставки ПО не ускоряется с той же скоростью.

Именно поэтому индустрия постепенно начинает строить инструменты уже не только для генерации.

Но и для контроля.

Для отслеживания происхождения изменений.

Для проверки.

Для автоматического ревью.

Для анализа безопасности.

Для управления действиями агентов.

Показательно, что сами платформы разработки в 2026 году начали активно двигаться именно в эту сторону: GitLab, например, добавляет инструменты для agentic code review, security review, автоматического исправления зависимостей и управления действиями AI-агентов.

То есть индустрия уже сама признаёт проблему.

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

И это меняет роль программиста

Самый популярный вопрос последних лет звучит примерно так:

«Зачем нужны программисты, если AI умеет писать код?»

На мой взгляд, вопрос поставлен неправильно.

Нужно спрашивать:

«Зачем нужен программист, если AI может написать слишком много кода?»

Потому что задача постепенно смещается.

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

И всё больше становится человеком, который принимает решения:

какую архитектуру выбрать;

что вообще нужно реализовывать;

что не нужно реализовывать;

какой результат AI можно принять;

что необходимо переписать;

где достаточно простого решения;

где нельзя доверять генерации;

какие ограничения нельзя нарушать.

То есть роль не исчезает.

Она становится менее похожей на набор текста и больше - на управление системой.

Возможно, главный навык будущего программиста - уметь удалять

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

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

Зато ценность хорошего решения растёт.

Удалить ненужный слой.

Не создать лишнюю абстракцию.

Не добавить ещё один сервис.

Не подключить новую библиотеку без необходимости.

Не оставить AI-коду существовать только потому, что он уже написан.

Раньше программистов часто подталкивали к мысли:

«Пиши быстрее».

В эпоху AI всё чаще понадобится другой навык:

«Понимай, что писать вообще не нужно».

Так кто будет поддерживать эти 1000 строк?

Ответ довольно простой.

Программисты.

Не AI и не специальный «человек, который потом во всём разберётся».

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

Только теперь таких фрагментов в проекте может стать гораздо больше.

И вот здесь AI меняет программирование действительно сильно.

Не потому, что научился писать код.

А потому, что стоимость появления нового кода резко упала.

Когда-то ограничением была способность его написать.

Теперь ограничением становится способность его понять, проверить и поддерживать.

Поэтому вопрос «AI написал 1000 строк. Кто их будет поддерживать?» на самом деле немного неправильный.

Поддерживать их будут те же люди.

Гораздо интереснее другое:

а нужно ли было писать все эти 1000 строк вообще?

Возможно, именно ответ на этот вопрос и станет одним из главных навыков программиста эпохи AI.