Try Benzi Tests Code Maps Against Claude Code

Try Benzi is a Show HN coding harness from its independent maker that builds a queryable map of a codebase for an agent. A coding harness is the scaffolding around an agent that controls what it can inspect, how it edits, and how its work is checked. The project deals with a familiar Claude Code problem: agents can lose time rediscovering repo structure, then make plausible edits that miss static checks. The useful takeaway for Claude Code, Anthropic's coding agent, is that how to use Claude Code skills starts with measurable task boundaries, not a prettier prompt.

Read the benchmark as a harness claim

Try Benzi's pitch is not just that another agent scored better. The interesting claim is that the harness changes the shape of the work.

The author says Benzi compiles codebases into O(1) hashmaps that the agent can query to answer structure questions and write code. The project also says it runs complete static analysis checks on writes the agent makes.

That matters because many coding-agent failures are boring. The agent searches twice, edits the wrong sibling file, misses a generated type, or times out after building a mental map that a compiler already knew. A repo map attacks that waste directly.

The benchmark page is still a project benchmark, not a neutral lab result. The author reports that Claude Code, mostly using Sonnet on one task, regressed or timed out on 2 of 20 tests, while Benzi did not and was cheaper, faster, or often better on many of the remaining tasks. Treat that as a reason to inspect the harness, not as a final leaderboard.

The trap is reading it as model drama. The more useful question is: what did Benzi measure that your Claude Code workflow probably does not?

Notice the map, not the model

The clever part is the code map. An agent with a queryable structure index does not have to spend every task reconstructing the same repo layout from grep, file reads, and guesses.

Picture a Node service with src/routes, src/services, src/db, and test/integration. A normal agent asked to add a billing endpoint may read route files, infer naming conventions, inspect tests, then finally discover that route registration lives in a plugin loader. A mapped harness can ask the codebase where routes are declared, where symbols point, and which files will be affected before it edits.

That is especially interesting for Claude Code users because Claude Code already gives you strong interactive ergonomics. The missing piece is often not chat quality. It is reliable evidence that the agent found the right surface area before touching code.

Static analysis is the second half. If a harness checks writes before returning success, it moves from answer generation toward task execution. A passing typecheck is not proof of correctness, but it is a useful floor.

The trap is assuming a map understands intent. A code map can find structure. It cannot know that your team intentionally duplicated an adapter during a migration unless that convention is written somewhere durable, such as a short repo memory note or a focused skill.

Keep Claude Code skills narrow enough to measure

Claude Code skills are reusable, on-demand instructions and assets that help Claude perform a specific kind of work. The best claude code skills feel less like training manuals and more like small instruments: they name a task, list the relevant files, define checks, and say what evidence counts.

This is where Benzi's lesson becomes practical. If you want to know how to use Claude Code skills after seeing Try Benzi, do not start with a giant skill called backend engineering. Start with one task where a map, a convention, and a check can meet.

A useful skill outline for the billing endpoint example might look like this:

---
name: api-route-change

description: Use when adding or changing HTTP routes in the Node API.

Read first:
- src/routes/index.ts
- src/routes/*
- test/integration/routes/*

Before editing:
- Identify the existing route registration pattern.
- Name the service method and test file that should change.

Acceptance checks:
- npm test -- --runInBand test/integration/routes
- npm run typecheck
- Show changed files and why each changed.

That is not as fancy as an agent leaderboard. It is better than vibes.

The trap is using claude skills as a dumping ground for everything the repo knows. Put durable, always-on constraints in concise project memory when needed. Put repeatable task procedures in skills. Keep task-specific context in the prompt.

For a neighboring story about packaging skills across app workflows, see aident-skill Connects Codex and Claude Code to Apps.

Try Benzi when the repo hides structure

Try Benzi is worth trying when the expensive part of the task is discovery. Large monorepos, framework-heavy apps, generated clients, and service boundaries are good candidates because agents burn real tokens and time learning where things live.

It is also a good fit for benchmarkable maintenance work. Examples include renaming an API field through handlers and tests, adding one route, migrating a lint rule, or updating a typed client. These tasks have enough structure to benefit from a map and enough checks to detect bad edits.

It is probably overkill for a tiny repo, a one-file script, or a design-heavy change where the hard part is deciding product behavior. In those cases, a code map may make the agent faster at finding files without making it wiser about the decision.

The practical Claude Code move is to pair the experiment with a narrow skill and a written acceptance rule. The skill says what kind of task this is. The harness or local workflow says what proof must pass. The review then compares Benzi, Claude Code, and human expectations on the same bounded task.

This is also the kind of convention that belongs in the related training topic: not a grand process, just a shared habit for measuring agent work before trusting it.

Try it safely: a skill acceptance rubric

Use this rubric when you test Try Benzi, Claude Code, or a Claude skill on the same repo task. Keep it small. One hour of honest measurement beats a week of arguing about which agent feels smarter.

A small permission note helps too: keep external systems read-only during the first test. If a task needs GitHub, Jira, or a database through MCP, let the agent read context but require a human to apply writes until the rubric has passed on a few real tasks.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude skills?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code skills. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Try Benzi Tests Code Maps Against Claude Code.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Try Benzi — source
• Claude Code — skills
• GitHub — anthropics/skills
• Claude Code docs: en getting started

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.