codevibes - Moses Yebei

codevibes

Abstract

CodeVibes is an intelligent AI-powered code analysis tool that scans your GitHub repositories to uncover security vulnerabilities, bugs and performance bottlenecks, and code quality issues — then translates them into actionable insights and a measurable Vibe Score that helps you continuously improve your codebase.

The Problem

Developers need fast, AI‑augmented feedback on code quality, security, and performance, but integrating such analysis into a CI pipeline is rarely turnkey. Without a unified front‑end and back‑end, teams end up cobbling together scripts, missing consistent scoring, and lacking actionable reports.

What This Does

CodeVibes provides a web UI (React + Vite) that lets a user paste a GitHub repository URL and watch a live analysis stream. The backend (codevibes-backend/src/server.ts) orchestrates calls to the GitHub API and the DeepSeek LLM, stores results in a SQLite DB, and returns a Vibe Score plus issue lists.

Key files:

Front‑end entry – src/main.tsx → src/App.tsx → page components such as src/pages/AnalyzePage.tsx.
Backend entry – codevibes-backend/src/server.ts sets up Express routes (/api/analyze) and wires controllers (analysisController.ts, authController.ts).
Core services – codevibes-backend/src/services/githubService.ts fetches repo trees, deepseekService.ts streams AI analysis, and analysisService.ts aggregates results.

Shared utilities (logger.ts, auth.ts, database.ts) are imported across many modules, making them the primary “hub” points.

How It Is Wired

User request – UI component AnalyzePage posts to POST /api/analyze.
Route handling – codevibes-backend/src/routes/analysisRoutes.ts forwards to analysisController.analyze.
Service orchestration – analysisService.analyzeRepo calls githubService.getRepoTree → iterates files by priority (P1 security, P2 core, P3 quality).
AI streaming – For each file, deepseekService.streamAnalysis sends file content to DeepSeek and receives a JSON issue stream.
Result persistence – Issues and the computed Vibe Score are stored via database.ts (SQLite).
Live feedback – The controller pipes server‑sent events back to the front end, which updates the UI in real time.

The import graph shows 112 modules with 54 edges and no cycles. The most depended‑upon module is codevibes-backend/src/utils/logger.ts (12 inbound imports). src/App.tsx has the highest instability (0.89) because it imports many UI components but is not itself imported elsewhere, indicating a potential refactor point. The backend server (server.ts) has instability 1, reflecting its role as the sole entry point.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/codevibes
cd codevibes

# Install dependencies (both front‑end and back‑end share the root package.json)
npm ci

# Prepare backend env (copy example and edit as needed)
cp codevibes-backend/.env.example codevibes-backend/.env
# Required keys: GITHUB_TOKEN, DEEPSEEK_API_KEY (documented in .env.example)

# Start the backend (refer to scripts in codevibes-backend/package.json)
npm run backend   # typically runs `ts-node src/server.ts` or compiled start

# Start the frontend (refer to root package.json scripts)
npm run dev       # Vite dev server on http://localhost:5173

If the scripts differ, inspect package.json and codevibes-backend/package.json for the exact command names. The Dockerfile can build the backend image with docker build -t codevibes-backend . and run it with the supplied .env.

Real‑World Use

A SaaS security team integrates CodeVibes into their PR workflow by invoking the backend API from a GitHub Action (once CI is added). When a pull request opens, the action posts the repo URL to /api/analyze; the resulting Vibe Score is posted as a comment, giving reviewers a quick risk signal without manual code review.

Code Health & Issues

HIGH – No test suite – 112 source files, zero test files.
HIGH – No CI workflow – No .github/workflows/* present.
HIGH – No build gate for Docker image – codevibes-backend/Dockerfile not validated by CI.
MEDIUM – Dependabot missing – No dependabot.yml for 2 manifests.
MEDIUM – Base image not pinned – node:20-alpine used without digest.
MEDIUM – Container runs as root – Dockerfile lacks a non‑root USER.
LOW – Repository conventions absent – No .editorconfig, .gitattributes, or formatter config.

Additional static findings: deep nesting (max depth 10) in several page components, duplicated 6‑line blocks across 11 files, oversized services (deepseekService.ts, AnalyzePage.tsx), empty catch blocks, and a high‑branching database.ts/encryption.ts.

The Bottom Line

CodeVibes delivers a complete AI‑driven analysis stack with a clear front‑end UI and a modular back‑end, but it currently lacks the engineering safeguards needed for production (tests, CI, hardened Docker image). Teams comfortable adding those missing pieces can benefit from the ready‑made analysis flow; otherwise, the repo should be treated as a prototype rather than a drop‑in service.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

151 files

TSX80
TypeScript30
JSON10
JavaScript2
CSS2
Markdown1

ReactExpressTailwindDocker

Module dependencies

The 10 most depended-upon modules of 112, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_bes_backend_src_utils_logger["logger"] n1_vibes_backend_src_utils_auth["auth"] n2_s_backend_src_utils_database["database"] n3_ibes_backend_src_types_index["index"] n4_backend_src_utils_fileFilter["fileFilter"] n5_ckend_src_utils_tokenCounter["tokenCounter"] n6_src_App["App"] n7_src_services_analysisService["analysisService"] n8_ntrollers_analysisController["analysisController"] n9_c_controllers_authController["authController"] n8_ntrollers_analysisController --> n7_src_services_analysisService n8_ntrollers_analysisController --> n0_bes_backend_src_utils_logger n8_ntrollers_analysisController --> n1_vibes_backend_src_utils_auth n9_c_controllers_authController --> n2_s_backend_src_utils_database n9_c_controllers_authController --> n1_vibes_backend_src_utils_auth n9_c_controllers_authController --> n0_bes_backend_src_utils_logger n7_src_services_analysisService --> n3_ibes_backend_src_types_index n7_src_services_analysisService --> n5_ckend_src_utils_tokenCounter n7_src_services_analysisService --> n4_backend_src_utils_fileFilter n7_src_services_analysisService --> n0_bes_backend_src_utils_logger n1_vibes_backend_src_utils_auth --> n2_s_backend_src_utils_database n1_vibes_backend_src_utils_auth --> n0_bes_backend_src_utils_logger n2_s_backend_src_utils_database --> n0_bes_backend_src_utils_logger n4_backend_src_utils_fileFilter --> n3_ibes_backend_src_types_index

Dependencies

35 of 88 declared dependencies are a major version behind. Resolved 88 of 88 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^20.10.6	26.2.0	6 major
`vite`	^5.4.19	8.2.1	3 major
`@octokit/rest`	^20.0.2	22.0.1	2 major
`@types/better-sqlite3`	^7.6.13	9.6.0	2 major
`typescript`	^5.3.3	7.0.2	2 major
`@hookform/resolvers`	^3.10.0	5.9.0	2 major
`react-day-picker`	^8.10.1	10.0.1	2 major
`react-resizable-panels`	^2.1.9	4.12.2	2 major

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium3

low1

Add a test suite; this repository has nonehigh112 occurrences

112 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Add a workflow that builds and tests this repositoryhigh

112 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh2 occurrences

codevibes-backend/Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

codevibes-backend/Dockerfile

node:20-alpine, node:20-alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Add a non-root USER to the imagemedium

codevibes-backend/Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.