Контент по тегу

Фронтенд умер? Нет, но AI уже держит лопату

Статьи frontend machine learning
Привет, на связи Рома Миронов. Я бывший — хотя бывших не бывает — фронтендер, а сейчас тим- и техлид. Ковыряю 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

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

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

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

Меня пугает не то, что AI пишет плохой код. Пугает количество кода, которое он выдает за короткое время.
Скорость умножает не только пользу, но и ошибки. Типовые фейлы уже знакомы:
  • выдуманные API;
  • лишние абстракции над другими лишними абстракциями;
  • поверхностные тесты, которые ничего не проверяют;
  • «красивый» diff, который делает не то, что хотелось;
  • и много-много другого :)
AI иногда решает задачу, которую сам себе придумал: добавляет требования, лезет не туда, лепит ненужные обертки, а потом уверенно защищает неправильное решение.
По мере распространения AI количество PR и объем кода на ревью будут драматически расти. Значит, нам придется перестраивать процессы и работать по-другому.
У меня агент работает не сам по себе, а внутри заранее описанной среды. Конфиг состоит из нескольких уровней:

Как описать среду для AI, чтобы он меньше ошибался

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

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

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

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

Пример отрисовки «как сейчас» и «как будет»

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

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

  1. Беру Jira-задачу, фиксирую цель и границы.
  2. Передаю агенту контекст, ссылки, файлы и ограничения.
  3. Прошу написать план — сначала ход решения, без кода.
  4. Провожу ревью плана: оцениваю риски, убираю лишнее и уточняю недосказанное.
  5. Указываю выполнять задачу небольшими проверяемыми шагами.
  6. Снова провожу ревью результата и повторяю цикл, пока меня не устроит.

Для маленького бага отдельный план не всегда нужен — иногда проще сразу сказать: «Иди и исправь». Но в большой задаче план помогает заранее увидеть, что агент собирается решать не ту проблему.
Практический совет
Не пишите в промте «Работай как senior-разработчик». Такая формулировка сама по себе ничего не дает. Лучше явно описать задачу, ограничения и способ проверки результата.
Можно ли поручить агенту ревью кода другого агента? Можно, если ответственность всё равно остается у человека. Сейчас агенты чаще всего плохо ревьюят, особенно сгенерированный код. Важно не попасть в ситуацию, где один агент написал код, второй формально подтвердил корректность, а человек вообще не понимает, что попало в PR и мерджит его.

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

В Авито уже есть MCP, skills и комьюнити вокруг AI. Но одну и ту же технологию можно одновременно считать зрелой, сырой и спорной — все зависит от того, где ее применять.
MCP уже много, но в конкретных местах их все еще не хватает. Skills полезны, но их может быть слишком много. Комьюнити хорошее, но хочется, чтобы в нем участвовало больше людей: чем больше мы делимся опытом, тем быстрее развиваемся.
При этом я не хочу превращать каждую маленькую задачу в систему из десяти подагентов, которые рассматривают один PR с разных сторон. Если в CSS поменялась одна строка, огромный оркестратор может оказаться сложнее самой задачи.

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

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

Кривая освоения AI

В опросе Авито о том, на каком этапе, как считает сам сотрудник, он находится, большинство голосов пришлось именно на налог на проверку:
Освоение AI требует времени — как выход на новую работу или изучение незнакомого фреймворка. Сначала всегда становится медленнее.

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

Мне все еще хочется писать код самому. Но у меня был пет-проект, в котором я примерно месяц делал админку, — агент потом сделал то же самое за день. Возникает логичный вопрос: зачем мне тратить месяц, если тот же результат можно получить быстрее?
Что AI чаще улучшает:
  • первый черновик;
  • прототип;
  • тесты и фикстуры;
  • миграции;
  • онбординг в код.
А это все, что связано со скоростью.
Но одновременно могут ухудшиться:
  • объем кода на ревью;
  • нагрузка на ревьюера;
  • количество переделок;
  • качество тестов;
  • поддержка.
AI уже полезен там, где есть хороший контекст и дешевая проверка. Он может расследовать инциденты, проходиться по незнакомому коду, делать миграции, писать тесты и собирать десятки связанных PR. Но та же скорость создает новый расход: растет объем ревью, количество переделок и риск уверенно решить не ту задачу. То есть места, где необходимо следить за качеством.
Мы переносим часть работы из написания кода в постановку задачи, проверку и сопровождение результата.
И самая важная мысль: за весь сгенерированный через AI код несет ответственность инженер, который этим управлял.