Йоу, котятки Я тут уже проделал большую работу на пару месяцев, делаю базу стандартов для разработки и зову всех участвовать.
Поскольку мы уже с вами не программисты, а больше архитекторы, то и диктуем правила: вот так называем таблицы вот так отвечает бэк вот так организуем API вот так пишем миграции вот так даем контекст агенту вот так не превращаем репозиторий в болото
Потому что без стандартов начинается классика жанра. В одном проекте таблица называется users, в другом user, в третьем app_users, а потом агент такой: “я понял архитектуру” нет, брат, не понял. В одном сервисе ошибки API выглядят так: { "error": "Something went wrong" } В другом так: { "message": "validate input", "code": 400 } А в третьем просто HTML-страница от nginx, потому что почему бы и нет. Где-то миграции нормальные: 001_create_users.sql 002_add_sessions.sql А где-то: new.sql fix.sql fix_final.sql real_final_2.sql Где-то бизнес-логика лежит в service layer, а где-то SQL-запрос внезапно живет в React-компоненте, потому что агент “оптимизировал”. Где-то OpenAPI есть, а где-то “ну эндпоинты же в коде видно”. Где-то .env не коммитится, а где-то “ой”. Где-то агенту дали нормальные правила, а где-то написали: “сделай красиво и не сломай” И он, конечно, сделал. И красиво. И сломал. Вот поэтому я и решил собрать в одном месте стандарты, которыми сам пользуюсь в разработке. Там будут стандарты под разные части проекта: — backend — frontend — база данных — миграции — API-контракты — тесты — логирование — security — структура папок — работа AI-агентов с репозиторием — quality gates — деплой — документация Когда стандарты есть, проект становится спокойнее. Ты не споришь в каждом PR, как назвать таблицу. Не придумываешь заново формат ошибок. Не объясняешь агенту каждый раз, куда класть бизнес-логику. Не держишь все правила в голове. Не превращаешь репозиторий в помойку из old/, tmp/, new_final/, app2/. И что особенно важно сейчас — AI-агенту тоже становится проще. Он уже не “угадывает стиль проекта”, а работает по правилам: — сюда кладем handlers — сюда services — миграции только так — секреты не трогаем — OpenAPI обновляем вместе с endpoint — тесты обязательны — disabled-фичи не создаем — лишние папки не плодим — без плана большую задачу не начинаем По структуре хочу прийти к такому виду: registry/ standards/ stacks/ templates/ checks/ Стандарты лежат отдельно. Стеки собираются из стандартов. Проект получает только то, что ему реально нужно. Например, выбрал стек: vibe use go-next-postgres И получил чистый проект под Go + Next.js + PostgreSQL. Без папок mobile, desktop, worker, payments, admin, если они сейчас не нужны. Если потом нужен worker: vibe enable worker Только тогда он появляется. Главная мысль такая: в registry лежит всё, а в конкретный проект попадает только выбранное. Сейчас там уже есть первые заготовки под Go + Next.js + PostgreSQL и Python + React + PostgreSQL. Дальше хочу развивать это как общую базу стандартов: чтобы можно было брать, адаптировать, обновлять, версионировать и подключать под свой стек.
Если у вас есть свои стандарты — приходите.
Коммитьте. Спорьте. Правьте. Предлагайте свои подходы. Добавляйте стандарты под свои стеки. Улучшайте существующие. Особенно интересно всё, что касается backend, frontend, БД, миграций, OpenAPI, тестов, observability, security и правил для AI-агентов. Репозиторий: https://github.com/sergey-from-riders/vibecoding-base Берите, смотрите, открывайте issues, кидайте PR. Всем вайба и меньше fix_final_real_3.sql 🫡
