Код пишется быстрее, а релизы нет. Два взгляда на одну проблему

За последние дни на Хабре вышли два материала, которые стоит прочитать вместе. Один про месяц работы с coding-агентом на реальном проекте, второй — про команду, где Claude Code делает вообще всё, а инженеры работают по 12–13 часов, просто нажимая Enter. 

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

В первой статье автор месяц смотрел не на количество сгенерированного кода, а на полный цикл изменения от постановки задачи до релиза. 

Локально агент действительно быстр: протянуть новое поле через модели и сериализаторы, сделать миграцию по шаблону, обновить однотипный API-клиент — всю работу, на которую раньше уходила львиная доля времени, агент почти уничтожает.

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

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

Во второй статье противоположная крайность. Разработчик устроился в компанию, где Claude Code создаёт спецификации, код, тесты, задачи и отчёты.

Руководство требует ускорения, потому что «написание кода больше не бутылочное горлышко».
Люди работают по 12–13 часов, но по сути только нажимают Enter: никто не читает код и не исправляет баги. Цитата из статьи: «никто больше не думает. Всё делает LLM. Это так изматывает».

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

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

AI в разработке