Осознанный вайб-кодинг

Про вайб-кодинг уже сказано и написано достаточно.

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

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

Чем пользуюсь

Модели

Claude Sonnet 4.5 - на данный момент лучшая модель для кодинга под мои задачи. Чаще всего даёт предсказуемый результат. Пробовал заменять, но полноценной альтернативы для себя пока не нашёл.
GPT 5.2 - использую в основном для общения и проектирования: обсудить идею, набросать план работ, подобрать стек, разложить варианты по плюсам и минусам, структурировать мысли.

Софт

Cursor - уже около года мой основной редактор. Главное преимущество, на мой взгляд, это режим Plan: он задаёт уточняющие вопросы и на выходе формирует MD файл с описанием задачи и списком того, что нужно сделать. Дальше Cursor работает с кодом, ориентируясь именно на этот файл.
Windsurf - начал использовать, когда стало не хватать токенов в подписке Cursor. В бесплатной версии есть GPT 5.2, чего вполне хватает для не самых сложных задач. Хорошо подходит для проектирования, прототипов и быстрых экспериментов. (а ещё там можно генерировать сколько угодно новых аккаунтов на 10 минутную почту)

Пет-проекты

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

Так сейчас выглядят мои первые шаги при создании нового проекта:

1. Появляется идея. Например, сервис для учёта финансов. Я обсуждаю её с ChatGPT: в каком виде лучше реализовать, на каких технологиях, как это можно хостить, что в итоге хочется получить. Прошу задать 10–15 вопросов, ответы на которые помогут при построении плана.

2. После этого прошу построить план с учётом моих ответов и контекста диалога. Получаю MD файл, внимательно его просматриваю, собираю свои вопросы, что-то уточняю и правлю. Когда файл становится понятным и логичным - считаю его готовым к работе.

3. Кладу этот файл в пустую папку проекта, передаю его как контекст в чат и прошу построить архитектуру и установить зависимости. Параллельно вручную накидываю свои конфиги для eslint, prettier, editorconfig и правлю мелочи, которые для меня важны и привычны.

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

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

Плюс ко всему, нейросеть в таком случае получает на вход не 3-4 абстрактных предложения, а вполне внятное и структурированное описание задачи, с которым она работает заметно лучше.

Рабочие задачи

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

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

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

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

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

Также я почти всегда прошу такие банальные вещи как:

• использовать бест практики

• задавать мне вопросы до написания кода

• уточнять моменты, связанные с масштабируемостью

• думать о переиспользовании решений

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

Мой рабочий процесс обычно выглядит так:

1. Беру текст задачи или формулирую его сам. Прикладываю максимум файлов и примеров, заранее говорю, какие новые файлы нужно создать и где они должны лежать. В конце прошу задать дополнительные вопросы и уточнить цель работы.

2. Отвечаю на вопросы, читаю фидбек нейросети, оцениваю, насколько она "в контексте", и только после этого даю команду приступать.

3. Первая итерация почти всегда выглядит как грубо обтёсанный кусок камня. Дальше я прохожусь по коду построчно: правлю стиль, выравниваю подходы, убираю шероховатости. На этом этапе важно не делать крупных переделок, цель - получить рабочее решение.

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

Цель такого подхода - сместить фокус с ручного решения задачи на управление процессом. Меньше механических действий и больше контроля над результатом.

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

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

Границы вайб-кодинга

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

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

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

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

Вывод

Для меня вайб-кодинг - это не попытка переложить ответственность на нейросеть и не способ "писать код не думая". Это инструмент, который помогает быстрее пройти путь от идеи к результату, если ты понимаешь, что именно делаешь и зачем.

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