DEV Community: Łukasz Holc

Here is ESLint-like tool for composing AI agent rules — here's why

Łukasz Holc — Wed, 04 Mar 2026 21:27:51 +0000

If you use AI coding agents — Claude Code, Cursor, Copilot, Codex, Windsurf — you already know the pain: every agent wants its own context file. Claude Code reads CLAUDE.md, Cursor wants .cursorrules, Copilot expects .github/copilot-instructions.md, Codex needs AGENTS.md. The rules inside are usually the same, but you end up maintaining them separately across files you can never remember the name of.

I kept copying the same guidelines between projects and agents, tweaking formatting, forgetting to update one file when I changed another. So I built ai-rulesmith — a CLI that lets you define your rules once and compose them into the right output for each agent.

The ESLint analogy

The mental model is borrowed directly from ESLint. Rules are small, focused atoms — each one enforces a single practice (like code-style/strict-typescript or workflow/verify-before-completing). You pick the ones you need, skip the ones you don't, and compose them into a config. The tool generates the right file for each target agent.

npm install -g ai-rulesmith
rulesmith init
rulesmith build

One config (AI_RULES.json), multiple agents, consistent rules everywhere.

What makes it different

There are a few tools in this space now, but ai-rulesmith focuses on two ideas I haven't seen elsewhere:

Priority Zones — LLMs pay most attention to the beginning and end of their context window. The middle is a lower-attention zone. ai-rulesmith lets you explicitly place rules in before_start (top of context) and before_finish (bottom of context) sections, so critical behavioral rules like "understand the codebase before changing anything" don't get buried between coding standards.

Multi-step workflows — Instead of dumping everything into one file, you can define a stepped workflow where each step gets its own rule file. The main output instructs the agent to read step-specific files as it progresses. Think: Step 1 (Create) → Step 2 (Review) → Step 3 (Ship), each with its own rules.

Built-in ruleset

The tool ships with 29 rules across 9 categories, distilled from patterns found across the AI coding community — awesome-cursorrules, cursor.directory, Addy Osmani's spec writing guide, Trail of Bits' Claude Code config, and others. Categories include code style, testing, error handling, git workflow, security, architecture, and AI behavior.

But the real value is the composability model. You can override built-in rules at the project or global level, add your own custom rules as plain markdown files, and even use rule variables for project-specific values (like a project name or tracker URL).

Testing your rules

One feature I'm particularly happy about: rulesmith test lets you define scenarios that verify your rules actually influence agent behavior. It uses an LLM to simulate a prompt against your composed rules, then a judge model evaluates whether assertions pass. You can catch regressions in your AI workflow the same way you'd catch regressions in code.

Try it out

npm install -g ai-rulesmith
rulesmith init
# edit AI_RULES.json
rulesmith build

GitHub: https://github.com/Luzgan/ai-rulesmith

It's MIT licensed and contributions are welcome — especially new rules. Good rules are focused (one practice per rule), universal (not tied to a specific stack), and actionable (concrete guidelines, not vague principles).

I'd love to hear how others are managing their AI agent rules — are you maintaining separate files per agent? Using a different tool? Just copy-pasting and hoping for the best?

I Built a Tool That Feeds AI Assistants Real Big-O Analysis Instead of Letting Them Guess

Łukasz Holc — Thu, 26 Feb 2026 21:35:11 +0000

The Problem

Frontier AI models can analyze time complexity. But they do it by reading your code, reasoning through it, and burning tokens in the process. Sometimes they get it right. Sometimes they confidently tell you a function is O(n) when it's actually O(n²) because there's a .contains() hiding inside a loop.

What if we skip all that and just feed them the answer through static analysis?

The Solution

I built Time Complexity MCP — an MCP server that parses your code into ASTs using tree-sitter, walks the syntax tree to detect complexity patterns, and reports per-function Big-O with line-level annotations.

It works as a tool that Claude Code or GitHub Copilot can call on demand — no tokens spent on analysis, just structured results.

GitHub: Luzgan/time-complexity-mcp

What It Detects

Loop nesting — for, while, do-while with depth tracking. Constant-bound loops (e.g., for i in range(10)) are recognized as O(1)
Recursion — linear recursion (O(n)) vs branching recursion like fibonacci (O(2^n))
Known stdlib methods — .sort() as O(n log n), .filter()/.map() as O(n), .push()/.pop() as O(1). Each language has its own pattern set
Combined complexity — a .indexOf() inside a for loop correctly reports O(n²), not O(n)

Supports JavaScript, TypeScript, Python, Java, Kotlin, and Dart.

How It Works

Each language has an analyzer class that implements 9 template methods from a shared BaseAnalyzer:

Parse the source file into an AST via tree-sitter
Extract all function nodes
For each function, walk the tree to find:
- Loops (and their nesting depth)
- Recursive calls (and whether they branch)
- Known stdlib calls (e.g., .sort(), .indexOf())
Combine the results: an O(n) method inside an O(n) loop = O(n²)
Return structured results with per-line annotations

No code is ever executed — it's pure structural analysis.

The Fun Part: Self-Analysis

I pointed the tool at its own codebase. 27 files, 150 functions.

The breakdown:

Complexity	Count
O(1)	102
O(n)	40
O(n log n)	1
O(n²)	4
O(n³)	2
O(2^n)	1

It found real issues:

The directory scanner was O(n³) — because .indexOf() was being called inside a .sort() comparator, which was called after a nested file → function iteration loop. A formatting utility was O(n²) for the same .indexOf() reason.

I fixed those based on its own report. Replaced .indexOf() lookups with a Map for O(1) access. The tool ate its own dog food.

Setup

Download a prebuilt release for your platform from GitHub Releases, extract it, and add to your MCP config:

{
  "mcpServers": {
    "time-complexity": {
      "command": "node",
      "args": ["/path/to/time-complexity-mcp/dist/index.js"]
    }
  }
}

Restart Claude Code and the tools are available. No npm install, no C++ compiler — just Node.js 18+.

Or install from source:

git clone https://github.com/Luzgan/time-complexity-mcp.git
cd time-complexity-mcp
npm install && npm run build

What's Next
Open to feedback and language requests. The architecture makes it straightforward to add new languages — each one is ~3 files implementing the template methods for that language's AST structure.

Repo: github.com/Luzgan/time-complexity-mcp