what they areA deterministic gate gives the same verdict every time.
A gate is an automated checkpoint a change must pass before it moves forward. "Deterministic" is the load-bearing word: for the same code in, you get the same pass/fail out — no temperature, no sampling, no model in the loop guessing. A linter either finds the unused variable or it doesn't. The type checker either resolves the call or it errors. The test suite is green or red. That repeatability is exactly what you want guarding production: a decision you can reproduce, audit, and trust at 3am, not a probabilistic 'looks fine to me' from a second AI that's as confident when it's wrong as when it's right.
- Deterministic = same code → same result, every run, with no LLM judging at runtime.
- Review is exploratory and can be fuzzy; merge is enforcement and must be exact.
- A reproducible green/red verdict is auditable. 'The AI thought it was okay' is not.
the four gatesLint, types, tests, security — ordered cheapest-first.
There isn't one gate, there's a wall of them, and the order matters because each one is more expensive than the last. Lint and formatting run in seconds and fail fast. Type checking catches the call that doesn't typecheck, the null that wasn't handled — the boring class of bug AI loves to introduce because the code reads beautifully. Tests prove the behaviour the change claims, and that nothing else broke. Security scanning catches leaked secrets, injection patterns, and known-vulnerable dependencies. Running the cheap gates first means a broken change dies in two seconds, not after a four-minute pipeline.
- Lint & format — style and dead code, seconds, fails fast.
- Types — the calls, nulls and contracts AI gets fluently wrong.
- Tests — proves the new behaviour and protects the old.
- Security — secrets, injection, vulnerable deps, before they reach prod.
why AI needs them moreAI-generated code is fluent by construction. Fluent isn't correct.
A model writes code that is more confident, more idiomatic and more plausible-looking than most humans write — which is precisely why it slips through human review. Your eyes skim a clean diff and approve it; the bug is in the edge case nobody re-derived. Multiply that by a model that can open twenty diffs an hour and human review stops being a safety net and becomes theatre. Deterministic gates don't get tired, don't get charmed by tidy formatting, and don't approve the twentieth diff more loosely than the first. They convert a category of human-review burden into evidence: machine-checked, every change, no exceptions.
- Generation got cheap; honest verification didn't — so it has to be automatic.
- Gates never skim, never rubber-stamp, never have a bad Friday.
- Using an AI to approve another AI's code just moves the unreviewed risk one layer up.
the methodGates are step three of the Digital Native Method.
Gates only work if someone decided what 'good' means and someone described what to build. That's the method. A Product Owner describes the intended result on the live product — no ticket, no spec dump. A Tech Lead encodes the rules once: architecture, conventions, the security bar, your company's non-negotiables. Then agents implement inside those rules, and the deterministic gates verify the output before anything lands — through your own GitHub, so the audit trail is yours. The gate is the last and least negotiable line: green or it doesn't ship. That's the difference between vibe coding at home and shipping vibe-coded software at work.
- Product Owner describes the outcome on the live product.
- Tech Lead encodes the rules once; every agent boots inside them.
- Agents implement; gates verify; only green changes merge to your GitHub.
the softwareA method needs software to enforce it. That's Agentation.
Knowing you should gate every change is not the same as having a structure that actually does — automatically, on every diff, before prod, without you wiring up five tools and praying the config holds. Agentation is that software. It spawns agents inside the Tech Lead's encoded rules, runs lint/types/tests/security as deterministic gates on each change, and only promotes work that comes back green. You watch results land, not diffs to babysit. The gates are the product, not a feature you remember to turn on.
- Every change is gated automatically — there's no 'skip review' button.
- The Tech Lead's rules and the gates travel with every agent.
- You see verified results, not raw output you have to trust by hand.
cocoricoYou can't own the model. You can own the gates.
Agentation is built by a French team. We're honest about sovereignty: nobody in Europe is sovereign on the frontier models — Claude and GPT are American, and pretending otherwise is theatre. But the model is the smallest part of the stack. With a raw model you can't do much: the value is in the orchestration, the encoded rules and the gates that turn output into shippable software — and that layer can be entirely yours. Ours runs in the EU: hosting in Germany (Hetzner), data in the EU (Supabase), your code in your own GitHub, GDPR by design. Sovereign where it's actually achievable: the tools, not the weights.
- French team; hosting in Germany; data in the EU; GDPR by design.
- Your code stays in your GitHub — the gates run on your side, not ours.
- Sovereignty on the orchestration and the gates — the part that's truly yours to own.
FAQWhat does 'deterministic' actually mean for a gate?
It means the gate returns the same pass/fail verdict for the same code, every single run, with no model sampling a judgement at runtime. A linter, type checker, test suite and security scanner are deterministic: same input, same output. That reproducibility is what makes a merge decision auditable — you can re-run it and get the identical answer, which a probabilistic AI reviewer can't promise.
Why not just use an AI to review the AI's code?
Because that moves the unreviewed risk up a layer instead of removing it. An LLM reviewer is fluent and confident even when it's wrong, and it can be inconsistent between runs — exactly the properties you don't want enforcing a merge. AI is great at exploring a diff and explaining it; it should not be the thing that says 'ship'. The merge decision belongs to deterministic checks you can reproduce and audit.
What order do the gates run in, and why?
Cheapest and fastest first: lint and formatting (seconds), then type checking, then tests, then security scanning, which is usually the heaviest. Failing fast in the cheap gates means a broken change is rejected in a couple of seconds instead of after a full pipeline — it keeps the loop responsive and the feedback immediate.
Do deterministic gates replace human code review entirely?
They replace the mechanical part of review — the style nits, the type errors, the obvious regressions, the leaked key — that humans do badly and inconsistently at scale, especially against fluent AI output. They free human judgement for what it's actually good at: is this the right product decision? In the Digital Native Method, the human judges the result; the gates verify the implementation.
Can't AI-generated code pass the gates and still be wrong?
Gates catch what they're configured to catch — broken types, failing tests, insecure patterns, drift from your conventions. They don't certify that you asked for the right feature; that's the Product Owner's call on the live result. The point isn't that gates make code perfect, it's that nothing ships unverified: every change carries machine-checked evidence instead of a rushed human 'looks fine'.
Where does Agentation run the gates, and who sees my code?
The gates run against your own GitHub, on your existing AI plan. Agentation's orchestration is hosted in the EU — servers in Germany (Hetzner), data in the EU (Supabase), GDPR by design — and we don't keep your source. You own the model relationship and the repository; Agentation provides the structure and the gates around them.