KI-Agenten bauen das Feature. Du entscheidest, wann es live geht.
Beschreib in eigenen Worten, was du brauchst. BuildBit plant es, baut es auf einem eigenen Branch und testet es in deinem echten Git-Repository. Nichts wird gebaut, bevor du den Plan freigibst, und nichts wird gemergt, bevor du klickst.
Betreib es auf deinen eigenen Servern mit der KI deiner Wahl, sogar mit einem Modell auf deiner eigenen Hardware, oder lass es von uns in EU-Rechenzentren hosten.
Früher Zugang für Teams. Du bekommst eine E-Mail zur Bestätigung und danach nur Neuigkeiten zu BuildBit.
Beispiellauf: Rechnungs-Export
-
Du
Die Buchhaltung will Rechnungen eines Zeitraums als CSV exportieren, die Excel direkt öffnet.
-
Architekt-Agent Plan v1
- Ansatz
- Ein neuer Export-Endpunkt, der die Filter der Rechnungsliste übernimmt und die Zeilen streamt.
- Entscheidung
- Semikolon und UTF-8 mit BOM, weil ein deutsches Excel eine Komma-Datei sonst als eine Spalte öffnet.
-
Du
Plan freigeben
-
QA-Agent Bericht v1
- Build Bestanden 0 Warnungen, 0 Fehler
- Testsuite Bestanden 214 bestanden, 0 fehlgeschlagen
-
Du
Jetzt mergen
Coding-Agenten sind stark. Sie zu überwachen ist schwer.
Ein Agent im Terminal hinterlässt eine Wand aus Text und eine Frage: Kannst du dem Ergebnis trauen? BuildBit dreht das um. Der Plan kommt vor dem Code, der Testbericht vor dem Merge, und beides ist auch Monate später noch lesbar.
Erst der Plan, dann der Code
Der Architekt-Agent liest deinen echten Code und schlägt einen Plan vor. Umgesetzt wird erst, wenn du ihn freigibst.
Ein Bericht, den du prüfen kannst
Jede Änderung kommt mit einer Liste einzelner Prüfungen und dem Beleg für jede davon.
Jeder Agent hat eine Aufgabe
Der Agent, der plant, kann keinen Code schreiben, und der Agent, der testet, kann nichts reparieren.
Ein lückenloser Verlauf
Jeder Statuswechsel wird gespeichert: wer ihn ausgelöst hat, wann und zu welchem Agent-Lauf er gehört.
So entsteht ein Feature
Zwei der sechs Schritte gehören dir. Alles dazwischen läuft von selbst.
-
Du
Beschreib, was du brauchst
So, wie du es einer Kollegin erklären würdest. BuildBit fragt nach und schlägt vor, wie sich die Arbeit in Features aufteilen lässt. Fehlermeldungen bekommen zuerst eine Diagnose, die den Fehler nachzustellen versucht.
-
Architekt-Agent
Du bekommst einen Plan
Der Plan nennt den Ansatz, die betroffenen Teile deines Codes, seine Entscheidungen und die Risiken, mit Diagramm und Bildschirmentwürfen, wenn die Änderung sie braucht.
-
Du
Du prüfst den Plan
Markier eine Stelle und stell eine Frage, die direkt dort beantwortet wird, ohne neue Version. Oder hinterlass Änderungswünsche, die als neue Version des Plans zurückkommen.
-
Entwickler-Agent
Es wird auf einem Branch gebaut
Jedes Feature bekommt einen eigenen Branch. Der Entwickler-Agent schreibt dort den Code und seine Tests und baut ihn, fasst deinen Hauptbranch aber nie an.
-
QA-Agent
Es wird getestet
Build, Tests, eine Prüfung im echten Browser, wenn dein Projekt eine Oberfläche hat, und ein Abgleich mit dem freigegebenen Plan. Schlägt eine Prüfung fehl, geht die Arbeit mit dem Bericht zurück an den Entwickler-Agenten.
-
Du
Mergen oder zurückschicken
Ein Klick mergt und pusht. Nicht zufrieden mit dem Ergebnis? Fordere Änderungen an, und es geht zurück in die Entwicklung.
Jede Änderung kommt mit einem QA-Bericht
Kein grünes Lämpchen, das die Details versteckt. Jede Prüfung steht einzeln da, mit dem, was ausgeführt wurde, und dem, was dabei herauskam, auch die bestandenen.
QA-Bericht, Version 2: Rechnungs-Export
| Prüfung | Ergebnis | Beleg |
|---|---|---|
| Build | Bestanden | dotnet build: 0 Warnungen, 0 Fehler |
| Testsuite | Bestanden | 214 bestanden, 0 fehlgeschlagen, 0 übersprungen |
| Semikolon und BOM sind durch Tests abgedeckt | Bestanden | UsesSemicolonSeparator, WritesUtf8Bom: bestanden |
| Zeilenlimit | Bestanden | 10.001 Zeilen liefern HTTP 400 statt einer abgeschnittenen Datei |
| Export im Browser | Bestanden | Nach Monat gefiltert, Export geklickt, 1.284 Zeilen heruntergeladen. Screenshot anbei |
| Entspricht dem freigegebenen Plan | Bestanden | Alle 3 Entscheidungen umgesetzt, kein neues Paket hinzugefügt |
Version 1 ist an der Prüfung des Zeilenlimits gescheitert: Die Datei wurde bei 10.000 Zeilen stillschweigend abgeschnitten. Dieser Bericht ging an den Entwickler-Agenten zurück und bleibt erhalten.
- Berichte bleiben dauerhaft erhalten, auch nachdem das Feature gemergt ist.
- Ein neuer QA-Lauf fügt eine neue Version hinzu. Fehlgeschlagene Versionen bleiben lesbar.
- Der QA-Agent kann keinen Code ändern. Er baut, testet und bewertet. Reparieren ist Aufgabe des Entwickler-Agenten.
Leitplanken, die in jeden Agent-Lauf eingebaut sind
Eine Anweisung im Prompt ist eine Bitte. Die Grenzen von BuildBit setzt das System bei jedem Lauf durch, sodass sie auch halten, wenn ein Agent sich irrt oder von Inhalten in deinem Repository in die Irre geführt wird.
Werkzeuge pro Rolle
Jeder Agent bekommt genau die Werkzeuge, die seine Aufgabe braucht. Kein Agent kommt allein vom Plan bis zum Merge.
Ein frischer Container pro Lauf
Jeder Lauf startet in einem neuen Einweg-Container mit einer frischen Kopie des Codes und wird danach entfernt. Zwischen Läufen und Projekten bleibt nichts zurück.
Nur du kannst auf main pushen
Der Push auf deinen Hauptbranch ist der einzige Schritt, der sich nicht rückgängig machen lässt. Er läuft aus BuildBits eigenem Code direkt nach deinem Klick, ohne KI. Agenten haben nie Push-Zugangsdaten.
Ein Branch pro Feature
Ein Agent arbeitet auf dem Branch seines Features und nirgendwo sonst. Geht etwas schief, bleibt der Schaden auf diesem Branch.
Alles wird aufgezeichnet
Das vollständige Protokoll jedes Laufs bleibt erhalten, auch die blockierten Aktionen. Du siehst, was ein Agent versucht hat, nicht nur, was ihm gelungen ist.
Grenzen für Zeit und Geld
Jeder Lauf hat ein Zeitlimit, und ein Monatsbudget pausiert neue Läufe, sobald es erreicht ist. Du kannst außerdem jedes Feature selbst pausieren.
| Wer | Darf | Darf nicht |
|---|---|---|
| Architekt-Agent | Den Code lesen und einen Plan vorschlagen | Irgendeine Datei ändern |
| Entwickler-Agent | Code und Tests schreiben, auf seinem Branch bauen | Die Tests ausführen oder auf main pushen |
| QA-Agent | Bauen, Tests ausführen, die Oberfläche im Browser prüfen | Irgendeinen Code ändern |
| Merge | Mergen und pushen, ohne KI | Laufen, bevor du auf „Jetzt mergen“ klickst |
| Jeder Agent | Die Werkzeuge seiner Rolle nutzen | Pushen, das Git-Remote oder die Git-Konfiguration ändern |
Gebaut für die DSGVO
Du entscheidest, wo BuildBit läuft und mit welcher KI es arbeitet. Betreib es auf deinen eigenen Servern mit einem Modell auf deiner eigenen Hardware, und dein Code verlässt nie dein Netzwerk.
Jeder KI-Anbieter
Nutz Claude Code, ein OpenAI-Abo oder einen anderen Anbieter, pro Projekt und pro Agent. Ohne Aufschlag: Du siehst, was jeder Lauf und jedes Feature gekostet hat.
Modelle auf deiner eigenen Hardware
Binde ein offenes Modell an, das auf deinen eigenen Servern läuft. Code, Prompts und Antworten bleiben in deinem Netzwerk.
Dein Repository
BuildBit arbeitet direkt auf deinem Git-Remote. Kein Import, keine Kopie.
Dein Stack
Alles, was in einem Container läuft, funktioniert: Node, Python, Go, Java, .NET oder eine Mischung, auch Tests, die eigene Container starten.
| Setup | Code und Verlauf liegen | Modellaufrufe gehen an |
|---|---|---|
| Deine Server, lokales Modell | Auf deinen Servern | Deine Server Nichts verlässt dein Netzwerk |
| Deine Server, Cloud-KI | Auf deinen Servern | Den Anbieter deiner Wahl |
| Von uns gehostet | In EU-Rechenzentren | Den Anbieter deiner Wahl |
Wofür Teams es nutzen
Einen Backlog abarbeiten
Viele kleine, klar umrissene Tickets laufen gleichzeitig, während du an etwas anderem arbeitest. Du steigst an den zwei Stellen ein, auf die es ankommt.
Bugs aus einer Beschreibung beheben
Beschreib den Fehler und bekomm einen Fix zurück, der vorher nachgestellt und danach getestet wurde, mit der Ursache schriftlich festgehalten.
Agenten an echtem Code ausprobieren
Setz KI-Agenten in deinem echten Repository ein, während Freigabe und Merge bei dir bleiben.
Fragen
Was Teams meistens fragen, bevor sie BuildBit ausprobieren.
Schreibt hier eine KI ungeprüft in mein Repository?
Nein. Agenten arbeiten nur auf dem Branch ihres eigenen Features. Der Push auf deinen Hauptbranch passiert ausschließlich aus BuildBits eigenem Code, nachdem du auf „Jetzt mergen“ geklickt hast.
Agenten haben nie Push-Zugangsdaten, und Push-, Remote- und Config-Befehle sind für jeden Agenten gesperrt.
Wie viel muss ich lesen, bevor ich freigebe?
Der Plan ist kurz und hat immer dieselben Teile: das Problem, den Ansatz, betroffene Bereiche, Entscheidungen, Risiken und den Umfang.
Ist etwas unklar, markierst du die Stelle und fragst. Ein Agent, der nur lesen darf, antwortet direkt dort, ohne eine neue Version des Plans anzulegen.
Was passiert, wenn ich einen Plan nicht freigebe?
Nichts. Das Feature wartet, bis du entscheidest, so lange es eben dauert. Während es wartet, läuft kein Agent, also kostet Warten nichts.
Was, wenn ein Agent sich im Kreis dreht?
Jeder Lauf hat ein Zeitlimit, und das Monatsbudget pausiert neue Läufe, sobald es erreicht ist. Du kannst außerdem jedes Feature jederzeit selbst pausieren.
Ein pausiertes Feature behält seinen Platz und macht dort weiter, wo es aufgehört hat, sobald du es fortsetzt.
Wohin geht mein Code?
BuildBit speichert deinen Code, Pläne, Berichte und Protokolle dort, wo es läuft: in deinem eigenen Kubernetes-Cluster oder, wenn wir es hosten, in deiner eigenen Instanz in einem EU-Rechenzentrum.
Die Agenten schicken Code nur an die KI, die du anbindest. Mit einem Modell auf deiner eigenen Hardware verlässt er nie dein Netzwerk.
Agenten können auch im Web lesen, haben aber die Anweisung, deinen Code und Zugangsdaten nirgendwo anders hinzuschicken.
Ist BuildBit DSGVO-konform?
Ja. Betreibst du es auf deinen eigenen Servern, bleibt alles, was BuildBit speichert, bei dir. Unsere gehostete Version läuft ausschließlich in EU-Rechenzentren.
Für die strengsten Anforderungen bindest du ein Modell auf deiner eigenen Hardware an. Dann verlässt kein Code, kein Prompt und keine Antwort dein Netzwerk. Sieh dir an, wohin deine Daten in jedem Setup gehen.
Kann ich Bugs genauso melden wie Features?
Ja. Ein Bug durchläuft zuerst eine Diagnose, die ihn nachzustellen versucht und die Ursache festhält. Danach nimmt er denselben Weg wie ein Feature.
Lässt er sich nicht nachstellen, bleibt dieses Ergebnis als Kontext angehängt und blockiert nichts.
Kann ich die Freigabe für kleine Änderungen überspringen?
Ja, pro Projekt. Mit automatischer Freigabe wird ein Plan ohne offene Fragen oder Änderungswünsche freigegeben, sobald er fertig ist. Standardmäßig ist sie aus.
Gemergt wird immer erst nach deinem Klick.
Öffnet BuildBit Pull Requests?
Nein. BuildBit pusht den Branch jedes Features in dein Repository. Nachdem du auf „Jetzt mergen“ geklickt hast, mergt es diesen Branch in deinen Hauptbranch und pusht ihn.
Deine CI läuft bei diesen Pushes wie gewohnt.
Können mehrere Features gleichzeitig laufen?
Ja. Jeder Agent-Lauf bekommt einen eigenen Container, also können viele Features gleichzeitig in Arbeit sein. Du kannst die Zahl gleichzeitiger Läufe begrenzen, und Läufe darüber warten auf einen freien Platz.
Merges in denselben Hauptbranch passieren nacheinander.
Was passiert, wenn der Merge auf einen Konflikt stößt?
Ein Agent mergt deinen Hauptbranch in den Feature-Branch, löst den Konflikt auf und pusht nur den Feature-Branch.
Das Ergebnis geht noch einmal durch QA, bevor „Jetzt mergen“ wieder angeboten wird.
Welche Git-Hoster funktionieren?
Jedes Git-Repository, das BuildBit über HTTPS erreicht, zum Beispiel auf GitHub, GitLab oder Azure DevOps. Für jedes Projekt hinterlegst du ein Zugriffstoken.
Ein Projekt ist ein Repository. Ein Monorepo funktioniert als ein einzelnes Projekt.
Welche Sprachen und Werkzeuge werden unterstützt?
Alles, was in einem Container läuft. Build- und Testbefehle stehen als einfacher Text in deinen Projekteinstellungen, und das Container-Image lässt sich um alles erweitern, was dein Build braucht.
Fehlt ein Werkzeug, meldet der Agent das, und BuildBit schlägt die passende Erweiterung des Images vor.
Welche KI-Modelle kann ich nutzen?
Die, die du wählst. BuildBit arbeitet mit Claude Code, einem OpenAI-Abo, anderen Anbietern und offenen Modellen auf deiner eigenen Hardware.
Du kannst pro Projekt und pro Agent wählen, zum Beispiel ein anderes Modell fürs Planen als fürs Programmieren.
Was kostet ein Feature?
Das hängt von seiner Größe ab. BuildBit zeigt die Kosten jedes Laufs und addiert sie pro Feature, sodass du nach ein paar Features weißt, womit du rechnen kannst.
Die Modellnutzung rechnet dein KI-Anbieter direkt mit dir ab. Ein Modell auf deiner eigenen Hardware hat keine Nutzungsgebühren.
Gibt es die App auf Deutsch?
Ja. Die App gibt es auf Deutsch und Englisch.
Wie bekomme ich Zugang?
BuildBit ist im frühen Zugang. Trag dich auf die Warteliste ein, und wir melden uns, sobald ein Platz für dein Team frei ist, von uns gehostet oder in deiner eigenen Infrastruktur.
Früher Zugang
BuildBit wird gerade mit einer kleinen Zahl von Teams getestet. Trag dich auf die Warteliste ein, und wir sagen dir Bescheid, sobald ein Platz für dich frei ist.