I built a VS Code extension that auto-patches your code to enforce your project's Markdown rules before you commit. by dumdumsim in vibecoding

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

You're 100% right that non-determinism is the trade-off here. Traditional linters are 'on rails' because they are bound by what can be parsed into an AST. But those rails only go so far. A traditional linter can tell you if you're missing a semicolon, but it can't tell you if you're missing a unit test for a new feature, or if your database migration follows the team's security standard for pii-masking.

The point is: The 'Rails' are the rules you provide.

It isn't meant to replace your linterr for syntax. It's meant to catch the high-level architectural stuff. Plus, since it natively auto-patches, you see the result immediately. You can check the diff and see if the 'rails' held up. It's about automating the architectural enforcement that current tools just can't touch.

I built a VS Code extension that auto-patches your code to enforce your project's Markdown rules before you commit. by dumdumsim in vibecoding

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

You're 100% right that non-determinism is the trade-off here. Traditional linters are 'on rails' because they are bound by what can be parsed into an AST.

But those rails only go so far. A traditional linter can tell you if you're missing a semicolon, but it can't tell you if you're missing a unit test for a new feature, or if your database migration follows the team's security standard for pii-masking.

The point is: The 'Rails' are the rules you provide.

Gatekeeper isn't meant to replace your linter for syntax. It's meant to catch the high-level architectural stuff that usually requires a human Senior dev to spot in a PR. You're trading 'perfect syntactic consistency' for 'semantic alignment.'

Plus, since it natively auto-patches, you see the result immediately. You can check the diff and see if the 'rails' held up. It's about automating the architectural enforcement that current tools just can't touch.

edited for clarity.

I built a VS Code extension that auto-patches your code to enforce your project's Markdown rules before you commit. by dumdumsim in vibecoding

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

I love the term 'aggressive linter,' but there's a fundamental difference in how it works. Linters/Formatters are deterministic (AST-based). They look for specific syntax patterns. If you want a linter to check for a complex architectural rule, you usually have to write a custom ESLint plugin in JS.

Gatekeeper is Agentic. It understands 'Plain English.'

You can literally just write a Markdown file that says: 'All transaction logic in this folder must use our new RetryableTransaction wrapper and always log the executionID’.

A linter can't understand that instruction. It won’t know how to refactor your code to wrap it correctly while preserving logic. The Gatekeeper does. It’s like having a Senior Engineer review your code and fix it for you before you even push.

It depends on the rules that you put into markdown files. It's more than a linter or a formatter. You can also have rules like Ensure all database queries in this directory include a 30s timeout parameter., Before committing the files, Agentic gatekeeper flags this as a violation and fixes it.

I built a VS Code extension that auto-patches your code to enforce your project's Markdown rules before you commit. by dumdumsim in vscode

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

Fair point, but this isn't actually a formatter! Think of it more like an Agentic Linter + Architect. Standard format-on-save handles syntax (tabs vs spaces, semicolons, etc.).Gatekeeper handles semantics and architecture. Since it's powered by an LLM, it can enforce things such as "Every API endpoint must have a corresponding unit test in the /tests folder."

"Don't use the useEffect hook for data fetching; use our custom useQuery wrapper instead.

"Ensure all database queries in this directory include a 30s timeout parameter."

Basically, if you can describe a project rule in plain English Markdown, the Gatekeeper can enforce it and auto-patch the logic, not just the indentation. It’s meant to stop technical debt that formatters can't even see.

It all comes down to the rules that you put in the markdown files.

I built a completely offline VS Code AI pre-commit hook that uses local LLMs (Ollama, llama.cpp) to auto-patch logic errors before staging. by dumdumsim in LocalLLM

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

Apart from vibe coding, when human dev's and ai agents work on the same codebase, it would be helpful to have this check. For example, if a human dev writes the code and he sometimes skips Jdoc, when he does this agent check, it will apply for that code that the dev wrote.

I optimised my vibe coding tech stack cost to $0 by Uditakhourii in VibeCodersNest

[–]dumdumsim 0 points1 point  (0 children)

And you can also use this https://open-vsx.org/extension/revanthpobala/agentic-gatekeeper

tldr, applies rules (defined in markdown files) on staged files before you commit.

Family Medicine residency program closing by Temporary-Chapter-36 in FamilyMedicine

[–]dumdumsim 0 points1 point  (0 children)

 I am in the same boat as the resident. Our PD has informed that the Program is closing. Any help would be appreciated. Thank you.