Jede Führungskraft im Engineering-Bereich, die kritische Infrastruktur aufbaut, ist von einer grundlegenden Annahme ausgegangen: Man kann entweder Geschwindigkeit oder Zuverlässigkeit haben, aber beides gleichzeitig zu erreichen galt als unmöglich.
Das ist kein Prozess- oder Teamproblem. Jahrelang akzeptierte die Branche dies als grundlegende Einschränkung der Softwareentwicklung. Zuverlässigkeit erfordert langsame, methodische Release-Zyklen. Umfassende Tests brauchen Zeit. Code-Reviews erzeugen Engpässe. Jede zusätzliche Sicherheitsebene verlängert die Bereitstellungszeiten um Wochen.
Bei EV-Ladeplattformen sind die Risiken höher als bei typischer Software. Ausfallzeiten können Sie sich nicht leisten, denn jede Minute Nichtverfügbarkeit bedeutet Umsatzverlust. Aber auch langsame Feature-Bereitstellung können Sie sich nicht leisten, da CPOs sich anpassen müssen, während sich der Markt weiterentwickelt.
Wir haben uns geweigert zu akzeptieren, dass „langsam“ der Preis für „sicher“ ist.
Wir haben erkannt, dass KI einen Reifegrad erreicht hat, bei dem dieser Trade-off endlich lösbar sein könnte. Die Frage war nicht, ob wir KI einsetzen, sondern wie wir ein Engineering-System architektonieren, in dem sich Geschwindigkeit und Qualität gegenseitig verstärken, anstatt zu konkurrieren – eine Veränderung, die wir in How AMPECO Became AI-Native.
Also haben wir AMPECOs gesamten Softwareentwicklungsprozess rund um KI-Agenten neu aufgebaut – nicht um eine Seite des Trade-offs zu wählen, sondern um ihn vollständig aufzubrechen. Wir haben den gesamten Entwicklungszyklus automatisiert: Planung, Programmierung, Testing und Deployment, wobei KI die Ausführung übernimmt, während Engineers die Architektur steuern und die Qualität validieren. Die Auswirkung: 2-Tage-Stories auf Stunden komprimiert, Bug-Raten halbiert, und wir sind von wöchentlichen Sprints zu täglichen Releases übergegangen.
So haben wir es gemacht.
Aufbau des CoOperator Dev Agent
Wir haben fast zwei Jahre lang mit KI-Coding-Tools experimentiert. GitHub Copilot für Autovervollständigung. CodeRabbit als Code-Review-Assistent. Der KI-Editor Windsurf. Alle zeigten Potenzial, lieferten aber gemischte Ergebnisse. Jedes Tool brachte uns schrittweise Verbesserungen, aber nichts, das das Spiel grundlegend veränderte.
Der Durchbruch kam mit Anthropics Claude Code. Frühere Tools erforderten ständige Überwachung – Entwickler mussten Zwischenergebnisse lesen und „weiter“ eingeben, um den Prozess am Laufen zu halten. Claude Code veränderte diese Dynamik: Es konnte an einer Aufgabe ohne Unterbrechung arbeiten, und wenn es die Fertigstellung signalisierte, war die Arbeit tatsächlich abgeschlossen. Entscheidend war auch, dass es über ein SDK skriptbar war, was es uns ermöglichte, es als zuverlässigen Schritt in unsere automatisierten Workflows einzubetten.
Wir haben unseren bestehenden Prozess – einen, der bereits gut funktionierte – genommen und ihn in kleine, einzelne Schritte zerlegt. Dieser granulare Ansatz war essenziell, um die Kontextbeschränkungen aktueller KI-Modelle nicht zu überfordern.
Für jeden Schritt haben wir spezifische Anweisungen geschrieben – die Art, die man einem menschlichen Entwickler geben würde – und exakt definiert, wie die Aufgabe abzuschließen ist und wie „erledigt“ aussieht. Wir haben diese Anweisungen als ausführbare Prompts gespeichert.
Dann haben wir diese Schritte in einen Workflow angeordnet, der den exakten Prozess unseres menschlichen Engineering-Teams widerspiegelt. Wir haben festgestellt, dass es keinen grundlegenden Schritt gab, den KI nicht ausführen konnte – vom Schreiben von Code bis zum QA – solange der Umfang korrekt gemanagt wurde.
Das Ergebnis ist das, was wir den CoOperator Dev Agent (CODA) nennen. Er dient als Workflow-Manager, der die Ausführung dieser Anweisungen orchestriert und den Prozess effektiv von Anfang bis Ende durchführt. Eine Architekturphase erstellt einen detaillierten Plan, eine Entwicklungsphase schreibt Tests und implementiert Features, und eine Code-Review-Phase führt ein internes Peer-Review durch, das die Arbeit strikt gegen Coding-Standards, Architekturmuster und Story-Anforderungen validiert. Wenn Probleme identifiziert werden, springt der Workflow zur Fehlerbehebung zurück und wiederholt sich, bis die Arbeit abgeschlossen ist.
Die KI-Engine: Systematische Beseitigung menschlicher Unterbrechungen
Wir haben erkannt, dass in einem KI-nativen System die primäre Geschwindigkeitsbeschränkung nicht die Generierungszeit der KI ist – sondern die menschliche Zykluszeit. Das Warten darauf, dass ein Mensch einen Plan überprüft oder einen Schritt genehmigt, erzeugt „Totzeit“, die die Geschwindigkeit zerstört.
Unser Ansatz geht nicht darum, „Schleifen“ von Mensch-KI-Interaktion zu managen. Es geht darum, Checkpoints zu etablieren und diese dann systematisch zu entfernen, während wir Vertrauen in die Autonomie des Agenten gewinnen.
Von Überwachung zu Autonomie
Anfangs war unser Prozess stark abgesichert. Ein Product Manager genehmigte die Story, dann generierten die KI-Agenten (Architect und QA) einen technischen Plan. Ein menschlicher Entwickler musste stoppen, diesen Plan überprüfen und genehmigen, bevor die Implementierung beginnen konnte. Erst dann trieben die Ausführungsagenten (Developer, Code-review und AcceptanceTest) die Aufgabe zur Fertigstellung, gefolgt von noch einem weiteren menschlichen Code-Review.
Als die Agenten ihre Fähigkeiten unter Beweis stellten, identifizierten wir, dass der „Plan-Review“-Checkpoint ein Engpass war. Die KI war in der Lage, valide Planung ohne ständige Handführung durchzuführen. Also haben wir diese menschliche Unterbrechung entfernt.
Der aktuelle Workflow
Heute übernehmen die Agenten vollständig, sobald der Product Owner und Engineer eine Story als „Ready for Development“ markieren. Sie handhaben autonom die Architekturplanung, Testplanung, Implementierung und Selbstkorrektur. Das System iteriert intern – schreibt Code, führt Tests aus, behebt Fehler – bis es einen „produktionsreiten“ Zustand erreicht.
Der menschliche Entwickler wird erst ganz am Ende für ein finales Review zurückgeholt. In dieser Phase kann er die Arbeit genehmigen oder Feedback geben. Wenn der Agent feststeckt oder Kurskorrektur benötigt, kann der Entwickler die Anweisungen des Agenten oder den Projektkontext manuell aktualisieren und den gesamten Prozess neu starten, um sicherzustellen, dass die Aktualisierung das Problem löst.
Der Weg zu Zero-Touch
Das Ziel ist es, diese menschlichen Checkpoints weiter zu entfernen. Wir erwarten, dass wir in den kommenden Monaten ein Vertrauensniveau erreichen, bei dem wir kein menschliches Code-Review mehr für jede Aufgabe benötigen. Durch die Beseitigung dieser Unterbrechungen ermöglichen wir der KI, mit ihrer vollen theoretischen Geschwindigkeit zu liefern und verwandeln Tage an Latenz in Minuten an Ausführung.
Das Sicherheitsnetz aus 25.000+ Tests
Um dieses Niveau an KI-Automatisierung zu ermöglichen, müssen Sie zunächst die Sicherheitsnetze einrichten. Aber das sind keine neuen Sicherheitsnetze, die wir für die KI erfunden haben.
Unser System basiert vollständig auf der Disziplin verpflichtender Unit- und Feature-Tests, kontinuierlicher Integration und automatisierter Security-Governance – Praktiken, die wir vor Jahren gemeistert haben, um unseren menschlichen Teams zu helfen, schnell zu arbeiten. Wir haben einfach festgestellt, dass dieselben Praktiken unseren KI-Agenten genauso gut helfen wie unseren menschlichen Engineers.
Für uns ist diese Grundlage eine massive Suite von über 25.000 automatisierten Tests. Ein Agent kann eine Aufgabe einfach nicht als „abgeschlossen“ definieren, bis er die Tests produziert, die beweisen, dass der Code funktioniert. Das gibt der KI sofortiges, programmatisches Feedback. Sie muss nicht „raten“, ob die Logik korrekt ist; die Test-Suite sagt es ihr sofort. Wenn ein Test fehlschlägt, korrigiert sich der Agent selbst und versucht es erneut, bis die Logik grün ist.
Diese Testdichte – generiert mit einer Geschwindigkeit, die Menschen nicht erreichen könnten – ist es, was uns ermöglicht, täglich ohne Chaos zu deployen. Sie fängt Regressionen sofort ab und stellt sicher, dass neue Features bestehende Funktionalität nicht kaputtmachen. Ohne dieses rigide Framework würde ein KI-Agent einfach fehlerhaften Code schneller produzieren, als Menschen ihn beheben könnten.
Während Tests die primäre Leitplanke sind, verstärken wir sie mit anderen automatisierten statischen Code-Analyse-Tools. Genau wie diese Tools verhinderten, dass Menschen unordentlichen oder unsicheren Code mergen, blockieren sie jetzt die KI-Agenten. Wenn die KI Code generiert, der korrekt funktioniert, aber gegen Architekturstandards verstößt, stoppen diese Tools den Prozess.
Letztendlich haben wir KI nicht auf leeren Versprechungen aufgebaut; wir haben sie auf etablierter Engineering-Disziplin aufgebaut.
Beibehaltene menschliche Checkpoints
Wir haben Menschen nicht aus dem Prozess entfernt; wir haben ihre Rolle zu „Managern“ ihrer KI-Kollegen aufgewertet. Es gibt zwei kritische menschliche Checkpoints, die den autonomen Workflow rahmen:
1. Das Alignment Sync (Vor der Arbeit) Bevor Code geschrieben wird, treffen sich der Product Owner und der Responsible Engineer (virtuell), um die Story zu iterieren. Das Ziel ist nicht, technische Implementierungsdetails zu diktieren, sondern sich über das „Was“ und das „Warum“ abzustimmen. Sie verfeinern die Anforderungen, bis beide Parteien zufrieden sind. Erst wenn der Engineer die Story explizit als „Ready for Development“ markiert, übernimmt der Agent.
2. Das Managerial Review (Nach der Arbeit) Sobald der Agent die Planung, Programmierung und das Testing abgeschlossen hat, präsentiert er die Arbeit für ein Produktions-Review. Der Engineer validiert das Ergebnis genau so, wie ein guter Manager die Arbeit eines Untergebenen überprüfen würde:
- Sie inspizieren den finalen Code und die Funktionalität.
- Sie überprüfen den Arbeitsnachweis – prüfen die Planungslogs, Testergebnisse und Logikpfade, die der Agent genommen hat.
- Sie geben Feedback via Code-Review.
Wenn der Engineer ein Problem oder einen besseren Ansatz entdeckt, hinterlässt er Feedback. Der Agent nimmt dieses Feedback, um den unmittelbaren Code zu beheben, und generiert entscheidenderweise eine Self-Improvement-Story, um seine eigenen Anweisungen zu aktualisieren, damit dasselbe Feedback beim nächsten Mal nicht mehr benötigt wird.
Diese konsolidierte Verantwortlichkeit ermöglicht Geschwindigkeit bei gleichzeitiger Aufrechterhaltung der Qualität. Verantwortung wird nicht über mehrere Teams verteilt; sie ist bei einem Engineer konzentriert, der die Arbeit ganzheitlich validiert.
Den alten Prozess beenden
Unser CEO Orlin Radev beschreibt es deutlich: „Wir haben nicht einfach KI-Tools an den Rändern hinzugefügt. Wir haben unseren Entwicklungsprozess zerstört und mit KI im Kern neu aufgebaut.“
Lesen Sie Orlins vollständige Perspektive darauf, was das für CPOs bedeutet, in Wie AMPECO KI-nativ wurde.
Wir haben traditionelle Grooming-Sessions abgeschafft, bei denen ein Engineering-Team und der Product Manager alle Stories einer Iteration diskutierten. Stattdessen haben wir fokussierte Alignment Syncs, bei denen Menschen (ein Engineer und ein Product Owner) die Absicht definieren und KI die technische Analyse übernimmt. Wir haben Iterations-Demos eingestellt, weil tägliches Shipping zweiwöchentliche Showcases obsolet machte. Wir sind von wöchentlichen Sprints zu kontinuierlichen täglichen Releases übergegangen.
Und die Ergebnisse beweisen, dass es sich gelohnt hat: 4x schnellere Velocity mit 50% weniger Bugs pro Story. Wir haben Qualität nicht gegen Geschwindigkeit getauscht, stattdessen haben wir ein System aufgebaut, in dem sich beide gemeinsam verbessern. Wir haben das erreicht, indem wir MEHR Qualitätschecks durchgesetzt haben, nicht weniger. Die Testabdeckung stieg, während die Bereitstellung beschleunigte.
Die strategische Verschiebung: Velocity als Wettbewerbsvorteil
Für einen CTO ist der „Geschwindigkeit vs. Zuverlässigkeit“-Trade-off oft die größte Bremse für die Organisation. Wenn Entwicklungszyklen langsam sind, akkumuliert sich Technical Debt, weil Teams es sich nicht leisten können zu refactorn und gleichzeitig Liefertermine einzuhalten. Wenn die Zuverlässigkeit niedrig ist, kannibalisiert die „Wartungssteuer“ – das Handhaben von Produktionsvorfällen und Bugs – die Roadmap.
Durch den Wechsel zu einem KI-nativen System haben wir die Organisation von einer defensiven zu einer offensiven Haltung verlagert.
Wenn Bug-Raten durch automatisierte Durchsetzung um 50% sinken, hört das Engineering-Team auf, ein Kostenzentrum für Fixes zu sein, und wird zu einer Fabrik für Innovation. 4x schnellere Entwicklungszyklen bedeuten nicht nur „mehr Features“ – es bedeutet, dass die Kosten für Experimente drastisch gesunken sind. Wir können jetzt komplexe regulatorische Updates oder Custom-Reporting-Anforderungen in Stunden integrieren und auf Marktdruck reagieren, der ein traditionelles Team wochenlang lahmgelegt hätte.
Die sich selbst verbessernde Engine
Dieses System schafft einen sich verstärkenden Vorteil, den traditionelle Prozesse nicht erreichen können. In einer Standard-Engineering-Organisation ist Wissen isoliert. Wenn ein Senior Developer eine Lektion lernt, bleibt sie möglicherweise in seinem Kopf oder landet bestenfalls in einem Wiki.
In einem KI-nativen System wird jede Lektion kodifiziert. Jedes Mal, wenn ein Agent eine Self-Improvement-Story basierend auf menschlichem Feedback generiert, wird dieses Wissen permanent in die Infrastruktur eingebettet. Die Baseline-Qualität der gesamten Abteilung steigt mit jeder einzelnen Aufgabe.
Wie Orlin es ausdrückt: „Wenn wir damit begonnen hätten, zuerst KI-Features für Kunden zu bauen, hätten wir das Problem von heute gelöst. Indem wir den Kern neu aufgebaut haben, haben wir das Problem von morgen gelöst.“
Nach innen bauen, um nach außen zu gehen
That’s already the correct German translation. It means „Building inward to move outward.“
Did you want me to verify it or provide an alternative translation?
Da unsere Agenten an unserem eigenen geschäftskritischen Produktionscode kampferprobt sind, haben wir eine klare Blaupause für die Erweiterung von KI-Fähigkeiten stromaufwärts – in Customer Success, Operations und Produktautomatisierung. Das werden keine spekulativen Features sein; sie werden Erweiterungen einer Architektur sein, die bereits unseren Kern antreibt.
Vor sechs Monaten haben wir uns vorgenommen zu beweisen, dass sich Geschwindigkeit und Zuverlässigkeit gegenseitig verstärken können. Die Daten beweisen, dass es möglich ist. Die Lücke zwischen KI-nativem Engineering und traditioneller Entwicklung beginnt sich gerade erst zu öffnen, aber sie wird definieren, wer im nächsten Jahrzehnt der Softwareentwicklung führt.
