Klarent erhält 8 Mio. Dollar – KI schreibt Tests, führt sie aber nicht aus

Das Zürcher Start-up Klarent hat am 9. Oktober 2026 eine Seed-Runde über 8 Millionen US-Dollar bekannt gegeben; Mosaic Ventures führte sie an, Moonfire Ventures beteiligte sich, und Mosaic-Partner Chandar Lal beschrieb das technische Prinzip mit „using AI to write tests, not to run them“. Die Finanzierung soll vor allem den Eintritt in den US-Markt ermöglichen.

Die Meldung von EU-Startups beziffert dieselbe Seed-Runde auf 7,13 Millionen Euro, nennt Jürgen Galler, Harris Barton und AngelInvest Ventures als weitere Geldgeber und führt JD Sports, NZZ und Sixt als Kunden auf. Die Euro-Angabe beschreibt dieselbe Finanzierung in einer anderen Währung, keine weitere Runde. Klarents Produkt nutzt Sprachmodelle zum Schreiben und Anpassen von Testcode; der fertige Code wird nach festen Abläufen ausgeführt.

Wofür Klarent das Kapital einsetzen will

Klarent wurde von den ehemaligen Google-Ingenieuren Asheem Panakkat und Momchil Ivanov gegründet. Panakkat ist Geschäftsführer, Ivanov Technikchef. Zunächst beschäftigten sie sich mit Verfahren zur Bewertung großer Sprachmodelle; daraus entstand der Fokus auf die Prüfung von Software, deren Entwicklung durch KI beschleunigt wird. Das Produkt soll auch zusammenhängende Abläufe über mehrere Systeme hinweg prüfen.

Der US-Markteintritt ist der Schwerpunkt der Runde. Dazu sollen vor allem der Vertrieb und die Präsenz vor Ort wachsen; zugleich will Klarent zusätzliche Ingenieure einstellen und Tests für Webanwendungen und mobile Apps ausbauen. Das sind angekündigte Verwendungen des Kapitals, keine abgeschlossenen Expansionsschritte. Eine Finanzierungsrunde ermöglicht diese Investitionen, belegt aber weder einen bestimmten Umsatz noch eine bestimmte Marktdurchdringung.

Die bisher genannten Kunden sitzen in unterschiedlichen Branchen: JD Sports im Handel, die NZZ im Mediengeschäft und Sixt in der Mobilität. Diese Ausgangsbasis sagt wenig darüber aus, wie viele Anwendungen oder Testfälle jeder Kunde tatsächlich über die Plattform laufen lässt. Für die Geschäftsidee ist deshalb die technische Konstruktion wichtig: Wiederholte Testläufe sollen ohne neue Entscheidungen eines Sprachmodells während der Ausführung funktionieren.

Warum das Modell schreibt und der Testcode läuft

Sprachmodelle entwerfen Testcode und passen ihn bei Änderungen an. Anschließend wird der erzeugte Code ausgeführt, ohne dass das Modell während jedes Testlaufs die nächste Aktion auswählen muss. Die Modellentscheidung liegt damit vor der Ausführung beziehungsweise bei der Überarbeitung des Tests. Für diese Aufgabenteilung steht der Begriff „deterministische Autonomie“.

Deterministisch beschreibt hier den Ablauf des fertig erzeugten Tests: Bei denselben Eingaben und derselben Umgebung werden dieselben Anweisungen wiederholt. Das bedeutet nicht, dass jeder Lauf erfolgreich endet. Eine geänderte Anwendung, andere Testdaten oder ein fehlerhafter Dienst können weiterhin zu einem anderen Ergebnis führen. Ein reproduzierbarer Ablauf macht aber klarer, an welcher Stelle eine Prüfung scheitert und ob eine Korrektur unter vergleichbaren Bedingungen wirkt.

Die Trennung begrenzt zudem die Zahl der Modellaufrufe während wiederholter Läufe. Ein einmal erzeugter Testcode kann erneut verwendet werden; das Modell muss wieder eingreifen, wenn ein Test neu geschrieben oder repariert werden soll. Daraus ergibt sich ein plausibler Kostenvorteil gegenüber Verfahren mit Modellaufrufen bei jeder Ausführung. Wie groß er unter realen Bedingungen ausfällt, hängt davon ab, wie oft sich Anwendungen ändern und wie aufwendig ihre Tests angepasst werden müssen.

Zum Angebot gehört außerdem eine menschliche Kontrollstufe für Resultate. Die Abrechnung soll an verifizierte Ergebnisse geknüpft sein. Damit bleibt die Qualitätssicherung nicht allein beim erzeugten Code: Auffällige Ergebnisse müssen auch eingeordnet werden. Diese Prüfung verursacht ebenfalls Arbeit. Ob das Gesamtverfahren bei großem Umfang günstiger ist als andere Testdienste, lässt sich aus der beschriebenen Architektur allein nicht bestimmen.

Was die Kundenbeispiele über die Nutzung zeigen

Bei JD Sports reicht der beschriebene Testweg von einer Bestellung auf der Website über die Bestellverwaltung bis zu den Liefersystemen. Solche Abläufe sind für Unternehmen anspruchsvoll, weil ein Fehler an einer Übergabe zwischen Systemen sichtbar werden kann, obwohl die einzelnen Oberflächen funktionieren. Das Beispiel erklärt den Produktnutzen konkreter als ein bloßer Hinweis auf automatisierte Tests: Geprüft wird eine zusammenhängende Kundenhandlung über mehrere Anwendungen hinweg.

Im Bericht von Tech Funding News ist von ungefähr 3.500 Tests pro Tag bei einem Kunden und 25 Beschäftigten bei Klarent die Rede. Die Testzahl beschreibt das Volumen bei einem Kunden, keine unabhängig ermittelte Fehlerquote oder Zeitersparnis. Auch aus den Kundennamen geht nicht hervor, ob alle denselben Funktionsumfang einsetzen. Die Angabe zeigt jedoch, dass bei einem Kunden Tests in erheblichem Umfang laufend ausgeführt werden.

Für den geplanten Ausbau in den USA wird entscheidend, ob Klarent solche Testläufe über viele Anwendungen hinweg stabil pflegen kann. Die Ausführung ist festgelegt; Testcode muss trotzdem mit geänderten Anwendungen Schritt halten, und die menschliche Prüfung muss bei größerem Volumen funktionieren. Angaben zu Fehlererkennung, Pflegeaufwand und Kosten über mehrere Kunden hinweg wären der nächste konkrete Maßstab dafür, wie weit sich das Verfahren über die genannten Beispiele hinaus trägt.

Lesen Sie auch:

• 10 Millionen Dollar für Ringg AI – Sprachagenten wechseln ins Kerngeschäft
• Deepslate erhält 7,7 Mio. Euro – Sprach-KI umgeht den Text
• ChatGPT und Claude fielen zugleich aus – ein zweiter Anbieter genügt nicht