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

Содержание

Обучение: почему боль — это не баг, а фича
Сложные анимации
Низкоуровневая оптимизация
Архитектурные решения
Этические решения
Как использовать ИИ правильно: просить объяснений, а не готовых решений

Часть 1. Что происходит, когда вы просите готовое решение

Вы изучаете замыкания в JavaScript. Читаете статью, понимаете не до конца, открываете чат и пишете: «Напиши пример замыкания». Получаете красивый код, вставляете в редактор — работает. Идёте дальше.

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

Это и есть проблема. Готовое решение создаёт иллюзию понимания. Вы видели код, он работал — значит, вы разобрались. Но мозг так не работает. Понимание приходит не от просмотра правильного ответа, а от борьбы с задачей.

Что такое «обучение через боль»

«Боль» здесь — не страдание. Это момент, когда вы застряли, не знаете как двигаться дальше и вынуждены думать. Именно в этот момент мозг строит новые связи.

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

Разработчики с опытом знают это интуитивно. Баг, который вы искали три часа, вы не забудете никогда. Баг, который нашёл линтер автоматически, вы не запомните вообще.

Пример: изучаем useEffect

Допустим, вы не понимаете, зачем в useEffect нужен массив зависимостей. Вот два пути:

Путь 1 — с ИИ:

// Просите нейросеть:
Напиши компонент, который загружает данные пользователя
по id через useEffect.

// Получаете:
useEffect(() => {
  fetchUser(userId).then(setUser);
}, [userId]);

// Вставляете. Работает. Идёте дальше.

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

Путь 2 — руками:

// Пишете сами, без массива зависимостей:
useEffect(() => {
  fetchUser(userId).then(setUser);
});

// Открываете браузер. Видите, что запросы идут бесконечно.
// Начинаете разбираться. Добавляете пустой массив — запрос один раз.
// Добавляете [userId] — запрос при каждом изменении id.
// Вот теперь вы понимаете, зачем это нужно.

Второй путь дольше. Но только он даёт настоящее понимание.

Правило для обучения

Если тема новая — сначала попробуйте сами. Потратьте на задачу минимум 20–30 минут в попытках разобраться. Застряли — посмотрите документацию, почитайте статьи. Совсем не идёт — тогда можно спросить у нейросети, но не готовый код, а объяснение.

Разница между этими запросами огромная:

// Плохо для обучения:
Напиши функцию, которая делает глубокую копию объекта.

// Хорошо для обучения:
Я пытаюсь написать функцию глубокого копирования объекта.
Вот что у меня получилось: [ваш код]
Объясни, почему это не работает для вложенных объектов.
Не пиши готовое решение — объясни принцип.

Первый запрос даёт вам рыбу. Второй учит рыбачить.

Часть 2. Сложные анимации

Почему анимации — особый случай

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

Когда вы получаете готовый код анимации, вы получаете набор чисел. Вы не понимаете, почему cubic-bezier(0.4, 0, 0.2, 1) выглядит лучше, чем ease-in-out. Вы не знаете, что делать, если анимация дёргается на слабом устройстве. Вы не можете её доработать, не сломав.

Что нужно понять руками

Принцип 12 принципов анимации

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

Разница между transform и изменением положения

Браузер перерисовывает страницу по-разному в зависимости от того, что вы анимируете. Изменение left и top вызывает перекомпоновку всей страницы — это дорого. Изменение transform: translate() происходит на уровне видеокарты — это бесплатно.

/* Медленно — браузер пересчитывает положение всех элементов */
.box {
  transition: left 0.3s ease;
}

/* Быстро — только этот элемент, на видеокарте */
.box {
  transition: transform 0.3s ease;
}

Это различие невозможно почувствовать, глядя на код, написанный нейросетью. Его нужно увидеть: написать анимацию через left, посмотреть, как она дёргается на слабом компьютере, переписать через transform, увидеть разницу.

Пример: анимация появления карточки

Попробуйте написать такую анимацию руками, без подсказок:

/* Шаг 1. Напишите базовое появление */
@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1; }
}

/* Запустите. Посмотрите. Скорее всего, выглядит скучно. */

/* Шаг 2. Добавьте движение снизу вверх */
@keyframes slideUp {
  from {
    opacity: 0;
    transform: translateY(16px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

/* Поиграйте с числами. 8px — слишком мало? 32px — слишком много? */

/* Шаг 3. Подберите кривую */
animation: slideUp 0.3s ease-out;
/* Попробуйте ease, ease-in, ease-out, ease-in-out */
/* Почувствуйте разницу */

Этот процесс подбора — и есть обучение. Нейросеть даст вам сразу «правильный» ответ, но вы не будете знать, почему он правильный и как его менять под другую задачу.

Когда можно подключить ИИ

После того как вы понимаете основы: написали несколько анимаций вручную, знаете разницу между кривыми, понимаете, что влияет на производительность. Тогда нейросеть полезна для рутины: сгенерировать набор keyframes для сложной последовательности, подобрать значения cubic-bezier.

Часть 3. Низкоуровневая оптимизация

В чём сложность

Оптимизация производительности — это детективная работа. Сначала нужно найти проблему, потом понять её причину, и только потом — исправить. Нейросеть умеет исправлять. Находить и понимать — значительно хуже.

Если вы отдаёте оптимизацию нейросети без понимания, что происходит, вы рискуете получить код, который работает на вашей машине и ломается у пользователя. Или код, который решает не ту проблему.

Задачи, которые нужно делать самому

Профилирование и поиск узких мест

Инструменты разработчика в браузере — вкладки Performance и Memory — это навык, который нарабатывается только практикой. Научитесь читать flame chart: вертикальная ось показывает глубину стека вызовов, горизонтальная — время. Широкий прямоугольник в самом верху — это то, что тормозит всё остальное.

// Пример: вы видите, что список из 1000 элементов рендерится медленно.
// Нейросеть предложит виртуализацию (react-window).
// Но сначала откройте профайлер и проверьте:
// - Действительно ли проблема в количестве элементов?
// - Или каждый элемент делает тяжёлые вычисления?
// - Или дело в лишних перерендерах?

// Ответы разные — решения разные.

Понимание того, как браузер рисует страницу

Браузер проходит через несколько шагов при отрисовке: разбор HTML и CSS, построение дерева элементов, вычисление расположения, отрисовка, наложение слоёв. Если анимация или обновление данных задевает первые шаги — страница тормозит. Это знание нужно именно вам, а не нейросети, потому что только вы видите реальный профиль вашего приложения.

Оптимизация перерендеров в React

Нейросеть знает про React.memo, useMemo, useCallback. Она охотно добавит их везде, если попросить. Но бездумное добавление мемоизации может сделать код медленнее: каждый вызов useMemo и useCallback — это тоже вычисление, которое нужно оплатить.

// Нейросеть добавит memo везде:
const MyComponent = React.memo(({ items }) => {
  const sorted = useMemo(() => [...items].sort(), [items]);
  const handleClick = useCallback(() => { ... }, []);
  return <div>...</div>;
});

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

// Правильный подход: сначала измерить.
// React DevTools → Profiler → посмотреть, что рендерится лишний раз.
// Потом — оптимизировать именно это.

Это нельзя делегировать. Нейросеть не видит ваш профиль. Она оптимизирует код в вакууме.

Практика: что сделать руками

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

Часть 4. Архитектурные решения

Почему архитектуру нельзя делегировать

Архитектура приложения — это решения, которые дорого менять. Как разделить данные и представление. Где держать глобальное состояние. Как организовать папки. Как компоненты будут общаться между собой.

Нейросеть даст вам ответ на эти вопросы. Но её ответ не учитывает размер вашей команды, привычки ваших коллег, историю проекта и задачи, которые придут через полгода. Архитектурное решение — это всегда компромисс между несколькими факторами, и только вы знаете их все.

Пример: выбор подхода к управлению состоянием

// Вопрос нейросети:
Какой менеджер состояния использовать для React-приложения?

// Нейросеть ответит что-то вроде:
// Redux Toolkit — для больших приложений,
// Zustand — для простых случаев,
// React Query — если данные приходят с сервера.

// Это полезная информация. Но решение зависит от:
// - Сколько человек в команде? Все знают Redux?
// - Есть ли уже другие решения в проекте?
// - Какие данные нужно хранить? Только серверные или локальные тоже?
// - Будет ли проект расти или это небольшой инструмент?

Нейросеть не знает ответов на эти вопросы. Вы — знаете. Поэтому решение принимаете вы.

Что нейросеть может сделать полезного

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

Часть 5. Этические решения

Код, который влияет на людей

Некоторые задачи выглядят как технические, но на самом деле являются этическими. Нейросеть напишет код, но она не несёт ответственности за последствия. А вот вы — да.

Сбор и хранение данных

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

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

Интерфейсы с манипулятивными паттернами

Тёмные паттерны — это приёмы в интерфейсе, которые подталкивают пользователя к действию против его интересов. Скрытые подписки, запутанные настройки отписки, кнопки «Принять» и «Отказаться» разного размера.

// Вам говорят: «Сделай кнопку отписки менее заметной».
// Нейросеть напишет:
.unsubscribe-btn {
  color: #bbb;
  font-size: 11px;
  border: none;
  background: none;
}

// Технически — выполнено. Но правильно ли это?
// Это ваш вопрос, не нейросети.

Разработчик — не просто исполнитель задач. Когда вы видите задачу, которая нарушает интересы пользователей, ваша работа — это заметить и поднять вопрос, а не молча написать код.

Алгоритмы с предвзятостью

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

Правило простое

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

Часть 6. Как использовать ИИ правильно: просить объяснения, а не готовые решения

Принцип «используй, чтобы учиться, а не чтобы обходить учёбу»

Нейросеть — отличный учитель, если правильно с ней работать. Разница между «учиться с ИИ» и «обходить учёбу с помощью ИИ» — в типе запросов.

Запросы для обучения

Попросите объяснить, а не написать

// Вместо:
Напиши функцию дебаунса на JavaScript.

// Спросите:
Объясни, как работает дебаунс. Почему он использует замыкание?
Что происходит с таймером при каждом вызове?
Не пиши код — объясни принцип.

Проверьте своё понимание

// После того как разобрались в принципе — напишите сами.
// Потом попросите проверить:

Вот моя реализация дебаунса: [ваш код]
Что здесь неправильно или можно улучшить?
Объясни почему.

Попросите объяснить чужой код

// Нашли непонятный код в проекте:
Объясни, что делает этот код построчно: [код]
Почему здесь используется именно такой подход?
Какие есть альтернативы?

Задавайте вопрос «почему»

// Нейросеть написала решение — не принимайте его как данность:
Ты использовал reduce вместо forEach. Почему?
В каком случае forEach был бы лучше?

Когда нейросеть точно полезна

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

Написать шаблонный код, который вы уже понимаете (формы, таблицы, стандартные хуки).
Написать тесты для кода, который вы уже написали руками.
Найти опечатку или синтаксическую ошибку.
Перевести код с одного стека на другой, когда вы понимаете оба.
Написать документацию к готовому коду.
Сгенерировать примеры данных для тестирования.

Ключевое слово во всех этих случаях — вы уже понимаете, что делаете, и представляете конечный результат. Тогда нейросеть ускоряет процесс, но не заменяет понимание.

Простой тест

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

Если да — это задача, которую нужно делать самому. Или как минимум делать вместе с нейросетью, но с полным пониманием каждой строки.

Если нет — смело делегируйте. Вы понимаете область, вы проверите результат, вы несёте ответственность за код.

Итог

Нейросеть — мощный инструмент. Как и любой мощный инструмент, она усиливает то, что уже есть. Если есть понимание — она ускоряет работу. Если понимания нет — она создаёт иллюзию компетентности, которая рассыпается при первой же нестандартной ситуации.

Задачи, где важно написать руками:

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

Во всех остальных случаях — используйте нейросеть. Она для этого и нужна.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Телеграм Подкаст Бесплатные учебники

Когда разработчику НЕ нужно использовать ИИ? Большой разбор