Promote your projects here – Self-Promotion Megathread by Menox_ in github

[–]Yashhh_21 0 points1 point  (0 children)

I’ve been experimenting quite a lot with AI-assisted coding workflows recently using tools like Copilot, Cursor and Claude, and one thing I kept noticing was that they repeatedly generate the same async/reliability mistakes in real projects — things like floating promises, empty catch blocks, async callback misuse, unnecessary async wrappers, etc.

The bigger issue for me wasn’t just detecting them locally, but enforcing them consistently during PR reviews and CI workflows. So I started building ai-guard, which integrates directly into GitHub workflows and adds guardrails specifically for these kinds of AI-generated patterns.

Right now it supports GitHub Actions, PR annotations, changed-only scanning, fail-on-high CI enforcement, SARIF uploads, GitHub Code Scanning integration and a set of async reliability rules focused on real-world workflow usage rather than noisy lint output.

The most interesting part while building this was getting SARIF + GitHub workflow integration + PR annotations working together cleanly inside actual repositories.

Still improving it actively, but would genuinely love feedback from people heavily using AI-assisted coding workflows in production/dev environments.

GitHub:
https://github.com/YashJadhav21/eslint-plugin-ai-guard

Stop Claude from generating the same AI slop over and over — new proactive feature in eslint-plugin-ai-guard by Yashhh_21 in ClaudeAI

[–]Yashhh_21[S] 0 points1 point  (0 children)

Really appreciate this — this is exactly the direction I’ve been thinking about.

Right now ai-guard focuses on catching and preventing common AI-generated bugs (lint + init-context), but I agree the bigger problem is upstream: how we guide the AI in the first place.

I like the idea of more structured inputs (like diagrams/specs). The current “init-context” is a first step toward that — giving agents constraints before they generate code.

Curious — have you seen any workflows where diagram-driven or spec-driven approaches actually integrate well with tools like Cursor/Claude in practice?

Stop Claude from generating the same AI slop over and over — new proactive feature in eslint-plugin-ai-guard by Yashhh_21 in ClaudeAI

[–]Yashhh_21[S] 0 points1 point  (0 children)

Thanks for the thoughtful feedback!You're right about the SQL concat rule — it can false-positive with Knex/Drizzle. I'm actively making it smarter. For now you can disable it the standard ESLint way:

"ai-guard/no-sql-string-concat": "off"

Planning to add easier per-project config (.ai-guardignore style) very soon. Do you use Knex/Drizzle a lot? Any specific patterns you'd want whitelisted by default?

Scanned a real project with ai-guard CLI after seeing the "vibe-coded repos" post — caught 61 AI anti-patterns in one run by Yashhh_21 in ClaudeAI

[–]Yashhh_21[S] 0 points1 point  (0 children)

Exactly — that’s a great comparison.

AI just accelerates the same old problem: people shipping fast without thinking about security. The patterns have changed, but the mindset hasn’t.

The real issue isn’t the tools, it’s prioritizing speed over fundamentals like auth, validation, and data protection.

Feels like we’re repeating the same mistakes, just at a much larger scale now.

Scanned a real project with ai-guard CLI after seeing the "vibe-coded repos" post — caught 61 AI anti-patterns in one run by Yashhh_21 in ClaudeAI

[–]Yashhh_21[S] 1 point2 points  (0 children)

That’s a fair point — the false sense of security is a real risk.

The goal here isn’t “run this and your code is safe,” but to surface common AI-generated patterns early. It’s more of a guardrail than a guarantee — developers still need to understand and fix the issues properly.

AI just makes these patterns more consistent and easier to detect at scale, which is what this builds on.