ИИ сделал код дешёвым.
Не бесплатным. Не правильным. Не пригодным к сопровождению. Просто дешёвым.
Это не мелочь. Долгое время разработка упиралась в простую механику: чтобы появился код, кто-то должен был набрать его руками. Теперь правдоподобная правка прилетает из автодополнения, чата, среды разработки с агентами или от небольшой команды агентов быстрее, чем ты успеваешь придумать приличный ответ на «ну что там по задаче?»
Сначала это очень похоже на продуктивность: всё появляется быстрее — код, текст, пулреквесты и бодрое ощущение «у меня работает».
Но софт никогда не был просто текстом в репозитории. Текст — только видимая часть. Дорого обходится всё вокруг: разобраться в системе, принять компромиссы, проверить редкие сбои с дорогими последствиями, сохранить замысел и через полгода безопасно всё поменять, когда уже никто не помнит, почему finalFinal2.ts вообще пропустили через ревью.
ИИ эти расходы не отменяет. Он просто переносит их в другое место.
Правка — не финиш
Представь: агент за пять минут написал то, на что у тебя ушёл бы час. Приятно. Красиво. Кажется, Jira должна выдать медальку «молодец, нажал кнопку».
А потом приходят настоящие вопросы.
Кто понимает, почему решение получилось именно таким? Кто проверил, что оно не ломает систему в скучном месте, где поломка стоит дорого? Кто объяснит его через три месяца? Кто отвечает за него, когда контекст уже потерян? Кто платит, если правдоподобный ответ оказался неверным?
Спорить о том, умеет ли ИИ писать код, уже скучно. Умеет. Гораздо интереснее, чего теперь начинает не хватать. Когда генерация дешевеет, узким местом становятся ревью, тесты, архитектура, фиксация замысла и доверие.
Дешёвый код — не то же самое, что дешёвый софт. Сгенерированная правка — начало. Иногда отличное. Но у реальности обычно своё мнение и плохое настроение.
Ощущение скорости — паршивая метрика
Исследование METR начала 2025 года отрезвляет: шестнадцать опытных разработчиков открытого ПО работали над 246 настоящими задачами в зрелых проектах, которые хорошо знали. До эксперимента они ждали ускорения на 24%. После эксперимента им всё ещё казалось, что ИИ ускорил их примерно на 20%.
Замеры показали другое: задачи с ИИ заняли на 19% больше времени.
Не стоит высекать на камне вывод «ИИ замедляет разработчиков». Контекст важен: инструменты начала 2025 года, опытные разработчики, зрелые кодовые базы и высокая планка качества. Более поздние заметки METR осторожнее: эффект, похоже, улучшается, но измерять его становится труднее, потому что разработчикам уже не нравится, когда их заставляют работать без ИИ. Понимаю. После бензопилы нож для масла кажется издевательством.
Полезный вывод скучнее, а значит, вероятно, полезнее: субъективная скорость — не продуктивность.
ИИ помогает не застрять перед пустым файлом. Он предлагает варианты, набрасывает каркас и не даёт задаче закиснуть. Но итоговый эффект зависит от интеграции, нагрузки на ревью, тестов, знания кодовой базы, качества задачи и человека, который в итоге отвечает за результат.
«Ускоряет ли ИИ программирование?» — слишком рыхлый вопрос. Лучше спросить, дешевле ли с ним менять софт на всём пути: от идеи до сопровождения.
У долга появились новые трюки
Технический долг был и раньше: кривые абстракции, баги, проблемы безопасности, запутанный код и все мелкие счета, которые твоему будущему «я» придётся оплатить с процентами.
ИИ выписывает новые счета.
Когнитивный долг возникает, когда система растёт быстрее, чем общее представление команды о ней. Кода становится больше. Понимания — не факт. Карта уже устарела, а картографы всё ещё на созвоне.
Долг замысла — это код без ответа на вопрос «почему так?». Цель, ограничения, отвергнутые варианты и допущения остаются в чат-логе, а иногда не остаются нигде. Будущий мейнтейнер видит правку, но не может восстановить, почему решение получилось именно таким.
Долг понимания тоньше: рабочее решение есть, а понимания, как его отладить, объяснить или повторить самому, не прибавилось. Это особенно опасно для новичков, но не только для них. Сеньоры тоже умеют отдавать обучение на аутсорс. Просто с более приличными именами переменных.
Исследование о когнитивном долге и долге замысла называет то, что многие команды уже чувствуют. В Debt Behind the AI Boom исследователи изучили коммиты, подтверждённо написанные ИИ, и нашли сотни тысяч замечаний статического анализа, в основном признаки проблемного дизайна кода. Статический анализ грубоват, но от сигнала трудно отмахнуться: дешёвая генерация может просто сдвигать стоимость сопровождения дальше по цепочке.
Исследование о том, как новички учатся программировать, показывает тот же механизм в учебной среде. Когда ИИ давали без ограничений, участники быстрее получали работающий результат, но позже, уже без ИИ, заметно хуже справлялись с задачами на сопровождение. А когда ИИ использовали как учебную опору и просили участников объяснять происходящее своими словами, провал стал меньше.
Механизм, по-моему, простой. Если ИИ работает как подрядчик, задача закрыта, но человек мог ничему не научиться. Если ИИ работает как наставник, критик и ревьюер, человек учится быстрее.
Я держу в голове: у каждой задачи два результата. Внешний — код, документ, правка, закрытый тикет. И внутренний — что я теперь могу объяснить, диагностировать и повторить без инструмента. ИИ по умолчанию оптимизирует первое. Второе нужно защищать.
Счёт приходит при сопровождении
У Джеймса Шора есть жёсткий практический тест: нужен ИИ, который снижает стоимость сопровождения.
Звучит не так захватывающе, как «разработчик в 10 раз продуктивнее», зато именно это решает, выдержит ли магия встречу с настоящей кодовой базой. Если ИИ удваивает выпуск кода, но каждое следующее изменение становится чуть дороже, выигрыш быстро испаряется. Кодовая база и без того умеет выписывать счета в будущее. Кормить её всё большим количеством кода при всё меньшем понимании — не ускорение. Это долг, который потом придётся обслуживать.
Хороший процесс с ИИ не заканчивается кодом. После него остаются доказательства.
От агента я хочу обоснование решения, явные допущения и хотя бы один отвергнутый вариант, если выбор неочевиден. Тесты должны проверять сценарии поломки, а не только удачный демо-сценарий, где сегодня всё совпало. Ревью должно выяснять, понятен ли замысел, а не только замолчала ли проверка стиля. Важные решения должны попадать туда, куда команда потом действительно вернётся: в документы, в AGENTS.md, в заметки о решениях, в историю задачи или в любое другое место, которое откроют, когда проблема проявится в продакшене.
После мёржа команда должна понимать систему лучше, чем до него. Если код изменился, а понимания не прибавилось, это не бесплатная скорость. Это счёт с отсрочкой.
Опенсорс показывает, кто платит
В опенсорсе особенно хорошо видно, на кого ложатся эти расходы.
Когда создавать тикеты и пулреквесты с помощью ИИ становится дёшево, мейнтейнеры расплачиваются вниманием. Пост Дэниела Стенберга о закрытии программы вознаграждений за уязвимости в curl на HackerOne был не о том, что «мы теперь ненавидим отчёты о безопасности», а об отказе от стимула, который плодил слишком много малоценного шума. Мейнтейнеры Godot описывали похожую проблему с пулреквестами, написанными ИИ: они могут выглядеть достаточно правдоподобно, чтобы забрать время на ревью, хотя автор может не понимать правку или не проверять её.
Так ломается доверие.
Мейнтейнер теперь спрашивает не только о том, корректен ли код. Он спрашивает: «Есть ли за этой правкой ответственный автор?» Автор должен понимать последствия, отвечать на замечания и не бросать работу, как только прошёл первый азарт от промпта.
Та же закономерность видна в исследовании пулреквестов, написанных с ИИ. Менее опытные контрибьюторы с ИИ присылали более крупные пулреквесты и получали намного больше замечаний на ревью; такие пулреквесты реже принимали и дольше держали открытыми. Это не повод отгонять новичков от ИИ. Это напоминание: ИИ даёт людям возможность генерировать код гораздо быстрее, чем они учатся отвечать за результат.
ИИ помогает человеку генерировать больше кода. Но вкус, контекст, сдержанность и умение смотреть на систему целиком в комплекте не идут. Увы, npm install experience всё ещё недоступен.
Ответ — обвязка, а не запрет
Я не думаю, что решение — избегать ИИ. Запрещать его из-за этих рисков — как запрещать погрузчики, потому что ими можно кого-то задавить.
Мой ответ скучный: сделать скрытые расходы видимыми.
Агенту нужна обвязка: ясные инструкции, ограниченные инструменты, права доступа, маленькие задачи, проверяемый результат, проектный контекст, память, правила передачи контекста и явные критерии готовности. Скучно? Да. Зато это разница между «ассистентом» и «джуном с доступом к командной строке и подозрительной уверенностью».
То, что теперь называют инженерией контекста, по сути становится обычной инженерией софта. AGENTS.md, CLAUDE.md, локальные заметки, проектные соглашения, команды тестов, права доступа и описания инструментов — уже не просто документация. Во время работы агент читает их как входные данные, поэтому качество контекста напрямую влияет на качество результата.
Личные заметки и проектные документы перестают быть архивом. Они становятся панелью управления.
Когда у агентов появляются инструменты, это уже не вопрос удобства чата. Текстовый ассистент может ошибиться так, что тебя это взбесит. Агент, который читает файловую систему, запускает команды в терминале, открывает пулреквесты, вызывает MCP-серверы или трогает внешние системы, ошибается уже не в чате, а в реальной системе — с последствиями. Инъекция промпта в таком мире — не смешной фокус с чатботом, а класс уязвимостей.
В какой-то момент агент перестаёт быть автодополнением и становится участником инженерной системы. Участников нужно вводить в контекст; им нужны права доступа, тесты, ревью и пути отката.
Новые дорогие части
Так что да: ИИ сделал код дешёвым. Это правда. Это полезно. Мне нравится. Я сам постоянно этим пользуюсь.
Но клавиатура никогда не была главной статьёй расходов.
Дефицит теперь не в синтаксисе. Дефицит — в обоснованной уверенности: мы знаем, что должно существовать; проверили, что оно действительно работает; сохранили ответ на вопрос «почему»; можем безопасно внести следующее изменение; доверяем коду настолько, чтобы не тратить день на реверс-инжиниринг машинной самоуверенности.
Перед тем как мёржить правку, написанную ИИ, я хочу понимать: какую проблему она решает; почему выбран этот подход; на каких допущениях он держится; как мы проверили, что он работает; что всё ещё может сломаться; смогу ли я потом восстановить замысел, не перечитывая чат-лог на 40 тысяч токенов под названием «быстрая правка».
Для меня тест вот в чём.
Не в том, стало ли дешевле печатать.
А в том, стало ли дешевле менять софт.
