Руководитель отдела разработки на 30 человек провёл двухнедельный эксперимент с AI-first разработкой и получил результат, который для бизнеса выглядит соблазнительно, а для инженерной команды — тревожно: задача формально закрыта, но кодовая база, по его оценке, более чем наполовину состоит из мёртвого кода. Для русскоязычной IT-аудитории это важный сигнал: искусственный интеллект пока не отменил профессию разработчика, зато резко повысил терпимость рынка к плохой архитектуре, хрупким решениям и деградации навыков.
Об этом как пишет Habr / Карьера рассказал бывший руководитель разработки, который описал не абстрактные страхи вокруг нейросетей, а конкретный кейс из собственной практики. Его главный тезис звучит жёстко: проблема не в том, что ИИ «автоматизировал программистов», а в том, что он меняет саму логику найма, обучения и оценки качества. Особенно заметно это на младших специалистах, которые всё чаще работают не как инженеры, а как операторы генеративных инструментов.
Эксперимент, который показал цену скорости
Поводом для текста стал внутренний эксперимент. Автор доверил студенту-практиканту задачу сделать UI-дашборд, интегрированный с API OpenProject, чтобы генерировать отчётные документы для отдела разработки. Формат был максимально благоприятный для новой школы: полная свобода, современный стек, AI-first разработка без жёсткого код-ревью на старте и с доступом к передовым моделям и инструментам.
Через два дня пришёл merge request. На поверхности всё выглядело убедительно: NestJS в роли серверной прослойки, React на фронтенде, приложение задеплоено на выделенную виртуалку, интерфейс визуально аккуратный, основные сценарии работают. Но дальше началась типичная история, знакомая любому техлиду, который хоть раз открывал «быстро собранный» AI-проект. Маршрутизация была декоративной: переходы по страницам не меняли URL, часть ссылок оказалась заглушками, а в корпоративный инструмент зачем-то попали блоки с продающим текстом, больше уместные на лендинге, чем во внутреннем сервисе.
После первого списка замечаний баги начали исправлять быстро. URL уже менялся, query-параметры частично сохранялись, тесты горели зелёным. Только ручная проверка показывала, что пользовательские сценарии по-прежнему ломаются. Несколько таких итераций закончились тем, что руководитель пошёл читать код сам. Там и обнаружилась настоящая цена скорости: React Router не подключён, стейт-менеджера нет, логика форм переплетена в монолитный фрагмент примерно на 1300 строк, а вместо нормальной маршрутизации используется условный рендеринг на useState и useEffect. Тесты, по сути, проверяли модель мира, придуманную внутри этой же неудачной реализации, а не реальное поведение приложения.
На бэкенде ситуация оказалась не лучше. По оценке автора, около 60% кода там вообще не исполняется и не нужно системе. Про фронтенд он даже не берётся судить детально, но предполагает сопоставимый масштаб мусора. Итог двух недель выглядит двусмысленно: функциональность кое-как работает, задача почти бесплатно закрыта, но дальнейшая поддержка такой кодовой базы превращается в очень дорогой вид страдания. Каждый новый запрос к нейросети не стабилизирует систему, а, наоборот, усложняет её и увеличивает объём лишнего кода.
Что это меняет на рынке разработки
Самая неприятная часть этой истории даже не в коде, а в смене профессиональной культуры. Автор пишет, что раньше младший разработчик был вынужден разбираться в причинах проблемы: сборка не встаёт, зависимость конфликтует, поведение фреймворка непонятно — значит, придётся читать документацию, копать issue-трекеры, спрашивать старших коллег и постепенно собирать в голове систему. Теперь многие проблемы решаются брутфорсом через промпты. Если задача, на которую раньше уходила неделя, закрывается за два часа, спорить с этим трудно. Даже когда внутри решения заложена будущая катастрофа, на короткой дистанции цифры выглядят убедительно.
Отсюда и разрыв между поколениями инженеров, который автор описывает почти без дипломатии. Опытный разработчик, умеющий видеть архитектурные последствия и стоимость поддержки, в новой оптике часто выглядит «дорогим скептиком». Младший специалист с подписками на нейросети и агентные инструменты, наоборот, кажется быстрым и современным. Проблема в том, что рынок оценивает не глубину понимания, а скорость поставки артефакта. Если бизнесу нужно выживать, а не строить идеальную инженерную культуру, аргумент «это потом развалится» всё чаще проигрывает аргументу «это уже можно показать заказчику».
Автор связывает это не только с модой на генеративный ИИ, но и с общим состоянием рынка. По его версии, дорогие кредиты и переориентация венчурных денег в AI-first проекты сократили готовность инвесторов финансировать обычную «ручную» разработку. На этом фоне компании начинают резать штаты и оптимизировать расходы не потому, что нейросеть реально достигла уровня сильного инженера, а потому, что она позволяет временно удешевить производство софта. Это принципиально другой тезис: ИИ не заменил разработчиков по качеству, но уже влияет на их стоимость, переговорную позицию и шансы удержаться в штате.
Для российских команд и русскоязычных специалистов здесь сразу несколько практических выводов. Первый: AI-first разработка не освобождает от инженерных стандартов, а делает их ещё важнее, потому что объём ошибочного и лишнего кода растёт быстрее обычного. Второй: если джун не учится понимать систему без костылей генератора, он рискует надолго остаться джуном, даже выполняя внешне сложные задачи. Третий: для тимлидов и CTO проблема теперь не только в выборе инструментов, но и в перестройке процессов — от код-ревью и тестирования до того, как команда вообще понимает слово «готово».
Сам автор завершает историю без победных нот: после описанного периода штат в его компании был сокращён, а сам он ушёл с работы и закрыл ИП, чтобы получить отсрочку по ипотеке. В этом, вероятно, и заключается самый неприятный вывод всей колонки: ближайшие годы спор в IT пойдёт не о том, может ли ИИ писать код, а о том, сколько бизнеса согласны платить за людей, которые ещё способны отличить рабочий продукт от дешёвой симуляции разработки.