I built a code-taste linter for coding agents

Sun, 18 Oct 2026 00:00:00 +0000

I like coding, and I still review the code my agents write. The frustrating part isn’t always that the code is wrong. Often it works, but it’s not how I would have written it.

I find it introduces an abstraction that doesn’t need to exist or spreads a simple operation across several helpers. After enough rounds of giving the same feedback, I started wondering if I could turn those preferences into rules.

That’s where Jevlint came from.

Not your normal linter

Traditional linters are good at questions with deterministic answers. Code taste is different. Two implementations can be correct, and I can still prefer one over the other.

Jevlint lets me describe a preference in plain language and check code against it. The rule belongs to the repository, rather than living in a prompt I have to repeat every time I use an agent.

Here is the kind of thing I mean. One of my rules is wrapper-without-value. The fixture I use to test it is a function that only forwards to another function:

func GetUserPoints(userID int) int {
	return fetchPoints(userID)
}

That compiles, and nothing is technically wrong with it. It’s just a layer that doesn’t earn its keep. The passing version of the same fixture adds a real guard, so the wrapper is now doing something:

func GetUserPoints(userID int) int {
	if userID <= 0 {
		return 0
	}
	return fetchPoints(userID)
}

No AST rule is going to tell those two apart on taste. A plain-language rule can.

What it does

Jevlint uses Tree-sitter to parse source files and extract functions, types, and other code units. It sends relevant units and applicable rules to a configured decision provider (currently support Jev, Cloudflare’s decisioning models, OpenAI decisioning models with more to come). It can also gather deterministic repository evidence, including direct callers, callees, related types, and imports.

It is conservative about resolution: when it can’t connect a relationship confidently, it omits it.

That evidence used to be a narrower “callee context” feature. I replaced it with a repository-wide index that is built once per run and resolves callees, callers, related types, and imports into evidence with provenance (path, lines, symbol, source). Being conservative mattered in practice. In review I found that a non-relative import from an unrelated module whose path happened to end in a local directory name (something like github.com/other/project/internal/auth) could bind to my local code. Now a non-relative Go import only resolves if it is inside the repository’s own module, read from go.mod. Wrong evidence is worse than no evidence, because the model will trust it.

Using Jevlint on Jevlint

Jevlint’s own repository has a jevlint.json at the root, and it applies my rules to Jevlint’s own source. It currently lists 26 rules (config format is in the README Rules section), things like unnecessary-abstraction, speculative-generalization, wrapper-without-value, boolean-parameter, swallowed-errors, and comment-quality, with include: ["**/*"] and the example fixtures and Go tests excluded. The README tells contributors to run go run ./cmd/jevlint check . from the repo root when working on Jevlint itself.

A rule like comment-quality is a good example of why I wanted this on my own code. It fails comments that just paraphrase the code, and passes ones that explain intent or constraints. Agents love writing the first kind.

Testing the rules

I added evals because a rule can sound clear and still produce surprising results. Each fixture declares an expected pass or fail. The eval runner reports whether the result matches, and distinguishes inconclusive decisions from actual passes.

The repo ships its own eval file, jevlint-evals.json, with 674 cases over the fixtures in examples/rules. Each rule has good and bad fixtures in a dozen or so languages, so I can check that a rule like boolean-parameter behaves the same in Go, TypeScript, Python, Rust, and the rest. A case looks like this:

{
 "rule": "database-joins",
 "file": "examples/rules/database-joins/bad/example.go",
 "expect": "fail"
}

My loop is to let an agent write code, run Jevlint, review the code myself, and update rules or fixtures when the feedback isn’t what I intended. Having evals allows me to create test cases that helps build my own confidences that my rules hold up to the test of time over a lot of code.

Limitations

Jevlint isn’t a guarantee that code is good. The model can be wrong, a rule can be vague, and repository context can be incomplete. Confidence scores don’t replace human review. Provider latency and costs matter, too.

I want to catch the recurring review comments before I have to repeat them. The goal isn’t to replace my judgment; it’s to make my preferences easier to apply consistently so that when a coding agent uses jevlint, they get immediate feedback before my eyes ever look at the code.