Why I’m Building Nereid: Trust After the Agent Writes the Code

Coding agents are making implementation faster. Review has not become proportionally easier. A pull request can look plausible while leaving basic questions unanswered: which instructions were followed, what ran, what failed, whether output was truncated, and what the agent still considers risky. Asking a reviewer to reconstruct all of that from the diff gives away much of the speed the agent created.

Nereid is for small engineering teams that want to use coding agents without turning approval into a ritual. The product starts from a GitHub issue and aims to produce one reviewable delivery packet: lifecycle, diff references, verification, risks, failures, and a human decision.

GitHub issue -> control plane -> customer runner -> branch + PR
                         ^                 |
                         +-- evidence -----+
                                  |
                           human decision

• Source code, repository tools, Git authentication, and Codex authentication remain in the runner environment.
• Runner events are versioned, schema-validated, ordered, and idempotent on identical retry.
• Failed verification prevents review readiness.
• Only an allow-listed human reviewer can approve or reject.
• Nereid records a GitHub check but never merges.

The repository now has the pnpm/Turborepo shape, shared Zod protocol, Drizzle/Postgres schema, Next.js evidence surface, Node runner, one-use enrollment flow, GitHub issue ingestion, and deterministic policy tests. The runner uses a disposable worktree and an ephemeral workspace-write Codex execution, then records verification and attempts to push a branch and open a PR through the locally authenticated GitHub CLI.

The readiness state machine is the most important completed part. Duplicate delivery is safe when content is identical, altered replays are rejected, events cannot arrive out of sequence, failed checks remain visible, and a PR is required before the packet becomes ready. Adversarial fixtures cover prompt injection, secret-like output, event replay, and approval bypass.

By the end of the hackathon, Nereid had moved from a local interface to a hosted Railway deployment with a managed Postgres service, a private GitHub App installation, and working GitHub reviewer sign-in. The deployment exposes the control-plane and evidence-review surfaces while keeping access to starting and reviewing runs allow-listed to my GitHub identity.

The most useful outcome was not a claim that the platform was finished. It was a clearer product boundary: an agent can submit structured evidence, but it cannot declare itself review-ready or approve its own work. The interface makes a missing pull request visible even when verification passes.

• A complete live run against a separate public fixture repository has not yet been published.
• The hosted path still needs the Postgres schema wired in place of the in-memory preview store, so run state is not durable across deploys yet.
• The worktree and Codex sandbox are useful boundaries, but they are not a hardened container or enforced egress policy.
• GitHub reviewer authentication works, but the real runner-to-PR-to-check lifecycle still needs a published smoke test.
• There are no performance, adoption, or security-review claims yet.

The next milestone is one durable vertical slice: issue in, agent run, tested branch, pull request, persisted evidence packet, and human decision. That is the point at which Nereid can responsibly invite its first design partners.