Нейронки

Подключите к Claude Code собственный MCP-сервер с одной функцией: получить вымышленный товар по идентификатору. Проверим результат, отсутствие товара и недоступность записи. Так будет видно, что агент действительно вызвал программу и какие действия она ему предлагает.

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

Сохраните проверку формы в SKILL.md, чтобы Claude Code каждый раз сверял одинаковые критерии. В упражнении навык найдёт несвязанный label и неправильный тип кнопки, а затем проверит исправную форму без выдуманных замечаний.

Команда claude должна открывать агент в нужной папке проекта. На Windows сначала выберите среду, затем проверьте установку и оболочку: это поможет отличить ошибку PATH от проблемы входа или выполнения команд.

Кнопка в карточке выходит за край экрана. Исправим её с помощью Claude Code в VS Code: подключим официальный инструмент, передадим нужные файлы и проверим предложенную правку по коду и в браузере.

Поручите Claude Code добавить поиск в учебный каталог и принимайте изменение по поведению страницы. Заранее задайте случаи проверки: тогда объяснение агента можно сверить с кодом, а спорную правку вернуть с точной причиной.

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

Вы открываете проект утром, копируете в нейронку задачу, получаете красивый компонент — и начинаете его переделывать. Меняете названия переменных, добавляете проверку данных с сервера, убираете стили, которые конфликтуют с общей темой. Знакомо?

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

Эта статья о том, как правильно описывать задачу, чтобы получить рабочий код с первого раза. Разберём три главных направления: компоненты, стили и тесты. А ещё поговорим о том, как давать нейросети контекст — описание данных с сервера и правила дизайн-системы.

Или: как одна нелепая строка кода дала ускорение в 100 раз.

Всегда знаешь, что попался хороший баг, когда первая реакция — «как такое вообще возможно?»

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

Естественно, я обвинил React.

Ну, конечно, в современном веб-приложении источников проблем с производительностью хватает: сторонний JavaScript, перегруженные серверы, раздутые ресурсы, отсутствующие индексы в базе данных — длиннющий список. Но десятилетия разработки для веба подсказывали: это проблема фронтенда. Я просто чувствовал это. Страница выглядела дёргающейся при загрузке. А экосистема React, при всей своей относительной приемлемости сегодня, полна способов превратить кодовую базу в запутанный тормозящий клубок.

Чтобы подтвердить теорию, я объяснил Claude, что панель загружается медленно, что наверняка виноват React, и попросил проанализировать проблемы и отсортировать их по серьёзности. И действительно, Claude нашёл кучу подозрительного в React: лишние перерисовки, пропущенные мемоизации. Выяснилось, что мы ещё не перешли на React Compiler. Я попросил Claude сделать первый проход по самым простым и серьёзным проблемам, и…

Это почти ничего не дало. Может, дело не в React?

Засучил рукава и начал разбираться по-настоящему.

1. Может, сервер медленный? Немного — но фронтенд он не блокирует.
2. Проблема во всех браузерах? Нет. Почему-то только в Safari.
3. Значит, виноват сторонний JavaScript? Intercom? Нет. PostHog? Нет.
4. Ладно, роем глубже — смотрим временную шкалу производительности.

Инспектор производительности Safari за последние годы заметно разошёлся с инструментами на основе Chromium и на этой странице работал капризно. Но картину он нарисовал вполне отчётливую: 7+ секунд тратились не на разбор JavaScript, не на вычисление стилей и не на загрузку сети. 94% процессора на M1 Max уходило на… компоновку вёрстки?

В подробностях было видно несколько проходов компоновки длительностью более 1600 мс каждый. Для сравнения: это примерно в 100 раз медленнее нормы. Что-то было серьёзно не так с тем, как браузер выстраивал страницу. Flexbox может чуть замедляться, но не настолько же.