Von der Idee bis in den Produktivbetrieb, ohne Rückschritte.
Nexus bringt seine eigene Softwarefabrik mit. Ideen werden eingestuft, ein Entscheidungsraum wählt eine aus, und KI-Agenten sowie Entwickler setzen sie auf Branches um. Forge testet jede Änderung gegen den künftigen Stand der Hauptlinie – nicht gegen den alten –, signiert jedes Build-Ergebnis und rollt es schrittweise mit gesichertem Rückweg aus. Schnell genug für Arbeit im KI-Takt, sorgfältig genug für regulierte Bereiche.
Von der Frage bis zum Release, in sechs Schritten.
Jeder Schritt wird protokolliert und hat eine verantwortliche Person, die ihn stoppen kann. Der Weg von der Idee bis zum laufenden Code lässt sich jederzeit zurückverfolgen.
Ideen entwickeln
Stellen Sie eine konkrete Frage. Ideenläufe generieren Optionen, testen sie gegeneinander und ordnen sie innerhalb eines Budgets nach Rang.
Entscheiden
Die engere Auswahl geht in einen Entscheidungsraum. Eine namentlich benannte Person entscheidet, und dieser Beschluss wird zum Plan.
Entwicklung
KI-Agenten und Entwickler schreiben die Änderung samt Tests auf einem Branch – jeweils in einer eigenen Sandbox.
Prüfung
Ein Sicherheits-Gate, das blockiert, eine KI-Prüfung, die erklärt, und ein Mensch, der dort freigibt, wo die Regeln es verlangen.
Mergen
Die Merge-Warteschlange testet jede Änderung zusammen mit den Änderungen vor ihr. Die Hauptlinie bricht nie.
Ausliefern
Signierte Images werden schrittweise und mit Systemprüfungen ausgerollt. Jedes Release lässt sich in einem einzigen geprüften Schritt zurücksetzen.
Am einen Ende Ideen hinein, am anderen Ende lauffähige Software heraus.
Die Fabrik verbindet die denkenden Teile von Nexus mit den bauenden Teilen. Ideen, Entscheidungen, Agenten und Forge nutzen ein gemeinsames Protokoll, sodass Sie jede Codezeile bis zur ursprünglichen Frage zurückverfolgen können.
Ideen, nach Rang geordnet
Ideenläufe testen Optionen gegeneinander und halten das stärkste Gegenargument zu jeder Option fest.
- Im direkten Vergleich eingestuft
- Gegenargumente dokumentiert
Ein Beschluss wird zum Plan
- Eine benannte Person entscheidet
- Der Beschluss ist der Auftrag
Änderungen von Agenten und Menschen
KI-Agenten erstellen Änderungsanfragen wie jeder Entwickler. Jede Anfrage zeigt ihre Prüfungen, ihre Reviews und ihren Platz in der Warteschlange.
- Gleiche Regeln für Agenten und Menschen
- Nichts wird automatisch gemergt
Ein KI-Prüfer für jede Änderung
Jede Änderung wird von einem KI-Prüfer gelesen, der seine Ergebnisse innerhalb eines täglichen Ausgabenlimits erläutert. Er berät; Menschen entscheiden.
- Anmerkungen im Klartext
- Festes Tageslimit
Die Hauptlinie bricht nie.
Die meisten Pipelines testen eine Änderung gegen den Stand der Hauptlinie zum Startzeitpunkt des Branches. Forge testet sie gegen den künftigen Stand der Hauptlinie – einschließlich aller Änderungen, die in der Warteschlange vor ihr liegen. Ein Build, der einen Sicherheitsscan nicht besteht, wird niemals signiert und kann daher nie ausgerollt werden.
Bauen, scannen, signieren, vorschlagen
Jeder Build durchläuft dieselben Phasen. Tests und Sicherheitsscan laufen parallel; die Signierung wartet auf beides.
- Scans blockieren, statt nur zu warnen
- Fehler im Klartext erklärt
Vier Gates, dann Wellen
Jedes Release passiert vier Gates und wird dann zunächst für 10 von 100 Anfragen, danach für die Hälfte und schließlich für alle ausgerollt.
- An ein exaktes Image gebunden
- Wellen mit Systemprüfungen
So schnell, wie die Agenten schreiben können.
Wenn KI-Agenten Code schreiben, treffen Builds schubweise ein. Runner werden hinzugefügt, solange Aufträge warten, und nach Abschluss wieder entfernt. Ein gemeinsamer Build-Cache sorgt dafür, dass der Großteil jedes Images wiederverwendet statt neu gebaut wird.
Runner, die mit der Warteschlange wachsen
Jeder Build läuft in einer eigenen, abgeschirmten Sandbox. Solange Aufträge warten, starten weitere Runner – innerhalb einer von Ihnen festgelegten Obergrenze.
- Für jeden Auftrag eine frische Sandbox
- Wächst und schrumpft innerhalb des Limits
Der Großteil jedes Builds wiederverwendet
Ein gemeinsamer Cache speichert unveränderte Ebenen, sodass ein typischer Build nur wenige Minuten dauert.
- Build-Zeit über 30 Tage erfasst
- Cache-Treffer nach Repository
Nur signierte Builds gehen in Produktion.
Jedes Image wird über seinen Fingerabdruck signiert – samt Protokoll darüber, wie und wo es gebaut wurde. Die Produktionsumgebung lehnt alles Unsignierte ab, und Secrets werden einmalig geschrieben und nie wieder angezeigt.
Über den Fingerabdruck signiert
Jeder Signaturschlüssel wird von zwei Personen gehalten. Jedes Image trägt ein Build-Protokoll, und unsignierte Images werden dort abgewiesen, wo Sie es festlegen.
- Schlüssel in der Hand von zwei Personen
- Unsignierte Images abgewiesen
Secrets, nur über den Namen
Builds und Tests lesen Secrets über ihren Namen. Ein Wert wird einmalig geschrieben und nie wieder angezeigt, und jeder Lesezugriff wird gezählt.
- Einmal geschrieben, nie angezeigt
- Wer welches Secret lesen darf
In Wellen ausliefern, immer mit Rückweg.
Ein Release ist eine kleine, geprüfte Änderung, die das exakt auszuführende Image festlegt. Es wird zunächst für wenige Anfragen ausgerollt, dann für die Hälfte, dann für alle – jeweils mit Systemprüfungen dazwischen. Ein Rollback ist dieselbe Art von Änderung, freigegeben durch eine zweite Person.
Von der gemergten Änderung bis zum Betrieb
- Jeder Schritt vom Merge bis zum Betrieb
- Was einen Menschen braucht, zuerst
In rund einer Minute zurück
Der Rückweg wird als Änderung vorbereitet, geprüft und von einer zweiten Person freigegeben. Regelmäßige Übungen halten den Ablauf schnell.
- Eine geprüfte Änderung, keine Hektik
- Jeden Monat geübt
Ihr Code, Ihre Hardware, Regeln folgen.
Forge läuft innerhalb Ihrer Installation, auf Ihrer eigenen Hardware oder in unserer EU-Cloud, ohne externe Dienste im Build-Pfad. Es baut auch dann weiter, wenn die Produktion ausgefallen ist – also genau dann, wenn Sie eine Fehlerbehebung ausliefern müssen. Jede Einstellung wird zudem als Datei gespeichert, sodass Änderungen genau wie Code geprüft werden.
Jede Einstellung versioniert
Einstellungen, Workflows, Skills und Richtlinien werden als Dateien abgelegt. Eine dort vorgenommene Änderung kehrt als geprüfte Änderung zurück.
- In beide Richtungen, immer geprüft
- Direkte Änderungen an der Hauptlinie abgewiesen
Riskante Aktionen fragen gezielt nach
Jede Aktion hat ein Risiko. Je höher das Risiko, desto höher die Anforderung: die Eingabe eines Namens, eine zweite Person oder eine erfüllte Vorbedingung.
- Rollen aus Ihren Gruppen
- Kritische Aktionen erfordern zwei Personen
Über Forge und die KI-Fabrik.
Müssen wir unseren Code in Forge speichern?
Nein. Forge ist standardmäßig vorhanden, aber Nexus arbeitet auf Organisations- oder Domain-Ebene auch mit dem Code-Host zusammen, den Sie bereits nutzen.
Schreiben KI-Agenten eigenständig Code?
Sie schreiben Änderungen auf Branches, wie jeder Entwickler. Nichts gelangt in die Hauptlinie, ohne dieselben Prüfungen zu bestehen, und überall dort, wo Ihre Regeln es vorsehen, gibt ein Mensch die Änderung frei.
Wie verhindern Sie Regressionen?
Jede Änderung wird zusammen mit allen vor ihr liegenden Änderungen getestet, sodass nur bestandene Kombinationen in die Hauptlinie gelangen. Releases werden in Wellen mit Systemprüfungen ausgerollt, und jedes Release lässt sich in einem einzigen geprüften Schritt zurücksetzen.
Hängt der Build-Pfad von externen Diensten ab?
Nein. Bauen, Scannen, Signieren und Ausrollen laufen vollständig innerhalb Ihrer Installation, sodass Sie auch dann noch eine Fehlerbehebung ausliefern können, wenn an anderer Stelle ein Ausfall vorliegt.
Können wir sehen, was die Fabrik kostet?
Ja. Build-Minuten, Runner und KI-Prüfung haben jeweils ein eigenes Budget und eine Obergrenze und werden wie jeder andere KI-Aufruf in Nexus abgerechnet.
Tiefer eintauchen
Sehen Sie selbst, wie die Fabrik etwas Reales baut.
Bringen Sie eine Idee mit. Wir zeigen Ihnen den Weg von einer nach Rang geordneten Auswahlliste bis zum signierten Release – auf Ihrer eigenen Hardware.