AI-программирование множит техдолг: два процесса, которые возвращают контроль над кодом

Тема всплыла в обсуждении на HackerNews, где разработчики описали два повторяющихся сценария. Первый: то, что раньше делали сто инженеров за пять лет, пять человек с ИИ собирают за полгода, но получают устаревший, запутанный код с первого дня. Второй: когда 99 % изменений генерирует ИИ, команда теряет понимание собственного проекта и работает с ним как с чужим. Хахалев отмечает, что к середине 2025 года обе проблемы он считал решёнными, однако практика показывает обратное. Ниже его подход, переложенный на язык, понятный не только разработчикам.

Почему построчное чтение кода больше не спасает?

Хахалев описывает ловушку, в которую попадают разработчики:

• Привычка к «владению» кодом мешает. Раньше человек знал проект, потому что писал его сам. Теперь код пишет ИИ-агент (автономная программа, выполняющая задачи без пошаговых команд), а человек пытается всё прочитать и проверить. К концу дня голова «ватная», качество проверки падает.
• Две крайности одинаково вредны. Одни «насилуют мозг», пытаясь угнаться за машиной. Другие перестают читать код вообще и слепо доверяют ИИ. Оба пути ведут к потере контроля.
• Корень проблемы не в ИИ, а в отсутствии планирования. Большинство разработчиков не выполняют работу технического менеджера: не формулируют задачу, критерии приёмки и способ проверки до того, как агент начнёт писать код.

Детальное ТЗ вместо тотальной вычитки

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

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

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

• Модель данных (структура, в которой хранится информация).
• Миграции базы данных (изменения в структуре хранилища, которые нельзя откатить без потерь).
• Биллинг (всё, что связано с деньгами пользователей).

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

Автоматическое ревью по расписанию: как настроить?

Второй инструмент, cron-задача (автоматический запуск по расписанию) с ИИ-агентом, который сам ищет проблемы в коде раз в неделю.

1. Опишите «скилл» для агента. В инструкции укажите: изучить коммиты (зафиксированные изменения) за последнюю неделю, сопоставить их с задачами в трекере (например, Jira) и найти так называемые code smells (признаки плохого кода, который работает, но создаёт проблемы в будущем).
2. Разверните Codex на сервере. Поставьте агента на VPS (виртуальный сервер) и настройте обычный cron, который запускается раз в неделю. В промпте (текстовой инструкции для модели) укажите созданный скилл.
3. Обогащайте скилл вручную. На начальном этапе раз в неделю проходите по репозиторию сами, в том числе вместе с ИИ-агентами, и дополняйте инструкцию примерами: как должно быть и как быть не должно.

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

Что делать, когда «прод упадёт»?

Хахалев честно предупреждает: детальное ТЗ не закрывает сто процентов пограничных случаев. Продакшен может упасть, но это происходило и до AI-кодирования. Если в команде нет отлаженного мониторинга, алертинга (оповещения об ошибках) и процедуры восстановления, то это проблема процессов, а не ИИ.

Сравнение: что доступно в России?

Для AI-кодирования в РФ пока нет прямого аналога Codex, который можно развернуть на своём сервере с полной автономией. Однако задачу частично закрывают:

• YandexGPT и GigaChat: обе модели умеют анализировать и генерировать код, но не работают как автономные агенты с доступом к репозиторию «из коробки».
• Для автоматического ревью по расписанию можно собрать связку из открытой модели (например, моделей с открытыми весами) и скрипта на сервере, но это потребует ручной настройки.

Подход Хахалева с детальным ТЗ не зависит от конкретного инструмента: он работает с любым ИИ-кодером, доступным в вашем регионе.

Что с этого прямо сейчас, по ролям?

Разработчику или техлиду. Перестаньте читать каждую строку сгенерированного кода. Вместо этого потратьте время на подробное ТЗ до генерации: архитектура, скелет решения, список тестов, критерии приёмки. После работы агента проверяйте только критичные точки.

Автору Дзена или контент-мейкеру. AI программирование затрагивает не только код. Если вы используете ИИ для генерации текстов, логика та же: чем точнее промпт, тем меньше «мусора» на выходе и тем меньше времени уходит на вычитку. Подход «детальное ТЗ вместо тотальной проверки» переносится на любую генерацию.

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

Частые вопросы

Обязательно ли владеть программированием, чтобы применить эти советы?

Подход с детальным ТЗ подходит любому, кто ставит задачи ИИ, будь то код, тексты или изображения. Но настройка cron-ревью требует технических навыков: развернуть сервер, написать скрипт запуска, сформулировать скилл. Без разработчика в команде эту часть не внедрить.

Можно ли полностью доверять ИИ-агенту проверку кода?

Нет. Хахалев прямо пишет, что агент не закроет все пограничные случаи. Его задача: находить типовые проблемы и создавать задачи на исправление. Финальное решение и проверка критичных мест (данные, деньги, миграции) остаются за человеком.

Работает ли этот подход с инструментами, доступными в России?

Да, частично. Детальное ТЗ перед генерацией не привязано к конкретной модели. Автоматическое ревью по расписанию можно собрать на открытых моделях, но готового решения «из коробки» для российского рынка пока нет.