Adrian Twarog: Giving Enterprise Vibe Coding a Governed Path to Production

A company can put customer data at risk with a single poorly governed application. If you are responsible for technology or security, the challenge is no longer limited to the software your engineering team produces. A board-level push to adopt AI can put coding tools in the hands of sales, finance and operations, with hundreds of applications appearing before IT has reviewed them.

Those applications still need somewhere to store data, somewhere to run and a way to authenticate users. When every database or deployment requires an engineering ticket, people improvise: personal account keys, public sharing links and untracked databases become shortcuts to getting an app working. Meanwhile, the same AI progress that accelerates development also improves attackers' capabilities.

Trying to stop employees from using these tools is unlikely to solve the problem. What we need is a dependable route to production: business teams can build, security teams establish the rules, and the applications follow those rules. One CIO at a Global 2000 company described hundreds of non-engineers building with consumer tools while IT had no visibility into the applications or their expanding attack surface.

Imagine a company rolling out Claude Code and encouraging everyone to automate their work. Maya in sales wants a Salesforce dashboard; colleagues want expense tools and ticketing systems. These are ordinary, useful ideas. The problem emerges when that activity happens throughout an organization at once, faster than a conventional IT team can inspect each application.

A business user may not recognize the consequences of giving an app a personal database key or sharing that key with colleagues. Security teams have to handle the resulting exposure while also dealing with increasingly capable AI-assisted attacks. At the same time, provisioning a database, login and runtime for every app turns IT into a queue that slows everyone down.

I am looking at Superblocks because its approach puts business application creation and centralized governance in the same system. Tools such as Lovable and Replit make rapid prototyping accessible, and Claude is increasingly part of the workflow. The enterprise question is how IT and security retain control over what reaches production, especially in regulated businesses such as healthcare and financial services.

The deployment model described here keeps applications and their data in the company's own AWS account. When an app is published, the platform can run multiple security policies: checking code for exposed keys and injectable database queries, examining functions and endpoints, and checking packages against known vulnerabilities. Technology and security teams can also express organization-specific policies in plain language.

Those policies give teams a common set of requirements for applications built inside the organization. If a finding appears, the AI can help fix it. The point is to make security part of the path an application takes through the platform, rather than expecting a separate security team to manually discover and review every tool an employee has created.

Developers can continue working in Claude Code through Superblocks MCP. They can connect to an approved Postgres database or the organization's AWS resources and develop against test data. When it is time to go live, IT supplies the production connection. In the workflow I describe, access goes through Superblocks so Claude does not need to receive the underlying credentials, and the application remains subject to the platform's checks.

Databases matter because people will find somewhere to save their data if you do not give them a supported option—even a spreadsheet can become the storage layer. Superblocks can run application databases within the company's AWS account. Each app has its own isolated Postgres database, with separate development and production instances, so teams do not have to scatter their data across independently chosen vendor services.

That arrangement gives IT a central place to manage application access, security and costs. Policy agents check applications, the Security Center can surface newly discovered vulnerabilities, and activity is logged. Administrators can see what is being built and what permissions are being granted. That organizational visibility is the piece I find missing when employees independently use consumer coding tools for business applications.

After signing in, the Superblocks home interface offers a prompt-based app builder, existing applications, integrations and security management. For the demonstration, I want a staff directory that helps people find colleagues around the organization. I connect the prompt to a Postgres integration that I configured once and shared with the relevant groups, allowing others to build on the connection without seeing its credentials.

The platform sets up the workspace and begins in plan mode, where it may ask questions before starting the build. It also retrieves knowledge maintained by the company. That can include organizational context, UI and design standards, data-formatting conventions and security rules, giving the agent shared requirements instead of leaving each employee to specify everything from scratch.

Once planning is complete, I switch to build mode and let the agent generate the application. The finished interface places the live app preview on the right and the conversation on the left. I can inspect the generated code at any point and, if needed, take it elsewhere. The builder also offers controls for sharing the application with selected people or embedding it in another context.

One feature I particularly like is the API-call view. For the staff directory, I can see the database query behind the staff lookup, how long the call takes and what data it returns. As I interact with the app, calls are tracked in the interface. A general business user might never need that detail, but it is exactly the kind of visibility I want when I am investigating how an application behaves.

Integrations are how applications connect to the databases and services an organization already uses. The menu includes options such as GitHub and MongoDB; in this example, I choose PostgreSQL. A connection can have a default or production environment and a custom development environment. After configuring it, I test the connection and reuse it across applications.

The administration area brings together users, groups, permissions and security policies. From a user's entry, I can inspect the applications they have built. I open an Account 360 application showing customer accounts across regions and can inspect its underlying code as an administrator. If everyone were building separately under personal Claude Code accounts, the organization would not have this same central view.

Users sign in through the company's single sign-on, with identity systems such as Okta and their security groups kept in sync. Groups can represent IT, engineering, business operations or other teams. Roles such as administrator, developer and user determine what those groups can do, and the roles-and-permissions page lets the organization control actions such as creating, modifying, deploying and sharing applications.

The knowledge base gives the building agent a place to find organizational facts and instructions. These can be straightforward Markdown files describing what the company does or specifying UI colors, typography and other design conventions. I can query that material, and the agent retrieves the context it needs. The approach is similar to supplying reusable skills rather than repeatedly writing the same guidance in each prompt.

To add knowledge, I can discuss it with the agent and choose whether it belongs to me, the whole organization or a particular integration or service. I generally prefer editing the Markdown directly because it is easy to maintain. Personal knowledge applies to my own work; organizational knowledge applies across users, and entries can be switched off when they are unnecessary.

Policy agents are another central part of the system. They scan applications for compliance with the organization's requirements when those apps move toward publication. Administrators choose how strict each policy should be: it can provide advice, block with an exception mechanism or block outright. Policies can target specific apps, though applying common requirements across the organization is generally more useful.

The Security Center shows the findings produced by those checks. In my account, several applications already have vulnerabilities listed, and I can review their severity before deciding what to fix. Selecting Fix with Clark sends the vulnerability to the agent as a repair task. That connects a security finding to the same workflow used to change the application, instead of leaving it as an isolated report.

Returning to the agent, I can see the finding marked as fixed and the application ready for publication. The details view lets me inspect affected packages and the vulnerabilities associated with them. If I need a fuller explanation, I can follow the link to the official vulnerability listing. This is the sort of information that would be difficult for IT to assemble if every employee's app lived in a separate personal tool account.

Data Setup defines the environments used through deployment, such as development, preview and production. In this demonstration, I use development and production, each with its own configuration and URL. The App Databases area extends the same separation to the databases used by those environments and by Claude MCP, so the path to production has explicit stages rather than a single undifferentiated connection.

Audit logs add another layer of visibility into activity across the applications in the organization. Logging is something I consistently advocate because it helps make the operation of these systems observable. Taken together, the app builder, administration, policies, database management and logs show the kind of coordinated oversight I want when AI-built software becomes part of a large business.