Agentic Deployment Framework
Built a repeatable, scalable process for evaluating vibe coded apps and tools, to ensure that company data was kept secure, while allowing teams to build custom tools that matched specifically to their needs.
At Builder's Vision, teams had started building their own tools with AI coding assistants. Most of those tools worked, and most of them needed company data to be useful. There was no developer on staff to check what they did with that access, and no process for deciding which ones should connect to production at all.
The Problem
A vibe-coded tool can look finished long before anyone has checked what it reads, what it writes, or where it sends data. Tools went in if they seemed fine. That left two risks on the same unguarded path. One was security: a tool asking for broader permissions than it needed, or moving sensitive data somewhere it shouldn't go. The other was data quality: a tool quietly writing duplicates, malformed values, or overwrites into records other teams relied on. With sensitive customer data spread across two active Salesforce orgs, that wasn't a defensible position.
Blocking every tool wasn't the answer either. The people building them knew their own workflows better than any off-the-shelf product did.
What I Built
Using Antigravity and Claude as the reasoning layer, I designed a review framework that every new tool passes through before it connects to production. Each one is evaluated against a defined set of criteria (security posture, permission scope, what data it reads and writes, and how it handles the records it changes) and pressure-tested before approval rather than after something breaks.
Claude handles review synthesis. Given a tool's code, its requested access, and the criteria set, it surfaces risks and gaps that a time-pressured manual review is likely to miss. Every review produces the same artifact, and the framework keeps a history of what was approved, when, and on what terms. None of that existed before.
Outcome
Teams kept building the tools they needed, and none of them reached production data without a documented review. The process was the same no matter who built the tool or which org it targeted, so a new request became a known procedure instead of a judgment call. The review history also gave the company a record of every tool touching its data, which is the first thing anyone needs when something goes wrong.