Запрос «какой ИИ лучше пишет код» звучит разумно, но почти всегда ведёт к неправильному сравнению. Сегодня один инструмент выигрывает тест, через месяц выходит новая модель, а ещё через месяц меняются тарифы и ограничения. Таблица устаревает раньше, чем вы успеваете к ней привыкнуть.

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

Условно ИИ для кода можно разделить на три типа.

Граница между типами не жёсткая. Современные продукты часто совмещают несколько режимов. Например, документация Cursor описывает поиск по кодовой базе, редактирование, запуск команд и просмотр изменений, а GitHub Copilot разделяет Ask, Plan и Agent. Важен не ярлык в интерфейсе, а доступный вам рабочий цикл: что инструмент видит, что может изменить и как показывает результат. Cursor Agent, GitHub Copilot Chat.

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

AI-редактор удобнее, когда ценность лежит в контексте. Просьба «переименуй поле во всех местах и обнови тесты» бессмысленна без доступа к файлам и связям между ними.

Агент нужен, когда работа превращается в цепочку: изучить проект, составить план, изменить несколько файлов, запустить приложение, увидеть ошибку и исправить её. В официальных примерах Codex такие задачи включают разбор кодовой базы, прототипирование, тестирование и проверку изменений. Codex use cases.

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

Хороший ответ начинается не с размера модели, а с доступного ей контекста. Видит ли инструмент только вставленный фрагмент? Может ли найти связанные файлы? Понимает ли правила проекта и предыдущие решения?

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

Проверка: попросите инструмент найти все места, которые придётся изменить при переименовании одного поля, но пока ничего не редактировать. Сильный ответ перечислит файлы и объяснит связи. Слабый сразу предложит код для первого попавшегося компонента.

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

Такие возможности есть, например, у Cursor и GitHub Copilot Agent. Cursor документирует поиск по проекту, редактирование и запуск команд, а GitHub Copilot Agent может разбивать задачу на шаги, менять код и итеративно исправлять ошибки. Cursor Agent overview, GitHub Copilot Agent mode.

Но наличие кнопки «Agent» ничего не гарантирует. Проверка: дайте небольшую задачу с однозначным результатом, например добавить валидацию одного поля и тест на пустое значение. Смотрите не только на патч, но и на то, запустил ли инструмент проверку и сообщил ли о её результате.

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

• какие файлы изменятся;

• какие команды будут запущены;

• просит ли агент доступ к сети или внешнему сервису;

• как отменить результат;

• где посмотреть разницу между версиями.

Некоторые инструменты дают отдельный просмотр diff, режим планирования и настройки разрешённых команд. В Claude Code, например, документация описывает режимы доступа и списки разрешённых или запрещённых инструментов. Claude Code CLI reference.

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

Git остаётся страховкой независимо от выбранного продукта: история изменений помогает сравнить версии и вернуться к рабочему состоянию. Git: About Version Control.

Инструмент может быть сильным в тестах и неудобным именно вам. Проверьте четыре бытовых ограничения:

• работает ли он в вашей операционной системе и привычном редакторе;

• можно ли использовать ваш язык и стек;

• хватает ли доступного режима на обычную неделю, а не на одну демонстрацию;

• допустимо ли передавать ему код и данные конкретного проекта.

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

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

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

Например: «В форме регистрации поле телефона должно быть обязательным. При пустом значении покажи ошибку рядом с полем и добавь тест на этот сценарий».

Дальше работайте с каждым кандидатом одинаково:

1. Дайте ссылку на один и тот же проект или одинаковый набор файлов.

2. Попросите сначала найти связанные места и предложить план без изменений.

3. Разрешите реализацию.

4. Попросите запустить подходящую проверку.

5. Посмотрите diff и задайте один уточняющий вопрос по решению.

6. Верните проект к исходной версии перед вторым тестом.

Сравнивайте не красоту ответа, а процесс:

Такой тест не определяет абсолютного победителя. Он отвечает на более полезный вопрос: какой инструмент создаёт меньше лишней работы в вашем обычном сценарии.

Курс «Вайбкодинг на максималках» строится не вокруг рейтинга моделей, а вокруг полного цикла: постановка задачи, работа с Codex и VS Code, Git, ошибки, база данных и деплой. Такой навык переносится на следующий инструмент лучше, чем заученный набор кнопок.

Посмотрите, где возникла самая дорогая ручная работа.

Если инструмент изменил первый найденный файл и пропустил связанные места, вам нужен режим с более глубоким контекстом проекта. Если он предложил правдоподобный код, но не смог запустить проверку, ищите доступ к терминалу и тестам. Если правка получилась, но её трудно понять и отменить, приоритетом становится прозрачный diff и управление действиями агента.

Бывает и обратная ситуация: оба кандидата справились, но один потребовал больше настроек, подтверждений и ручной передачи файлов. Тогда выбирайте более простой рабочий путь. Дополнительная автономность не даёт пользы сама по себе.

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

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

1. Видит ли инструмент нужный контекст?

2. Может ли выполнить и проверить задачу?

3. Понимаете ли вы его действия и можете ли их отменить?

4. Подходит ли он к вашим проектам и ограничениям?

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