Open Source · Für Code und für Office-Dokumente

Prüfen, was zählt.

Änderungen häufen sich schneller an, als jemand sie lesen kann: mit KI-Assistenten geschriebene Pull Requests, Budgets und Verträge, die durch viele Hände gehen. Probe vergleicht jede neue Version mit der, der Sie zuletzt vertraut haben, legt Ihnen die wenigen Änderungen vor, die Ihr Urteil brauchen, und zeigt, warum.

Neueste Version v0.5.1 · Befunde stammen aus festen Regeln, nicht aus einem Modell · KI optional.

Eine Person arbeitet ruhig an einem Schreibtisch in einem hellen Lichtkreis, mitten in einem Tunnel aus verhedderten Kabeln, Benachrichtigungen und Dashboards
18 / 110 Zeilen brauchen Sie Probe filtert den Rest.
Zwei Werkzeuge, eine Methode

Dieselbe Review-Methode für Entwickler und für Fachabteilungen.

Beide Werkzeuge gehen von der zuletzt geprüften Version aus, markieren riskante Änderungen mit festen, erklärbaren Regeln und halten fest, was geprüft wurde. Ein KI-Modell kann helfen, einen Befund zu erklären; es entscheidet nie, was markiert wird, und nichts verlässt Ihren Rechner, sofern Sie es nicht wollen.

Probe für Code

KI-geschriebene Pull Requests prüfen

Für Entwickler, Tech Leads und CI-Pipelines.

  • Ordnet einem Git-Diff Risikosignale zu: Authentifizierung, Zahlungen, entfernte Validierung, öffentliche APIs, Abhängigkeiten.
  • Führt Ihre Tests in Wegwerf-Containern aus und versucht, Probleme auf beiden Revisionen zu reproduzieren.
  • Prüft den Plan eines Agenten, bevor der Code existiert, und lässt konforme, risikoarme Änderungen dann mergen.
  • Liest die Anforderung aus Jira, Linear, Notion oder Google Docs und prüft den Code daran.
CLIHub (Docker)GitHub · GitLabClaude Code · MCPGo · TypeScript · Python · Rust
Probe Desktop

Geteilte Office-Dokumente überwachen

Für Finanz-, Rechts-, Vertriebs- und Operations-Teams und alle, die Dateien teilen.

  • Verfolgt die Word-, Excel- und PowerPoint-Dateien Ihrer OneDrive- oder Google-Drive-Ordner.
  • Meldet eine durch eine Zahl ersetzte Formel, eine Summe, die nicht mehr alle Zeilen zählt, einen geänderten Betrag oder eine geänderte Frist, ein „muss“, aus dem ein „kann“ wurde.
  • Führt eine Liste der zu prüfenden Dokumente; nach der Prüfung wird eine Version zur Referenz für die nächsten Änderungen.
WindowsmacOSOneDrive · Google DriveWord · Excel · PowerPoint

Was brauchen Sie?

Probe für CodeProbe Desktop
Sie sindEntwickler, Reviewer oder Platform-TeamController, Jurist, Führungskraft oder Assistenz
Was sich ändertQuellcode, in Git-Commits und Pull RequestsWord-, Excel- und PowerPoint-Dateien in OneDrive oder Google Drive
Die ReferenzDer Basis-Branch des Pull RequestsDie letzte Version, die jemand als geprüft markiert hat
Worauf es achtetSicherheitsrelevanter Code, entfernte Validierung, API- und Abhängigkeitsänderungen, fehlschlagende oder fehlende TestsFest eingetragene Formeln, verkleinerte Bereiche, geänderte Beträge, Daten und Pflichten, ausgeblendete Blätter oder Folien, Makros
NachweiseIn einer Sandbox ausgeführte Prüfungen, reproduzierte Probleme, ein Bericht in JSON und MarkdownVorher und Nachher jeder markierten Änderung und wer zuletzt gespeichert hat
Wie es läuftEin Kommandozeilenwerkzeug in Ihrem Terminal oder Ihrer CI oder der Hub für ein ganzes KontoEine Anwendung in der Taskleiste oder der Menüleiste, die im Hintergrund überwacht
Probe Desktop · Für Dokumente

Geteilte Dateien ändern sich unbemerkt. Erkennen Sie, was zählt.

Ein Budget, das durch fünf Hände geht, ein Vertrag, den die Gegenseite überarbeitet hat, eine Vorstandspräsentation, die am Vorabend aktualisiert wurde. Niemand liest alles noch einmal, und niemand sollte das müssen. Probe Desktop überwacht die Ordner, die Ihr Team bereits nutzt, und zeigt Ihnen die Änderungen, die eine Zahl, eine Verpflichtung oder eine Berechnung verändern – mit Vorher und Nachher.

  • Sieht, was die Änderungsverfolgung nicht zeigt. Eine Formel, die stillschweigend durch ihren Wert ersetzt wurde, eine Summe, die eine Zeile zu früh endet, ein unsichtbar gemachtes Blatt.
  • Funktioniert dort, wo Ihre Dateien schon liegen. Wählen Sie einen auf Ihrem Computer synchronisierten OneDrive- oder Google-Drive-Ordner. Keine Migration, kein Add-in, kein Konto.
  • Bleibt auf Ihrem Computer. Dokumente werden lokal verglichen. Eine KI-Erklärung ist optional und erhält nur die markierten Auszüge und die Passagen, die noch einen ersetzten Namen oder Begriff verwenden.
Probe Desktop · 2 Dokumente zu prüfen
  • X Ein Bereich in der Formel wurde verkleinert: Einige Zellen werden nicht mehr gezählt Budget 2026.xlsx · Budget!B1 · hoch

    =SUM(A1:A3)

    =SUM(A1:A2)

  • X Eine Formel wurde durch ihren Wert ersetzt: Die Zelle aktualisiert sich nicht mehr Budget 2026.xlsx · Budget!D2 · hoch

    =A2*2

    400

  • W Eine Pflicht wurde abgeschwächt Supplier contract.docx · Absatz 2 · hoch

    The supplier shall deliver before 15/03/2026.

    The supplier may deliver before 15/03/2026.

  • W Ein Betrag oder Prozentsatz wurde geändert Supplier contract.docx · Absatz 3 · hoch

    The price is set at €12,000 excluding VAT.

    The price is set at €15,000 excluding VAT.

Probe für Code

KI-Assistenten schreiben große Pull Requests in kurzer Zeit. Probe sagt Ihnen, welche Zeilen Sie zuerst lesen sollten: Es ordnet dem Diff Risikosignale zu, führt Ihre Prüfungen in Wegwerf-Containern aus, versucht Probleme mit differenziellen Tests zu reproduzieren und übergibt Ihnen einen fokussierten Review-Plan mit nachvollziehbaren Belegen. Ein Kommandozeilenwerkzeug für Windows, Linux und macOS und ein Docker-Hub für ein ganzes GitHub- oder GitLab-Konto. In 2 Minuten ausprobieren →

Probe für Code · Der Prozess

Kennen Sie die Auswirkungen, bevor der Code existiert. Prüfen Sie nur, was Sie braucht.

KI-geschriebener Code wird vorhersehbar, wenn der Agent seine Arbeit vorher ankündigt. Probe misst das Risiko des Plans, bevor Code geschrieben wird, und prüft dann, ob die Änderung genau das Angekündigte umgesetzt hat. Eine Änderung, die einem risikoarmen Plan folgt und ihre Prüfungen besteht, kann gemergt werden, ohne dass ein Mensch den Diff liest; alles andere geht mit Begründung ins Review.

  1. Planen und Intent prüfen

    probe plan lässt den Agenten die Änderung schreibgeschützt simulieren. Feste Regeln, nicht das Modell, markieren kritische Pfade, Änderungen an öffentlichen APIs und Abhängigkeiten sowie viel genutzten oder ungetesteten Code. Ein markierter Plan geht an einen Menschen, bevor Code geschrieben wird.

  2. Ein Agent programmiert den Plan

    Der Plan wird zum Vertrag: die Dateien, Symbole und Abhängigkeiten, die der Agent anfassen darf. Er setzt genau das um, und nur das.

  3. Konformität prüfen

    probe review --plan bewertet den Plan neu, führt die Prüfungen in der Sandbox aus und vergleicht den Diff mit dem Vertrag: Jede ungeplante Datei, jede nicht angekündigte API-Änderung, jeder kritische Pfad und jede Abhängigkeit wird gemeldet.

  4. Mergen oder prüfen

    Konforme Änderung, risikoarmer Plan, Prüfungen bestanden, sonst nichts markiert: kein menschliches Review erforderlich, Exit-Code 0, die Pipeline mergt. Andernfalls Exit-Code 2: Ein Mensch prüft den Pull Request, ausgehend von den aufgeführten Gründen.

Exit 0 Merge

  1. Der zum Zeitpunkt des Reviews neu bewertete Plan hat keine Risikokategorie ausgelöst und wurde vollständig gemessen.
  2. Der Diff bleibt innerhalb des Plans: keine ungeplante Datei, API, kein kritischer Pfad und keine Abhängigkeit.
  3. Alle Prüfungen bestanden; kein hohes Signal, kein reproduziertes Problem, kein nicht verifizierter Bereich.

Exit 2 menschliches Review

  1. Der Plan berührt etwas Kritisches, Öffentliches oder viel Genutztes oder konnte nicht gemessen werden.
  2. Die Änderung ist vom Plan abgewichen.
  3. Eine Prüfung ist fehlgeschlagen oder der Bericht hat etwas gefunden, das man sich ansehen sollte. Jeder Grund wird aufgeführt.
# 1. before coding: plan, and let a human validate a flagged plan
probe plan --intent-file task.md --ci
# 2. the agent implements .probe/PLAN.json
# 3-4. in CI: conformance, checks and the gate (exit 0 = merge, 2 = review)
probe review --base origin/main --plan .probe/PLAN.json --ci
Plan conformance: conforming; 0 high, 0 medium, 0 low differences from the plan.
Plan gate: no human review required (low-risk plan, conforming change, checks passed, nothing else requests review).

Das Gate ist eine Prozessentscheidung, kein Korrektheitsbeweis: Ihre vertrauenswürdige Policy entscheidet, was kritisch ist und welche Tests laufen, und jeder Zweifel schickt die Änderung zu einem Menschen. Wie das Gate entscheidet.

Tests, vet, Build und Coverage liefen bei dieser Änderung alle durch. Sie entfernte außerdem die Prüfung, die Erstattungen auf den gezahlten Betrag begrenzte, und erlaubte der Support-Rolle Erstattungen. Probe setzte beides an die Spitze des Reviews, unter 18 markierten von 110 Zeilen.

Probe für Code · Warum es Zeit spart

Schluss damit, KI-generierte Diffs von oben nach unten zu lesen.

Das Aufwendige am Review eines KI-gestützten Pull Requests sind nicht die riskanten Zeilen. Es ist, sie zwischen den Hilfsfunktionen, Tests und Dokumenten drumherum zu finden und dann herauszufinden, ob ein Verdacht begründet ist. Probe übernimmt diese Sortierung und sammelt die Belege, bevor Sie den Diff öffnen.

Ohne Probe jede Zeile, gleiche Aufmerksamkeit

  1. Den Branch auschecken und Tests, vet und Build von Hand ausführen.
  2. 110 geänderte Zeilen in Dateireihenfolge lesen, Hilfsfunktionen zuerst.
  3. Mit Glück bemerken, dass die Erstattungsgrenze aus dem Zahlungscode verschwunden ist.
  4. Einen Wegwerf-Test schreiben, um herauszufinden, ob es darauf ankommt.
  5. Freigeben, ohne festzuhalten, was tatsächlich geprüft wurde.

Mit Probe Risiko zuerst, Belege dabei

  1. Die Prüfungen sind bereits in einem isolierten Container gelaufen, mit Protokollen und Hashes.
  2. Den Bericht öffnen: 18 markierte Zeilen, nach Schwere sortiert, mit Begründung.
  3. Mit dem obersten Risiko des KI-Berichts beginnen: die aus payment/refund.go entfernte Erstattungsgrenze, reproduziert durch einen Test des Reviewers.
  4. Den optionalen Reviewer versuchen lassen, das Problem auf Basis und Kandidat zu reproduzieren.
  5. Die Berichte in Markdown und JSON als Nachweis des Reviews aufbewahren.

Weniger, das zuerst gelesen werden muss

Ein deduplizierter Review-Umfang, gezählt in tatsächlich geänderten Zeilen, sodass große generierte Änderungen auf die Teile schrumpfen, die Authentifizierung, Zahlungen, Validierung, Abhängigkeiten oder öffentliche APIs betreffen.

Kein lokales Setup pro PR

Ihre Test-, Typecheck-, Build- und Coverage-Befehle laufen in Wegwerf-Containern ohne Netzwerk. Nichts vom Kandidaten wird auf Ihrem Rechner ausgeführt.

Wissen, wann Schluss ist

Nicht verifizierte Bereiche und unvollständige Prüfungen werden ausdrücklich aufgeführt, und --ci macht daraus einen Exit-Code. Sie wissen, was abgedeckt wurde und was noch Ihr Urteil braucht.

Probe für Code · Beispielbericht

Was Sie statt des rohen Diffs öffnen

Ein echter Lauf auf dem Beispiel-Repository „shop“. Der Commit erlaubt Support-Mitarbeitern Erstattungen, fügt eine Wiedereinlagerungsgebühr und Katalog-Hilfsfunktionen hinzu und entfernt stillschweigend die Prüfung, dass eine Erstattung nie den gezahlten Betrag übersteigt. Alle Tests bestehen weiterhin. Bauen Sie es mit make-repo.sh nach und führen Sie dieselben Befehle aus.

Auszug aus .probe/PR_SUMMARY.md, geschrieben von probe review HEAD~1..HEAD --ci mit dem Reviewer-Modell von Probe Hub. Der Lauf endet mit Exit-Code 1: ein reproduziertes Problem. Im Hub steht derselbe Bericht über der Alarmliste, und jedes Zitat klappt seinen Diff auf.

.probe/PR_SUMMARY.md
# Let support issue refunds, add a restocking fee and catalog helpers

## Risks1
- high The bound on refunds was deleted rather than adapted,
  so an order can be refunded more than it was paid, from
  both payment.Refund and the public api.RefundOrder.
  — payment/refund.go:23-24 (old) ✓, payment/refund.go:28-29 ✓,
  Refund no longer checks the amount against what the order
  was paid — payment/refund.go:24 (reproduced finding), …
- high The new lines of api.RefundOrder were not executed
  by any instrumented package, so the removed refund bound
  is not covered through the public entry point.
  — api/refund.go:17 ✓, …
  … 1 more high risk, 1 low

## Changes2
- Add restocking fee and return value to refunds: payment.Refund
  now takes a restock flag, subtracts RestockingFee from the
  amount when restocking, and returns the refunded amount; …
  — payment/refund.go:20 ✓, …
  - REPRODUCED / high Refund no longer checks the amount
    against what the order was paid — payment/refund.go:24
  - Payment-sensitive function body changed — payment/refund.go:20
    … 6 more signals
  … 3 more areas; each of the 19 signals sits under one area

## Where to look first3
- high Check that dropping the paid-amount guard is intended
  and that the refund total still cannot exceed what was
  captured, since the sentinel and its test assertion are
  gone. — payment/refund.go:23-24 (old) ✓, payment/refund.go:15 ✓

## Testing4
Probe executed 10 checks for this review: 6 PASS, 3 FAIL, 1 ERROR.
  1. Der Fehler steht zuerst, reproduziert. Die entfernte Erstattungsgrenze führt die Risiken an, obwohl alle Tests bestehen. Der Reviewer schrieb einen Test, der auf der Basis besteht und auf dem Kandidaten scheitert: Probe führte beide aus und hielt das Problem als reproduziert fest.
  2. Jedes Zitat wird geprüft. ✓ bedeutet, dass der vom Modell zitierte Code an diesen Zeilen des Diffs steht: Probe hat ihn ohne Modell gesucht und verwirft ein Zitat, das es nicht findet. Das belegt, worauf die Aussage zeigt, nicht dass sie stimmt.
  3. Befunde nach Absicht gruppiert. Das reproduzierte Problem und die von Probe berechneten Signale stehen unter der Änderung, zu der sie gehören, mit ihrem festgehaltenen Status, ihrer Schwere und Position. Ein Befund, den kein Bereich zitiert, bleibt am Ende aufgeführt.
  4. Was lief, stammt von Probe, nicht vom Modell. Die Check-Zeile zählt, was tatsächlich in der Sandbox ausgeführt wurde, die Tests des Reviewers eingeschlossen, und das Urteil beruht auf Belegen. Das Modell bewertet und beschreibt; es ändert nichts am Ergebnis.

Auszug aus .probe/CONFIDENCE_REPORT.md, erzeugt von probe review HEAD~1..HEAD --reviewer=false --ci auf demselben Commit. Es wurde kein KI-Anbieter verwendet.

.probe/CONFIDENCE_REPORT.md
## Change Summary
93 additions / 17 deletions · 7 files changed
Exit code: 2. No confidence percentage is assigned.

## Automated Checks1
- PASS test      (check-1; exit 0; 7136 ms)
- PASS typecheck (check-2; exit 0; 5006 ms)
- PASS build     (check-3; exit 0; 4177 ms)
- PASS coverage  (check-4; exit 0; 7480 ms)

## Reproduced Issues2
No issue was reproduced by a passing baseline
and failing candidate experiment.

## Suggested Human Review3
- high api/refund.go:17–17 (new): Added lines were not
  executed by any instrumented package in the coverage
  run; Exported Go declaration changed;
  Payment-sensitive function body changed
- high auth/auth.go (whole file): Lines added and
  removed in a sensitive file
- high payment/refund.go:24–26 (new): Payment-sensitive
  function body changed
  … 16 more signals

## Review Surface4
Focused review: 18 / 110 changed lines.

## Changed-line Execution5
Measured from check check-4: of 61 added Go lines,
33 were executed at least once, 3 were not executed,
25 are not inside any instrumented block.
  1. Die Checks sind erledigt, und sie sind nicht die Antwort. Jeder konfigurierte Befehl lief in einem isolierten Container erfolgreich, und trotzdem lässt der Commit eine Erstattung über den gezahlten Betrag zu.
  2. Belege, keine Meinungen. Ein reproduziertes Problem erfordert einen Test, der auf der Basis besteht und auf dem Kandidaten fehlschlägt. Ohne KI-Anbieter wird hier nichts behauptet, und der Bericht sagt das auch.
  3. Ihre Lesereihenfolge. Hohe Signale zuerst: Die Erstattungs-API, die Autorisierungsregel und der Zahlungscode haben sich in sensiblen Dateien geändert. Sie zeigen, wo Sie hinschauen sollten; die entfernte Prüfung zu finden ist dann Ihre Aufgabe oder die des KI-Reviewers.
  4. Der Umfang der Arbeit. 18 von 110 geänderten Zeilen tragen ein Signal. Lesen Sie diese zuerst und entscheiden Sie dann, wie viel Aufmerksamkeit der Rest verdient.
  5. Eine Beobachtung, kein Beweis. Die neue Erstattungs-API lief während der Tests nie: Keine ihrer hinzugefügten Zeilen wurde ausgeführt. Probe meldet die Ausführung, stellt sie aber nie als Beweis dar, dass der Code getestet ist.
Probe für Code

So funktioniert es

  1. Unveränderliche Commits vergleichen

    Beide Refs werden zu Commit-IDs aufgelöst. Umbenennungen, Löschungen, Binärdateien und die Merge-Basis-Semantik werden berücksichtigt; nur committete Dateien werden geprüft, sodass lokale Änderungen nie ins Ergebnis gelangen.

  2. Risikosignale sammeln

    Go-AST-Vergleich, gekennzeichnete lexikalische Heuristiken und Regeln für sensible Pfade markieren Authentifizierung, Zahlungen, Abhängigkeiten, entfernte Validierung, unsichere Konstrukte und fehlende Tests in Go, TypeScript/JavaScript, Python und Rust.

  3. In einer Sandbox ausführen

    Ihre Test-, Typecheck- und Build-Befehle laufen als argv-Arrays in Wegwerf-Containern ohne Root und ohne Netzwerk, mit CPU-, Speicher-, PID- und Zeitlimits.

  4. Reproduzieren statt behaupten

    Ein optionaler Reviewer schreibt temporäre Tests. Ein Test, der auf der Baseline besteht und auf dem Kandidaten fehlschlägt, stützt ein reproduziertes Problem; alles andere bleibt UNVERIFIED.

Vom ersten Versuch bis zu jedem Pull Request

Probieren Sie es an Ihrem letzten Commit aus, ohne Konfiguration, ohne Docker und ohne API-Schlüssel. Wenn Sie es einführen, committen Sie eine Policy in Ihren Basis-Branch: Sie wird aus der Basis gelesen, sodass ein Pull Request seine eigenen Regeln nicht lockern kann.

Zur Anleitung „Erste Schritte“ →

# try it: compare with the previous commit
probe lint HEAD~1..HEAD

# adopt it: once, in your repository
probe init
git add .probe.json && git commit -m "Add review policy"

# on every pull request
probe review --base main --ci
Probe für Code · Docker

Oder für ein ganzes Konto betreiben: Probe Hub

Der Hub ist das begleitende Docker-Image. Starten Sie einen Container, melden Sie sich mit GitHub oder GitLab an, und jedes Repository, dem noch eine .probe.json fehlt, erhält mit einem Klick einen Policy-Vorschlag, den Sie vor dem Commit in den Standard-Branch in einer Vorschau sehen.

Repositories mit einer Richtlinie lassen sich überwachen: Jeder neue Commit wird analysiert, und sein Bericht öffnet sich von selbst. Mit einem konfigurierten Reviewer-Modell schreibt die KI den Bericht und Probe prüft ihn: Risiken und erste Prüfstellen nach Schwere bewertet, jedes Zitat gegen den Diff verifiziert und die Alarme unter der Änderung gruppiert, zu der sie gehören. Ein Schwere-Regler filtert den ganzen Bericht von low bis critical, und ein Klick auf einen Alarm oder ein Zitat klappt die betroffenen Änderungen auf, mit den Zeilen im Diff hervorgehoben.

Das Team prägt den Reviewer: Jedes Repository hat seine eigenen Coding-Regeln, und Abstimmungen, Kommentare und Antworten zu Befunden zeigen ihm, was das Team nützlich findet. Coding-Agenten wie Claude Code oder Cursor verbinden sich mit dem MCP-Server des Hubs, um Reviews auszulösen, Befunde zu lesen und Feedback zu geben.

Der Hub kann sein LLM auch dem Kommandozeilenwerkzeug bereitstellen: probe login verbindet einen Arbeitsplatz im Browser mit Ihrem Konto, und probe review untersucht danach mit dem Modell des Hubs, im Rahmen eines Tageskontingents, ohne eigenen Anbieterschlüssel.

Ein Docker-Container, kein externer Dienst erforderlich, der Zustand liegt auf einem Volume oder in PostgreSQL – so kann ein Unternehmen ihn intern für die eigene GitHub-Enterprise- oder GitLab-Instanz bereitstellen. Im Standardmodus führt er den analysierten Code nie aus.

Gehostet unter app.probe.technology – dasselbe Image, das Sie in Ihrem eigenen Netzwerk betreiben können.

# one container, on your own network
$ docker run -p 8080:8080 \
    -e PROBE_HUB_BASE_URL=https://hub.example.com \
    -e PROBE_HUB_GITHUB_CLIENT_ID=... \
    -e PROBE_HUB_GITHUB_CLIENT_SECRET=... \
    -v hub-data:/var/lib/probe-hub \
    gvinsot/probe-hub

Sign in · bootstrap the missing policies · watch pushes
Reports open by themselves, filtered by severity.
Probe für Code

Funktionen

Fokussierter Review-Umfang

Deduplizierte Review-Bereiche mit alten und neuen Koordinaten, gezählt in tatsächlich geänderten Zeilen, nach Schweregrad sortiert.

Differenzielle Nachweise

Generierte Tests laufen auf Baseline und Kandidat in frischen Umgebungen. Die Go-Ausführung wird anhand strukturierter Testereignisse verifiziert.

Ausführung geänderter Zeilen

Optional messen, welche hinzugefügten Go-Zeilen ein aufgezeichneter Lauf ausgeführt hat – als Beobachtung gemeldet, nie als Testnachweis.

Auswirkungsanalyse

Ein statischer Index für Go, TypeScript/JavaScript, Python und Rust listet die unveränderten Aufrufer jeder geänderten Funktion und die vorhandenen Tests, die sie erreichen.

Tests auf beiden Revisionen

Betroffene und geänderte Baseline-Tests, differenzielles Fuzzing und Mutation hinzugefügter Zeilen laufen auf Basis und Kandidat und werden als Nachweis aufgezeichnet, nie als Urteil.

Erst planen, dann den Umfang prüfen

probe plan bewertet den Plan eines Agenten, bevor Code existiert; --plan markiert dann jede Datei und jede exportierte API, die die Änderung ohne Ankündigung berührt hat.

Begrenzter KI-Reviewer

Verwenden Sie einen beliebigen OpenAI-kompatiblen Anbieter oder mit probe login den Ihres Probe Hubs. Die Werkzeuge sind begrenzt: geschwärztes Lesen von Dateien, Suche und Testläufe. Keine Shell, kein URL-Abruf. Er entwirft auch die Pull-Request-Beschreibung, nie das Urteil.

Reviewer-Schwarm

Spezialisierte Agenten für Korrektheit, Sicherheit, Tests, Kompatibilität, Zuverlässigkeit und Intent untersuchen parallel. Ihre Befunde werden zusammengeführt und anhand von Nachweisen geprüft: Übereinstimmung ist kein Beweis.

Über den Diff hinaus

Ein Repository-Graph, die verwandten Repositorys eines Clusters und eine bearbeitbare Wissensbasis lassen den Reviewer erkennen, wer von einer Änderung abhängt und welchen Vertrag sie brechen könnte.

Anforderungen als Intent

Verweisen Sie Probe auf ein Jira- oder Linear-Issue, Notion-Seiten oder Google Docs: Deren Akzeptanzkriterien werden zum Maßstab, an dem die Änderung geprüft wird, zusammen mit den Coding-Regeln Ihres Teams.

Bereit für CI

Ein wiederverwendbarer GitHub-Actions-Workflow, aussagekräftige Exit-Codes, JSON-Berichte mit Commit-IDs, Nachweisen und Artefakt-Hashes sowie SARIF und ein PR-Kommentar, der nur durch Nachweise gestützte Befunde enthält.

Agentenfreundlich

Coding-Agenten führen lint und review aus, bevor sie Arbeit übergeben. Ein Claude-Code-Plugin und der MCP-Server des Hubs ermöglichen es ihnen, Reviews anzufordern, Befunde zu lesen und zu beheben.

Was Probe nicht behauptet

Ein Review-Werkzeug gewinnt Vertrauen, indem es seine Grenzen genau benennt. Probe vergibt keine Konfidenzprozente und gibt nie eine Änderung auf das Wort eines Modells hin frei. Bei Code entfällt das menschliche Review nur über das Plan-Gate, wenn ein risikoarmer Plan eingehalten wurde und jede automatisierte Prüfung sauber war. Bei Dokumenten entscheidet immer ein Mensch.

  • Signale sind Gründe für eine Untersuchung, keine bestätigten Bugs.
  • Bestandene Tests und ein kleiner Review-Umfang garantieren keine Korrektheit.
  • Eine ausgeführte Zeile ist eine Beobachtung, kein Beweis, dass sie getestet ist.
  • Die Aussage eines Modells ist nie ein Nachweis; nur ein reproduzierter Unterschied ist es.
  • Das Plan-Gate besagt, dass der angekündigte, risikoarme Umfang eingehalten wurde, nicht, dass der Code korrekt ist.
  • Fehlt Docker, weicht die Ausführung nie auf Ihren Host aus.
  • Ein als geprüft markiertes Dokument ist eine menschliche Entscheidung, keine Garantie, dass seine Zahlen stimmen.
  • Auch ein Dokument ohne Befund hat sich geändert: Die vollständige Liste der Änderungen ist nur einen Klick entfernt.

Investieren Sie Ihre Review-Zeit dort, wo es zählt.

Open Source, lizenziert unter AGPL-3.0. Ein Kommandozeilenwerkzeug für Code, eine Anwendung für Dokumente, beide mit jeder Version veröffentlicht.