Von der Geschäftsidee bis zum laufenden Betrieb. Risikokontrolle wie im Konzern, Aufwand wie im Startup.

Eine KI baut Ihnen an einem Nachmittag eine Anwendung. Teuer wird alles danach.

Eine Anwendung zu erstellen ist vielleicht 1 % der Kosten. Die anderen 99 % sind Änderungen, Wartung und Betrieb. Genau dort scheitern KI-Projekte: Funktionen verschwinden, eine Änderung bricht drei andere, niemand weiß mehr, warum etwas so gebaut wurde, und das Wissen steckt im Chatverlauf eines einzelnen Werkzeugs.

Ein durchgehender Weg, von der Idee bis zum Feedback aus dem Betrieb.

1. Ziel festhalten. Jede Änderung beginnt mit einem schriftlichen Geschäftsziel: was erreicht werden soll, was nie passieren darf, woran man erkennt, dass es fertig ist. Ein Mensch gibt es frei, bevor gebaut wird.
2. Unklares zuerst prüfen. Wo noch offen ist, was eigentlich gebraucht wird, klären wir das mit einem Wegwerf-Prototyp (DEAD), getrennt vom echten System.
3. Bauen gegen die Vorgabe. Ob Mensch oder KI: Die Umsetzung muss die festgehaltenen Ziele, Regeln und Abnahmekriterien erfüllen. Tests prüfen das Vereinbarte, nicht das, was der Code zufällig tut.
4. Kontrolliert ausliefern. Jede Änderung läuft durch dieselbe Pipeline: bauen, prüfen, ausliefern. Live geht genau die Version, die geprüft wurde. Die alte Version bleibt bereit, und schlägt die Prüfung im Betrieb fehl, schaltet das System automatisch zurück.
5. Aus dem Betrieb lernen. Was im Betrieb passiert und welche Fehler auftreten, fließt in die nächste Vorgabe ein. Ein Fehler wird erst behoben, wenn klar ist, welche Regel gilt.

Die Regeln, die ACD fest einbaut.

• Die Verantwortung bleibt beim Menschen. Ziele, Regeln und Freigaben gehören Ihren Leuten. Eine KI darf Unterlagen lesen und Vorschläge erstellen, aber nie selbst festlegen, was gilt.
• Keine KI gibt sich selbst frei. Wer eine Änderung schreibt, kann sie nicht selbst in den Betrieb bringen. Über die Freigabe entscheidet die Pipeline, und ihr Urteil gilt.
• Rot heißt Stopp. Solange die Pipeline einen Fehler meldet, darf nur repariert werden, nichts Neues.
• Niemand braucht Zugriff auf die Produktion. Änderungen erreichen den Betrieb ausschließlich über die Pipeline.
• Alles Wissen liegt im Repository. Ziele, Regeln, Code, Prüfungen und Auslieferung sind dort festgehalten. Sie können das KI-Werkzeug jederzeit wechseln, ohne Wissen zu verlieren, und jeder Mensch oder jede KI kann dort weitermachen.
• Der Rückweg ist erprobt. Bei der Einrichtung brechen wir die Pipeline absichtlich und stellen sie wieder her. Erst wenn der Rückweg funktioniert, verlassen Sie sich darauf.

Die Basisversion steht an einem Tag.

Sie brauchen keine Kubernetes-Landschaft und kein DevOps-Team. Für den Anfang reichen ein Rechner, ein Repository und eine Zielumgebung, zum Beispiel ein kleiner Server.

Was am Ende des Tages steht:

• Arbeitsumgebung, Repository und Zielumgebung sind eingerichtet und dokumentiert, sodass Sie sie jederzeit neu aufsetzen können.
• Eine Pipeline bringt Änderungen in drei Schritten in Ihre Produktion: bauen, prüfen, ausliefern, mit automatischem Zurückschalten bei Fehlern.
• Der Ernstfall ist geprobt: Pipeline absichtlich gebrochen und wiederhergestellt.
• Eine erste kleine Funktion ist vom schriftlichen Ziel bis in den Betrieb gegangen.

Das geht auch, wenn in Ihrem Team noch nie jemand Software entwickelt hat. ACD funktioniert mit jedem KI-Werkzeug und jeder Technik.

Unser eigenes Produktions-Release vom 31. Oktober 2026

Platzhalter: anonymisierter Screenshot des Pipeline-Laufs

• 3 Min. 14 Sek. vom Start bis zum fertigen Produktions-Release
• Pflicht-Gate Staging: ohne erfolgreiche Testumgebung keine Produktion (Staging-Lauf: 1 Min. 16 Sek.)
• Dieselbe Version: live ging nachweislich exakt das geprüfte Image
• 9.809 von 9.809 Anfragen während des Updates erfolgreich, 0 Fehler
• Längste Unterbrechung 810 ms, bei erlaubten 2.000 ms
• Automatischer Rollback stand bereit

Das ist kein Demo-System, sondern . Die Code-Beispiele im ACD-Buch stammen aus Michael Küsters' eigenem Produktiv-Repository.

Woher die Methode kommt: Michael Küsters arbeitet seit über zehn Jahren mit Continuous Delivery und entwickelt ACD seit 2023. Ende 2025 veröffentlichte er das ACD-Manifest gemeinsam mit Bryan Finster auf MinimumCD.org. Das Buch „Agentic Continuous Delivery – Make change work. In minutes.“ ist in Vorbereitung bei Leanpub. Den ACD-Praxisleitfaden können Sie schon heute kostenlos auf MinimumCD.org lesen und selbst anwenden. Mit uns läuft die Basis nach einem Tag, und wir stehen für das Ergebnis ein.

Das Ziel ist, dass Sie ACD danach selbst betreiben. Sie sollen wissen, was Sie ändern, warum es vertretbar ist, und das System bereit für die nächste Änderung hinterlassen.

Ist ACD nur etwas für Entwicklerteams? Nein. ACD ist gerade für Gründer, Fachabteilungen und kleine Teams gedacht, die mit KI eigene Lösungen bauen und dabei nicht in die Wartungsfalle laufen wollen. Für erfahrene Entwickler schließt es die Lücken, die KI-Agenten in bewährte Praktiken reißen.

Was brauchen wir für den Basis-Tag? Einen Rechner, ein KI-Werkzeug Ihrer Wahl, ein Repository und eine Zielumgebung, zum Beispiel einen kleinen Server mit Administratorzugang. Kann Ihre IT diese Umgebung nicht bereitstellen, ist das bereits ein wichtiger Befund, und wir besprechen ihn vorab.

Bauen Sie auch unsere Software? Wenn es nötig ist, ja, bis hin zur kompletten Entwicklung. Nicht als Dienstleister, sondern damit es vorangeht. In jedem Fall richten wir mit ACD den Weg ein, auf dem Ihr Team, mit oder ohne KI, danach selbst sicher baut und ausliefert. Die Produktentscheidungen bleiben bei Ihnen.

Wir haben schon eine Anwendung. Geht das trotzdem? [Platzhalter: Angebot und Aufwand für bestehende Anwendungen, Entscheidung Michael

Für Unternehmen: Gibt es eine Standardkonfiguration? Ja, für kommerzielle Nutzung stellen wir eine Standardkonfiguration bereit. [Platzhalter: Konditionen; Kontaktadresse festlegen: das Buch nennt acd@intelygence.com und michael-acd@intelygence.com