Когда запускают AI-инструменты для кодирования, на слайдах всегда одно число: «продуктивность ×10».
Никто не показывает второе число: насколько вырастет стоимость обслуживания?
На этой неделе на Hacker News завирусился пост — «Я возвращаюсь к ручному написанию кода». Автор не ретроград — это разработчик, принявший такое решение после использования различных AI-инструментов. 121 очко, 51 комментарий. Секция комментариев разделилась на два лагеря: одни говорят «наконец-то кто-то говорит правду», другие — «вы неправильно используете инструменты».
Обе стороны правы.
ИИ пишет код быстро, но обслуживание чужого кода — даже ИИ — никогда не было быстрым
Это не проблема 2026 года. Мир программной инженерии давно знает: чтение кода занимает гораздо больше времени, чем написание. AI усиливает это неравенство.
Когда Claude Code или Codex генерируют 500 строк кода за 30 секунд, вы экономите время на написании. Но через три месяца, когда в этом коде баг и вам нужно понять, почему он написан именно так, от каких неявных предположений зависит, повлияет ли изменение переменной на что-то ещё — ни одна секунда этого времени не была сэкономлена.
Две недооценённые стоимости
Первая: стоимость ревью. Сгенерированный ИИ код выглядит правильным — синтаксис верный, логика здравая, тесты проходят. Но он может внести ненужные абстракции, чрезмерно спроектированные паттерны или баг, срабатывающий только при определённых граничных условиях. Ревью 500 строк ИИ-кода может занять больше времени, чем написание 200 строк самостоятельно.
Вторая: стоимость разбавления знаний. Если вы позволили ИИ написать основную бизнес-логику и не прочитали её построчно — никто в вашей команде по-настоящему не «понимает» этот код. Когда возникают проблемы, никто не может интуитивно локализовать — приходится читать с нуля.
Но не спешите выбрасывать AI-инструменты
Высокооценённый ответ в комментариях HN сказал точно: «Проблема не в том, что ИИ пишет код — проблема в „бездумном принятии вывода ИИ".»
AI-агенты для кодирования действительно дают 10-кратную продуктивность в этих сценариях:
- Шаблоны: CRUD-интерфейсы, определения моделей данных, файлы конфигурации
- Рефакторинг известных паттернов: преобразование callback в async/await, class component в hooks
- Генерация тестов: создание каркаса юнит-тестов на основе существующего кода
- Документация и комментарии: дополнение сложных функций документацией
Но будьте начеку в этих сценариях:
- Основная бизнес-логика: каждое решение здесь имеет бизнес-смысл, ИИ не понимает ваш бизнес
- Критичные для производительности пути: ИИ пишет «правильный» код, не обязательно «быстрый»
- Код, чувствительный к безопасности: ИИ может пропустить проверки граничных условий или внести ненужные зависимости
Практический рабочий процесс
Мой подход в проектах: ИИ генерирует, я ревью; ИИ предлагает, я решаю.
Пусть агент напишет черновик, но перед тем как каждая строка попадёт в main, я просматриваю. Не построчно, а с вопросами: какую проблему решает этот код? Есть ли более простой способ? Будет ли коллега, который примет проект через полгода, ругаться на это?
Если ответ «не уверен» — перепишите сами.
Следующая фаза AI-кодирования
Кто-то в комментариях HN задал хороший вопрос: реальная проблема не в том, «должен ли ИИ писать код», а в том, что «мы ещё не выстроили инженерную дисциплину для управления сгенерированным ИИ кодом».
Процессы code review должны адаптироваться к AI-эре. Возможно, в будущих шаблонах PR нужно добавить поле: «Какой процент этого кода сгенерирован ИИ? Какие части вы ревьюили?»
Возможно, CI-пайплайнам нужно добавить обнаружение качества ИИ-кода — не «написан ли это ИИ», а «насколько поддерживаем этот ИИ-код».
Эта инфраструктура ещё не зрелая. Но будет, рано или поздно.
Основные источники:
- Hacker News - "I'm going back to writing code by hand" — Горячий пост HN
- James Shore - AI coding agent maintenance costs — Связанная статья