Искусственный интеллект — это не будущее разработки и не игрушка, которую можно игнорировать, чтобы почувствовать свое превосходство. Это скорее очень быстрый джуниор-разработчик, который никогда не устает, иногда с полной уверенностью галлюцинирует и понятия не имеет, зачем вообще существует ваша система.
Если относиться к нему как к магии, он незаметно снизит ваши стандарты. Если использовать его как рычаг (инструмент влияния), он подарит вам дополнительное время.
Это не статья-хайп. Это рассказ о том, как ИИ проявляет себя в повседневной работе старшего фронтенд-инженера.
Где ИИ действительно экономит время
Есть три направления, где ИИ справляется на «отлично» и без лишнего шума.
1. Шаблонный код, который и так понятен
Если я точно знаю, что мне нужно, ИИ отлично подходит для того, чтобы набирать текст быстрее, чем я когда-либо смогу.
Примеры:
- создание нового React-хука с разумными настройками по умолчанию;
- написание базового среза (slice) для Zustand или Redux;
- создание однотипных схем валидации форм;
- быстрая верстка компонента таблицы с пропсами, типами и обработчиками-заглушками.
Я уже знаю структуру. Знаю пограничные случаи. Я просто не хочу набирать текст.
Это важный момент. Как только вы просите ИИ придумать структуру — у вас проблемы. ИИ полезен, когда процесс обдумывания завершен, а узким местом остается только набор текста.
2. Механический рефакторинг
Вот где ИИ незаметно экономит часы работы.
Примеры из реальной практики:
- переименование пропса в 15 компонентах;
- конвертация классовых компонентов в функциональные;
- разделение большого компонента на несколько малых без изменения поведения;
- миграция устаревшей логики из lifecycle-методов на хуки.
Я все равно проверяю каждый дифф. Все равно запускаю приложение. Но черновая работа осталась позади.
Ключевой момент: рефакторинг должен быть механическим, а не концептуальным. Если рефакторинг требует решений о владении, потоках данных или зонах ответственности, ИИ с радостью примет неверное решение, причем сделает это с уверенностью.
3. Каркасы для тестов
ИИ на удивление неплох в написании тестов, если вы относитесь к ним как к каркасу, а не как к истине в последней инстанции:
- генерация базовых файлов тестов для Jest или Vitest;
- мокинг очевидных зависимостей;
- покрытие «счастливых путей» (happy paths) для сосредоточения на граничных случаях.
Не стоит доверять ИИ:
- асинхронные граничные случаи;
- поведение, связанное с таймингами;
- код, критичный к производительности.
ИИ пишет тесты так же, как джуниоры: много зеленых галочек, поверхностная уверенность. Сеньорам все еще нужно добавлять тесты, которые проваливаются, когда что-то выходит из строя.
С чем ИИ не справляется
Эти провалы системны. Если вы обожглись однажды, начинаете замечать их заранее.
1. Архитектура и границы ответственности
ИИ не понимает, почему та или иная граница вообще существует.
Он с радостью:
- приблизит состояние, потому что это покажется ему удобным;
- протащит пропсы глубже, вместо того чтобы подвергнуть сомнению право владения;
- внедрит новые абстракции, потому что в изолированном виде они кажутся чистыми.
Но фронтенд-архитектура строится на компромиссах, а не на чистоте кода.
Почему это состояние глобальное? Почему эта логика намеренно продублирована? Почему этот компонент выглядит слегка странно?
Ответы кроются в контексте, истории и ограничениях. У ИИ ничего этого нет.
2. Рассуждения о производительности
Здесь кроется опасность, потому что код часто выглядит разумно.
Предложения ИИ по оптимизации производительности обычно включают:
- общую мемоизацию;
- обертывание каждой функции в useCallback;
- преждевременное дробление компонентов;
- предложение виртуализации без измерений.
ИИ оптимизирует формы, а не поведение. Настоящая работа с производительностью исходит из понимания:
- частоты рендеров;
- путей обновления состояния;
- поведения браузера;
- паттернов взаимодействия с пользователем.
ИИ не способен запустить приложение у себя в голове. Сеньоры — могут.
3. Асинхронные баги и конкурентность
Асинхронные баги во фронтенде коварны, потому что здесь важны тайминги, а не логика. Вещи, в которых ИИ часто ошибается:
- устаревшие замыкания в хуках;
- состояния гонки между эффектами;
- неправильные массивы зависимостей;
- обработка промисов внутри обработчиков событий.
ИИ может написать асинхронный код. Но он не способен рассуждать о том, когда что-то происходит. Если вы когда-либо отлаживали проблему в продакшене, вызванную пропущенной зависимостью в useEffect, вы уже знаете, почему это важно.
Как все происходит на практике
Использование ИИ ощущается уже не столько как переписка с чат-ботом, сколько как ревью пул-реквеста, который вы сами же и запросили. Вы не доверяете ИИ по умолчанию. Вы не предполагаете, что он прав. Вы просматриваете код в поисках «душка». Вы проводите агрессивное тестирование.
По иронии судьбы, именно поэтому сеньоры выигрывают от ИИ больше, чем джуниоры.
Если вы не знаете, как выглядит хороший код, спешка сослужит вам плохую службу.
Ментальная модель, которая работает
Вот модель, которой я делюсь во время просмотра кода. ИИ — это рычаг, усиливающий ясность, а не ее замена.
- Если проблема неясна, ИИ усилит путаницу.
- Если архитектура слаба, ИИ исправит то, что не нужно.
- Если компромиссы неизвестны, ИИ выберет самый «громкий» вариант.
Но когда вы уже знаете, что нужно построить, ИИ убирает трения.
Думайте об ИИ как о:
- ускорителе процесса набора текста;
- помощнике в рефакторинге;
- генераторе каркасов для тестов.
Но не как о:
- проектировщике систем;
- инженере, повышающем производительность;
- отладчике состояний гонки.
При таком подходе ИИ не делает вас ленивее. Он дает вам больше времени на работу, которая требует опыта. В этом и заключается ценность старших инженеров.
Читайте также:
- Как ускорить full-stack разработку, не создавая API
- Умные инструменты фронтенда: отлавливание ошибки до того, как ее заметят пользователи
- JavaScript async/await: что хорошего, в чём опасность и как применять?
Читайте нас в Telegram, VK и Дзен
Перевод статьи Rahul Dinkar: How Senior Frontend Engineers Actually Use AI at Work
