eSimphony wird von einem fünfköpfigen Engineering-Team gebaut. Das Produkt deckt über 150 Länder ab, liefert native iOS- und Android-Apps, betreibt einen Stack für Netzanbindungen über mehrere Regionen, unterstützt fünf Sprachen von vorn bis hinten und bringt wöchentlich Produktänderungen heraus. Wir sind kein Telko mit tausend Leuten. Wir sind ein kleines Team, das bewusst mit Hebelwirkung arbeitet.

Diese Hebelwirkung kommt aus einer bestimmten Herangehensweise ans Engineering, die wir uns in den letzten 18 Monaten angeeignet haben. Wir nennen sie KI-native Entwicklung. So sieht sie in der Praxis aus.

Der Zuschnitt des Teams

Fünf Engineers. Ein Produktdesigner. Ein CEO, der immer noch einen Teil der Produktspezifikationen schreibt. Kein formaler Product Manager — Specs entstehen aus CEO plus Moza-gestütztem Entwurf plus Engineering-Urteil. Kein eigenes QA-Team — Testen ist Teil der Bauschleife. Kein separates DevOps — für die Infrastruktur ist verantwortlich, wer das Feature ausliefert.

Das ist keine Angeberei, sondern eine Randbedingung. Bei dieser Teamgröße lässt sich ein Produkt vom Umfang eSimphonys nur ausliefern, wenn der Output jedes Engineers vervielfacht wird. KI ist der Multiplikator, auf den wir gesetzt haben.

Der Workflow in fünf Stufen

Jede Änderung bei eSimphony — vom Textfix bis zur neuen Netzanbindung — durchläuft dieselben fünf Stufen. Jede Stufe ist KI-gestützt; in jeder Stufe sitzt ein Mensch in der Schleife.

1. Erkunden (keine technischen Hürden)

Wenn eine neue Anforderung eintrifft („wir brauchen die Anbindung von Anbieter X für Ägypten-Abdeckung“), ist der erste Schritt des Engineers nicht, Annahmen über Unbekanntes zu treffen. Er nutzt KI, um unbekanntes Terrain in 20 Minuten statt in 2 Tagen zu erkunden.

Konkret: Ein Engineer, der noch nie einen ägyptischen MVNO angebunden hat, kann einem KI-Assistenten die API-Dokumentation des Anbieters geben, eine strukturierte Zusammenfassung der Integrationsfläche bekommen, Rückfragen zu Sonderfällen stellen („wie sieht der typische eKYC-Ablauf in diesem Markt aus?“) und noch vor dem Mittagessen eine einseitige Einschätzung zu Aufwand, Risiken und offenen Fragen liefern.

Was sich ändert: Der Engpass ist nicht mehr „haben wir jemanden, der sich in dieser Domäne auskennt?“, sondern „kann die Person, die wir haben, mit KI-Unterstützung in ein paar Stunden kompetent genug in dieser Domäne werden?“. Fast immer lautet die Antwort ja.

2. Spezifizieren (Stunden statt Wochen)

In den meisten Unternehmen dauert eine Produktspezifikation 1 bis 3 Wochen: Ein PM schreibt einen Entwurf, Stakeholder prüfen, Sonderfälle kommen dazu, Abnahmekriterien werden verfeinert, dann schneidet Engineering neu zu. Bis eine Spec „fertig“ ist, hat sich die ursprüngliche Gelegenheit verschoben.

Unser Weg: Der Engineer (oder je nach Feature der CEO) skizziert eine Produktidee in einem Satz. Die KI baut daraus ein strukturiertes PRD — User Flow, Sonderfälle, Erfolgskennzahlen, Abnahmekriterien, offene Fragen. Das Team verfeinert es in einer 45-minütigen Arbeitssitzung. Die Spec geht am selben Tag ins Engineering.

Der Kompromiss: Specs aus diesem Prozess sind etwas rauer als eine klassische, zweiwöchige PM-Spec. Das nehmen wir in Kauf. Die Zeitersparnis bis zur ersten Implementierung ist die zusätzliche Unschärfe wert, die dann während des Bauens statt davor aufgelöst wird.

3. Designen (schnelle Feedbackschleife)

Bei Features mit viel Oberfläche arbeitet unser Designer mit dem Engineer in einer Schleife aus Design, Bauen und Feedback, gemessen in Minuten statt Tagen. KI-generierte Mockups (Figma-Plugins plus Bildgeneratoren) erkunden Varianten in kurzer Zeit. Der Engineer liefert in wenigen Stunden einen Prototyp. Der Designer prüft ihn auf echter Hardware. Iterationen laufen im Tagesrhythmus.

Das Ergebnis: Design und Engineering laufen nicht nacheinander, sondern parallel. Wenn das Design „final“ ist, ist die Implementierung schon fast produktionsreif.

4. Bauen (die KI schreibt den Code; Menschen prüfen jeden Diff)

Das ist der sichtbarste KI-native Teil. So läuft der Engineering-Prozess bei eSimphony heute:

Die KI erzeugt rund 90 % des neuen Codes (Cursor, Claude, GitHub Copilot, oft in Kombination)
Die Engineers schreiben die Architekturentscheidungen, die Integrationsgrenzen und die kniffligen Geschäftslogiken, für die tiefes Systemwissen nötig ist
100 % des Codes wird vor dem Merge von Menschen geprüft. Jeder Diff. Jeder PR. Ohne Ausnahme.

Der letzte Punkt ist entscheidend und wird oft missverstanden. „Die KI schreibt den Code“ heißt nicht „kein Mensch schaut sich den Code an“. Es heißt, dass sich die Rolle des Engineers vom Tippen der Implementierung zum Prüfen der Implementierung verschiebt. Die geistige Arbeit — passt das zur Spec, deckt es die Sonderfälle ab, fügt es sich in die Architektur, skaliert es — bleibt beim Engineer. Die mechanische Arbeit — Absicht in syntaktisch korrekten, idiomatischen Code übersetzen — wird delegiert.

Ein typischer PR bei eSimphony hat:

200 bis 800 geänderte Codezeilen (gegenüber klassisch rund 100 bis 200 in Teams von 2024)
1 Engineer, der ihn im Detail prüft
häufig KI-generierte Unit-Tests mit über 80 % Abdeckung auf neuem Code
Reviewer-Kommentare, die sich auf Architektur konzentrieren, nicht auf Syntax

5. Ausliefern (in Minuten nachsteuern)

Ausgeliefert wird schrittweise: Feature-Flags für riskante Änderungen, Canary-Deployments für Backend-Dienste, KI-überwachte Telemetrie, die Anomalien binnen Minuten nach dem Rollout sichtbar macht. Wenn ein Release etwas kaputt macht, misst sich der Rollback in Minuten, nicht in Stunden.

Zur „KI-überwachten Telemetrie“ ein Satz: Nach dem Deploy achtet ein KI-Agent auf Anomalien bei Fehlerraten, Latenz, gemeldeten Problemen und Conversion. Überschreiten Anomalien eine Schwelle, wird die Bereitschaft mit einer Zusammenfassung der wahrscheinlichen Ursachen alarmiert. Das verkürzt die Zeit bis zur Entdeckung von „Nutzer meldet um 9 Uhr einen Bug“ auf „Alarm um 09:03“.

Die Zahlen

Ungefähre Kennzahlen der letzten 12 Monate:

Sprintlänge: 1 Woche. Neue Features gehen wöchentlich live; kleine Fixes täglich.
5 Engineers arbeiten in Vollzeit am Produkt. Ein weiterer Engineer arbeitet in Teilzeit auf Vertragsbasis mit.
Über 90 % des neuen Codes ist KI-generiert (vor allem Cursor plus Claude).
100 % des gemergten Codes wurde von Menschen geprüft.
Median von der Feature-Spec bis in Produktion: 5 bis 10 Tage.
Produktionsvorfälle pro Quartal: 1 bis 2. Unter dem Branchendurchschnitt für unseren Umfang.
An Engineering eskalierte Supporttickets: rund 5 pro Woche. Die meisten sind noch am selben Tag gelöst.

Diese Zahlen sind nicht theoretisch. Sie sind das tatsächliche Arbeitstempo unseres Teams.

Was das nicht ist

Es lohnt sich, explizit zu sagen, was KI-native Entwicklung bei eSimphony nicht bedeutet.

Es ist kein „Vibe Coding“. Code wird Zeile für Zeile geprüft. Architekturentscheidungen treffen Menschen. Die KI beschleunigt das Tippen, nicht das Denken.

Es heißt nicht „kein Testen“. KI-generierte Tests haben typische Schwächen (sie prüfen glückliche Pfade gründlicher als Sonderfälle), also schreiben die Engineers Tests für die Ränder von Hand. Die Testabdeckung auf neuem Code liegt durchgängig über 80 %.

Es heißt nicht „keine Senior-Engineers nötig“. Im Gegenteil. KI steigert den Wert von Senior-Urteilskraft drastisch, weil erfahrene Engineers KI-Output 5- bis 10-mal schneller prüfen und schärfen können, als sie ihn von Grund auf schreiben würden. Junior-Engineers, die KI ohne Senior-Review nutzen, produzieren meist Code, der kompiliert, aber strukturell brüchig ist.

Es heißt nicht „kein Design- oder Produktdenken“. KI ist ohne klare Spezifikationen und durchdachte Nutzerflüsse nutzlos. Die geistige Arbeit — was bauen wir, warum, für wen — bleibt beim Menschen.

Was es voraussetzt

Drei Dinge, nach Wichtigkeit geordnet.

1. Strenges menschliches Review

Jede Zeile KI-generierten Codes geht vor dem Merge durch das Review eines Senior-Engineers. Die Versuchung, das Review bei „offensichtlich korrekten“ Kleinigkeiten zu überspringen, ist real und gefährlich. Wir halten die 100-Prozent-Linie.

2. Enge architektonische Leitplanken

Wenn KI Code erzeugt, folgt sie den lokalen Konventionen. Starke Konventionen = starker KI-Output. Wir haben viel in klare Modulgrenzen, konsistente Benennung, gut typisierte Schnittstellen und explizite Dokumentation zu „so machen wir das hier“ investiert, damit die KI sauber Muster erkennen kann.

3. Kulturelle Akzeptanz von KI als Standard

Das Team hat sich ausdrücklich darauf verständigt, dass KI-Unterstützung in jedem Workflow der Standard ist. Neue Engineers werden in diesen Standard eingearbeitet. Widerspruch („ich schreibe es lieber selbst“) wird gehört und diskutiert, aber die Teamnorm lautet: Die KI übernimmt die mechanische Arbeit, solange kein konkreter Grund dagegen spricht.

Wofür wir KI nicht einsetzen

Für das Review von KI-generiertem Code (wir wollen frische menschliche Augen)
Für die Entscheidung, was wir bauen (Produktstrategie ist menschlich)
Für direkte Eskalationen im Kundensupport (die harten Fälle übernehmen Menschen)
Für Leistungsbeurteilungen und Team-Feedback (ausschließlich menschlich)
Für Einstellungsentscheidungen (ausschließlich menschlich, mit KI-Unterstützung bei Sourcing und Vorauswahl)

Das Muster: KI verstärkt die Ausführung; Menschen treffen die Entscheidungen.

Warum das fürs Produkt zählt

Das Ergebnis dieses Workflows ist im Produkt sichtbar. Wir haben ausgeliefert:

die Architektur der lebenslangen eSIM (in den meisten Unternehmen ein Projekt über mehrere Quartale)
Moza, die KI-Reisebegleiterin, in fünf Sprachen
KI-gestützte dynamische Tarife in drei Regionen
KI-Fehlerbehebung mit Selbstheilung
native iOS- und Android-Apps mit wöchentlichen Releases
ein Multi-Region-Backend mit über 99,9 % Verfügbarkeit
Lokalisierung in fünf Sprachen über die gesamte Produktoberfläche

Für diese Liste braucht es normalerweise 30 bis 50 Engineers und mehr als 3 Jahre. Wir haben sie mit 5 Engineers in 18 Monaten geliefert.

Eine Anmerkung zum Recruiting

Wir lassen das Team bewusst langsam wachsen. Die Engineers, die hier gut zurechtkommen, teilen drei Eigenschaften:

Urteilskraft vor Output. Die KI übernimmt das Tippen; wir suchen Leute, die im Prüfen, Entscheiden und Formen stark sind.
Umgang mit KI als Kollegin. Engineers, die KI als Mitarbeitende behandeln (delegieren, prüfen, widersprechen) statt als magisches Orakel oder als Bedrohung ihrer Identität.
Interesse am Nutzer. KI-native Workflows sind schnell genug, um viel Code zu erzeugen, der kompiliert, aber nichts bewirkt. Am besten arbeiten die Engineers, die jeden PR an der Frage „hilft das dem Nutzer?“ verankern.

Wenn das auf Sie zutrifft: Wir stellen ein. Melden Sie sich über die Karriereseite oder schreiben Sie Trung direkt an.

Was als Nächstes kommt

Derselbe Workflow, der das heutige Produkt gebaut hat, liefert auch die Roadmap:

Verwaltung mehrerer eSIMs (Mai 2026)
Familientarife (Juni 2026)
Treue und Prämien (August 2026)
Weltweite Direktanbindung an Netzbetreiber (2027)

Jedes dieser Vorhaben ist bei einem klassischen Telko ein Projekt über mehrere Monate. Nach unseren internen Schätzungen kommen alle vier planmäßig — mit demselben fünfköpfigen Team.

Das ist der Hebel. Das ist die Wette. So liefert ein kleines Team gegen die Trägheit einer ganzen Branche an.

Sehen Sie eSimphony in Aktion, lesen Sie über unsere Positionierung oder sehen Sie sich unser Pitch Deck von der MVNO Nation Americas an.

Wie ein Fünf-Personen-Team 10× liefert: KI-natives Engineering bei eSimphony