VibeeИИ для программирования сегодня уверенно закрывает типовой, хорошо описанный код и заметно хуже справляется с задачами внутри большой системы, которую нужно держать в голове целиком. Разница не в «умности модели», а в том, сколько неявного контекста требует задача.
Ниже — по классам задач, с измерениями там, где они есть, и без обещаний ускорения в разы.
Что вообще называют ИИ для кода
Под «нейросетью для программирования» в разговоре мешают четыре разные вещи:
- Автодополнение — дописывает строку или функцию прямо в редакторе.
- Чат — отвечает текстом, код вы переносите руками.
- Агент — сам правит файлы, запускает команды, читает вывод. Разница с чатом принципиальная, она разобрана в отдельной статье про агентов.
- Модель — то, что стоит под всеми тремя. Одна и та же модель в чате и в агенте даёт очень разный результат, потому что у агента есть доступ к реальности: он может запустить код и увидеть ошибку.
Когда сравнивают «ИИ для кода», чаще всего сравнивают именно обвязку, а не модель.
Где выигрыш заметен
Задачи, на которых модели стабильно экономят время:
- Код, который вы уже писали десять раз. Форма, CRUD, парсер конфига, обёртка над API, миграция формата. Здесь нет неявного контекста — есть шаблон.
- Незнакомый язык или фреймворк. Вы знаете, что нужно, но не знаете синтаксиса и идиом. Модель даёт рабочий каркас, вы правите смысл.
- Одноразовые скрипты. Переименовать тысячу файлов, вытащить данные из выгрузки, посчитать статистику по логам. Результат виден сразу, цена ошибки — перезапустить.
- Объяснение чужого кода. Прочитать функцию на 200 строк и рассказать, что она делает — модель делает это быстрее и обычно верно.
- Тесты по готовому коду. Скучная, механическая, хорошо формализуемая работа.
- Первый черновик документации. С последующей вычиткой — модели склонны описывать намерение, а не поведение.
Где выигрыша нет
- Тонкая логика в системе, которую вы знаете наизусть. Объяснить контекст дороже, чем сделать.
- Задачи, где «работает» ≠ «правильно». Права доступа, платежи, миграции данных, персональные данные. Запуск ничего не докажет.
- Производительность. Модель напишет корректный код, который делает пять запросов к базе там, где нужен один. Симптома не будет, пока не вырастут данные.
- Решения об архитектуре. Модель охотно согласится с любым вашим вариантом и обоснует его. Это не экспертиза, это вежливость.
- Всё, что зависит от свежих фактов. Версии, лимиты, цены, статусы API. Проверяйте по документации поставщика, а не по ответу модели.
Что показывают измерения
Публичных цифр немного, и они не совпадают с ощущениями пользователей — это отдельно интересно.
METR, июль 2025. Рандомизированный эксперимент: 16 опытных разработчиков открытых проектов, 246 реальных задач в репозиториях, где у них в среднем пять лет опыта. С разрешёнными ИИ-инструментами задачи заняли на 19% больше времени. При этом до начала участники ожидали ускорения на 24%, а после — считали, что ускорились примерно на 20%.
Из этого не следует, что инструменты бесполезны. Следует другое: сценарий «опытный разработчик, знакомый большой проект» — как раз тот, где выигрыш не гарантирован, а ощущение выигрыша появляется всё равно. Собственному впечатлению «стало быстрее» доверять нельзя, нужен секундомер.
Stack Overflow, опрос 2025 года. 84% разработчиков используют ИИ-инструменты или собираются, но доверяют точности их вывода 29% — против 40% годом раньше. Активно не доверяют точности 46%. Самая осторожная группа — опытные разработчики.
Разрыв между принятием и доверием — не противоречие. Люди пользуются инструментом и одновременно знают, что проверять придётся. Это здоровая позиция, и она задаёт правильный рабочий процесс.
Правила: отдавать или делать самому
Четыре вопроса перед тем, как отдать задачу модели:
- Смогу ли я проверить результат? Не «прочитать код», а именно проверить: запуском, тестом, сверкой с известным ответом. Нет — не отдавать.
- Сколько контекста нужно объяснить? Больше, чем сам код, — делать самому.
- Что случится, если оно тихо неправильное? Испорченный файл — ничего страшного. Испорченная база или утёкший ключ — сначала стенд, потом всё остальное.
- Это шаблон или решение? Шаблон отдаём, решение принимаем сами, а модель просим найти дырки в нём.
Что происходит с качеством кода
Главный систематический эффект — не ошибки, а размножение. Модель охотнее напишет новую похожую функцию, чем найдёт и переиспользует существующую: искать дороже, чем сгенерировать. За несколько месяцев это превращается в проект, где одно и то же сделано четырьмя способами.
Что помогает:
- Проговаривать существующие решения прямо в задаче: «используй уже имеющийся хелпер, не пиши новый».
- Держать в проекте файл с правилами — конвенции, запреты, куда что класть. Агенты его читают.
- Регулярно спрашивать у агента обратное: «найди в проекте дублирующуюся логику и предложи, что объединить».
Второй эффект — код, который выглядит правильно. Аккуратные имена, комментарии, обработка ошибок — и посередине неверное условие. Такой код проходит беглый просмотр лучше, чем человеческий черновик, и именно поэтому нужен формальный этап проверки, а не «на глаз».
Если вы только начинаете — практический старт с контрольными точками собран в статье вайбкодинг с нуля, а выбор инструмента разобран в обзоре инструментов. Отдельный порядок действий для приёмки результата — в статье как проверять код от ИИ.