Use case · Engineering

AI code review that read the project first

Most AI review tools see a diff. Hedy reviews merge requests with project context — recent decisions, related modules, your conventions — and posts a draft-first comment a human can act on. Merging stays human; writes are allowlisted per repository.

Hedy reviews merge and pull requests as a private AI employee that runs on your own infrastructure, not as a cloud bot living in someone else's chat. It reads your repo for real project context, posts inline review comments on GitLab and GitHub, and never merges. Every write is draft-first and whitelist-gated: comment and draft-note actions are allowed, while approve, merge, and push to protected branches are denied by default. Governance is the product—append-only audit, L0/L1/L2 approval tiers, and evidence-gated findings.

Last updated: 20 July 2026

How Hedy runs it

01

MR opened

Hedy pulls the diff plus surrounding source, recent commits on the touched files, and project context from her memory.

02

Context-aware review

Comments on correctness, hidden coupling and missed cases — referencing your codebase, not generic lint advice.

03

Draft-first, allowlisted

She can comment only on allowlisted repositories, never approve, never merge. The merge button stays with your team.

04

Logged as work

Each review lands in the activity ledger with a link — visible output, not vibes.

Governed by design

  • Repo writes are default-deny: an explicit allowlist opens each project
  • Review comments are logged append-only with reasoning
  • GitLab and GitHub supported; credentials stay in your deployment environment

In depth

Hedy reviews code with project context, not just the diff. Because it is deployed inside your infrastructure via Docker or Kubernetes, and can run against air-gapped networks, it reads the surrounding repository—conventions, adjacent modules, prior decisions—so review comments reference how your codebase actually works rather than generic lint. It adapts to both GitLab merge requests and GitHub pull requests through a dual adapter, using the same review behavior and the same governance controls on either platform.

The default posture is draft-first and comment-only. Hedy leaves inline review comments and draft notes; it does not approve, does not merge, and does not push to protected branches. This is not a prompt-level request—it is enforced in configuration and code, because a limitation that lives only in a system prompt does not exist. Merge, approve, and force-push sit outside the write whitelist and are denied by default, so a review pass can never silently change the state of your repository.

This is where Hedy diverges from cloud AI employees that live in Slack or Teams. Those tools mostly summarize and record; Hedy takes on the reviewing engineer's output while staying governed. Write operations follow a deny-by-default whitelist, sensitive actions escalate through L0/L1/L2 approval tiers, and every finding is evidence-gated—Hedy must cite the exact lines and sources it is reacting to, so a human can verify a comment instead of trusting an unsourced claim.

Everything runs under your governance stack. The audit log is append-only with no update or delete path, so the full history of what Hedy reviewed and posted is preserved. You bring your own model key—including local vLLM or Ollama—so code and diffs never leave your boundary, there are no sub-processors, and licensing is verified offline with Ed25519. Setup is a roughly 30-minute compose deploy, and Lark/Feishu and Slack are first-class for notifications and approvals.

Questions

Can the AI reviewer merge or approve my pull requests automatically?
No. Hedy is comment-only by default. It posts inline review comments and draft notes but cannot approve, merge, or push to protected branches. Those actions sit outside the write whitelist and are denied at the config and code layer, not just requested in a prompt, so a review pass never changes your repository state on its own.
Does Hedy work with both GitLab and GitHub?
Yes. Hedy has a dual adapter covering GitLab merge requests and GitHub pull requests, applying the same draft-first review behavior and the same governance controls—write whitelist, approval tiers, append-only audit—on either platform, so your review policy does not change based on which host you use.
How does Hedy avoid making up review comments?
Hedy runs behind an evidence gate: every finding must cite the exact lines and sources it references, so a reviewer can verify each comment against real code instead of trusting an unsourced assertion. Combined with project-context reading of the surrounding repo, comments reflect your actual conventions rather than generic rules.
Where does my code go during review, and who else can see it?
Nowhere outside your infrastructure. Hedy is self-hosted on Docker or Kubernetes, including air-gapped setups. You supply your own model key, including local vLLM or Ollama, so diffs never leave your boundary. There are no sub-processors, licensing is verified offline via Ed25519, and the audit log is append-only.

Related

hedy.one

See it on your own infrastructure.

Book a demo