Статьи
Vibecoding: написание софта через разговор
Вы описываете, что хотите, и AI пишет код. Это работает на удивление хорошо — и ломается ровно там, куда вы не смотрите.
Термин новый, практика — не очень. Vibecoding — это написание софта, когда вы описываете желаемый результат обычным языком, а AI выдаёт код. Вы читаете, говорите, что не так, и повторяете.
Почему это вообще работает#
Код для машины проще прозы. У него строгий синтаксис, огромный корпус публичных примеров и мгновенная обратная связь: запускается или нет. На коде модели обучены плотнее, чем почти на чём-либо ещё.
Где это действительно работает#
Прототипы. Проверить идею за два часа вместо двух дней. Здесь польза очевидна.
Рутинный код. Формы, таблицы, преобразование данных, скрипты. Скучный код, который никто не хочет писать.
Незнакомый язык или фреймворк. Если вы умеете программировать, но не именно на этом языке, с AI вы стартуете гораздо быстрее.
Тесты. Одно из самых благодарных применений: писать тесты важно и нудно.
Где это ломается#
Когда вы не умеете читать код. Это суть всего. Код от AI всегда выглядит хорошо. Если вы не можете оценить, верен ли он, — вы не знаете, верен ли он. Та же проблема, что с галлюцинациями, только последствия исполняемые.
Безопасность. Модель пишет работающий код. Работающий не значит безопасный. Аутентификация, проверка прав, валидация ввода — там, где ответ по умолчанию часто неполон.
Архитектура. AI хорош внутри файла. Он гораздо хуже в том, как двадцать файлов должны общаться между собой. Крупные структурные решения остаются за вами.
Технический долг. Быстрый результат, который никто не просмотрел, через три месяца становится кодом, который никто не решается трогать.
Что всё равно нужно уметь#
Честно: больше, а не меньше, чем кажется на первый взгляд.
Нужно уметь читать код и понимать, что он делает. Нужно знать, как выглядит хороший вопрос. Нужно замечать, когда ответ правдоподобен, но неверен. И нужно уметь тестировать.
Vibecoding не превращает непрограммиста в программиста. Он превращает среднего программиста в более быстрого — а новичка в человека, производящего код, который он не в состоянии оценить.
Практический совет#
Смело используйте для прототипов и рутины. Просматривайте весь код так, как просматривали бы pull request коллеги. Пишите тесты. И чем ближе продукт к реальным пользователям и реальным данным, тем больше человека должно оставаться в контуре.