#рецепт
Манифест вайбинжиниринга: что надо делать, чтобы не ловить фейспалмы (часть 1)

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

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

1️⃣ Чёткое проектирование: Формализуй архитектуру, схемы БД, правила именования и OpenAPI с первого дня, минимизируя семантическую энтропию;

2️⃣ Монорепозиторий и единая БД: Используй один репозиторий и одну БД с разделением на схемы. Даже не пытайся делать в отдельных репозиториях, это ужасно;

3️⃣ Семантическая разметка: Веди anchors в коде и документации, минимизируй интерференцию, связывай через graph-обход;

4️⃣ Три линтера: Именование (snake_case, kebab-case), семантическая разметка, OpenAPI/события — запускай с первого коммита;

5️⃣ Юнит-тесты: Покрывай все API, очереди, интеграции с первого дня, пиши простые тесты;

6️⃣ Логирование: Раздели на public (для Grafana) и dev (с файлами/строками), структурируй в JSON с trace_id, user_id;

7️⃣ Безопасность: Храни креды только в auth-схеме, передавай через защищённые каналы, не индексируй в git. ЖЕСТКО ОПИШИ ЭТО ПРАВИЛАМИ и желательно покрой тестами;

8️⃣ Документация на английском: Веди строго структурированную, с anchors, синхронизируй с кодом. К сожалению, на русском больше чудит любая модель и любой сервис;

9️⃣ OpenAPI и REST: Полные схемы request/response, CRUDL, описание ошибок для каждого endpoint'а;

🔟 Внешние сущности: Для каждой сущности — external_id, external_name, external_value_id, id (UUID) в clean-схеме;

1️⃣1️⃣ Docker-compose: Единый для всех сервисов, БД, BI (Metabase), с поддержкой локального/VPS деплоя;

1️⃣2️⃣ Мониторинг и телеметрия: С первого дня интегрируй Grafana/Prometheus для публичных логов и метрик;

1️⃣3️⃣ Self-hosted флоу: Поддерживай установку локально/VPS, админка для настройки интеграций, выбор проектов/параметров;

1️⃣4️⃣ Технофашизм: Жёстко следи за правилами, линтерами, тестами и документацией, чтобы код не превратился в хаос;

1️⃣5️⃣ На полную пользоваться всё-таки git, особенно github flow, потому что его придумали не просто так. И в случае вайб-инжиниринга больше всего работает именно он. И вырабатывать привычку атомарных коммитов, прям на уровне “меняю хоть что-то — коммит”, и все фичи, любые маломальские изменения — всегда в отдельных бранчах;

1️⃣6️⃣ Не писать самостоятельно промпты вообще никогда, ни в коем случае. Всегда, если тебе нужно сделать что-то новое, сперва излагай свои мысли в каком-нибудь Google AI Studio, в каком-нибудь Gemini 2.5 Pro. И только после этого копируй этот промпт на английском, когда он учитывает все моменты, когда он тебя поспрашивал, когда ты воспользовался действительно полным флоу устранения галлюцинаций и критическим мышлением;

P.S. Я по сути не инженер и не разработчик, но за 9 месяцев вайбкодинга и перманентного обучения уже могу писать +- продакшн код на уровне junior + <-> middle - и вступать в осознанные архитектурные дискуссии, которые помогают компании. Ну и просто очень быстро учусь