Inspect the whole project
Point VibeTect at the project root, not a single folder. Many issues live in configuration files, middleware and shared helpers rather than the feature you just built.
VTHow it works
From project folder to findings, on your machine.
No pipeline to configure, no repository to connect and no code to upload. VibeTect works where your project already is — your own computer.
01The workflow
The VibeTect workflow
Stage 01
Install the desktop app
VibeTect is a desktop application, not a website you paste code into. You install it on the computer where your project already lives.
- You
- Request early access and choose your operating system.
- VibeTect
- Runs as a local application on your machine.
Stage 02
Open a project folder
Choose the folder that contains your code — a cloned repository, a project exported from an AI app builder, or a client deliverable.
- You
- Select the folder. No accounts to connect, no repository permissions to grant.
- VibeTect
- Reads the source and configuration files in that folder.
Stage 03
Inspect locally
The analysis runs on your device using your machine’s own resources. Your source code doesn’t need to be uploaded anywhere to be checked.
- You
- Nothing — let it run.
- VibeTect
- Looks for exposed secrets, access-control gaps, unsafe authentication, risky configuration and vulnerable code patterns.
Stage 04
Review findings by severity
Findings are grouped by how urgent they are, each with an exact location, a plain-English explanation and fix guidance.
- You
- Start with critical and high findings — they’re the ones most likely to be exploited.
- VibeTect
- Explains what’s wrong, why it matters and how to fix it.
Stage 05
Fix and re-check
Apply the fix yourself or hand the finding to your AI assistant. Then run the inspection again to confirm the issue is resolved.
- You
- Make the change and re-run before you deploy.
- VibeTect
- Confirms what’s resolved and what still needs attention.
02The data boundary
Everything happens inside one boundary: your device.
Local-first means the inspection doesn’t depend on sending your source code to someone else’s server. It also means VibeTect only sees what’s in the folder you give it — so be deliberate about what else you check.
Your device
- InputYour project folderSource and configuration files, as they are on disk.
- AnalysisVibeTect desktop appInspects the project with your machine’s own resources.
- OutputFindingsSeverity, location, explanation and fix guidance.
Uploading source codeNot required for analysis
03Working with your AI assistant
Turn a finding into a precise fix request.
Vague prompts produce vague fixes. A finding gives your assistant exactly what it needs: the problem, the location and the required outcome.
- Paste one finding at a time, with its file and line.
- State the required behavior, not just “make it secure”.
- Ask the assistant to keep unrelated code unchanged.
- Review the diff yourself, then re-run VibeTect to confirm.
Fix this security finding. Keep all other behavior the same.
Finding: Any signed-in user can read any invoice (High)
Location: app/api/invoices/[id]/route.ts, line 11
Problem: The invoice is fetched by the ID in the URL without
checking that it belongs to the signed-in user.
Required fix: Scope the query to the signed-in user's ID and return
404 when no matching invoice exists.
After the change, explain what you modified and why.04Getting the most from a check
Five habits that make every check count.
Fix critical findings first
Exposed secrets and missing access control are the issues attackers find fastest. Clear those before you polish anything else.
Rotate, don’t just delete
If a key was ever committed or deployed, removing it from the code isn’t enough — it still exists in Git history and any copies. Revoke it and issue a new one.
Check what lives outside the code
Database policies created in a web console, storage bucket settings and hosting environment variables don’t live in your folder. Review them in the platform where they’re configured.
Re-run after every fix
A fix can introduce a new problem, especially when an assistant rewrites more than you asked for. A second inspection takes moments and closes the loop.
Inspect your project before you ship it.
Run a local security inspection on the project you’re about to deploy — and fix what it finds while it’s still cheap to fix.
Local analysis · No repository access required