Фронтендер через десять лет

Когда меня спрашивают, не страшно ли мне за профессию на фоне ИИ, я отвечаю, что страшно за конкретную форму профессии, а не за неё саму. Фронтендер, каким он сложился за последние пятнадцать лет — человек, который переводит макет в код, — действительно уходит. Но не в небытие, а в другую роль. Я думаю, через десять лет это будет UX/UI-инженер: человек, который держит в одной голове и взаимодействие, и его реализацию.

Что исчезает

Исчезает механический слой. Перевести готовый дизайн в вёрстку, собрать форму по описанию, разложить состояние по стандартному паттерну — это та часть работы, которую ИИ уже сегодня делает быстрее человека и будет делать только лучше. Долго гордиться тем, что ты «хорошо верстаешь», больше не выйдет: это как гордиться красивым почерком после изобретения клавиатуры.

Если убрать механический слой, обнажается вопрос: а что, собственно, остаётся ценного? И ответ, на мой взгляд, неудобный для многих: остаётся понимание что и зачем строить, а не как.

Что становится дороже

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

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

UX/UI-инженер

Это и есть тот, кто держит эти слои вместе. Не «фронтендер, который ещё и в Figma умеет». Это инженер, для которого интерфейс и его смысл — одно целое. Он одинаково свободно рассуждает о том, что должен почувствовать пользователь, и о том, как это честно выразить в коде; видит, где проходит граница между задачей UI и задачей бэкенда; и берёт на себя продукт целиком, а не свой участок конвейера.

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

Книга, которая становится инструментом

Мне близок один частный случай этой работы. Можно взять анемичную книгу — просто текст — и превратить её в рабочий инструмент исследования знания, которое предложил автор. Придумать интерактивные виджеты, через которые читатель не просто следит за мыслью, а проживает её: осваивает новое, закрепляет и сам открывает новое знание и новые смыслы. Это и есть инженерия смысла, а не разметки — ценность здесь не в коде, а в том, какой опыт понимания ты спроектировал. Для меня это не теория, а текущий эксперимент и исследование: я как раз превращаю книгу по financial ML в набор таких интерактивных островков. И уже совершенно неважно, на чём этот инструмент написан — React, Vue, Svelte или Elm. Фреймворк — расходник; замысел — нет.