{"slug": "typesafe-ai-jev-running-370-text-rules-under-2-seconds", "title": "Typesafe AI Jev Running 370 Text Rules under 2 seconds", "summary": "Developer MrDesjardins built Jev Realtime Code Check, a VS Code/Cursor extension that runs 370 Markdown coding rules against local Git diffs using TypeSafe AI's Jev model, in a single 2-hour session. The extension loads only rule files whose applies_to glob matches a file in the diff, and a second Jev request uses the score and choice primitives to rate severity from Minor to Blocking and identify the responsible code block, with line numbers parsed from diff hunk headers. The author reported hitting a max_tokens_exceeded error at scale, which led to sizing request batches by measured payload rather than a fixed rule count.", "body_md": "[← All technical posts](https://patrickdesjardins.com/blog)\n\n# Typesafe AI Jev Running 370 Text Rules under 2 seconds\n\nPosted on:\n\nI wanted a way to catch coding-rule violations the moment I introduce them, not three days later in a PR review. So one evening I sat down with Claude Code and built a real VS Code/Cursor extension for it. What surprised me most wasn't the idea, is that by using Jev I could run locally by hitting save a large corpus of 370 rules. Furthermore, because these rules live in the repository, the pull request agent could use them later having the same rules.\n\n## What it does\n\n[Jev Realtime Code Check](https://github.com/MrDesjardins/jevrealtimecodecheck) watches your local Git changes and checks them against your own coding rules, using [TypeSafe AI](https://docs.typesafe.ai)'s Jev model. The rules aren't hardcoded into the extension; they live in a directory of Markdown files you write and version-control like any other project file:\n\n```\n---\napplies_to: **/*.ts\n---\n\n# No console statements\nCode must not contain `console.log`, `console.debug`, or `console.info`\ncalls. Use a proper logger, or remove them before committing.\n\nGood:\n``` ts\nlogger.info(\"Config loaded\", { path });\n```\n\nBad:\n``` ts\nconsole.log(\"Config loaded\", path);\nThat `applies_to` line matters more than it looks. The extension only loads and sends the rule files whose glob actually matches a file in your diff, so a Python-only change never pulls in your TypeScript rules, and a `.tsx` edit only loads your React rules. As a stress test I ended up writing 370 example rules across 11 file types (TypeScript, React, CSS, Sass, Markdown, Python, Go, JSON, YAML, HTML, shell) and confirmed a mixed diff correctly loads only the rule files that apply, nothing more.\n\nFor anything Jev flags as an actual violation, a second, smaller request asks two more questions: how severe is this (Minor to Blocking, using Jev's `score` primitive), and which specific block of newly added code is responsible (Jev's `choice` primitive again, this time over the diff's own hunks). The line number for that block is never invented by the model, it's parsed straight out of the diff's hunk headers, so clicking a violation in the sidebar jumps to a real line, and it shows up as an actual Problems-panel diagnostic too.\n\n## How fast this actually went to use Jev?\n\nThe whole thing, from a blank repo to an installed extension I could point at real edits, took a single working session. The rough shape of it:\n\n- Scaffolded the extension, the rules parser, and the Git-diff collector.\n- Wired up the Jev API calls (one `choice` question per rule, batched).\n- Built the sidebar UI, grouped by outcome so hundreds of rules don't turn into a wall of green checkmarks.\n- Hit a real `max_tokens_exceeded` error once I scaled the rules up, which pushed the batching from \"fixed number of rules per request\" to \"size the batch by the actual measured payload,\" since a large diff, not the rule count, turned out to be what blew the request budget.\n- Found and fixed a subtler bug where a global cap on diff \"blocks\" silently starved every file except the first two from ever getting a click-to-jump location, only caught because I tested against the live API instead of trusting the code.\n\nTotal time: 2 hours!\n\n## Why I like Jev and using Markdown\n\nThe rules are just data. I'm not maintaining a linter plugin or writing custom AST checks, I'm writing a Markdown heading and a sentence, and letting Jev's judgment handle the \"is this actually a violation of the specific code that changed\" part, including the part regular static analysis is bad at: distinguishing a newly introduced problem from one that was already there before my change.\n\nSource code [in Github](https://github.com/MrDesjardins/jevrealtimecodecheck), and the video above walks through it live.", "url": "https://wpnews.pro/news/typesafe-ai-jev-running-370-text-rules-under-2-seconds", "canonical_source": "https://patrickdesjardins.com/blog/typesafe-ai-jev-running-370-text-rules-under-2-seconds", "published_at": "2026-09-17 00:00:00+00:00", "updated_at": "2026-09-17 04:54:20.036706+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products", "large-language-models"], "entities": ["Jev Realtime Code Check", "TypeSafe AI", "Jev", "MrDesjardins", "Claude Code", "VS Code", "Cursor", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/typesafe-ai-jev-running-370-text-rules-under-2-seconds", "markdown": "https://wpnews.pro/news/typesafe-ai-jev-running-370-text-rules-under-2-seconds.md", "text": "https://wpnews.pro/news/typesafe-ai-jev-running-370-text-rules-under-2-seconds.txt", "jsonld": "https://wpnews.pro/news/typesafe-ai-jev-running-370-text-rules-under-2-seconds.jsonld"}}