AI создал новое направление в ИТ — DevEx Engineering, считает Роман Бугаев, технический директор Flo. Компаниям остро нужны разработчики, которые это поняли и развиваются как инженеры нового типа.
AI создал новое направление в ИТ — DevEx Engineering, считает Роман Бугаев, технический директор Flo. Компаниям остро нужны разработчики, которые это поняли и развиваются как инженеры нового типа.
Новые специальности, порождённые ИИ-революцией, это не про гипотетическое будущее — это про настоящее. В общении с CTO Flo Health Романом Бугаевым узнали про относительно новое направление в ИТ — DevEx Engineering (Developer Experience, опыт разработчика) и agentic development. Компания ищет людей, которые понимают современный DevEx и и могут не просто ускорять отдельные шаги, а менять сам процесс разработки.
Попросили Романа рассказать, что это за специализация.
Важно сразу зафиксировать контекст: всё, что дальше говорится про Developer Experience и agentic development, основано на том, где индустрия находится в мае 2026 года. Если вы читаете этот текст из будущего, включайте критическое мышление и адаптируйте его под реальность.
Май 2026 года в разработке принципиально отличается от мая 2025-го.
Отличается он тем, что к концу прошлого года фронтирные модели OpenAI и Anthropic накопили критическую массу качества и позволили достаточно надёжно писать код на языках программирования напрямую с человеческого языка.
При этом сама идея писать программу на человеческом языке не новая.
В индустрии всегда была роль Software Architect, даже если на практике ее часто выполнял Senior-разработчик. Суть этой роли — описывать, какой должна быть система: ее структуру, интерфейсы, зоны ответственности компонентов и ключевые сценарии поведения. Записанное формально на бумаге или только в голове разработчика, описание так или иначе существовало всегда. Потом по этому описанию выполнялась реализация. И чем точнее была спецификация, тем выше был шанс, что реализация получится такой, как задумано.
Когда у моделей произошел качественный скачок, мы все утром проснулись в роли Software Аrchitects — независимо от своего опыта в индустрии.
Парадоксальным образом, вторая роль, в которой мы проснулись, — это роль Quality Assurance Engineer, потому что качественный тест-план и автоматизированная обратная связь стали решающими компонентами успешной агентной разработки.
После этой метаморфозы разработчик начинает работать иначе, но не обязательно быстрее.
По нашему опыту, при максимальном использовании агентной разработки примерно половина времени уходит не на развитие продукта, а на настройку агента: harness, skills, инструменты, интеграции и проверку на применимость новых подходов, которые появляются каждый день.
Возникает парадокс: модель освобождает время, но это время тут же инвестируется обратно в изучение и настройку среды.
Итоговая продуктивность отдельного разработчика может остаться такой же, как до появления agentic development. Для одного инженера это может быть осознанной инвестицией. Для компании это хуже масштабируется: если каждый разработчик тратит половину времени на собственный ресёрч, общий эффект получается дорогим и неравномерным.
И здесь появляется современный DevEx-инженер. Его работа — агентная разработка на фулл-тайме. Он исследует инструменты, собирает практики, настраивает среду, упаковывает знания и распространяет их внутри компании.
Для обычного разработчика переход в DevEx часто начинается незаметно: сначала человек автоматизирует что-то для себя, потом — для команды, а затем начинает системно устранять трение в разработке вокруг других инженеров. В эпоху agentic development это особенно важно: DevEx engineer не просто пишет код, а проектирует среду, в которой AI и инженеры вместе могут стабильно и быстро развивать большие системы.
Следующий вопрос: что именно там надо настраивать? Почему нельзя просто взять агента, написать ему задачу и получить систему, готовую к эксплуатации?
Проблема в том, что агенты уже хорошо превращают человеческий язык в код, но сами по себе пока плохо удерживают большую поддерживаемую систему. Как только задача выходит за рамки прототипа, начинает накапливаться технический долг.
Во многих случаях такой обмен абсолютно оправдан: на этапе поиска product-market fit или проверки идеи бизнесу часто важнее скорость здесь и сейчас.
Но важно понимать границу компромисса. Если просто вайбкодить сложную систему, наступает момент, когда модель уже не может добавить новую функциональность, не сломав старую.
Однажды мы провели контролируемый эксперимент: использовали агентов для создания пайплайна машинного обучения. ML-инженеры работали над data pipeline с помощью языковых моделей почти в режиме вайбкодинга: описываешь, что нужно, и получаешь результат.
Для такой задачи это было хорошее место для эксперимента. Пайплайн не был customer-facing, мы могли позволить себе определенный уровень падений, а качество результата проверялось тестами и data quality техниками. В исследовательской работе такой код часто приходится переписывать, чтобы быстрее двигаться вперёд.
Эксперимент работал и на первом этапе дал большой прирост скорости. Но постепенно пайплайн вырос примерно до 7000 строк в одном Python-файле. Агенту с этим ещё было комфортно работать, а людям уже становилось трудно понимать, что там происходит. Тесты и проверки были, но архитектура постепенно стала неудобной для дальнейшего развития.
В какой-то момент наступил предел. Фронтирные модели все еще бодро добавляли новую функциональность, но когда дело дошло до исправления ошибок, они начали чинить одно и ломать другое. Код стал настолько запутанным и неструктурированным, что модель фактически загнала сама себя в угол.
Это хороший пример текущих пределов возможностей моделей: агент может быстро нарастить работающий объем кода, но без правильных ограничений и архитектурной рамки этот объем перестает быть управляемым.
Удивительно — исправляется это почти так же, как исправлялось до появления агентов.
Инженерные практики, которые работали для людей, продолжают работать и для моделей: Test-Driven Development, Test Plan, Plan Review, Code Review, ADR/RFC.
Задача современной разработки — построить систему ограничений, в которой модель не просто меняет скорость на технический долг, а помогает держать этот долг под контролем.
Это задача всех инженеров. Но для DevEx- инженера она становится отдельным фокусом: найти рабочие практики, встроить их в инструменты и распространить по компании.
Фактически agentic development — это промышленная версия вайбкодинга: код пишется не по наитию модели, а с соблюдением инженерных практик, которые индустрия вырабатывала десятилетиями.
Здесь важно не остановиться на уровне отдельных инструментов. Если просто добавить AI к старому процессу разработки, эффект будет ограниченным: где-то станет быстрее ревью, где-то проще написать тест, где-то легче собрать черновик документации. Но сам процесс останется прежним.
Когда фабрики переходили с паровых двигателей на электричество, сначала почти не было роста производительности — просто потому что они оставляли старую архитектуру: один центральный двигатель и вся фабрика, выстроенная вокруг него через валы и ремни.
Настоящий скачок произошёл позже, когда фабрики переосмыслили целиком. На современном предприятии двигатель подстраивается под оптимальную модель производства, и каждая машина становится независимой.
С инженерными процессами сейчас происходит то же самое. AI не просто новый инструмент, это возможность переизобрести SDLC, опираясь на инженерный опыт, накопленный за десятилетия.
Поэтому задача DevEx-инженера — проектировать такую фабрику разработки нового поколения.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.