Habr AI: генерация кода меняет роль разработчика — меньше рутины, больше архитектуры

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

Разработчик как редактор

Отправной точкой стал практический эксперимент: автор попробовал собрать почти целый сервис через генерацию кода, поручив модели API, базу данных и обработчики. На этом фоне привычная схема «сел и написал» быстро ломается. Разработчик всё чаще не печатает контроллеры и SQL вручную, а задаёт структуру, ограничения и ожидаемое поведение, после чего получает черновик системы.

Работа смещается на уровень выше: от реализации каждой функции — к описанию задачи и последующему редактированию результата. Это меняет и то, где теперь тратится время. Если раньше основная энергия уходила на написание кода, то при массовом использовании генераторов главным узким местом становится понимание того, что именно получилось на выходе.

Чужой код всегда был дорогим в сопровождении, а AI делает его ещё более «чужим», даже если он создан по твоему запросу. Автор формулирует это предельно прямо: > «Время написания кода почти исчезает. Но время понимания кода наоборот растёт».

Архитектура и дебагинг

Вторая важная мысль колонки — код сам по себе перестаёт быть главным дефицитом. Сгенерировать endpoint, CRUD-операцию или типовой сервис сегодня уже не проблема. Куда сложнее решить, как должна быть устроена система в целом, чтобы этот код не развалился через полгода.

Именно поэтому на первый план выходит архитектура: модель может выдать рабочий фрагмент, но редко берёт на себя ответственность за долгосрочную связность проекта, стоимость изменений и эксплуатационные риски. В практическом плане это означает, что разработчик всё чаще отвечает не за каждую строку, а за набор системных решений: где и в каком виде хранятся данные как масштабируется сервис под рост нагрузки как устроены кэширование и data pipeline как согласованы стили, шаблоны и границы модулей * как проверяются логические ошибки в сгенерированном коде Отсюда вырастает и новая цена дебага. В колонке приводится показательный пример с функцией нормализации, которая на вид выглядит нормально, но при отрицательном значении возвращает 0.

5 вместо 0. Такие ошибки особенно неприятны: синтаксис чистый, структура аккуратная, тестов может не хватать, а логическая проблема прячется в одной строке. Когда код написан не тобой, найти источник сбоя сложнее ещё и потому, что у тебя нет авторской памяти о том, как принималось решение.

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

Отсюда прогноз автора: следующим большим рынком могут стать не генераторы кода, а инструменты, которые умеют анализировать, объяснять и приводить к порядку код, написанный ИИ.

Что это значит

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