Vibe coding gets you to a working demo quickly. The problems arrive after that: a leaked key, a dependency that changed under you, a test that never ran, a service that only works on one laptop. Each tool below covers one of those gaps. They are listed roughly in the order I would add them to a new project.
1. Git hooks with pre-commit
A pre-commit framework runs your checks before a commit lands, so a broken change never reaches the shared branch. Keep the hook fast. Run formatting, linting, and a quick test subset there, and leave the full suite for CI.
2. Gitleaks
Gitleaks scans your repository for secrets such as API keys and tokens, both in new commits and in history. Agents sometimes copy an example value into real code, and a scanner catches it before it is pushed.
3. A linter and formatter
Biome and ESLint both catch common mistakes, such as unused variables and unsafe patterns. A formatter removes style arguments from review. Pick one tool for each job, and make CI fail on warnings, not just errors, so the rules actually bind.
4. A type checker
TypeScript's compiler, or the equivalent for your language, catches mismatched types before the code runs. Run it in strict mode if you can. Agents often produce code that looks right and works only for the cases they tried.
5. A unit test runner
Vitest or Jest lets you check functions in isolation, quickly. Write tests for the behaviour you want, and confirm they fail when the behaviour breaks. A test that passes on broken code tells you nothing.
6. Playwright
Playwright drives a real browser through the flows your users take. It catches what a unit test misses: a button that does nothing, a form that submits to the wrong place, a page that breaks after a refactor.
7. Dependabot or Renovate, plus a dependency audit
Dependabot and Renovate open pull requests when a dependency has a new version or a known vulnerability. Pair them with an audit in CI, such as npm audit or pip-audit, and treat a new high-severity finding as a failed build. Keeping dependencies current in small steps is far easier than one large upgrade after months of drift.
8. Semgrep
Semgrep runs pattern-based static analysis, and you can write rules for the mistakes your agent tends to repeat, such as building a query from a string. It turns a review comment you keep writing into an automatic check.
9. An error tracker
Sentry and similar services capture exceptions from the running app, with the stack trace and the request that caused them. Without one, the first report of a bug usually comes from a user.
10. TDK CLI: the local stack
Most vibe-coded apps are more than one process: a frontend, an API, a database, a worker. They work on the author's machine and fail on a colleague's, usually because the services start in the wrong order or on clashing ports.
TDK CLI describes each service in a service.json file, generates the Docker, routing, and Tilt files from it, and starts the whole stack with tdk up. Three features help with fragility:
-
tdk doctor --jsonchecks whether the machine can run the stack, including whether a container runtime is reachable. -
tdk up main --dry-runshows the plan, the ports, and the start order without starting anything. - Drift checks compare the generated files with saved snapshots before startup, so a hand-edited Dockerfile or Tiltfile blocks the start and names the file.
It is for local development. Production deployment stays with tools such as Helm, Argo CD, or Kustomize. It also supports an MCP server, tdk mcp, if you want an agent to start the stack and read its readiness directly.
How to start
Add the tools in the order above. Start with the pre-commit hook and the secret scanner, since they catch the costliest mistakes early. Then add the type checker and the tests. Add TDK CLI once the app has more than one service, so every teammate can start it the same way. Browser tests and error tracking can follow once the app has real users.
Each tool checks something the agent cannot check for itself. Together they turn a fast demo into code you can run, change, and ship.
Top comments (2)
The order makes sense — pre-commit + Gitleaks first is right because those catch the mistakes you can't fix retroactively (once a secret is in git history, it's leaked forever).
One thing I'd add to #3 (linter/formatter): make sure the "fail on warnings" rule doesn't cover security-relevant rules. Otherwise devs learn to disable warnings for things like
no-evalordangerouslySetInnerHTMLwhen they're in a hurry. Split the config: style warnings are warnings, security rules are errors.Also curious about #10 (TDK CLI): does the drift check compare file hashes or actual content? Asking because hash is fast but a hand-edit that doesn't change line count could still slip through if it's structural.
TDK CLI describes each service in a service.json file, generates the Docker, routing, and Tilt files from it, and starts the whole stack with tdk up. Three features help with fragility:
tdk doctor --json checks whether the machine can run the stack, including whether a container runtime is reachable.
tdk up main --dry-run shows the plan, the ports, and the start order without starting anything.
Drift checks compare the generated files with saved snapshots before startup, so a hand-edited Dockerfile or Tiltfile blocks the start and names the file.
It is for local development. Production deployment stays with tools such as Helm, Argo CD, or Kustomize. It also supports an MCP server, tdk mcp, if you want an agent to start the stack and read its readiness directly.