I've been writing code with AI assistants for a while now. Copilot, Claude, ChatGPT — I've used them all. And for the most part, they're genuinely impressive. They save time. They help me think through problems. They write boilerplate I'd rather not write myself.
But here's the thing nobody talks about enough: AI-generated code has a specific category of bugs that normal linters don't catch.
Not syntax errors. Not style violations. I'm talking about security vulnerabilities, false-confidence patterns, and subtle logic issues that look completely correct — until they're not.
I got burned enough times that I built something about it. It's called hallint, and it's a free, open-source static analysis tool designed specifically for AI-generated code. You can find it on GitHub: github.com/Asyncinnovator/hallint
Traditional linters were designed for human-written code. They're great at catching things humans commonly get wrong — unused variables, missing semicolons, incorrect type usage.
But AI assistants fail differently.
Here are the patterns I kept seeing over and over:
1. Hardcoded secrets
AI assistants will happily write const API_KEY = "sk-abc123..."
in your source code. It passes every lint check. It works perfectly in dev. And then you push to GitHub and your key is live in a public repo.
2. SQL injection
// AI generates this and it looks totally fine
const user = await db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)
No ESLint rule will flag this. But it's a textbook SQL injection vector. Every time.
3. Missing auth on route handlers
AI is great at generating CRUD routes. It's not great at remembering to add authentication middleware. You end up with a perfectly structured Express router where half the routes are completely unprotected.
4. Permissive CORS
app.use(cors({ origin: '*' }))
This is a one-liner fix for the CORS errors you see in development. AI assistants suggest it constantly. It's also a wildly bad idea in production.
5. innerHTML with unsanitized strings
element.innerHTML = userInput // XSS waiting to happen
LLMs write this pattern a lot. It's the obvious, readable way to set content — and it's a cross-site scripting vulnerability.
hallint is a TypeScript library and CLI tool that scans your codebase for these AI-specific failure patterns.
It uses three detection layers:
No install needed — just run it with npx:
npx @asyncinnovator/hallint-cli ./src
Or scan a specific glob pattern:
npx @asyncinnovator/hallint-cli "./src/**/*.ts"
Only care about serious issues? Filter by severity:
npx @asyncinnovator/hallint-cli ./src --min-severity high
It exits with code 1
on any critical or high finding, which makes it easy to use as a CI gate.
If you want to integrate it into your own tooling:
npm install @asyncinnovator/hallint
js
import { scan } from '@asyncinnovator/hallint'
const result = await scan({
files: ['./src/**/*.ts'],
rules: 'recommended',
minSeverity: 'high',
})
result.findings.forEach(f => {
console.log(`[${f.severity}] ${f.ruleId} ${f.filePath}:${f.line}`)
console.log(` ${f.message}`)
console.log(` fix: ${f.fix}`)
})
You can also scan a string directly without touching the filesystem:
import { scanSource } from '@asyncinnovator/hallint'
const findings = scanSource(`const apiKey = "sk-abc123def456"`, 'example.ts')
Right now hallint ships with eight rules, all targeting the patterns I described above:
| Rule | Severity | What it catches |
|---|---|---|
hardcoded-secret |
||
| critical | API keys, tokens, passwords in source code | |
sql-injection |
||
| critical | User input interpolated into SQL queries | |
unsafe-eval |
||
| critical | ||
eval() or new Function() with dynamic input |
||
missing-auth-check |
||
| high | Route handlers with no auth middleware | |
xss-innerHTML |
||
| high | Unsanitized strings assigned to innerHTML |
|
permissive-cors |
||
| high | ||
cors({ origin: '*' }) in route handlers |
||
async-no-catch |
||
| medium | ||
async functions with no try/catch or .catch() |
||
http-not-https |
||
| medium | Hardcoded http:// URLs in fetch or axios calls |
ESLint with the right plugins will catch some of this. But there are a few important differences.
Existing linters weren't built with AI failure modes in mind. They weren't designed around the question "what does an AI assistant get wrong?" They were designed around the question "what do humans get wrong?" Those are different questions with different answers.
hallint is designed to be AI-aware. The rules target the specific intersection of "AI generates this confidently" and "this is actually a problem." The goal isn't to be comprehensive — it's to be precise about the failure modes that matter most for AI-generated code.
The LLM layer is something ESLint can't do. When you enable the optional LLM review, hallint can flag issues that don't match a known regex or AST pattern — things like "this auth flow looks structurally correct but has a logical flaw." That's a different category of analysis entirely.
Here's the kind of thing it catches. Say you take some AI-generated Express code:
import express from 'express'
import db from './db'
const app = express()
app.get('/users/:id', async (req, res) => {
const user = await db.query(
`SELECT * FROM users WHERE id = ${req.params.id}`
)
res.json(user)
})
hallint flags it:
[critical] sql-injection: User input interpolated directly into SQL query.
Use parameterized queries: db.query('SELECT * FROM users WHERE id = $1', [req.params.id])
→ src/routes/users.ts:6
Clean, direct, tells you exactly what to fix.
One of the things I wanted from day one was a zero-friction GitHub Actions integration. hallint exits with code 1
on critical or high findings, so this just works:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npx @asyncinnovator/hallint-cli ./src --min-severity high
You can also add it as a pre-commit hook via husky if you want to catch issues before they even get pushed.
The whole thing is MIT licensed and lives at ** github.com/Asyncinnovator/hallint**. Issues and PRs are open.
I think this kind of tooling should exist in public, not behind a paywall. If AI-generated code has specific vulnerability patterns, the entire ecosystem benefits from shared, community-maintained detection rules.
The rule-writing surface is intentionally small — each rule is a single file (~30 lines) with a bad.ts
/ good.ts
fixture. If you've seen an AI-specific pattern that hallint doesn't catch yet, the path from "I noticed this" to "I shipped a fix" is genuinely short. Issues labeled good first issue are pre-scoped and ready to pick up.
hallint is MIT licensed. Free to use in personal and commercial projects.