Un cancello per le merge request su GitLab. Un agente di intelligenza artificiale propone una modifica al codice; un verificatore deterministico la misura e dà un verdetto con le prove. Nessuna modifica entra solo perché la pipeline era verde.
Il problema
Scrivere codice con l'intelligenza artificiale è diventato facile. Fidarsi del risultato no. Un agente apre una merge request che dice "ho sistemato il test instabile" o "ho aggiornato la libreria", la pipeline diventa verde, e qualcuno deve decidere se quel verde significa qualcosa.
Un esempio con i numeri. Un test che fallisce il 15% delle volte passa tre volte di fila nel 61% dei casi. Tre verdi di fila non dimostrano niente. Una nota di rilascio dice cosa è cambiato per tutti, non quale riga del tuo codice si romperà.
Cosa fa
Verdict Gate esegue un verificatore come lavoro della pipeline su ogni merge request, confronta la modifica con il ramo di partenza e scrive una sola riga nel registro del lavoro: la parola VERDICT seguita dal verdetto in formato leggibile da macchina.
Quattro esiti, sempre gli stessi: PASSA, NON PASSA, INCERTO, ROTTO. Insieme all'esito arrivano le prove: un file e una riga, un conteggio di fallimenti, una probabilità, un limite superiore. Cose che una persona può ricontrollare in un minuto. Quando il cancello è chiuso, la pipeline è rossa.
I cinque verificatori
Test instabili. Rilancia il test cento volte prima e cento volte dopo la modifica, alternando i due lati così che il rumore della macchina colpisca entrambi allo stesso modo. Applica un test statistico esatto e un limite superiore al 95% sul tasso di fallimento residuo. Risponde: RISOLTO, NON RISOLTO, SERVONO PIÙ ESECUZIONI (e dice quante), NON RIPRODOTTO, ROTTO. Una guardia sul diff scopre i trucchi: asserzioni tolte o allentate, test saltati, tentativi ripetuti, tempi massimi alzati. Un RISOLTO con la guardia scattata diventa "risolto ma test indebolito" e richiede una persona. Una modalità di bisezione trova il commit che ha introdotto l'instabilità con la stessa statistica.
Aggiornamenti di dipendenze. Confronta due versioni pubblicate di una libreria e le incrocia con le righe esatte del tuo codice che le usano: funzioni rimosse, pacchetti passati a soli moduli ES mentre tu li importi ancora alla vecchia maniera, importazioni profonde che non si risolvono più, requisiti di versione di Node. Il verdetto indica file e riga da correggere.
Traduzioni. Controlla un catalogo tradotto contro l'originale: chiavi mancanti, frasi lasciate nella lingua di partenza, tag e segnaposto non conservati, interruzioni di riga, normalizzazione Unicode, testi troppo lunghi per lo spazio.
Prestazioni. Esegue un comando di misura su entrambi i lati, applica un test non parametrico e un intervallo di confidenza sulla mediana, e si rifiuta di chiamare "regressione" il semplice rumore.
Contratti API. Confronta un contratto OpenAPI prima e dopo e classifica ogni cambiamento: rompe chi lo usa, aggiunge soltanto, oppure è cosmetico.
Dove entra l'intelligenza artificiale
L'IA non decide mai. Scrive il rapporto. Un agente personalizzato e un flusso automatico della piattaforma agenti di GitLab Duo leggono il registro del lavoro, estraggono la riga del verdetto e pubblicano una nota sulla merge request con le prove copiate alla lettera, dicendo se serve una persona. Il flusso è formato da due agenti in un file YAML nel repository: uno può solo leggere (merge request, lavori falliti, registro), l'altro può solo scrivere la nota. Parte da solo a fine pipeline o quando viene menzionato il suo account di servizio.
Un server MCP espone gli stessi cinque verificatori come strumenti a qualsiasi agente, compresa la chat agentica di GitLab Duo.
Cosa ha girato davvero (25 ottobre 2026)
Tutto è visibile nel repository pubblico, nelle merge request e nella storia delle pipeline.
Quattro merge request dimostrative con i verdetti attesi: una finta correzione con un'attesa aggiunta (NON PASSA, p = 0,92), la correzione vera (PASSA, 17 fallimenti prima, 0 dopo), un test indebolito (PASSA ma test indebolito, serve una persona), un aggiornamento di libreria da 4 a 5 (ROMPE, con le due righe da correggere).
L'agente personalizzato eseguito dalla chat sulla terza merge request, con approvazione esplicita, ha pubblicato la nota.
Il flusso automatico è partito due volte sulla seconda merge request, una volta dall'evento di pipeline e una volta da una menzione, e ha pubblicato la nota da solo con il suo account di servizio.
Non ancora fatto: la proposta automatica del commit di correzione; i verificatori traduzioni, prestazioni e API girano in pipeline ma non sono ancora collegati al flusso.
A chi serve
A chi lascia lavorare agenti di IA sul codice e vuole le prove prima di accettare le loro modifiche.
Ai team con test instabili che tornano rossi settimane dopo la "correzione".
A chi rimanda gli aggiornamenti di librerie per mesi perché non sa cosa si romperà.
A chi spedisce traduzioni con tag e segnaposto persi senza accorgersene.
A chi vuole una regola sola per tutto il ciclo dopo il codice: l'agente propone, un verificatore deterministico decide, una persona approva con le prove davanti.
Come si usa
Si include il componente CI/CD nel file di pipeline del progetto. Il verificatore si sceglie con un'etichetta sulla merge request o dal nome del ramo. Ogni verificatore è anche uno strumento a riga di comando senza configurazione, senza chiave API e senza account: Python con la sola libreria standard, Node con il compilatore TypeScript come unica dipendenza reale per gli aggiornamenti. Lo schema JSON del verdetto è nel repository, con un test di conformità che gira sull'uscita di ogni verificatore.
Codice sorgente con licenza MIT su GitLab. Video dimostrativo di tre minuti.
Verdict Gate partecipa al concorso GitLab "Life After Code" (ottobre 2026).
Provalo nel browser
Qui sotto c'è la console interattiva: tre dei cinque verificatori (test instabili, aggiornamenti di dipendenze, traduzioni) si provano a mano, senza chiave e senza account, e restituiscono la stessa riga VERDICT che legge la pipeline.
A merge-request gate for GitLab. An AI agent proposes a code change; a deterministic verifier measures it and returns a verdict with evidence. No change gets in just because the pipeline was green.
The problem
Writing code with AI has become easy. Trusting the result has not. An agent opens a merge request that says "fixed the flaky test" or "upgraded the library", the pipeline turns green, and someone has to decide whether that green means anything.
An example with numbers. A test that fails 15% of the time passes three times in a row in 61% of cases. Three greens in a row prove nothing. A release note tells you what changed for everyone, not which line of your code will break.
What it does
Verdict Gate runs a verifier as a pipeline job on every merge request, compares the change with the base branch and prints a single line to the job log: the word VERDICT followed by the machine-readable verdict.
Four outcomes, always the same: PASS, FAIL, UNSURE, BROKEN. With the outcome comes the evidence: a file and a line, a failure count, a probability, an upper bound. Things a person can re-check in a minute. When the gate is closed, the pipeline is red.
The five verifiers
Flaky tests. Reruns the test one hundred times before and one hundred times after the change, alternating sides so machine noise hits both equally. Applies an exact statistical test and a 95% upper bound on the residual failure rate. Answers: FIXED, NOT FIXED, NEED MORE RUNS (and says how many), NOT REPRODUCED, BROKEN. A diff guard catches the tricks: removed or loosened assertions, skipped tests, added retries, raised timeouts. A FIXED with the guard fired becomes "fixed but test weakened" and requires a human. A bisect mode finds the commit that introduced the flakiness with the same statistics.
Dependency upgrades. Compares two published versions of a library and crosses them with the exact lines of your code that use them: removed members, packages that went ESM-only while you still import them the old way, deep imports that no longer resolve, Node version requirements. The verdict names the file and line to fix.
Translations. Checks a translated catalog against its source: missing keys, strings left in the source language, tags and placeholders not preserved, line breaks, Unicode normalization, texts too long for their space.
Performance. Runs a benchmark command on both sides, applies a non-parametric test and a confidence interval on the median, and refuses to call plain noise a regression.
API contracts. Compares an OpenAPI contract before and after and classifies every change: breaks consumers, only adds, or cosmetic.
Where the AI comes in
The AI never decides. It writes the report. A custom agent and an automatic flow on the GitLab Duo Agent Platform read the job log, extract the verdict line and post one note on the merge request with the evidence copied verbatim, saying whether a human is needed. The flow is two agents in a YAML file in the repository: one can only read (merge request, failed jobs, log), the other can only write the note. It starts on its own at the end of the pipeline or when its service account is mentioned.
An MCP server exposes the same five verifiers as tools to any agent, including GitLab Duo Agentic Chat.
What actually ran (25 October 2026)
Everything is visible in the public repository, in the merge requests and in the pipeline history.
Four demo merge requests with the expected verdicts: a placebo fix with an added sleep (FAIL, p = 0.92), the real fix (PASS, 17 failures before, 0 after), a weakened test (PASS but test weakened, needs a human), a library upgrade from 4 to 5 (BREAKS, with the two lines to fix).
The custom agent, run from chat on the third merge request with explicit approval, posted the note.
The automatic flow started twice on the second merge request, once from the pipeline event and once from a mention, and posted the note by itself as its service account.
Not done yet: the automatic fix-proposal commit; the translation, performance and API verifiers run in the pipeline but are not wired to the flow yet.
Who it is for
Anyone who lets AI agents work on their code and wants evidence before accepting their changes.
Teams with flaky tests that come back red weeks after the "fix".
Anyone who postpones library upgrades for months because they do not know what will break.
Anyone who ships translations with lost tags and placeholders without noticing.
Anyone who wants one rule for the whole lifecycle after code: the agent proposes, a deterministic verifier decides, a human approves with the evidence in front of them.
How to use it
Include the CI/CD component in the project's pipeline file. The verifier is chosen with a label on the merge request or from the branch name. Every verifier is also a zero-config command-line tool with no API key and no account: Python with the standard library only, Node with the TypeScript compiler as its only real dependency for upgrades. The JSON schema of the verdict is in the repository, with a conformance test that runs on every verifier's output.
Source code under the MIT license on GitLab. Three-minute demo video.
Verdict Gate is an entry in the GitLab "Life After Code" hackathon (October 2026).
Try it in the browser
Below is the interactive console: three of the five verifiers (flaky tests, dependency upgrades, translations) can be run by hand, with no key and no account, and return the same VERDICT line the pipeline reads.
Una puerta de control para merge requests de GitLab. Un agente de IA propone un cambio de código; un verificador determinista lo mide y devuelve un veredicto con evidencias. Ningún cambio entra solo porque la pipeline estuviera en verde.
El problema
Escribir código con IA se ha vuelto fácil. Confiar en el resultado, no tanto. Un agente abre una merge request que dice «arreglé el test inestable» o «actualicé la librería», la pipeline se pone en verde, y alguien tiene que decidir si ese verde significa algo.
Un ejemplo con números. Un test que falla el 15 % de las veces pasa tres veces seguidas en el 61 % de los casos. Tres verdes seguidos no demuestran nada. Una nota de versión te dice qué cambió para todos, no qué línea de tu código va a romperse.
Qué hace
Verdict Gate ejecuta un verificador como trabajo de la pipeline en cada merge request, compara el cambio con la rama base e imprime una única línea en el log del trabajo: la palabra VERDICT seguida del veredicto en formato legible por máquina.
Cuatro resultados, siempre los mismos: PASS (aprobado), FAIL (fallo), UNSURE (no concluyente), BROKEN (roto). Con el resultado llega la evidencia: un archivo y una línea, un recuento de fallos, una probabilidad, un límite superior. Cosas que una persona puede volver a comprobar en un minuto. Cuando la puerta está cerrada, la pipeline está en rojo.
Los cinco verificadores
Tests inestables. Vuelve a ejecutar el test cien veces antes del cambio y cien veces después, alternando los lados para que el ruido de la máquina afecte a ambos por igual. Aplica una prueba estadística exacta y un límite superior del 95 % sobre la tasa residual de fallos. Responde: FIXED (arreglado), NOT FIXED (no arreglado), NEED MORE RUNS (se necesitan más ejecuciones, e indica cuántas), NOT REPRODUCED (no reproducido), BROKEN (roto). Un guardián de diferencias detecta los trucos: aserciones eliminadas o relajadas, tests omitidos, reintentos añadidos, tiempos de espera aumentados. Un FIXED con el guardián activado se convierte en «arreglado, pero test debilitado» y requiere una persona. Un modo bisect encuentra, con la misma estadística, el commit que introdujo la inestabilidad.
Actualizaciones de dependencias. Compara dos versiones publicadas de una librería y las cruza con las líneas exactas de tu código que las usan: miembros eliminados, paquetes que pasaron a ser solo ESM mientras tú todavía los importas de la forma antigua, importaciones profundas que ya no se resuelven, requisitos de versión de Node. El veredicto indica el archivo y la línea que hay que corregir.
Traducciones. Compara un catálogo traducido con su original: claves que faltan, cadenas que siguen en el idioma de origen, etiquetas y marcadores de posición no conservados, saltos de línea, normalización Unicode, textos demasiado largos para su espacio.
Rendimiento. Ejecuta un comando de benchmark en ambos lados, aplica una prueba no paramétrica y un intervalo de confianza sobre la mediana, y se niega a llamar regresión a un simple ruido.
Contratos de API. Compara un contrato OpenAPI antes y después y clasifica cada cambio: rompe a los consumidores, solo añade o es cosmético.
Dónde entra la IA
La IA nunca decide. Redacta el informe. Un agente personalizado y un flujo automático en GitLab Duo Agent Platform leen el log del trabajo, extraen la línea del veredicto y publican una nota en la merge request con la evidencia copiada textualmente, indicando si hace falta una persona. El flujo son dos agentes definidos en un archivo YAML del repositorio: uno solo puede leer (merge request, trabajos fallidos, log) y el otro solo puede escribir la nota. Se inicia solo al final de la pipeline o cuando se menciona su cuenta de servicio.
Un servidor MCP expone los mismos cinco verificadores como herramientas a cualquier agente, incluido GitLab Duo Agentic Chat.
Lo que realmente se ejecutó (25 de octubre de 2026)
Todo es visible en el repositorio público, en las merge requests y en el historial de pipelines.
Cuatro merge requests de demostración con los veredictos esperados: un arreglo placebo con un sleep añadido (FAIL, p = 0,92), el arreglo real (PASS, 17 fallos antes, 0 después), un test debilitado (PASS pero test debilitado, necesita una persona), y una actualización de librería de la 4 a la 5 (BREAKS, con las dos líneas que hay que corregir).
El agente personalizado, ejecutado desde el chat en la tercera merge request con aprobación explícita, publicó la nota.
El flujo automático se inició dos veces en la segunda merge request, una vez por el evento de la pipeline y otra por una mención, y publicó la nota por sí solo con su cuenta de servicio.
Pendiente: el commit automático con la propuesta de corrección. Los verificadores de traducciones, rendimiento y API se ejecutan en la pipeline, pero todavía no están conectados al flujo.
Para quién es
Para quien deja que los agentes de IA trabajen en su código y quiere pruebas antes de aceptar sus cambios.
Para equipos con tests inestables que vuelven a fallar semanas después del «arreglo».
Para quien aplaza durante meses las actualizaciones de librerías porque no sabe qué se va a romper.
Para quien publica traducciones con etiquetas y marcadores de posición perdidos sin darse cuenta.
Para quien quiere una sola regla para todo el ciclo de vida después del código: el agente propone, un verificador determinista decide y una persona aprueba con la evidencia delante.
Cómo se usa
Incluye el componente CI/CD en el archivo de pipeline del proyecto. El verificador se elige con una etiqueta en la merge request o a partir del nombre de la rama. Cada verificador es también una herramienta de línea de comandos sin configuración, sin clave de API y sin cuenta: Python solo con la biblioteca estándar, y Node con el compilador de TypeScript como única dependencia real para las actualizaciones. El esquema JSON del veredicto está en el repositorio, con una prueba de conformidad que se ejecuta sobre la salida de cada verificador.
Código fuente bajo licencia MIT en GitLab. Vídeo de demostración de tres minutos.
Verdict Gate es una entrada en el hackatón «Life After Code» de GitLab (octubre de 2026).
Pruébalo en el navegador
A continuación está la consola interactiva: tres de los cinco verificadores (tests inestables, actualizaciones de dependencias, traducciones) se pueden ejecutar a mano, sin clave y sin cuenta, y devuelven la misma línea VERDICT que lee la pipeline.
Une porte de contrôle pour les merge requests GitLab. Un agent d'IA propose une modification de code ; un vérificateur déterministe la mesure et renvoie un verdict accompagné de preuves. Aucun changement n'entre simplement parce que le pipeline était vert.
Le problème
Écrire du code avec l'IA est devenu facile. Faire confiance au résultat, beaucoup moins. Un agent ouvre une merge request qui dit « correction du test instable » ou « mise à jour de la bibliothèque », le pipeline passe au vert, et quelqu'un doit décider si ce vert signifie quelque chose.
Un exemple chiffré. Un test qui échoue dans 15 % des cas réussit trois fois de suite dans 61 % des cas. Trois verts d'affilée ne prouvent rien. Une note de version vous dit ce qui a changé pour tout le monde, pas quelle ligne de votre code va casser.
Ce qu'il fait
Verdict Gate exécute un vérificateur comme tâche de pipeline sur chaque merge request, compare la modification à la branche de base et affiche une seule ligne dans le journal de la tâche : le mot VERDICT suivi du verdict lisible par la machine.
Quatre issues, toujours les mêmes : PASS (réussi), FAIL (échec), UNSURE (incertain), BROKEN (cassé). Avec l'issue vient la preuve : un fichier et une ligne, un nombre d'échecs, une probabilité, une borne supérieure. Des éléments qu'une personne peut revérifier en une minute. Quand la porte est fermée, le pipeline est rouge.
Les cinq vérificateurs
Tests instables. Relance le test cent fois avant la modification et cent fois après, en alternant les deux côtés pour que le bruit de la machine touche les deux de la même façon. Applique un test statistique exact et une borne supérieure à 95 % sur le taux d'échec résiduel. Répond : FIXED (corrigé), NOT FIXED (non corrigé), NEED MORE RUNS (davantage d'exécutions nécessaires, avec leur nombre), NOT REPRODUCED (non reproduit), BROKEN (cassé). Un garde-fou sur les différences détecte les astuces : assertions supprimées ou assouplies, tests ignorés, relances ajoutées, délais augmentés. Un FIXED avec le garde-fou déclenché devient « corrigé mais test affaibli » et exige une intervention humaine. Un mode bisect trouve, avec les mêmes statistiques, le commit qui a introduit l'instabilité.
Mises à niveau de dépendances. Compare deux versions publiées d'une bibliothèque et les croise avec les lignes exactes de votre code qui les utilisent : membres supprimés, paquets passés en ESM uniquement alors que vous les importez encore à l'ancienne, imports profonds qui ne se résolvent plus, exigences de version de Node. Le verdict indique le fichier et la ligne à corriger.
Traductions. Vérifie un catalogue traduit par rapport à sa source : clés manquantes, chaînes laissées dans la langue source, balises et marqueurs de substitution non conservés, sauts de ligne, normalisation Unicode, textes trop longs pour leur espace.
Performance. Exécute une commande de benchmark des deux côtés, applique un test non paramétrique et un intervalle de confiance sur la médiane, et refuse de qualifier de régression un simple bruit.
Contrats d'API. Compare un contrat OpenAPI avant et après et classe chaque changement : il casse les consommateurs, il ajoute seulement, ou il est cosmétique.
Où intervient l'IA
L'IA ne décide jamais. Elle rédige le rapport. Un agent personnalisé et un flux automatique sur GitLab Duo Agent Platform lisent le journal de la tâche, extraient la ligne du verdict et publient une seule note sur la merge request, avec les preuves copiées mot pour mot, en indiquant si une personne est nécessaire. Le flux compte deux agents définis dans un fichier YAML du dépôt : l'un ne peut que lire (merge request, tâches échouées, journal), l'autre ne peut qu'écrire la note. Il démarre tout seul à la fin du pipeline ou lorsque son compte de service est mentionné.
Un serveur MCP expose les cinq mêmes vérificateurs comme outils à tout agent, y compris GitLab Duo Agentic Chat.
Ce qui a réellement été exécuté (25 octobre 2026)
Tout est visible dans le dépôt public, dans les merge requests et dans l'historique des pipelines.
Quatre merge requests de démonstration avec les verdicts attendus : un correctif placebo avec un sleep ajouté (FAIL, p = 0,92), le vrai correctif (PASS, 17 échecs avant, 0 après), un test affaibli (PASS mais test affaibli, une intervention humaine est nécessaire), une mise à niveau de bibliothèque de la 4 à la 5 (BREAKS, avec les deux lignes à corriger).
L'agent personnalisé, lancé depuis le chat sur la troisième merge request avec une approbation explicite, a publié la note.
Le flux automatique a démarré deux fois sur la deuxième merge request, une fois sur l'événement du pipeline et une fois sur une mention, et a publié la note seul avec son compte de service.
Pas encore fait : le commit automatique de proposition de correctif. Les vérificateurs de traductions, de performance et d'API s'exécutent dans le pipeline, mais ne sont pas encore reliés au flux.
Pour qui c'est
Pour quiconque laisse des agents d'IA travailler sur son code et veut des preuves avant d'accepter leurs modifications.
Pour les équipes dont les tests instables redeviennent rouges des semaines après le « correctif ».
Pour quiconque repousse des mois les mises à niveau de bibliothèques faute de savoir ce qui va casser.
Pour quiconque publie des traductions avec des balises et des marqueurs perdus sans s'en apercevoir.
Pour quiconque veut une seule règle pour tout le cycle de vie après le code : l'agent propose, un vérificateur déterministe tranche, et une personne approuve en ayant les preuves sous les yeux.
Comment l'utiliser
Incluez le composant CI/CD dans le fichier de pipeline du projet. Le vérificateur se choisit avec un libellé sur la merge request ou à partir du nom de la branche. Chaque vérificateur est aussi un outil en ligne de commande sans configuration, sans clé d'API et sans compte : Python avec la seule bibliothèque standard, et Node avec le compilateur TypeScript comme seule vraie dépendance pour les mises à niveau. Le schéma JSON du verdict se trouve dans le dépôt, accompagné d'un test de conformité exécuté sur la sortie de chaque vérificateur.
Code source sous licence MIT sur GitLab. Vidéo de démonstration de trois minutes.
Verdict Gate est un projet inscrit au hackathon GitLab « Life After Code » (octobre 2026).
Essayez-le dans le navigateur
Voici la console interactive : trois des cinq vérificateurs (tests instables, mises à niveau de dépendances, traductions) peuvent être lancés à la main, sans clé et sans compte, et renvoient la même ligne VERDICT que lit la pipeline.
Ein Merge-Request-Gate für GitLab. Ein KI-Agent schlägt eine Codeänderung vor; ein deterministischer Verifier misst sie und liefert ein Urteil mit Belegen. Keine Änderung wird übernommen, nur weil die Pipeline grün war.
Das Problem
Code mit KI zu schreiben ist einfach geworden. Dem Ergebnis zu vertrauen dagegen nicht. Ein Agent öffnet einen Merge Request mit dem Satz „flaky Test behoben“ oder „Bibliothek aktualisiert“, die Pipeline wird grün, und jemand muss entscheiden, ob dieses Grün etwas bedeutet.
Ein Beispiel mit Zahlen: Ein Test, der in 15 % der Fälle fehlschlägt, besteht dreimal hintereinander in 61 % der Fälle. Drei grüne Durchläufe hintereinander beweisen nichts. Eine Release Note sagt dir, was sich für alle geändert hat, aber nicht, welche Zeile deines Codes kaputtgeht.
Was es tut
Verdict Gate führt bei jedem Merge Request einen Verifier als Pipeline-Job aus, vergleicht die Änderung mit dem Basis-Branch und schreibt eine einzige Zeile ins Job-Log: das Wort VERDICT, gefolgt vom maschinenlesbaren Urteil.
Vier Ergebnisse, immer dieselben: PASS, FAIL, UNSURE, BROKEN (bestanden, nicht bestanden, unsicher, defekt). Zum Ergebnis kommen die Belege: eine Datei und eine Zeile, eine Fehleranzahl, eine Wahrscheinlichkeit, eine obere Schranke. Dinge, die eine Person in einer Minute nachprüfen kann. Ist das Gate geschlossen, ist die Pipeline rot.
Die fünf Verifier
Flaky Tests. Führt den Test hundertmal vor und hundertmal nach der Änderung aus, wobei die beiden Seiten abwechselnd getestet werden, damit das Rauschen der Maschine beide gleich stark trifft. Wendet einen exakten statistischen Test und eine 95-%-Obergrenze für die verbleibende Fehlerrate an. Antwortet mit: FIXED, NOT FIXED, NEED MORE RUNS (und nennt, wie viele Durchläufe nötig sind), NOT REPRODUCED, BROKEN. Ein Diff-Wächter erkennt die Tricks: entfernte oder abgeschwächte Assertions, übersprungene Tests, hinzugefügte Wiederholungen, erhöhte Timeouts. Ein FIXED, bei dem der Wächter angeschlagen hat, wird zu „fixed but test weakened“ und erfordert einen Menschen. Ein Bisect-Modus findet mit denselben Statistiken den Commit, der die Flakiness eingeführt hat.
Abhängigkeits-Upgrades. Vergleicht zwei veröffentlichte Versionen einer Bibliothek und gleicht sie mit den genauen Zeilen deines Codes ab, die sie verwenden: entfernte Elemente, Pakete, die auf reines ESM umgestellt wurden, während du sie noch auf die alte Art importierst, Deep Imports, die nicht mehr aufgelöst werden, Anforderungen an die Node-Version. Das Urteil nennt die Datei und die Zeile, die korrigiert werden müssen.
Übersetzungen. Prüft einen übersetzten Katalog gegen seine Quelle: fehlende Schlüssel, Zeichenketten, die in der Ausgangssprache stehen geblieben sind, nicht erhaltene Tags und Platzhalter, Zeilenumbrüche, Unicode-Normalisierung, Texte, die für ihren Platz zu lang sind.
Leistung. Führt einen Benchmark-Befehl auf beiden Seiten aus, wendet einen nichtparametrischen Test und ein Konfidenzintervall für den Median an und weigert sich, bloßes Rauschen als Regression zu bewerten.
API-Verträge. Vergleicht einen OpenAPI-Vertrag vor und nach der Änderung und ordnet jede Änderung ein: bricht Konsumenten, fügt nur hinzu oder ist rein kosmetisch.
Wo die KI ins Spiel kommt
Die KI entscheidet nie. Sie schreibt den Bericht. Ein benutzerdefinierter Agent und ein automatischer Ablauf auf der GitLab Duo Agent Platform lesen das Job-Log, extrahieren die Urteilszeile und veröffentlichen eine einzige Notiz im Merge Request, mit den wörtlich übernommenen Belegen und dem Hinweis, ob ein Mensch nötig ist. Der Ablauf besteht aus zwei Agenten in einer YAML-Datei im Repository: Einer kann nur lesen (Merge Request, fehlgeschlagene Jobs, Log), der andere kann nur die Notiz schreiben. Er startet von selbst am Ende der Pipeline oder wenn sein Service-Account erwähnt wird.
Ein MCP-Server stellt dieselben fünf Verifier als Tools für jeden Agenten bereit, auch für GitLab Duo Agentic Chat.
Was tatsächlich lief (25. Oktober 2026)
Alles ist im öffentlichen Repository sichtbar, in den Merge Requests und im Pipeline-Verlauf.
Vier Demo-Merge-Requests mit den erwarteten Urteilen: eine Placebo-Korrektur mit eingefügtem sleep (FAIL, p = 0,92), die echte Korrektur (PASS, vorher 17 Fehler, nachher 0), ein abgeschwächter Test (PASS but test weakened, braucht einen Menschen), ein Bibliotheks-Upgrade von 4 auf 5 (BREAKS, mit den zwei Zeilen, die zu korrigieren sind).
Der benutzerdefinierte Agent, im Chat am dritten Merge Request mit ausdrücklicher Freigabe gestartet, hat die Notiz veröffentlicht.
Der automatische Ablauf startete zweimal am zweiten Merge Request, einmal durch das Pipeline-Ereignis und einmal durch eine Erwähnung, und veröffentlichte die Notiz selbstständig unter seinem Service-Account.
Noch nicht fertig: der automatische Commit mit dem Korrekturvorschlag. Die Verifier für Übersetzungen, Leistung und API laufen in der Pipeline, sind aber noch nicht mit dem Ablauf verbunden.
Für wen es gedacht ist
Für alle, die KI-Agenten an ihrem Code arbeiten lassen und vor der Übernahme ihrer Änderungen Belege wollen.
Für Teams mit Flaky Tests, die Wochen nach der „Korrektur“ wieder rot werden.
Für alle, die Bibliotheks-Upgrades monatelang aufschieben, weil sie nicht wissen, was dabei kaputtgeht.
Für alle, die Übersetzungen mit verlorenen Tags und Platzhaltern ausliefern, ohne es zu bemerken.
Für alle, die eine Regel für den gesamten Lebenszyklus nach dem Code wollen: Der Agent schlägt vor, ein deterministischer Verifier entscheidet, ein Mensch genehmigt mit den Belegen vor Augen.
So wird es verwendet
Füge die CI/CD-Komponente in die Pipeline-Datei des Projekts ein. Der Verifier wird über ein Label am Merge Request oder über den Branch-Namen gewählt. Jeder Verifier ist außerdem ein Kommandozeilenwerkzeug ohne Konfiguration, ohne API-Schlüssel und ohne Konto: Python nur mit der Standardbibliothek, Node mit dem TypeScript-Compiler als einziger echter Abhängigkeit für die Upgrades. Das JSON-Schema des Urteils liegt im Repository, zusammen mit einem Konformitätstest, der bei der Ausgabe jedes Verifiers läuft.
Quellcode unter der MIT-Lizenz auf GitLab. Drei-Minuten-Demovideo.
Verdict Gate ist ein Beitrag zum GitLab-Hackathon „Life After Code“ (Oktober 2026).
Im Browser ausprobieren
Unten sehen Sie die interaktive Konsole: Drei der fünf Verifier (Flaky Tests, Abhängigkeits-Upgrades, Übersetzungen) lassen sich von Hand ausführen, ohne Schlüssel und ohne Konto, und liefern dieselbe VERDICT-Zeile, die die Pipeline liest.