Справочник по Angular и React · модуль 0 · фронтенд в эпоху ИИ

ИИ во фронтенде:
инструменты и измерения

В этой главе разобраны инструменты ИИ, которыми пишут фронтенд в 2026 году: от подсказки в редакторе до генератора целого приложения. Объяснено, как языковая модель получает код и почему он бывает «почти правильным». Затем собраны измерения: в одних исследованиях ИИ ускоряет работу больше чем в полтора раза, в других замедляет на 19%, — и разобрано, почему оба результата верны. Глава заканчивается картой задач фронтенда с оценкой, какие из них ИИ сегодня выполняет надёжно.

Категория: Инструменты
Уровень: Вводный
Связанные темы: Фронтенд и фреймворки (0.1), фреймворки и инструменты ИИ (0.2, §5)
Зачем это знать: Выбирать инструмент под задачу и знать, где его результату нельзя верить без проверки

§1Четыре уровня инструментов

Сравнение из жизни

Помощь при ремонте бывает разной. Можно позвать знакомого, который подаёт нужный инструмент. Можно спросить совета у мастера по телефону. Можно нанять бригаду, которая сама сделает комнату, пока вы на работе. И можно купить квартиру с готовым ремонтом. Чем больше работы отдано, тем меньше времени она занимает у вас и тем внимательнее нужно принимать результат.

Бригада отвечает за свою работу по договору, а за код, написанный ИИ, отвечает тот, кто его принял в проект.

Инструменты ИИ для разработки различаются тем, сколько работы они выполняют без участия человека. Это свойство называют автономностью. От неё зависит, как часто разработчик проверяет результат и сколько кода попадает в проект без его прочтения. Ниже инструменты разложены по четырём уровням, от наименее к наиболее автономному.

АвтодополнениеДописывает строку или функцию в редакторе, пока разработчик печатает. Разработчик принимает подсказку клавишей Tab или пишет дальше.GitHub Copilot с 2021 года, встроенные подсказки редакторов

Человек видит каждую строку до того, как она попала в файл.

ЧатОтвечает на вопрос, объясняет ошибку, пишет фрагмент кода по описанию. Разработчик сам переносит код в проект.ChatGPT с ноября 2022 года, Claude, Gemini, GigaChat

Человек решает, что вставить; остальной проект модели не передаётся.

Агент в редакторе или терминалеЧитает файлы проекта, меняет несколько файлов сразу, запускает сборку и тесты, исправляет ошибки и повторяет, пока не получится.Claude Code с февраля 2025 года, Cursor, агент GitHub Copilot

Человек ставит задачу и проверяет итоговые изменения; промежуточные шаги выполняются без него.

Генератор приложенийСоздаёт приложение целиком по описанию на обычном языке: интерфейс, базу данных, публикацию в интернете.v0, Lovable, Bolt, Google AI Studio

Код можно ни разу не открыть. Так работают люди без опыта программирования.

Уровни не заменяют друг друга: разработчик в течение дня может пользоваться тремя из них. Чем выше уровень, тем больше кода, который никто не прочитал, и тем дороже ошибка, найденная поздно. Работа на четвёртом уровне без чтения кода получила в 2025 году название вайбкодинг. Его ввёл Андрей Карпаты, один из основателей OpenAI: в записи от 2 февраля 2025 года он описал, как пишет программы голосом, принимает все изменения не читая и, если что-то сломалось, просит модель исправить. В той же записи он уточнил, что такой способ годится для небольших проектов «на выходные».

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

§2Как модель пишет код

Сравнение из жизни

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

Модель не помнит отдельных писем: она хранит закономерности, по которым одно слово следует за другим.

В основе всех четырёх уровней — большая языковая модель: программа, которая по началу текста предсказывает его продолжение. Модель обучена на большом объёме текстов, среди которых миллиарды строк открытого кода. Код для неё — такой же текст: по началу const [query, setQuery] = она предсказывает, что дальше с большой вероятностью идёт useState(, потому что видела это сочетание сотни тысяч раз.

Предсказание следующего фрагмента

const[query,setQuery]=?

useState(высокая useRef(низкая signal(низкая useReducer(низкая

Модель выбирает продолжение из вариантов с разной вероятностью; оценки здесь условные. Вариант useState( вероятнее всего, потому что так эта строка выглядит в большинстве проектов на React. Правильно ли это для вашего проекта, модель не проверяет; проверка возможна, только когда код запущен.

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

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

Ускорение работы с ИИ измеряли разными способами, и результаты расходятся.

§3Что показывают измерения

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

Эксперимент GitHub, 2023 год: на 55,8% быстрее

Исследователи из GitHub, Microsoft и MIT дали 95 программистам одну задачу: написать HTTP-сервер на JavaScript. Половине разрешили GitHub Copilot. Группа с Copilot справилась в среднем на 55,8% быстрее. Задача была новой, небольшой и типовой: сервер написан с нуля, в пустом проекте, по ясному условию.

Эксперимент METR, 2025 год: на 19% медленнее

Некоммерческая лаборатория METR пригласила 16 опытных разработчиков открытых проектов. Каждый работал в своём проекте, который знал годами: в среднем пять лет опыта и около 1500 коммитов в этом репозитории. Задачи были настоящими — 246 исправлений и доработок из списка задач самих проектов. Для каждой задачи случайно решалось, можно ли пользоваться ИИ (в основном Cursor с моделями Claude 3.5 и 3.7 Sonnet). С ИИ задачи решались на 19% дольше. До эксперимента разработчики ожидали ускорения на 24%, а после него считали, что ИИ ускорил их на 20%.

Эксперимент METR: ожидание, ощущение и измерение

Изменение времени на задачу с ИИ. Влево от нуля — быстрее, вправо — медленнее. Шкала от −30% до +30%.

Ожидали до начала−24%

Оценили после−20%

Измерено+19%

−30%0+30%

Источник: METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 июля 2025.

Отдельный результат этого исследования — разница между ощущением и измерением. Разработчики, у которых были все данные о своей работе, ошиблись в оценке на 39 процентных пунктов и в другую сторону. Авторы исследования предупреждают, что результат относится к опытным людям в знакомых больших проектах и к инструментам начала 2025 года; на новичков и на незнакомый код его переносить нельзя. Для студента вывод практический: ощущение «с ИИ я быстрее» нужно проверять по часам и по числу возвратов на доработку.

Airbnb, 2025 год: перевод тестов React

В Airbnb нужно было перевести около 3500 файлов тестов React-компонентов со старой библиотеки Enzyme на React Testing Library. Вручную это оценили в полтора года работы инженеров. Команда построила конвейер: модель переписывала файл, затем запускались тесты, линтер и проверка типов TypeScript, и при ошибке модель получала её текст и пробовала снова. За первые четыре часа автоматически перевели 75% файлов, после доработки конвейера — 97%, оставшиеся 3% инженеры доделали руками за неделю. Всего ушло шесть недель.

Задача у Airbnb устроена удобно для ИИ: правило перевода одинаковое для всех файлов, а результат проверяется автоматически — тест либо проходит, либо нет. Из этого случая видно и то, сколько работы оставили людям: построить конвейер, собрать в подсказку до 100 тысяч токенов примеров и связанных файлов, разобрать трудные 3%.

Google, 2024–2026 годы: доля кода, написанного ИИ

Генеральный директор Google Сундар Пичаи несколько раз называл долю нового кода в компании, которую создаёт ИИ: больше четверти в октябре 2024 года, около половины осенью 2025 года и 75% в апреле 2026 года. Во всех заявлениях оговаривается, что код проверяют и принимают инженеры.

Что означает «доля кода, написанного ИИ»

Доля кода и ускорение работы — разные величины. Строки, которые предложила модель и принял инженер, считаются кодом ИИ, даже если инженер потратил на постановку задачи и проверку больше времени, чем на написание. Кроме того, это заявление руководителя публичной компании, которая продаёт инструменты ИИ; независимым измерением оно не является. Число показывает, что в Google ИИ пишет большую часть нового кода; сколько времени это экономит, из него не следует.

Почему результаты расходятся

Четыре измерения не противоречат друг другу, если сравнить условия. ИИ ускоряет работу больше всего, когда задача типовая, проект новый или небольшой и результат можно проверить автоматически: сервер с нуля в эксперименте GitHub, однотипный перевод тестов в Airbnb. ИИ замедляет работу, когда разработчик знает проект лучше модели, а требования к результату нигде не записаны и держатся в голове: так было в эксперименте METR. Там значительная часть времени уходила на то, чтобы объяснить модели задачу, прочитать её код и переделать «почти правильное».

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

Как разработчики относятся к инструментам ИИ, показывают опросы.

§4Насколько разработчики доверяют ИИ

В опросе Stack Overflow 2025 года 84% участников ответили, что пользуются инструментами ИИ или собираются начать; годом раньше таких было 76%. Среди профессиональных разработчиков 51% пользуются ими каждый день. При этом доверие к результату снижается: точности ответов ИИ доверяют 33%, не доверяют 46%, полностью доверяют 3%. Доля тех, кто относится к инструментам ИИ положительно, упала с более чем 70% в 2023–2024 годах до 60%.

84%пользуются ИИ или собираются начать 46%не доверяют точности ответов; доверяют — 33% 66%выбрали претензию: решения «почти правильные, но не совсем» 72%говорят, что вайбкодинг не входит в их профессиональную работу

Чаще всего — 66% участников — выбирали претензию — решения «почти правильные, но не совсем». Вторая по частоте — 45%: отладка кода, написанного ИИ, занимает больше времени, чем ожидалось. Эти две претензии описывают одно явление с двух сторон. Код, который не работает совсем, видно сразу. Код, который работает в обычном случае и ошибается в редком, проходит беглую проверку и обнаруживается позже — у пользователя.

Опрос показывает, что ИИ стал обычным инструментом разработчика, но решения о том, что попадает в продукт, разработчики оставляют за собой. 76% участников ответили, что не собираются поручать ИИ развёртывание и наблюдение за работающей системой, а 75% при сомнении в ответе ИИ спрашивают коллег.

§5Карта задач фронтенда

Карта ниже собирает задачи фронтенд-разработчика и оценивает, насколько надёжно их выполняют инструменты ИИ в 2026 году. Оценка опирается на исследования из этой главы и два исследования, указанные в карте отдельно; в правом столбце указано основание. Карта описывает положение на 2026 год, оно меняется каждые несколько месяцев.

ЗадачаНадёжностьОснование

Вёрстка экрана по описанию или макетуГенераторы v0, Lovable, Bolt создают работающие экраны за минуты; это основной сценарий их использования.

Типовой компонент: форма, таблица, список с фильтромЗадача типовая, примеров в обучающих данных много; эксперимент GitHub: +55,8% к скорости на типовой задаче.

Перевод кода на новую версию или библиотеку при хороших тестахAirbnb: 97% файлов переведено автоматически, проверка тестами, линтером и типами.

Написание тестов к существующему кодуТесты пишутся быстро, но проверяют то, что код делает сейчас, включая его ошибки; что проверять, решает человек.

Изменение в большом знакомом проектеMETR: опытные разработчики в своих проектах работали с ИИ на 19% медленнее.

Доступность для людей с ограничениямиAudioEye: 15 сайтов от пяти инструментов ИИ, все не прошли базовый уровень WCAG; исследование опубликовано компанией, которая продаёт проверку доступности.

Безопасность: защита от XSS, хранение ключей, праваVeracode: в 86% задач модели не защитили код от XSS; в 45% всех задач выбрали небезопасный вариант.

Понять, что нужно пользователю и бизнесуМодель опирается только на то, что есть в контексте; требования, которые нигде не записаны, она не учитывает (§2).

По карте видно, как распределяется работа. Верхние строки — задачи, где требование легко описать и результат легко проверить; их ИИ выполняет хорошо и быстро. Нижние строки — задачи, где требование либо не записано, либо проверяется специальными знаниями: доступность, безопасность, смысл продукта. Здесь ИИ выдаёт правдоподобный результат, который выглядит готовым, а ошибка обнаруживается у пользователя. Больше всего внимания дисциплина уделяет нижней части карты. Случаи из настоящих проектов собраны в отдельном разборе «Заменил ли ИИ фронтенд-разработчика».

§6Проверьте себя

Чем агент третьего уровня отличается от чата второго уровня?

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

Почему модель уверенно пишет имя функции, которой нет в библиотеке?

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

Эксперимент GitHub показал ускорение на 55,8%, эксперимент METR — замедление на 19%. Какое исследование ошиблось?

Оба верны для своих условий. В эксперименте GitHub задача была типовой, новой и небольшой, а участники не знали ничего, чего не знала бы модель. В METR опытные разработчики работали в больших проектах, которые знали годами, и много времени уходило на объяснение задачи и переделку кода. Результат зависит от типа задачи и от того, насколько разработчик знает проект лучше модели.

Google сообщает, что 75% нового кода создаёт ИИ. Значит ли это, что инженеры Google работают в четыре раза быстрее?

Нет. Доля кода считает строки, которые предложила модель и принял инженер; время работы она не учитывает. Время на постановку задачи, проверку и исправление в эту долю не входит. Кроме того, это заявление руководителя компании; независимым измерением оно не является.

Почему агенты работают лучше в проектах со строгой типизацией и большим числом тестов?

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

Итог главы

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