Stop repeating the same architecture review on AI-generated PRs.

Turn recurring architecture review comments into deterministic PR checks before they reach human review.

Apply for the design partner pilot See how it works

TypeScript / JavaScript teamsAI coding tools already in workflowRecurring architecture review debt

Evaluation result highlighting a forbidden pattern

Who this is for

We are currently onboarding a small number of companies to validate Unbx on real repositories.

Using AI coding toolsActive PR workflowRecurring architecture review debt

Define

Describe the architectural decision your team already repeats in review.

Rule

Controllers must not import repositories directly.

Detect

Unbx validates the rule and scans the repository for structural violations.

Detectable2 violations found

Enforce

Surface violations in the development workflow before they become repeated review work.

PR #142 · Unbx check failed2 violations

Your team has already written the rules. They are trapped in review comments.

Senior Review · PR #89

"Move this logic out of the controller."

Senior Review · PR #103

"Do not call the database from this layer."

Senior Review · PR #117

"Use the project logger instead of print."

Senior Review · PR #134

"Follow the existing repository pattern."

AI coding makes implementation faster, but written guidelines remain advisory. Senior engineers repeatedly reconstruct the same architectural context during review.

Unbx turns the repeatable part of that context into enforceable rules.

From engineering intent to enforceable checks.

Describe the rule

Enter a natural-language engineering constraint.

Rule

Controllers must not import repositories directly.

Validate the rule

Unbx converts it into a structured rule specification and reports its support level.

Rule specification generated

Query compiled

Canary positive matched

Canary negative passed

Fix template: not available

DetectableTypeScript · JavaScript

Scan and enforce

The rule is applied to repository changes through Unbx, CI, or pull-request checks.

src/orders/controller.tsViolation

src/payments/handler.tsViolation

Rules for every layer of your architecture.

Keep dependencies and responsibilities inside the boundaries your system expects.

Example rule

API handlers must call services, not repositories.

Enforced

src/users/users.service.ts

src/orders/orders.handler.tsViolation

src/payments/payments.service.ts

Linters know syntax. Unbx enforces your architecture.

Capability	Linters	Semgrep	AI review	Human review	Unbx
Style and syntax rules	Strong	Strong	Variable	Strong	Supported
Known code patterns	Limited	Strong	Variable	Strong	Strong
Organization-specific architecture	Weak	Manual	Non-deterministic	Strong	Core capability
Natural-language rule input	No	No	Yes	Yes	Yes
Deterministic repeatable checks	Yes	Yes	No	No	Yes
Explain support limitations	Limited	Technical	Variable	Yes	Required

A generated rule is not trusted until it is verified.

Before a rule is used, Unbx validates its structure and tests whether it detects the intended pattern. The interface exposes validation status, supported scope, and scan integrity instead of hiding uncertainty behind an AI response.

Rule verificationScan integrity: Passed

Rule specification generatedPassed

Query compiledPassed

Canary positive matchedPassed

Canary negative passedPassed

Fix templateNot available

Supported languagesTypeScript · JavaScript

Enforce rules where code already changes.

Unbx runs on pull requests automatically. Changed files are scanned against your active rules and violations are surfaced before the code reaches review.

github.com / your-org / your-repo / pull / 142

Add order processing feature#142

Openfeat/order-processing → main · 3 commits · 5 files changed

Checks

Unbx · Architecture check2 violations · Controllers must not access repositories directly

just now

CI · Build and testAll checks passed

2 min ago

Controllers must not access repositories directly.2 violations

src/orders/controller.tsline 13

src/payments/handler.tsline 9

View rule and suggested direction →

Built for engineering teams that need to understand the result.

Deterministic scanning

Rule checks are structural, not probabilistic. The same input produces the same result.

Limited AI responsibility

AI is used for rule input and suggestions only. Detection logic is deterministic.

Explicit support status

Detectable, partially detectable, and unsupported rules are always clearly labeled.

Least-privilege GitHub access

Unbx requests only the permissions required to read changed files and post check results.

Transparent scan integrity

Every rule shows its validation result. Uncertainty is surfaced, not hidden.

Data handling controls

Customer code is not used for model training. Data retention policy is documented.

Read the architecture & security brief →

Help shape architecture enforcement for AI-native teams.

What you get

Early access to Unbx
Direct support for rule definition
Priority influence on supported rules and languages
A structured pilot around a real repository

What we ask for

An active software repository
Regular use of AI coding tools
A recurring architecture or review problem
Periodic feedback during the pilot

Best suited for 2–20 person engineering teams using AI coding tools in production development.

We review applications personally and prioritize teams with active repositories, recurring architecture review issues, and regular use of AI coding tools.

About 1 minuteDirect response from the team

FAQ

: Linters detect style, syntax, and known code patterns through predefined rules. Unbx enforces organization-specific architectural decisions that linters cannot express — such as which modules may import from which layers, or which patterns are prohibited in your specific codebase.
: Semgrep requires manually writing pattern rules in its own syntax. Unbx accepts natural-language rule descriptions, converts them into structured checks, and reports whether the rule can be detected before applying it. Unbx is focused on team-specific architectural intent rather than generic security patterns.
: No. LLM assistance is used to interpret natural-language rule input and generate rule specifications. The actual code scanning is deterministic. The same rule applied to the same code always produces the same result.
: No. Unbx validates each rule and reports whether it is detectable, partially detectable, or unsupported before applying it. Rules that depend on runtime behavior, business semantics, or context that cannot be determined structurally will be marked as unsupported.
: Unbx reports the rule as unsupported and explains why. It will not apply a rule that cannot be reliably detected. You can modify the rule, narrow its scope, or leave it as a documented guideline outside Unbx.
: No. Unbx detects violations and surfaces suggested directions. It does not apply automatic code changes. Fix availability varies by rule and is clearly labeled in the interface.
: TypeScript and JavaScript are supported in the current MVP. Additional languages are planned based on design partner feedback.
: Unbx requests read access to repository contents and permission to write check results on pull requests. It does not request write access to code or the ability to merge or close pull requests.
: Unbx is in design partner validation. It is functional on real repositories but is not yet a general-availability product. Design partners work directly with the team during a structured pilot.
: Design partners connect a real repository, define rules for their recurring architectural problems, and use Unbx during active development. The team provides direct support throughout. Partners give structured feedback in exchange for early access and direct influence on the product roadmap.

Stop repeating the same architecture review.

Join a limited pilot with direct onboarding from the founding team and validate Unbx on a real repository.

Apply for the design partner pilot See how it works