Guarani AI
ENFR Essai gratuit

Guarani Verify

Bêta privée · Espaces d'essai sur demande

Revue de code IA autonome et conformité d'architecture

Une analyse sémantique approfondie de chaque pull request. Verify construit un graphe de votre base de code, confronte chaque modification à vos règles d'architecture et signale les régressions de performance avant la fusion.

Essai gratuitParler à un ingénieur

Ce qu'il fait

  • Revue sémantique des pull requests

    Revue sémantique des pull requests à travers les fichiers, les services et les périmètres de responsabilité

  • Régressions de performance

    Détection précoce des régressions de performance au regard des budgets de latence et de mémoire

  • Validation des contrats d'API

    Validation des contrats d'API REST, GraphQL et gRPC, avec blocage des changements incompatibles

  • Tests générés

    Génération automatique de tests unitaires et d'intégration pour les chemins non couverts

À quoi ressemble une revue

Une pull request d'exemple, revue par l'agent d'architecture : un constat de performance avec une modification suggérée, une note de contrat et les tests générés.

Revue de pull requestRevue d'exemple
#1842orders: add fulfillment ETA
acme/core-apifeat/fulfillment-eta vers main6 fichiers modifiés
Verify, agent d'architecturePerformanceservices/orders/eta.ts:48

estimateEta() appelle le service d'inventaire une fois par article, dans la boucle. Sur les grosses commandes, ces appels séquentiels font dépasser à GET /v2/orders son budget p95 de 450 ms.

Regroupez les lectures en un seul appel getAvailability() pour rester dans le budget.

Modification suggérée
- for (const item of order.items) {-   const stock = await inventory.get(item.sku);-   etas.push(estimate(item, stock));- }+ const skus = order.items.map((item) => item.sku);+ const stock = await inventory.getAvailability(skus);+ const etas = order.items.map((item) => estimate(item, stock[item.sku]));
Verify, agent d'architectureContratopenapi/orders.yaml

Champ ajouté fulfillment_eta sur GET /v2/orders. Les clients existants ne sont pas affectés : compatible avec le contrat v3.

4 tests unitaires et 1 test d'intégration générés pour estimateEta(), tous réussis.

Sa place dans le verdict de release

Chaque modification s'exécute comme un pipeline tracé, à travers des régions cloud managées, de l'inférence GPU et des pools d'appareils réels. Le code client est traité dans des tenants isolés et n'est jamais utilisé pour entraîner des modèles.

Pas encore disponibles publiquement : la CLI, les SDK et l'API font partie de la bêta privée.

Voir toute l'architecture

  1. Webhook reçu

    Une pull request sur GitHub ou GitLab notifie le plan de contrôle sur api.guarani-llc.com/v1. Le moteur de règles détermine le profil du dépôt.

  2. Code indexé

    L'orchestrateur met à jour le graphe sémantique et l'index vectoriel des fichiers modifiés, dans le tenant isolé du client.

  3. Agents de revue lancés

    Les agents d'architecture, de contrat et de performance s'exécutent sur les workers d'analyse : des conteneurs sur AKS, ECS/EKS et Cloud Run.

  4. CLEARED pour la mise en production

    Des règles de politique versionnées marquent la strip CLEARED, le verdict est publié sur la pull request sous forme de check, et chaque étape est consignée dans une piste d'audit.

Les verdicts découlent de règles de politique versionnées appliquées aux constats : les mêmes constats et la même politique produisent toujours le même verdict.

Le configurer

guarani init crée guarani.yml à la racine du dépôt. Ce fichier déclare les profils, les budgets de performance, la règle et les fournisseurs Mesh, ainsi que les suites et appareils mobiles.

Pas encore disponibles publiquement : la CLI, les SDK et l'API font partie de la bêta privée.

Lire la documentation : Configuration, GitHub Actions, GitLab CI

Le profil se choisit avec --profile. hold_on liste les constats qui placent une exécution en HOLD, ce qui fait échouer le contrôle dans votre pipeline. Les avertissements ne bloquent jamais.

guarani.yml, extrait
profiles:
  pull-request:
    checks: [architecture, contracts, performance]
    tests: generate-missing
    hold_on: [blocking]
  release:
    checks: [architecture, contracts, performance, tests]
    mobile: checkout
    hold_on: [blocking, flaky-device]

budgets:
  latency_p95_ms: 450
  memory_mb: 512

Ajoutez un workflow déclenché sur pull_request. Enregistrez le jeton de l'espace de travail dans le secret de dépôt GUARANI_TOKEN. La permission checks: write permet à la CLI de publier le verdict sous forme de check.

.github/workflows/guarani.yml
name: guarani
on: pull_request

permissions:
  contents: read
  checks: write
  pull-requests: write

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm i -g @guarani-ai/cli
      - run: guarani verify --profile pull-request --report github
        env:
          GUARANI_TOKEN: ${{ secrets.GUARANI_TOKEN }}

Données et déploiement

Traitement des données

  • Chiffrement en transit et au repos.
  • Traitement aux États-Unis ou dans l'UE selon la région choisie pour l'espace de travail.
  • Aucun entraînement sur le code, les prompts ou les sorties des clients.
  • Durée de conservation configurable pour le contenu des dépôts et les artefacts.

Options de déploiement

  • Cloud multi-tenant avec tenants isolés, par défaut sur toutes les offres.
  • VPC dédié sur Azure, AWS ou Google Cloud.
  • Points d'inférence GPU isolés pour les modèles open-weight.

Explorer la plateforme