Was wir gebaut haben – und warum es funktioniert hat

Als wir CHERRISK für UNIQA starteten, war das Briefing wirklich greenfield: keine Legacy-Einschränkungen, ein Team, das es richtig machen wollte, und ein Unternehmen, das eine vollständig online-basierte Versicherungsplattform für mehrere Märkte launchen musste. Wir entschieden uns für Scala / Play, eine ereignisgesteuerte CQRS-Architektur, Kafka für Event-Streaming, GraphQL / Sangria für die API-Schicht und GitLab CI/CD mit Docker Swarm für das Deployment.

Dieser Stack hat gehalten. Die Plattform startete, skalierte, bewältigte echte Produktionslast und unterstützte Aktuarsarbeit und BI durch ihre ElasticSearch-Event-Sourced-Datenschicht. Die Entscheidungen waren fundiert — und die meisten davon würden wir heute wieder treffen.

Was sich seitdem verändert hat: KI im Engineering-Workflow

Die größte Einzelveränderung zwischen damals und heute ist nicht ein Framework oder ein Cloud-Anbieter — es ist die Etablierung von KI-Coding-Assistenten als alltägliches Engineering-Werkzeug. Seit Ende 2022 haben wir ChatGPT, Claude, Cursor und verwandte Tools progressiv in jede Lieferphase integriert. Das Produktivitätsdelta ist nicht marginal; bei bestimmten Arbeitsklassen — Boilerplate, Test-Scaffolding, Dokumentation, Datentransformationslogik — misst es sich in Stunden, die täglich pro Entwickler eingespart werden.

Bei einem Projekt im Maßstab von CHERRISK ist das enorm wichtig.

Was wir heute anders machen würden

1. Schlankeres Initialteam, schnellere Hochlaufkurve

Ein erheblicher Teil des Aufwands in der Frühphase großer Greenfield-Projekte entfällt auf Setup: Projekt-Scaffolding, CI/CD-Konfiguration, Umgebungsstandardisierung, das Schreiben der ersten 80% der Boilerplate-Service-Schicht. Mit KI-unterstützter Entwicklung können heute zwei Senior-Ingenieure im gleichen Zeitraum das produzieren, was früher vier oder fünf erforderte. Wir würden schlanker starten, das Core-Domain-Modell schneller validieren und das Team erst skalieren, wenn die Architektur in der Produktion bewiesen ist.

2. KI-generierte Testabdeckung von Tag eins

Testabdeckung auf einem CQRS/Event-Sourced-System ist nicht trivial — das Schreiben realistischer Command-Fixtures, Event-Snapshots und Integrationsszenarien ist mühsame Arbeit, die historisch unter Lieferdruck deprioritisiert wurde. Heute würden wir KI verwenden, um kontinuierlich den ersten Pass von Test-Scaffolding zu generieren und die Abdeckung ehrlich zu halten, ohne die Feature-Auslieferung zu verlangsamen.

3. Engere Feedbackschleifen zwischen Domain-Experten und Code

Versicherungs-Domain-Regeln — Pricing, Eligibility, Produktlogik — übersetzen sich langsam in Code, wenn die gesamte Übersetzung durch Entwicklerköpfe fließen muss. Wir würden erkunden, KI einzusetzen, um Business-Analysten und Aktuaren zu helfen, strukturierte Logik zu produzieren, die direkt in die Codebasis einfließt.

4. Aggressiverer Einsatz von Managed Services für nicht-differenzierende Infrastruktur

Wir betrieben unser eigenes Kafka, verwalteten eigenen Ceph-Objektspeicher, betrieben eigenen Docker Swarm. In 2026 existiert für die meisten dieser Komponenten ein managed Cloud-Äquivalent. Wir würden weniger Zeit für Infrastruktur-Operationen aufwenden und mehr für Produktauslieferung.

Was wir exakt gleich lassen würden

• Die ereignisgesteuerte CQRS-Architektur. Für eine Domain, die ein Audit-Trail erfordert, aktuarielle Wiederherstellung unterstützt und Produktregeln ohne Downtime weiterentwickeln muss, ist dies nach wie vor die richtige Wahl.
• Scala / Play für das Core-Backend. Das Typsystem verhindert ganze Fehlerklassen. Die Performance ist exzellent. KI-Tools sind überraschend gut bei der Scala-Codegenerierung geworden.
• GitLab CI/CD mit Multi-Environment-Pipelines und Quality Gates. Automatisierte, auditierbare Auslieferung war einer der größten Erfolge des Projekts. Daran würden wir keine Kompromisse eingehen.

Das Fazit für ähnliche Projekte heute

Wenn Sie jetzt ein ähnliches Projekt starten — eine komplexe, hochkorrekte Domain, die Event-Sourced-Daten und Multi-Markt-Skalierbarkeit erfordert — bleibt die fundamentale Architektur gültig. Der Unterschied liegt in der Geschwindigkeit und Teamgröße, die zur Ausführung benötigt werden. Ein kleineres, KI-augmentiertes Senior-Team kann heute liefern, was früher ein größeres Team über eine längere Laufzeit erforderte.

Wenn das für Ihr Projekt relevant klingt, sprechen wir miteinander.