Wie wir KI-geschriebenen Code prüfen

„Wir entwickeln mit KI“ kann zwei sehr unterschiedliche Dinge bedeuten. Es kann heißen, dass Code, den niemand wirklich gelesen hat, etwas schneller in Produktion geht. Oder es heißt, dass die KI den Großteil des Schreibens übernimmt, während Review, Tests und Verantwortung dort bleiben, wo sie immer waren — bei erfahrenen Engineers.

Wir machen das Zweite. Dieser Artikel zeigt, wie das in einem echten Projekt aussieht: zwei native Apps, eine in Swift für iOS und eine in Kotlin für Android, bei denen KI-Agenten einen großen Teil der Arbeit erledigen und trotzdem jede Änderung über einen Senior-Engineer läuft, bevor sie ausgeliefert wird. Kunde und Projekt können wir nicht nennen, die Pipeline aber zeigen.

Ausgangslage: zwei native Apps, ein Verhalten

Der Kunde braucht zwei native Apps, die sich gleich verhalten. Jede Funktion zweimal von Hand zu schreiben, ist langsam, und die beiden Versionen driften auseinander: eine Validierungsregel, die es auf iOS gibt, auf Android aber nicht, ein Grenzfall, der nur auf einer Plattform behandelt wird.

Deshalb teilen wir die Arbeit danach auf, was jeder Beteiligte am besten kann:

Ein Entwickler baut die Funktion auf iOS, KI-gestützt.
Ein Agent portiert sie nach nativem Android, eins zu eins.
Ein zweiter Agent prüft die Portierung.
Beide Apps werden nebeneinander getestet.
Ein Senior-Engineer prüft und testet zum Schluss — und verantwortet das Release.

Schritt 1 — iOS: ein Entwickler mit KI und ein normaler Pull Request

Jede Funktion beginnt auf iOS. Der Entwickler arbeitet mit Claude Code: Die KI entwirft Implementierung und Tests, der Entwickler steuert, korrigiert und testet auf einem echten iPhone. Das Ergebnis geht durch einen normalen Pull Request mit verpflichtenden Tests in der CI und einem Senior-Review vor dem Merge.

Diese gemergte iOS-Änderung ist das wichtigste Artefakt der ganzen Pipeline. Sie ist keine „Beschreibung einer Funktion“ mehr, sondern eine funktionierende, geprüfte und getestete Implementierung — und wird zur Spezifikation für Android.

Schritt 2 — Android: ein Agent portiert die gemergte Änderung 1:1

Sobald der iOS-Pull-Request gemergt ist, starten wir über unser internes Agent-Harness einen Agenten. Seine Aufgabe ist eng und klar definiert: dieselbe Änderung eins zu eins in der nativen Android-App umsetzen — dieselben Screens, dieselben Zustände, dieselbe Validierung, dieselbe Fehlerbehandlung, dieselben Grenzfälle.

„Eins zu eins“ heißt nicht, Swift Zeile für Zeile in Kotlin zu übersetzen. Das Verhalten muss gleich sein, der Code muss idiomatisches Android sein. Lifecycle, Berechtigungen, Hintergrundarbeit und Navigation folgen den Regeln von Android, nicht denen von iOS. Genau bei so einer engen, gut spezifizierten Aufgabe sind Agenten stark: Die Spezifikation ist vollständig, geprüft und ausführbar.

Schritt 3 — ein zweiter Agent prüft die Portierung

Der portierende Agent prüft seine Arbeit nicht selbst. Ein separater Review-Agent mit frischem Kontext und anderer Anweisung — finde, was falsch ist — liest die Android-Änderung gegen das iOS-Original. Er sucht nach den Problemen, die eine Portierung typischerweise mitbringt:

Verhalten, das stillschweigend abweicht — ein Grenzfall, der auf iOS behandelt wird, auf Android aber fehlt, ein anderer Standardwert, ein fehlender Fehlerzustand.
Plattform-Idiome, die bei der Übersetzung verloren gehen — iOS-Muster, die Android aufgezwungen werden, wo Lifecycle, Threading oder Berechtigungsmodell anders funktionieren.
Tests, die bestehen, ohne etwas zu prüfen — Assertions, die immer wahr sind, Mocks, die den Test sinnlos machen.
Abkürzungen bei Sicherheit und Daten — sensible Daten im Log, gelockerte Validierung, unsicherere Speicherung als auf iOS.

Die Befunde fließen in die Änderung zurück, bevor ein Mensch Zeit darauf verwendet.

Schritt 4 — beide Apps nebeneinander testen

Dann werden beide Apps parallel und vergleichend getestet: Dieselben Szenarien laufen auf der iOS- und der Android-App, die Ergebnisse werden verglichen. Die Frage ist nicht nur „Funktioniert Android?“, sondern „Verhält sich Android genau wie iOS?“. Getestet wird auf echten iPhones und Android-Geräten, über TestFlight- und Google-Play-Internal-Testing-Builds, nicht nur im Simulator.

Schritt 5 — der Senior-Engineer, zum Schluss

Nichts erreicht die Nutzer, bevor ein Senior-Engineer es geprüft und getestet hat. Egal, wer — oder was — den Code geschrieben hat, der Senior prüft jedes Mal dasselbe:

Architektur und Design — passt die Änderung zur Architektur der App, oder fügt sie Komplexität hinzu, die später teuer wird?
Sicherheit und Daten — Authentifizierung, Berechtigungen, sensible Daten, nicht vertrauenswürdige Eingaben.
Echte Tests — prüfen die Tests das Verhalten, auf das es ankommt, oder bestehen sie nur?
Auf dem Gerät — funktioniert es tatsächlich in der App, auf einem echten Telefon?

Die Agenten beschleunigen das Senior-Review, weil viel Rauschen schon weg ist. Sie ersetzen es nicht. Der Senior sagt „das geht raus“ — und steht dafür ein.

Was wir gelernt haben

Eine geprüfte Implementierung ist der beste Prompt. Von einer gemergten, getesteten iOS-Änderung aus zu portieren, funktioniert weit besser, als nach einer schriftlichen Beschreibung zu implementieren.
Agenten sollen Agenten prüfen — mit anderem Auftrag. Der Agent, der den Code geschrieben hat, ist sein schlechtester Reviewer. Ein zweiter Agent, der Probleme suchen soll, findet eine andere Klasse von Fehlern.
Vergleichen statt nur testen. Bei zwei nativen Apps ist „beide bestehen ihre Tests“ schwächer als „beide verhalten sich in denselben Szenarien gleich“.
Am Ende immer ein Mensch. KI ändert, wer den Code tippt. Sie ändert nicht, wer dafür verantwortlich ist.

Sie möchten so entwickeln — mit KI-Tempo und Senior-Verantwortung? So gehen wir KI-Produktentwicklung an, oder lesen Sie, wie wir Claude-Agenten für ein Bauunternehmen gebaut haben.