Anvil CoderAnmelden

Bau was hammermässiges

Vom Ticket zum Pull Request mit KI-Agenten

Anvil Coder setzt Software-Aufgaben in deinem Repository um. KI-Agenten zerlegen Tickets in kleine Schritte und erstellen nachvollziehbare Commits. Du legst die Projektregeln fest und prüfst das Ergebnis vor dem Merge. Im betriebenen Dienst entsteht ein Entwurf eines Pull Requests.

Der Zugang läuft zurzeit über eine Warteliste. Die Abopreise sind noch nicht final. Plattformverbrauch und externe Modellkosten sind getrennt.

Amboss-Symbol von Anvil Coder

Die Arbeit im Cockpit verfolgen

Du siehst, welche Schritte erledigt sind, gerade laufen oder noch warten. Die entstandenen Änderungen prüfst du im Pull Request bei deinem Git-Hoster.

Laufübersicht von Anvil Coder mit erledigten, laufenden und ausstehenden Arbeitsschritten (Beispieldaten)
Produktansicht mit Beispieldaten. Ein erledigter Arbeitsschritt bedeutet für sich allein noch nicht, dass Build und Tests bestanden sind.

Ein Referenzlauf zum Nachlesen

Ein Laravel-Fehler führte in einem Referenzlauf zu drei Commits mit Korrektur und Regressionstest. Die Sandbox konnte den Test wegen der fehlenden PHP-Toolchain nicht ausführen; die fachliche Prüfung blieb offen.

31.08.2026 (ein Lauf, ~24 Minuten)

Ablauf, Artefakte und Prüfgrenzen ansehen

Welche Werkzeuge kannst du anbinden?

Welche Modelle verfügbar sind, bestimmt die Betriebskonfiguration. Deinen Projekt-Stack legst du separat in einem Stack-Profil fest.

Modell-Anbindungen

  • Anthropic
  • OpenAI
  • Groq
  • Gemini
  • Mistral
  • Ollama

Gebaut mit

  • Java
  • Spring Boot
  • Angular
  • Astro
  • PostgreSQL
  • NATS
  • Kubernetes
  • Flux CD

Integrationen und Betrieb

  • GitHub
  • YouTrack
  • Keycloak
  • nginx
  • Prometheus
  • Grafana
Projekt-Kompatibilität ist nicht dasselbe wie der Plattform-Stack
BereichUmfang und Voraussetzungen
Projekt-StackJava und Spring Boot sind der am breitesten erprobte Weg. Weitere Profile benötigen die passende Build- und Test-Toolchain. Stack-Voraussetzungen
Ticket-SystemeInternes Issue Board, YouTrack, GitHub Issues, Jira Cloud, GitLab Issues, Bitbucket. Anbindung und Trigger müssen konfiguriert sein.
Git hostingGitHub, GitLab, Bitbucket. Zugriffsrechte und Ausgabeeinstellungen hängen von der Integration ab.
Plattform-KomponentenDie Liste „Gebaut mit“ beschreibt Anvil Coder selbst, keine Garantie für erfolgreiche Builds oder Tests jedes Kundenprojekts.
Integrationen und Voraussetzungen ansehen

Verbinde dein bestehendes Repository und nutze das interne Issue Board oder einen externen Tracker. Ein Stack-Profil beschreibt Sprache, Framework und Prüfkommandos. Java und Spring Boot sind der am breitesten erprobte Weg; weitere Stacks hängen von der verfügbaren Toolchain ab.Voraussetzungen für deinen Stack prüfen.

Wie es funktioniertEin Ticket von der Planung über Umsetzung und Prüfungen bis zum Review verfolgen.IntegrationenTracker, Code-Host und Modell-Anbieter verbinden.SicherheitDatenstandort, Zugriffsschutz und Übermittlung an Modell-Anbieter verstehen.

Was kostet Anvil Coder?

Ein Team-Abo je Organisation, bis zu zehn Sitzplätze zum Basispreis und 75% der Basis als Laufzeit-Guthaben. Die aktuellen Beträge sind Platzhalter. Verbrauch über dem Kontingent ist kostenpflichtig; BYOK-Modellkosten werden separat bezahlt.

Abo und Verbrauchskosten verstehen

Was solltest du vor dem Start wissen?

Merged Anvil Coder automatisch?
Im betriebenen Dienst entsteht ein Entwurf eines Pull Requests; auf den Hauptzweig führt ihn ein Mensch zusammen. Freigaben während des Laufs sind je Projekt einstellbar; ohne gesetzte Stufe läuft der Auftrag ohne Zwischenfreigabe durch.Details: Review und Aufsicht
Was, wenn das Ergebnis nicht taugt?
Dafür gibt es zwei Stellen, eine im Lauf und eine danach. Im Lauf steht am Ende ein Konsistenz-Durchgang über das Ganze. Misst er eine Verschlechterung, schickt er die betroffenen Arbeitsschritte in gedeckelte Reparatur-Runden. Kann er nicht messen, lässt er den Lauf wie das VERIFY-Gate durch und vermerkt am Gate einen Fehler — geprüft wurde dann nichts. Die Messung selbst steht im betriebenen Dienst bereit und wird je Projekt eingeschaltet; ein zusätzlicher Build- und Test-Durchgang über den Gesamtstand ist zuschaltbar und im betriebenen Dienst an. Danach liegt der Entwurf des Pull-Requests in deinem Review-Werkzeug: ein Kommentar am Pull-Request wird dort zur Anforderung eines inkrementellen Folgelaufs — ein zuschaltbarer Kanal, im betriebenen Dienst eingeschaltet.Der Ablauf im Ganzen: Wie es funktioniert: Phasen und Slices · Integrationen: der Rückkanal am Pull-Request
Läuft das in der Schweiz?
Ja, der betriebene Dienst läuft auf der Infomaniak Public Cloud in der Schweiz. Quelltext in Modellanfragen geht jedoch an den konfigurierten Modell-Anbieter. Auch Ergebnisse können die Schweiz verlassen, wenn dein Repository oder Tracker im Ausland liegt. Schweizer Hosting bedeutet deshalb nicht, dass alle Daten in der Schweiz bleiben.Wo die Daten liegen: Sicherheit: wo die Daten liegen
Wie behalte ich die Kontrolle?
Wie viel Aufsicht du behältst, stellst du je Projekt ein: von jede Aktion braucht eine Freigabe bis nur die folgenreichen — aber ohne gesetzte Stufe läuft der Auftrag durch, die Freigabe-Stufen sind ein Merkmal je Projekt und keine Voreinstellung. Was auch dann gilt: im betriebenen Dienst kommt das Ergebnis als Entwurf eines Pull-Requests an, und auf den Hauptzweig führt ihn ein Mensch zusammen.Warum das die eigentliche Frage ist: Für Produktteams: die Durchführung abgeben, die Entscheidung behalten

Alle Fragen und Antworten

Zur Methode hinter dem Ablauf: Spec-Driven Development · GitHub Spec Kit (externe Methodenreferenz).

Inhalt geprüft von Halvic Labs GmbH am .