ИИ-агенты вроде Claude Code меняют фронтенд-разработку и её преподавание
Автор поста, в прошлом сотрудник команды, занимавшейся производительностью браузера, обычно пишет о фронтенд-разработке, в первую очередь о производительности CSS: как устроен shadow DOM, как работает движок стилей браузера, в чём ловушки CSS-in-JS. В этом посте автор перечисляет нескольких преподавателей фронтенда, которыми восхищается, и отмечает, что они сокращают активность или уходят вовсе: Аксель Раушмайер, Сальма Алам-Нейлор и Джош У. Комо, источник не уточняет, кто из троих именно ушёл, а кто просто снизил обороты. Ещё четверо заметных в индустрии людей, Кент Си Доддс, Адди Османи, Рейчел Наборс и Лидия Халли, вовсе перестали говорить о фронтенде и переключились на другую тему; на какую именно, автор впрямую не называет, предлагая читателю догадаться самому.
Решив проверить, насколько ИИ разбирается в теме, которой посвящён сам блог, производительности браузера, автор запрещает модели искать что-либо в интернете и задаёт Claude Sonnet классическую загадку: в трассировке Chrome видны повторяющиеся всплески дорогой стадии Style (пересчёт стилей) при низкой стоимости Layout (расчёта раскладки), что смотреть и что измерять дальше? Claude даёт, по оценке автора, ответ, достойный всяческой похвалы: указывает на сложность и охват CSS-селекторов, на широкую инвалидацию стилей при переключении класса высоко в дереве DOM (например, на элементе body), на то, что смена унаследованного свойства или CSS-переменной на :root пересчитывает стиль у всех потомков, и советует включить в DevTools функцию «Selector Stats» (статистику по селекторам) и проверять предупреждения «Forced reflow» (принудительный пересчёт раскладки). У автора за плечами, годы текстов о производительности браузеров и работа в профильной браузерной команде, но сегодня, по собственному признанию, дело обычно ограничивается тем, что трассировку Chrome просто отдают агенту Claude Code с просьбой предложить исправления; автор утверждает, что именно так поступает на основной работе и получает хорошие результаты.
Дальше автор объясняет, почему видит будущее фронтенд-образования «не в лучшем положении». Первая причина: фронтенд-код стало безопаснее отдавать агенту без присмотра, чем, скажем, миграцию базы данных, риск не нулевой (агент может сломать доступность или устроить бесконечный цикл, блокирующий пользователей), но обычно ощутимо ниже. Вторая причина: удобство для разработчика (developer experience) значит меньше, чем раньше. До эпохи больших языковых моделей споры вокруг фронтенда шли о том, что эргономика инструмента определяет результат, автор приводит как пример эссе Алекса Расселла «Подмена „удобства для разработчика“» и годами звучавший довод Svelte и Solid о том, что их эргономика даёт лучший результат, чем React. Но теперь Cursor и Viget сами публично рассказали о переходе своих кодовых баз на React, Cursor с Solid, Viget с Lit. Причину Cursor называет прямо (а для Viget автор лишь предполагает то же самое): «агенты знают React», React непропорционально широко представлен в обучающих данных моделей, и «опыт агента» начинает значить больше, чем опыт разработчика. Третья причина: веб-стандарты, по мнению автора, будут смещаться туда же, усилия по улучшению эргономики (более короткий синтаксис CSS и JavaScript) станут менее значимыми, чем возможности, которые реально расширяют браузер: агенту не так важно, писать 3 строки CSS или одну. Автор вспоминает разговор на конференции TPAC ещё до бума ИИ-кодинга: услышав про работу над стандартами веб-компонентов, специалист из команды Chrome реагирует прохладно, подобные API, по словам специалиста, влияют только на удобство для разработчика, а не на реальные возможности браузера, и в пример приводится инициатива Project Fugu.
Несмотря на мрачный прогноз, автор называет три направления, где фронтенд-экспертиза остаётся востребованной. Во-первых, агентов и инструменты для них ещё нужно учить видеть картину целиком: они охотно генерируют React-SPA (одностраничные приложения) там, где для условного маркетингового сайта подошёл бы MPA-фреймворк (многостраничное приложение) вроде Astro или Eleventy: по прикидке автора, это даёт примерно вдвое меньше кода, даже если агентам с такими фреймворками (особенно с Astro, который внешне похож на React, но им не является) работать чуть сложнее. Во-вторых, перспективным автор считает создание сайтов, удобных для самих агентов, в пример автор приводит проект Vercel is-agentic; иронично, что это возвращает к тем же основам, которые сайтам стоило соблюдать и раньше: серверный рендеринг, доступность, скорость загрузки. Здесь автор сам делает оговорку: веб в нынешнем виде, возможно, вообще не переживёт эпоху агентов, если единственная причина, по которой агент не может, скажем, сам узнать цену перелёта, это блокировка ботов или отсутствие у сайта интерфейса MCP (протокол для подключения ИИ-агентов к внешним сервисам), а не что-то более фундаментальное. В-третьих, автор видит нишу в консалтинге по исправлению фронтенда, наспех собранного ИИ без глубокого понимания (то, что называют vibe coding): часть такого кода, по выражению, характерному для самого Claude, станет «несущей», то есть окажется критически важной, и когда такие сайты окажутся медленными, недоступными или дырявыми по безопасности, одной просьбы «почини мой сайт» может не хватить, особенно если на кону деньги, а сам заказчик не смыслит в веб-разработке дальше того, что «сайт, это приложение в интернете».
Ключевые факты
- Несколько известных преподавателей фронтенда, Аксель Раушмайер, Сальма Алам-Нейлор, Джош У. Комо, сокращают активность или уходят вовсе (источник не говорит, кто именно и как); ещё четверо, Кент Си Доддс, Адди Османи, Рейчел Наборс, Лидия Халли, перестали говорить о фронтенде, переключившись на тему, которую автор впрямую не называет.
- Автор просит Claude Sonnet (без доступа к интернету) разобрать классическую загадку производительности браузера, трассировку Chrome с высокой стоимостью Style и низкой Layout, и называет ответ модели «достойным всяческой похвалы»; сегодня для такой задачи автор просто отдаёт трассировку агенту Claude Code и получает хорошие результаты на основной работе.
- Cursor и Viget перевели свои кодовые базы на React, с Solid и с Lit соответственно; Cursor прямо называет причину «агенты знают React», для Viget автор лишь предполагает то же самое, фреймворк выбирают не по эргономике, а по тому, насколько хорошо его знают модели.
- Автор ожидает, что веб-стандарты сместятся от эргономики (более короткий синтаксис) к возможностям, которые реально расширяют браузер, и вспоминает разговор на конференции TPAC, где человек из команды Chrome называет стандарты вроде shadow DOM неважными именно потому, что они меняют лишь удобство разработки, а не возможности браузера (в пример приведён Project Fugu).
- Автор видит будущее для фронтенд-экспертизы в трёх направлениях: учить агентов выбирать MPA (Astro, Eleventy) вместо тяжёлого React-SPA для простых сайтов (по прикидке автора, вдвое меньше кода); делать сайты удобными для самих агентов (пример, Vercel is-agentic); и чинить на консалтинге фронтенд, наспех собранный ИИ без понимания задачи (vibe coding), часть такого кода, по выражению, характерному для Claude, станет «несущей», то есть критически важной.
Почему это важно
Это не пресс-релиз компании, а взгляд практика изнутри отрасли: автор с опытом работы в браузерной команде показывает на собственном примере, что ИИ-агенты вроде Claude Sonnet и Claude Code уже неплохо справляются с задачами уровня специалиста по производительности, а не только с шаблонным кодом. Параллельно несколько заметных преподавателей фронтенда сокращают активность или сменили тему, а команды вроде Cursor и Viget выбирают фреймворк не по эргономике, а по тому, насколько хорошо его «знают» модели. Для целой дисциплины это сигнал точки перелома: меняется не просто инструмент разработки, а то, что вообще стоит изучать и преподавать во фронтенде, и кто на этом фоне ещё нужен как эксперт.
Кому это важно
Фронтенд-разработчикам и техническим руководителям, которые решают, сколько ревью нужно коду, написанному агентом, и на каком фреймворке строить новый проект. Авторам курсов и блогов о фронтенде, материал прямо про их нишу. Мейнтейнерам React, Solid, Svelte и Lit, то, насколько охотно выбирают их фреймворк, теперь зависит не только от технических достоинств, но и от того, чему лучше обучены модели. И тем, кто задумывается о консалтинге или продукте для проверки и починки фронтенда, сделанного ИИ на скорую руку.
Как это применить
Выбирая стек для проекта, который будет поддерживать агент, учитывайте не только технические плюсы фреймворка, но и то, насколько он представлен в обучающих данных моделей, экзотичный, пусть и более элегантный инструмент, агенту будет сложнее сопровождать. Для контентных и маркетинговых сайтов сравнивайте тяжёлый React-SPA (одностраничное приложение) с MPA-фреймворками (многостраничное приложение) вроде Astro или Eleventy, по прикидке автора поста, это может дать примерно вдвое меньше кода. Разбирая производительность браузера, можно опереться на Claude: задать модели трассировку Chrome и явно спросить про разницу между стоимостью Style и Layout, именно такой тест описан в разбираемом посте. Стоит заранее думать и о том, насколько сайт удобен для самих ИИ-агентов (ориентир, проект Vercel is-agentic): серверный рендеринг, доступность и скорость страниц теперь работают на два фронта сразу, на живых пользователей и на агентов. И держите в уме растущий спрос на аудит и починку фронтенда, собранного агентом без глубокого понимания задачи.
Можно ли доверять
Это личный блог-пост от первого лица, а не исследование или пресс-релиз: то, что описано, личное наблюдение и личный эксперимент, а не опрос или статистика. Список «уходящих» преподавателей, личное впечатление автора поста, а не подтверждённый перечень: источник сам формулирует это осторожно («кажется, что...») и не уточняет, кто именно и что решил; куда переключились ещё четверо, источник не раскрывает вовсе. Оценка ответа Claude Sonnet («достойный похвалы»), тоже субъективное мнение автора поста, а не независимая экспертиза, хотя в тексте заявлен опыт работы с браузерной производительностью. Часть прогнозов прямо помечена как предположение или догадка, о причине решения Viget, о будущем веб-стандартов, о том, выживет ли веб в нынешнем виде, то есть это открыто заявленные догадки, а не установленные факты.
Риски и подводные камни
Сам автор признаёт: у передачи фронтенда агенту без присмотра риск не нулевой, доступность можно сломать, а бесконечный цикл способен заблокировать пользователей. Растёт объём фронтенд-кода, наспех собранного ИИ без глубокого понимания задачи (vibe coding), и часть такого кода станет критически важной («несущей»), продолжая при этом оставаться медленной, недоступной или дырявой по безопасности, а одной просьбы «почини мой сайт», обращённой к агенту, для этого может не хватить. Отдельный открытый вопрос, который сам автор не закрывает: переживёт ли веб в привычном виде эпоху, когда агенты всё чаще выполняют задачи напрямую, минуя сайты, и что будет с сайтами, которые блокируют ботов или не предлагают интерфейс для агентов (MCP).
«Как бы к этому ни относиться, React непропорционально широко представлен в обучающих данных моделей, и «опыт агента» начинает значить больше, чем опыт разработчика.»
— автор поста