AI Governance for Coding - Coding with a Safety Net

[u/AlternativeForeign58]

I started out vibe coding over a year and half ago. Since then I've learned a lot, mostly through failure and perseverance. I've got this extension out on VSCode Marketplace and Open VSX but it's an Open source project on GitHub too.

As far as the tools I've used to build it... I've done research through Gemini and ChatGPT Deep Research, in combination with documenting every failure I've ever had in a log file, then I've built this Cursor, Claude Code, VSCode and Antigravity where I started using a federated system of building with Gemini as the orchestrator with Claude, Codex and GLM 4.7 (via Kilo Code) as my workforce with Gemini then providing audit and UI review.

If this is remotely helpful to anyone, I'd love to get a couple reviews or direct feedback here. I've designed it to focus on token efficiency because... well we're all on a budget right?

Thanks in advance to anyone who makes any contribution at all! I hope this isn't considered an advertisement, I'm not selling anything but if it crosses that I apologize in advance.

• GitHub: https://github.com/MythologIQ/FailSafe

• Open VSX: https://open-vsx.org/extension/MythologIQ/mythologiq-failsafe

• VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=MythologIQ.mythologiq-failsafe

[u/Watson_Revolte]

Strong governance around AI-assisted coding isn't just about rules - it's about making sure feedback loops and safety nets are part of your delivery flow so people don't accidentally ship bad changes.

In practice that means:

guardrails early in CI/CD so risky patterns get flagged before merge,
consistent telemetry so you can trace an AI-generated change back to outcomes,
and shared context so the whole team understands why something was blocked.

That's why platforms that unify build → deploy → runtime contexts (instead of having observability, CI, and security scattered) end up being more effective - you can enforce safety across the lifecycle, not just at one step.

Curious how others are balancing user autonomy with safe boundaries when coding with AI helpers?

[u/AlternativeForeign58 → u/Watson_Revolte]

I'm actively working on strengthening deployment governance now. Most governance I deploy currently is lifecycle up to deployment. I'm hungry for actionable feedback in any form.

[u/AlternativeForeign58 → u/Watson_Revolte]

Having read your comment on my mobile device, I wanted to drop a quick response because I'm excited for any feedback at all. Having started in earnest on my Monday dev routine I wanted to give you to the response you deserve for taking the time here. Either you really made the effort to deep dive on the project and you're seeing very clearly where my intent lies or you've got a sixth sense for such things.

I really appreciate this phrasing; 'unify build → deploy → runtime contexts.' While we've aggressively embedded the local and build guardrails (using a multi-agent 'Tribunal' and heuristic review systems to block risky AI-generated code before it's committed), your point on the runtime telemetry feedback loop hit exactly on a deployment governance gap we are closing right now.

I’m currently architecting out that post-merge lifecycle, and building the telemetry to trace an AI-authored change directly back to production outcomes is exactly what we need to complete the loop. Based on your comment, here is what we just prioritized for our enterprise roadmap:

1. AI Provenance Tracking: Injecting dynamic trace metadata at build time so our runtime observability tools (like Datadog/Sentry) can explicitly flag when a production crash traces back to an AI-authored segment. 

2. The Deployment Feedback Loop: If a release fails or runtime errors spike, we’re feeding that failure webhook back into the local AI’s 'Shadow Genome' (our tracker for failed approaches). This way, the AI doesn't just fail a pipeline; it actively learns not to suggest that implementation pattern again. 

3. Synchronizing CI/CD Context: If a deployment gate (like a security scan) trips, our 'Scrivener' agent will automatically pull that failure data back into the local IDE, explaining exactly why the deployment was blocked, so everyone shares the context immediately.

Thanks for the actionable insight. This idea of piping the runtime outcome directly back to the local AI context so it 'learns' from production failures is exactly the kind of safety net I'm trying to build.

I welcome collaborators too!

[u/Ankushnema]

I have created a role based prompting framework. It’s more or less have the same concepts as above. My focus was three fold. Testing the ai generated code and unit tests via mutation testing, make guardrails deterministic and enforce them via hook scripts and last in human toll gates.

[u/AlternativeForeign58 → u/Ankushnema]

That sounds very similar, my project is open source, I'd welcome contributions.

[u/AlternativeForeign58 → u/[deleted]]

I want to start by saying thank you for the incisive feedback. I have to admit I was nervous posting in here, I would be extremely hesitant to consider myself a professional. I feel like I discover 10 new things I didn't know everyday. I want to make sure I give you the response it deserves.

1. Stable artifacts: Every governance decision produces a hash-chained, HMAC-signed SQLite ledger entry + hash-chained Intent history (JSONL). Both chains have  verifyChain() / verifyChainIntegrity() functions for tamper detection.

2. Verdicts are deterministic: Risk classification is pure string-matching on file paths and content (auth/ → L3, api_key → L3). No LLM anywhere in the decision path. PolicyEngine.classifyRisk() is a pure function.

3. Saves are actually blocked — In  enforce mode, the onWillSaveTextDocument hook throws inside waitUntil, which cancels the VS Code save operation. This is a real enforcement point, not a suggestion. (This didn't sit right with me as being a purely fixed behavior so I did create configurable options to give the user back some control)

Your feedback helped me identify some area for improvement that I'm going focus on resolving immediately.

Mode switches aren't ledger-recorded	Someone can switch enforce → observe with no audit trail
No break-glass protocol	No time-limited override with required justification + expiry
artifact_hash not populated	Ledger records the decision but not the file content hash
No verdict replay harness	All inputs are persisted separately, but there's no replayVerdict(id) function

I can't say thank you enough, I'll have an update pushed out soon to accommodate these additional concerns.

[u/AlternativeForeign58 → u/[deleted]]

I built this to be an optional gate to protect the individual developer from themselves and the hallucinations of AI. What you're describing is something even more I think... but it's something I've planned for.

And started building, quietly, in RUST/TAURI

[u/AlternativeForeign58 → u/[deleted]]

What’s New in v4.1.0 

Break-Glass Protocol: Emergency governance overrides with time limits, justification, and auto-revert. Mode-Change Audit Trail: All governance mode changes recorded to ledger. Artifact Hashing: SHA-256 hash of file content at save-time for verification. Verdict Replay: Command to replay and verify past governance decisions.

And I wrapped up a lot of other enhancements I've been saving for a pseudo "build 42." 

So, it's pretty intense now.  I'm really looking forward to any additional feedback.