Три «vibe-coded» PR и один grader: что предлагает автор с Dev.to

Разработчик wd400 на dev.to описывает типичный сценарий vibe coding: промпт к языковой модели, быстрая генерация проекта и отправка в продакшен. В ответ на собственный опыт ревью трёх таких pull request’ов он собрал CLI-инструмент vibescore, который выставляет проекту буквенную оценку по нескольким осям — от секретов в коде до тестов и зависимостей.

Ниже — пересказ и структура инструмента по тексту первоисточника, без претензии на независимую проверку каждого утверждения автора.

Промпт, целый проект и риски при ускоренной поставке

В начале публикации на dev.to автор формулирует тезис так: «vibe coding» встречается повсеместно; вы даёте ИИ промпт, модель «пишет весь проект», после чего код уходит в релиз.

На прошлой неделе он смотрел три PR из «vibe-coded» проектов и в каждом находил захардкоженные API keys. По его словам, у двух не было тестов, в одном встретился «raw eval()» на пользовательском вводе. Это именно его выборка, а не статистика по индустрии — такой оговорки придерживается и сам материал при пересказе опыта.

Что считает vibescore: четыре категории и шкала A+–F

Автор называет пакет vibescore. Установка и запуск в корне репозитория описываются так:

pip install vibescore
vibescore .

Итог — буквенная оценка от A+ до F по четырём измерениям:

• Security: в том числе hardcoded secrets, SQL injection, eval/exec, небезопасные значения по умолчанию
• Code Quality: длина функций, сложность, глубина вложенности, покрытие type hints
• Dependencies: pinning, lock-файлы, устаревшие пакеты, известные CVE
• Testing: соотношение числа тестов и строк кода, настройка coverage, конфигурация CI

В посте приведены ссылки на репозиторий https://github.com/stef41/vibescore и страницу пакета на PyPI https://pypi.org/project/vibescore/. Детали релизов и метрик репозитория в этой статье не подменяются данными вне цитируемого текста поста.

Языки: AST, регексы и отдельные правила для Rust и Go

По описанию автора:

• Python — анализ через AST
• JavaScript/TypeScript — на основе регулярных выражений
• Rust — перечень проверок с кодами VC221–VC227 (в т.ч. плотность unwrap, блоки unsafe, doc comments, clone detection)
• Go — VC231–VC237 (в т.ч. непроверенные ошибки, утечки горутин, naked returns, panic в библиотечном коде)

Дополнительные режимы CLI и заявленные свойства

В том же материале перечислены флаги:

• vibescore --init-ci — генерация workflow для GitHub Actions
• vibescore --watch — повторное сканирование при изменении файлов
• vibescore --dashboard — веб-интерфейс (в посте указан Streamlit) для истории оценок
• vibescore --save-history — сохранение результатов прошлых запусков для трендов

Автор также пишет, что у инструмента «Zero dependencies» и что у него «201 tests» — это формулировки из текста поста, а не результат отдельного аудита зависимостей или тестов со стороны редакции.

Как автор сопоставляет инструмент с SonarQube, SaaS и линтерами

Сравнение в статье носит характер мнения автора, не бенчмарка. Кратко по его тезисам:

• SonarQube: нужен Java-сервер, сложная настройка, enterprise-ценообразование
• Codacy / CodeClimate: SaaS, нужен аккаунт, код уходит на серверы сервиса
• pylint / ruff: в основном lint-правила, без заявленного в посте охвата security / testing / dependencies и без одной сводной буквенной оценки
• vibescore: «один pip install, одна команда», работа локально, четыре измерения и буквенная оценка

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

Иллюстрации в тексте и комментарий к посту

В посте есть демонстрационный фрагмент вывода (включая строку вида vibescore v0.4.0 — Project Report и условные цифры в таблице примера — например, «3 tests for 2,400 LOC», «2 eval() calls found»). Это пример из статьи, а не факт о чужом продакшене; переносить такие цифры как реальные метрики проекта читателя нельзя.

У публикации на dev.to в доступном снимке метаданных платформы зафиксирован один комментарий. Содержание комментария при просмотре страницы поста не было доступно для цитирования, поэтому здесь оно не воспроизводится.

---

Источники

• wd400, I code-reviewed 3 "vibe-coded" PRs last week. Every one had hardcoded API keys. So I built a grader. — dev.to: dev.to (дата обращения: 2026-04-11, 09:03 UTC).
• Метаданные той же публикации на dev.to: дата публикации 2026-04-11T03:19:17Z, время чтения 2 мин, один комментарий, две реакции; в доступных полях карточки поста число просмотров не указано.
• Ссылки на https://github.com/stef41/vibescore и https://pypi.org/project/vibescore/ приведены внутри указанного поста; отдельная верификация содержимого репозитория и страницы PyPI для этой публикации не выполнялась.