Vibe coding an AI governance platform forced me to rethink governance itself

For most of my career, governance operated on the assumption that technology evolves slowly enough for oversight processes to keep pace.

Policies are written. Architecture reviews happen. Security teams validate controls. Compliance mappings are documented. Audit cycles verify implementation.

That model worked reasonably well for traditional enterprise systems.

It breaks down quickly once AI enters the environment.

I realized this while vibe coding a production AI governance platform almost entirely through direct collaboration with Claude. What started as a technical experiment became much more significant. The process forced me to confront how quickly AI compresses the distance between concept, deployment and operational risk.

I have spent more than 30 years in cybersecurity building security practices, advising regulated organizations and working across governance, ransomware readiness, penetration testing and security operations. Over the last two years, one issue kept surfacing repeatedly in executive conversations:

Organizations knew employees were using AI, but they had very little visibility into where it was happening, what data was being exposed or how decisions influenced by AI were being validated.

The problem was not theoretical.

Employees were already integrating AI into day-to-day workflows faster than governance processes could adapt.

That became impossible to ignore once I started building with AI directly myself.

AI compresses governance timelines faster than organizations expect

I am not a modern software engineer.

I learned to code decades ago, then spent most of my career focused on security leadership, consulting and operational strategy. Like many executives, I eventually moved away from hands-on development because my role shifted toward organizational leadership and technical oversight.

AI changed that equation almost immediately.

Instead of handing requirements to development teams and waiting through traditional engineering cycles, I could work directly with the model myself.

I would describe a capability. Claude would generate code. I would test it. Break it. Refine it. Iterate again.

That loop repeated thousands of times during development.

The speed difference was dramatic enough that it forced me to rethink some of my assumptions around governance entirely.

At one point during development, I asked Claude to estimate what a traditional engineering effort might have looked like for the platform we had built. Based on the codebase size, integrations, compliance workflows, governance features and operational capabilities, the estimate suggested a traditional U.S.-based engineering effort could have required more than 20 engineers, multiple years of development and potentially tens of millions of dollars in fully loaded cost.

Whether the estimate was directionally perfect is almost beside the point.

The execution compression is real.

That compression creates governance consequences most organizations are not prepared for.

Traditional governance models assume enterprise technology evolves slowly enough for architecture reviews, security assessments and compliance oversight to keep pace with implementation.

AI breaks that assumption.

Capabilities evolve faster. Integrations happen faster. Workflows change faster. Employees adopt tools faster. Shadow AI spreads faster.

The largest governance risk I encountered during development was not hallucination.

It was governance lag.

The platform evolved faster than traditional governance processes naturally operate.

That forced me to rethink governance as a continuous operational discipline instead of a periodic review process.

This is one of the reasons frameworks like the NIST AI Risk Management Framework and the emerging EU AI Act matter so much right now. Both acknowledge something many organizations are still struggling to operationalize AI systems require ongoing governance because their behavior, usage patterns and risk exposure evolve continuously.

Building with AI made that reality impossible to ignore.

Building with AI exposed the real governance problem

The second major realization came from how the models behaved operationally.

The models were simultaneously extremely capable and confidently wrong.

Not obviously wrong. Plausibly wrong.

Sometimes Claude would generate elegant code that referenced nonexistent functions. Sometimes logic appeared operationally sound while quietly introducing security risk. Sometimes compliance mappings looked correct while subtly misrepresenting implementation requirements.

The dangerous part was not hallucination itself.

The dangerous part was synthetic confidence.

Outputs often looked authoritative enough that less experienced operators might never challenge them.

That changes governance fundamentally.

Traditional enterprise systems generally behave deterministically enough to validate periodically. AI systems behave probabilistically. Outputs are influenced by prompting, context windows, user interaction, model updates and external data sources.

That creates a very different operational governance problem.

The more I built, the more obvious it became that AI governance cannot remain document-centric.

Policies matter. Committees matter. Review processes matter.

But governance without runtime visibility becomes governance theater.

Most organizations currently approach AI governance through static control structures:

• Acceptable use policies
• Steering committees
• Procurement reviews
• Periodic assessments
• Compliance documentation

Those are necessary foundations.

They are not operational governance.

Operational governance requires visibility into how AI is actually behaving inside the environment.

That visibility challenge is much larger than most organizations currently understand.

Traditional DLP architectures were designed around obvious exfiltration patterns:

• Large file transfers
• Suspicious destinations
• Malicious behavior
• Bulk exports

Shadow AI rarely behaves that way.

Most of the time, it looks like productive employees trying to move faster.

A developer troubleshooting code through a public model. A finance employee refining contract language. A marketing team generating customer-facing content. An analyst uploading sensitive business data into an unsanctioned workflow.

Not malicious insiders.
Normal business behavior.

That creates a governance challenge traditional security architectures were never designed to handle.

The more I built, the more I realized AI governance required at least five operational dimensions:

• Policy
• Procedure
• Implementation
• Testing
• Training

Most organizations currently stop at policy.

Policy without implementation visibility is ineffective. Policy without testing creates false confidence. Policy without training collapses under productivity pressure.

Most importantly, governance without observability fails operationally.

This is why work from organizations like OWASP’s Top 10 for LLM Applications and MITRE ATLAS is becoming increasingly important. They move governance discussions closer to runtime behavior, attack surfaces and operational controls instead of treating AI strictly as a policy problem.

The organizations that operationalize governance early will shape what comes next

Building a production AI governance platform through vibe coding changed how I think about AI entirely.

Not because AI replaced engineering teams.

Not because models became magically intelligent.

Because building with AI exposed how quickly traditional governance assumptions stop working once AI becomes operational inside a business.

Most organizations are still treating AI governance as a future-state problem.

It is not.

Employees are already using AI throughout the enterprise whether leadership has visibility into it or not. That means the real governance question is no longer, “Should we allow AI?”

The real question is, “How do we operationalize governance around systems already influencing business decisions?”

That requires much more than documentation.

It requires runtime visibility. Human accountability. Evidence validation. Testing. Trust boundaries. Continuous monitoring. Operational controls.

Most importantly, it requires leadership teams to engage directly enough with the technology to understand where traditional governance assumptions begin to fail.

That was the unexpected lesson from vibe coding the platform myself.

The closer I got to the technology; the less theoretical governance became.

And the more convinced I became that the organizations operationalizing AI governance now will shape what enterprise AI looks like over the next decade.

The ones waiting for governance frameworks to fully mature before engaging are probably going to inherit systems, workflows and risks they never truly controlled.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?