The problem it solves
When you deploy from a vibe coder, you have two sources of truth that can conflict:- Your builder — where you keep iterating with AI prompts
- Your GitHub repo — where developers make code changes directly
How it works
Nometria maintains a canonical Git repository as the single source of truth between your builder and your infrastructure.builder/latest. They never touch main directly.
Developer changes happen on main or feature branches, via pull requests.
Nometria watches both. When builder/latest has new commits:
- If there are no conflicts with
main→ auto-merge (optional, configurable) - If there are conflicts → a PR is opened with conflict markers for you to resolve
main gets a new commit → Nometria triggers a production redeploy.
Why this branch strategy works
The key insight is isolation by branch. The builder never directly touchesmain. Developers never touch builder/latest. Nometria acts as the merge coordinator.
This means:
- A bad AI prompt can’t directly break production — it lands on
builder/latestfirst - Developers can work on
mainwithout worrying about the builder overwriting their work - Every change — from builder or developer — is a Git commit with full history and rollback
Configuration via .Nometria.yml
Fine-tune sync behavior by adding .Nometria.yml to your repo root:
What two-way sync gives you
Once set up, you get professional engineering workflows on top of your vibe-coded app:- Rollback — every builder change is a commit; revert to any previous state with one click
- Staging vs production —
builder/latestpreviews deploy to staging;maingoes to production - Code review — PRs give you a diff of every builder change before it touches production
- Audit trail — compliance and debugging both benefit from a complete commit history
- Developer collaboration — contractors and teammates can open PRs without needing builder access
Day-to-day workflow
How to use two-way sync while actively building
Handling conflicts
What to do when builder and developer changes clash