AI стварыў новы кірунак у ІТ — DevEx Engineering, лічыць Раман Бугаеў, тэхнічны дырэктар Flo. Кампаніям востра патрэбныя распрацоўшчыкі, якія гэта зразумелі і развіваюцца як інжынеры новага тыпу.
AI стварыў новы кірунак у ІТ — DevEx Engineering, лічыць Раман Бугаеў, тэхнічны дырэктар Flo. Кампаніям востра патрэбныя распрацоўшчыкі, якія гэта зразумелі і развіваюцца як інжынеры новага тыпу.
Новыя спецыяльнасці, нараджоныя AI-рэвалюцыяй, — гэта не пра гіпатэтычную будучыню, а пра сучаснасць. У размове з CTO Flo Health Раманам Бугаевым даведаліся пра адносна новы кірунак у ІТ — DevEx Engineering (Developer Experience, вопыт распрацоўшчыка) і agentic development. Кампанія шукае людзей, якія разумеюць сучасны DevEx і могуць не проста паскараць асобныя крокі, а мяняць сам працэс распрацоўкі.
Папрасілі Рамана расказаць, што гэта за спецыялізацыя.
Важна адразу зафіксаваць кантэкст: усё, што далей гаворыцца пра Developer Experience і agentic development, грунтуецца на тым, дзе індустрыя знаходзіцца ў траўні 2026 года. Калі вы чытаеце гэты тэкст з будучыні — уключайце крытычнае мысленне і адаптуйце яго пад рэчаіснасць.
Травень 2026 года ў распрацоўцы прынцыпова адрозніваецца ад траўня 2025-га.
Адрозніваецца ён тым, што да канца мінулага года франтырныя мадэлі OpenAI і Anthropic назапасілі крытычную масу якасці і дазволілі дастаткова надзейна пісаць код на мовах праграмавання наўпрост з чалавечай мовы.
Пры гэтым сама ідэя пісаць праграму на чалавечай мове не новая.
У індустрыі заўсёды існавала роля Software Architect, нават калі на практыцы яе часта выконваў Senior-распрацоўшчык. Сутнасць гэтай ролі — апісваць, якой павінна быць сістэма: яе структуру, інтэрфейсы, зоны адказнасці кампанентаў і ключавыя сцэнарыі паводзінаў. Зафіксаванае фармальна на паперы ці толькі ў галаве распрацоўшчыка, апісанне так ці інакш існавала заўсёды. Потым па гэтым апісанні выконвалася рэалізацыя. І чым дакладнейшай была спецыфікацыя, тым вышэй быў шанс, што рэалізацыя атрымаецца такой, як задумана.
Калі ў мадэляў адбыўся якасны скачок, мы ўсе раніцай прачнуліся ў ролі Software Architects — незалежна ад свайго вопыту ў індустрыі.
Парадаксальным чынам, другая роля, у якой мы прачнуліся, — гэта роля 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-інжынера — праектаваць такую фабрыку распрацоўкі новага пакалення.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.