Сейчас vibe coding обычно означает: описал задачу для нейросети – получил готовый код. Но у этого выражения есть и другой смысл. Им можно описать часть работы руководителя. Когда в команде такая атмосфера, что можно высказывать разные мнения, спорить по существу, показывать сырой результат, задавать «глупые» вопросы и честно говорить о рисках. И при этом – отвечать за качество. Это не про дружбу, корпоративы или обязательный позитив. Хороший вайб – часть инженерной системы. Он влияет на качество решений, предсказуемость релизов и на то, смогут ли специалисты работать долго и не выгореть за полгода.

Культуру видно в мелочах Культуру команды не видно на доске почета. Её видно в обычных рабочих моментах. В первом комментарии к спорному pull request, например. Можно ли написать: «Я не понимаю, почему это правильное решение» – и не выглядеть слабым? Что происходит, если задача оказалась сложнее оценки? Можно ли остановить релиз, заметив риск? Кто отвечает за инцидент: автор последнего коммита или команда, которая разбирает, где система дала сбой? В слабой среде люди не показывают незаконченный код, потому что боятся критики. Code review воспринимается как личная атака. Все живут в режиме постоянного дедлайна и предпочитают промолчать, если не согласны. Или обсуждают проблему в кулуарах, когда решение уже принято. В здоровой – ранняя обратная связь считается нормой. Code review защищает продукт, а не решения. Ошибки разбирают через процессы, а не через поиск виноватого. Можно жёстко спорить о подходах, но оставаться уважительными к людям.

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

Безопасность без снижения качества Можно не знать, ошибиться или изменить мнение. Но подсветить риск, принять замечания и не перекладывать ответственность. Безопасность – это не отсутствие требований. Это возможность честно сказать о проблеме до того, как она стала инцидентом.

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

Прямой разговор о работе Вайб, как и культуру, надо выращивать. Следить за собой: вместо «плохой код» – «при повторном запросе состояние может разъехаться; давай оставим один источник истины». Важно обсуждать риск и предлагать альтернативное решение, а не обесценивать первоначальный подход и не оценивать человека.

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

Устойчивый ритм Факапы случаются, но они не должны быть моделью работы. Героизм из-за плохого планирования не стоит романтизировать: он обычно означает, что система снова дала сбой. Устойчивая скорость ценнее героической недели.

Роль руководителя Такой вайб не создаётся тимбилдингом и не принадлежит HR. Его задаёт лидер – тем, что делает допустимым, особенно когда команда под давлением. Он признаёт ошибки, спрашивает мнение до того, как озвучивает своё, даёт обратную связь по решению, а не по личности. Делает явными договорённости: что блокирует релиз, когда эскалировать спор, какие решения нужно записывать. И защищает фокус команды: объясняет контекст, формулирует приоритет, помогает убрать второстепенное и делает цену срочности видимой, а не просто транслирует сверху очередной срок.

Лучшие команды, в которых мне хотелось работать, не обязательно были тихими и всегда согласными. Они были честными, требовательными и достаточно безопасными, чтобы не тратить силы на самозащиту. Эти силы уходили в продукт. Именно такую инженерную среду я хочу помогать строить.