До 80% типовых задач в своей работе Илья Благородов уже отдает ИИ-инструментам, но называет это не концом профессии, а сменой ее фокуса. Для тех, кто работает с продуктами, кодом и командами, история про ИИ в разработке звучит довольно приземленно: рутины меньше, ответственности не меньше.
Об этом Благородов, разработчик с 30-летним опытом и эксперт онлайн-магистратуры ИТМО и Яндекс Практикума, пишет в колонке, сообщает Habr / Карьера. По его словам, за последние полгода его рабочий процесс заметно изменился: почти каждый день он использует Cursor и Claude Code, а раньше подключал ChatGPT скорее точечно, чтобы сгенерировать функцию, разобраться с ошибкой, собрать регулярное выражение или быстро проверить гипотезу. С февраля 2026 года, пишет он, роль таких инструментов стала куда шире: ИИ берет на себя CRUD-обработчики, бизнес-логику по заранее описанному алгоритму, тесты, документацию, прототипы интерфейсов, админ-панели и конфигурации.
Главный тезис автора сводится к вещи, которую рынок пока не очень любит формулировать без лишнего пафоса: писать код и программировать — не одно и то же. Код можно сгенерировать. Программирование остается работой по постановке задачи, проверке ограничений, оценке последствий, стыковке с существующей архитектурой и контролю результата. Именно поэтому, по наблюдению Благородова, он стал писать меньше кода, но программировать при этом больше. Машина снимает часть механической нагрузки, а человеку приходится сильнее думать о системе целиком. Для русскоязычной IT-аудитории это важный сдвиг: рынок, похоже, начинает платить не просто за скорость набора строк, а за способность удерживать логику проекта в голове, когда строки уже набирает кто-то другой.
Отдельно автор разводит два модных сюжета, которые часто смешивают в один. Первый — вайбкодинг, когда с помощью ИИ быстро собирают MVP, лендинг или демонстрационный сервис, не особенно вникая в устройство системы. Такой режим он не демонизирует: для проверки идеи это рабочий подход. Проблемы начинаются позже, когда временную конструкцию пытаются выдать за промышленный продукт. Благородов приводит пример проекта с нетривиальным функционалом, который владелец компании собрал таким способом, а потом передал на интеграцию с существующей системой. В итоге значительную часть пришлось переделывать, а часть возможностей — отключать, чтобы вообще подключить решение к API основного продукта. Второй сюжет — агентная разработка, где ИИ выступает не магической кнопкой, а исполнителем отдельных подзадач под контролем инженера. В этой модели инструмент полезен, но без постоянной проверки быстро накапливает в проекте бойлерплейт, дублирование и случайные архитектурные решения.
Сравнение с IDE здесь тоже не случайно. Благородов напоминает, что когда-то и автодополнение, и рефакторинг по кнопке, и навигация по проекту вызывали подозрение: мол, настоящий разработчик так не работает. Теперь это выглядит почти музейной дискуссией. Его мысль в том, что ИИ в разработке продолжает ту же линию автоматизации, только на другом уровне. IDE подсказывала метод, ИИ может предложить сервис. IDE помогала перемещаться по коду, ИИ собирает контекст и выдает первичный план изменений. Но принцип не изменился: инструмент не несет юридическую, техническую и репутационную ответственность за решение. Если в продакшн ушел плохой код, это не «ошибка нейросети», а решение команды или конкретного разработчика, который этот код принял.
При этом автор не пытается продать читателю сказку о полном контроле над машиной. Он довольно трезво перечисляет, где ИИ в разработке уже действительно силен, а где пока опасен. Хорошо формализуемые и рутинные задачи — его территория: генерация CRUD, тестов, документации, SQL, регулярных выражений, конфигов для деплоя, мелких функций, типовых исправлений, рефакторинга и простых интерфейсных прототипов. Особенно полезной Благородов считает способность быстро разбираться в большом объеме кода и строить стартовый план изменений. Для команды это экономия не только времени, но и ментальной энергии: меньше ручного поиска по файлам, меньше потерь на переключение контекста. Но как только задача упирается в сложную бизнес-логику и архитектуру большой системы, у ИИ начинаются проблемы. Он может предложить локально рабочее решение, которое при этом ломает стиль проекта, дублирует существующие абстракции, обходит принятые паттерны или добавляет новую параллельную логику рядом со старой. На ревью это иногда выглядит убедительно: все разложено по папкам, в коде мелькают знакомые слова вроде service, repository, DTO или middleware, а системного понимания под капотом нет.
Отсюда и практический вывод, который в 2026 году звучит куда полезнее разговоров о «замене программистов». Чем сложнее задача, тем подробнее разработчику приходится описывать контекст: бизнес-логику, архитектурные ограничения, структуру базы данных, допустимые и недопустимые подходы, набор файлов для изменений, существующие решения в проекте, ожидаемые тесты. То есть с ростом возможностей инструмента растут и требования к квалификации человека, который им пользуется. Для бизнеса это значит, что экономить на сильных инженерах в эпоху ИИ в разработке вряд ли получится: слабый специалист с мощным ассистентом быстрее производит не только код, но и технический долг. Для тимлидов и CTO вывод еще прозаичнее: процессы ревью, архитектурные стандарты и требования к качеству никуда не исчезли, просто теперь скорость поступления сомнительных решений в репозиторий стала выше.
Если этот взгляд и отличается от рекламного образа «разработчика будущего», то как раз в полезную сторону. Рынок, похоже, движется не к исчезновению профессии, а к ее пересборке: ручного кода будет меньше, а цена инженерного мышления, насмотренности и ответственности — выше. Вопрос уже не в том, будет ли ИИ писать куски системы, а в том, кто в команде сможет удержать границы между быстрым прототипом и продуктом, который не развалится на первом серьезном изменении.