Build1 publisher2 min readPublished
AI Employee runs secret and dependency checks in plain code before any model sees the diff
In this self-hosted pipeline, secret scans and a three-day minimum age on new npm packages run with no model call, and a branch reaches GitHub only after a human clicks approve in the dashboard. The author calls it a developer preview.
The Engineer · Build desk

What happened
- A developer released AI Employee, a self-hosted system that runs coding agents through planner, coder, check, reviewer and critic stages before anything reaches GitHub.
- New dependencies are checked against the npm registry before the planner writes anything, and must be stable, at least three days old, and free of known advisories.
- The coder can write only inside its own task's git worktree, never the main checkout, while the planner, reviewer, critics, git and memory agents are read-only.
- On a server the agents run as a separate unprivileged Linux user with no sudo, no Docker, no GitHub credentials and no model API keys.
- Projects, tasks, events, approvals, cost records and memory all live in one SQLite file through Node's built-in node:sqlite, with FTS5 for memory search.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Every diff the no-model checks reject is a review round that never costs a model call, and the gateway refuses calls once a budget is hit, so a looping agent stops spending.
- constraint An age floor blocks legitimate same-day releases too: a team that needs a patch published this morning has to wait out the three days or override the gate.
- decision Adopters have to decide where model keys and GitHub credentials live, because this design keeps both off the account the agents run as.
- exposure The dashboard approval is the last control before GitHub, so the person clicking owns whatever the reviewer and critics missed.
The plain-code checks run after the coder finishes and before a reviewer session opens [4]. They look for secrets, broken JSON, YAML or JS, debug leftovers and risky new dependencies, and none of them calls a model [5]. A failure routes straight back to the coder, so obviously broken output never reaches a reviewer session [5]. "Coding agents are good at writing code and bad at knowing when they're wrong," the author wrote [1].
The dependency gate is the one stage that decides with a number. Three days is 72 hours. The author writes that he has watched an agent add a dependency published 20 hours earlier [2]. A 72-hour floor rejects that package with 52 hours to spare [22]. "This alone has saved me from a couple of typosquats," he wrote [7]. He is counting his own projects.
The containment is in the configuration. Agents sit inside the coding harness's own sandbox, Landlock or bwrap on Linux [11]. The author's reason for also running them as a stripped-down account is specific: without that separation, sandboxing alone cannot stop an agent reusing your git credentials [14]. Model keys sit in a local gateway that injects the provider key, records tokens and cost, and refuses calls once a budget is hit [17]. Planning, routine coding and final review can each point at a different provider, which in the author's example means OpenAI, a local Ollama model and Claude [18].
For any of this to help on your repository, your bad output has to be the kind plain code can see. Secrets are pattern-matched out of memory, handoff notes and commits before anything is written [15]. A change that parses and is still wrong goes to the reviewer, a separate read-only session that checks requirements, crashes, frontend and backend agreement, and tests, for up to three rounds [8]. One stage gets evidence of its own: the UI critic starts the app and judges real phone and desktop screenshots instead of the agent's self-report, and it runs only when a change touches UI or security-sensitive files [9].
The author says every stage exists because he hit the failure mode without it [23]. The post includes no measured results. This is a developer preview, used daily on his own projects, with interfaces and a database schema that may still shift between commits [19]. The repo is MIT licensed, and he asks for pull requests on the review and critic pipeline and on sandbox hardening [20].
What to watch
- Whether the schema settles out of developer preview, since anything built against the single SQLite file moves with it.
- Whether the dependency age and advisory gate extends past npm, which is the only registry the post covers.
- Whether outside pull requests arrive on the two areas the author named: the review and critic pipeline, and sandbox hardening.