Привет, на связи Рома Миронов из Авито. Я бывший — хотя бывших не бывает — фронтендер, а сейчас тим- и техлид. Ковыряю AI и больше ничем не занимаюсь — кроме команды, конечно :) В этой статье расскажу, почему фронтенд пока не умер, какие задачи уже можно отдавать агентам, где они красиво ошибаются и почему сначала от AI становится больнее, а не легче.

• Фронтенд не умер. Умирает часть ручной рутины

• Почему фронтенд попал под первую волну AI-изации

• Два кейса: расследование 500 и 38 PR

• Недостатки AI и мой подход

• Как дела с AI в Авито в целом?

• Почему сначала становится больнее

• Итого: что ускоряется, а что может ухудшиться

Нет, фронтенд не умер. Умирает часть ручной рутины

Начну с главного: петь панихиды рано. Фронтенд просто трансформируется. Раньше ценность была в том, чтобы быстро и аккуратно написать много кода руками. Мы брали задачи на спринт и писали код. Теперь от нас требуется правильно поставить задачу, дать агенту необходимый контекст и взять ответственность за результат.

Я уже во многом так и работаю. Сам код пишу редко: больше слежу за тем, что делает агент, направляю его и проверяю. Нравится ли мне это — не знаю. Но пока выглядит прикольно.

В среднем по больнице ситуация аналогичная: AI уже стал рабочим инструментом, но доверия пока мало.

Вокруг Codex и Claude много шума: в X они то хоронят друг друга, то вместе чинят чей-нибудь monorepo. Но X — не то место, которому хочется безоговорочно доверять, поэтому посмотрим на цифры из настоящих исследований:

• 90% разработчиков регулярно используют хотя бы один AI-инструмент на работе;

• 74% используют специализированные AI-инструменты для разработки;

• 72% из попробовавших эти инструменты используют их каждый день;

• 69% пользователей AI-агентов видят прирост эффективности;

• по оценке опрошенных разработчиков, 42% кода, который они коммитят, сгенерировано либо существенно дополнено AI (AI-generated или AI-assisted).

Одновременно сохраняется большой разрыв между использованием и доверием: 96% разработчиков не готовы полностью доверять функциональной корректности сгенерированного кода. И при этом только 48% всегда проверяют AI-generated код перед коммитом.

(Я знаю, вы хотите фактчекнуть! Источники: JetBrains Research, Sonar и Stack Overflow. Возможно, данные уже несколько устарели, так что я бы сильно увеличил каждый процент.)

DORA — исследовательская программа Google Cloud — описывает AI как то, что усиливает существующую инженерную систему: сильные практики ускоряются, но хаос — тоже.

Вопроса, пользоваться AI или нет, уже нет на повестке. Актуальный вопрос — как не потерять в качестве, когда объем сгенерированного кода растет.

Почему фронтенд попал под первую волну AI-изации

По моему опыту, с AI проще работать там, где есть короткая обратная связь. Фронтенд для этого подходит очень хорошо:

1. результат сразу виден в браузере;

2. есть компонентная модель;

3. повторяются знакомые UI-паттерны;

4. можно использовать скриншоты и Storybook;

5. локальная обратная связь обычно быстрая;

6. тесты, type-check и линтеры дают дешевую проверку.

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

В контексте Авито сделать компонент — совсем не то же самое, что написать JSX. Агенту приходится учитывать массу вводных:

• дизайн-систему;

• bundle-check (проверка размера бандла) и check-deps (проверка валидности зависимостей);

• аналитику и эксперименты;

• сервисы и пакеты;

• поисковую оптимизацию, производительность и доступность;

• размазанную ответственность — ведь не всегда понятно, у кого уточнить логику конкретного компонента.

Надо не просто сверстать, а правильно реализовать в контексте Авито. Сейчас я спокойно использую AI для тестов, Storybook, разбора легаси, рефакторинга, миграций, подготовки к ревью и еще множества задачек.

Два кейса: расследование 500 и 38 PR

Кейс №1. Как агент расследовал 500 на выдаче

Недавно один из микрофронтендов на выдаче начал выдавать ошибку 500. Sentry зафиксировал падение на preparedItem.images.length с категорией CATEGORY_WIDGET. Код был не мой, причина была непонятна.

Я дал агенту простую задачу: найти причину ошибки. После этого ушел заниматься своими делами.

Агент прошелся по релизам, виджетам и контрактам данных, открыл браузер, посмотрел инфомодель, A/B-тесты, ботов и разные платформы (бэкенд, фронтенд). После тонны потраченных токенов он в итоге сформулировал гипотезу: Googlebot с мобильным user agent начал ходить на desktop, из-за чего для него начал выдаваться невалидный контент с бэкенда.

Барабанная дробь — гипотеза оказалась правильной.

Я почти полностью отдал AI дебаг этого инцидента. Он потратил много токенов в xHigh-режиме, но собрал факты, прошел по незнакомому коду и остался в нужном контексте. Когда я вернулся (через 30 минут), у меня уже было с чем идти к нужным людям.

Кейс №2. PR для удаления заметок

Здесь функционал был на выдаче, в избранном и на карточке объявления, плюс существовал бэкенд-сервис, который отдавал заметки. Я спросил коллег, сколько pull requests понадобится, чтобы убрать отображение заметок. Ответы были: шесть, десять. А правильно — 38.

Один из PR на карточке потянул еще около 30 изменений в разных сервисах из-за сгенерированного контракта карточки объявления. Вручную делать это мне совсем не хотелось, поэтому я отдал задачу агенту. Он собрал все PR, довел изменения до выкладки и закончил задачу (мерджил и выкатывал сам агент).

Наверное, это был какой-то рекорд Авито по количеству PR на одну фронтовую — а может, и не только — задачу. Но важнее другое: агент может произвести огромный объем изменений за очень короткое время.

Недостатки AI и мой подход

Меня пугает не то, что AI пишет плохой код. Пугает количество кода, которое он выдает за короткое время.

Скорость умножает не только пользу, но и ошибки. Типовые фейлы уже знакомы:

• выдуманные API;

• лишние абстракции над другими лишними абстракциями;

• поверхностные тесты, которые ничего не проверяют;

• «красивый» diff, который делает не то, что хотелось;

• и много-много другого :)

AI иногда решает задачу, которую сам себе придумал: добавляет требования, лезет не туда, лепит ненужные обертки, а потом уверенно защищает неправильное решение.

По мере распространения AI количество PR и объем кода на ревью будут драматически расти. Значит, нам придется перестраивать процессы и работать по-другому.

У меня агент работает не сам по себе, а внутри заранее описанной среды. Конфиг состоит из нескольких уровней:

Если агент ошибается в повторяющейся вещи, я прошу записать правильный вариант в правила и больше не повторять ошибку.

При этом важно не переусердствовать. Чем больше правил, skills и MCP попадает в контекст, тем больше модель знает лишнего. К тому же токены расходуются быстрее. Для фронтенд-задачи не всегда нужны знания о бэкенде. Избыточный контекст может мешать.

Важный инструмент в моей работе — планы. С новыми моделями они не всегда нужны, но довольно часто для заметной задачи я сначала прошу агента описать ход решения без кода.

Я генерирую планы не только в Markdown, но и в HTML. Когда это полезно, агент добавляет скриншоты, рисует состояние «как сейчас» и «как будет», показывает схемы и изменения.

Так мне проще понять, что именно он собирается делать, потому что визуальная информация воспринимается человеком проще.

Дальше процесс выглядит так:

1. Беру Jira-задачу, фиксирую цель и границы.

2. Передаю агенту контекст, ссылки, файлы и ограничения.

3. Прошу написать план — сначала ход решения, без кода.

4. Провожу ревью плана: оцениваю риски, убираю лишнее и уточняю недосказанное.

5. Указываю выполнять задачу небольшими проверяемыми шагами.

6. Снова провожу ревью результата и повторяю цикл, пока меня не устроит.

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

Можно ли поручить агенту ревью кода другого агента? Можно, если ответственность всё равно остается у человека. Сейчас агенты чаще всего плохо ревьюят, особенно сгенерированный код. Важно не попасть в ситуацию, где один агент написал код, второй формально подтвердил корректность, а человек вообще не понимает, что попало в PR и мерджит его.

Как дела с AI в Авито в целом?

В Авито уже есть MCP, skills и комьюнити вокруг AI. Но одну и ту же технологию можно одновременно считать зрелой, сырой и спорной — все зависит от того, где ее применять.

MCP уже много, но в конкретных местах их все еще не хватает. Skills полезны, но их может быть слишком много. Комьюнити хорошее, но хочется, чтобы в нем участвовало больше людей: чем больше мы делимся опытом, тем быстрее развиваемся.

При этом я не хочу превращать каждую маленькую задачу в систему из десяти подагентов, которые рассматривают один PR с разных сторон. Если в CSS поменялась одна строка, огромный оркестратор может оказаться сложнее самой задачи.

Почему сначала становится больнее

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

Я смотрю на это как на J-кривую. Сначала мы вкладываем время в обучение и замедляем обычную разработку. Потом появляется налог на проверку: мы учимся понимать, где AI полезен, а где нет. Следующий этап — адаптация пайплайна и собственных процессов. Только после этого можно выйти в заметный рост.

В опросе Авито о том, на каком этапе, как считает сам сотрудник, он находится, большинство голосов пришлось именно на налог на проверку:

Освоение AI требует времени — как выход на новую работу или изучение незнакомого фреймворка. Сначала всегда становится медленнее.

Итого: что ускоряется, а что может ухудшиться

Мне все еще хочется писать код самому. Но у меня был пет-проект, в котором я примерно месяц делал админку, — агент потом сделал то же самое за день. Возникает логичный вопрос: зачем мне тратить месяц, если тот же результат можно получить быстрее?

Что AI чаще улучшает:

• первый черновик;

• прототип;

• тесты и фикстуры;

• миграции;

• онбординг в код.

А это все, что связано со скоростью.

Но одновременно могут ухудшиться:

• объем кода на ревью;

• нагрузка на ревьюера;

• количество переделок;

• качество тестов;

• поддержка.

AI уже полезен там, где есть хороший контекст и дешевая проверка. Он может расследовать инциденты, проходиться по незнакомому коду, делать миграции, писать тесты и собирать десятки связанных PR. Но та же скорость создает новый расход: растет объем ревью, количество переделок и риск уверенно решить не ту задачу. То есть места, где необходимо следить за качеством.

Мы переносим часть работы из написания кода в постановку задачи, проверку и сопровождение результата.

И самая важная мысль: за весь сгенерированный через AI код несет ответственность инженер, который этим управлял.

Фронтендеры, где находитесь вы на J-кривой освоения AI? Обучение, налог на проверку, адаптация пайплайна или уже экспоненциальный рост? Какие задачи уже отдаете агентам, а какие пока оставляете себе? Делитесь опытом в комментариях!

Кстати, если вам интересна работа в бигтехе —  Хабр совместно с ЭКОПСИ проводит большое исследование IT-брендов работодателей. В прошлом году в нём поучаствовали 34 000 специалистов. Если у вас есть опыт — он точно будет учтён