We Open-Sourced Sensei. It Is Code Review That Teaches Judgment.

TL;DR: We released Sensei as an open-source agent skill. It is not another code generator. It is a coaching layer for code review, debugging, planning, testing, refactoring, PR writeups, and engineering tradeoffs.

A lot of AI coding workflows have the same awkward ending.

The code works.

The developer cannot explain it.

That is a real problem.

If someone cannot explain the change, they cannot defend it in review, debug it when it breaks, or safely extend it next week. The code may pass today, but the team has already taken on debt.

This is especially visible with juniors, solo developers, students, and anyone building with AI assistance. The agent can produce something plausible very quickly. What it often does not produce is engineering judgment.

So we built Sensei.

Sensei is a senior engineering coach for your repo. It helps developers review code, debug issues, check implementation plans, inspect test quality, write PR descriptions, and reason through refactors and tradeoffs. The point is not to make the agent sound smarter. The point is to make the developer think more clearly before the code ships.¹

Now it is open source.

The missing layer is not another reviewer

Most review tools optimize for output.

They find problems. They suggest fixes. They summarize a diff. That can be useful, but it also trains a bad habit: outsource the judgment, accept the suggestion, move on.

Sensei is built around a different premise.

The developer still owns the code.

Sensei asks the questions that make that ownership real.

Can you explain what changed? What could break? Which existing pattern does this follow? What evidence proves this is safe? What did the tests actually prove? Is this the smallest clear change, or did the AI add scaffolding because it could?

This matters because code review is not just defect detection. It is how teams teach taste, boundaries, risk, and local architecture.

When the review becomes a stream of automated suggestions, the developer may get a cleaner diff and learn almost nothing.

Sensei is deliberately a little uncomfortable.

It pushes on reasoning before it pushes on code.

It works inside the repo because the repo is the context

Generic code advice is cheap.

Useful review depends on local context.

Sensei is meant to be installed in the project it is reviewing. That lets the agent inspect the things that actually shape quality: existing components, helper patterns, architecture docs, AGENTS.md, CLAUDE.md, Cursor rules, tests, package files, folder structure, Git state, open pull requests, recent commits, and any other installed skills.¹

That is the difference between "this function could be cleaner" and "this creates a second way to handle authorization compared with the rest of this codebase."

The second one is review.

The first one is commentary.

The skill set is a coaching loop

Sensei is not one giant prompt with a nice name.

It is a set of focused skills, each one aimed at a moment where developers usually need better judgment.

sensei-assess reads the Git state and routes the session. If there are uncommitted changes, it moves toward review. If there is an open pull request, it frames the review. If the branch is ahead of main, it helps prepare the PR. If work just finished, it reflects on what was learned.¹

sensei-spar is teaching-mode code review. It looks for correctness risks, security and privacy concerns, missing verification, code bloat, local pattern mismatches, unclear responsibilities, and generated-looking code that has not really been integrated.

sensei-trace is debugging without guessing. It starts with reproduction, expected versus actual behavior, recent changes, evidence, hypothesis, and experiment.

sensei-gameplan reviews an implementation plan before code is written. This is where it asks whether the plan fits the architecture, follows local patterns, names the security surface, and has a verification strategy that matches the risk.

sensei-prove-it checks what the tests actually prove. Passing tests are not enough. Sensei asks whether they cover the contract, the failure modes, the boundaries, and the security-sensitive paths.

sensei-scroll helps write a PR description with intent, risks, verification, and reviewer focus.

This is the shape we wanted: small skills, clear responsibilities, no fake super-agent.

The bar is simple

Sensei has a strong opinion about quality.

Less is more.

Prefer the smallest clear change that fits the existing codebase.

Challenge code bloat. Challenge duplicated knowledge. Challenge one-off abstractions dressed up as frameworks. Challenge clever hacks that bypass the architecture. Challenge security gaps as normal engineering work, not as a specialist concern someone else can worry about later.²

It also translates technical feedback into plain English.

If it says DRY, it explains that DRY means avoiding duplicated knowledge, not deleting every repeated line. If it says Single Responsibility Principle, it explains that a module should have one primary reason to change. If it flags a security concern, it names the consequence: could the wrong person see, change, delete, or trigger something they should not?

That plain-language layer is not cosmetic.

It is how you help a junior developer, a founder, or a non-technical builder understand the risk instead of just accepting the verdict.

Open source matters because review standards should be inspectable

We released Sensei as an open-source project under Apache 2.0.³

The reason is boring: if a skill is going to coach developers on code quality, security, refactoring, and PR readiness, teams should be able to inspect the coaching rules.

You should be able to see what it pushes on.

You should be able to change the bar.

You should be able to fork it for your own codebase, your own teaching style, your own risk tolerance, and your own engineering culture.

Sensei also fits the broader skills ecosystem. The registry page gives teams a simple installation path, and the repository keeps the actual skill behavior inspectable.⁴

That is healthier than hiding the review philosophy inside one closed prompt.

How to try it

Install Sensei in the repo you want it to review:

npx skills add onehorizonai/sensei

Then start with:

/sensei-assess

You can also call the focused skills directly:

/sensei-spar/sensei-trace/sensei-gameplan/sensei-prove-it/sensei-scroll

The first useful version can be as simple as a local pre-push reminder:

echo "Before pushing, consider running /sensei-spar and /sensei-prove-it"

Not ceremony.

The point is to catch the moment where "it works" is about to become "we understand it, we tested it, and we can defend it."

This is part of a bigger shift

At One Horizon, we care about the chain from intent to shipped work.

Tasks, specs, commits, pull requests, reviews, and decisions should not live as disconnected artifacts. They are the operating record of how software gets built.

Sensei is one piece of that direction.

It helps make the review and learning layer explicit. It turns AI-assisted development back into something a developer can explain, not just something an agent can generate.

That is the signal I care about.

More code is not the goal.

Better judgment is.