Instagram Direct baute seine Android-UI auf Jetpack Compose in Richtung einer KI-nativen Architektur um

Instagram Direct ist eine der wichtigsten Oberflächen von Instagram: Über sie laufen täglich Milliarden von Nachrichten. Viele Jahre lang presste das Team Mikrooptimierungen aus dem veralteten Android-View-System heraus, bis es an eine Grenze stieß: Eine stark optimierte, aber veraltete Oberfläche zu pflegen und zu erweitern wurde immer teurer – der technische Schuldenberg und der Engineering-Aufwand wuchsen, zumal deklarative UI und KI-Helfer beim Schreiben von Code zur Norm geworden waren. Statt die Einführung von Compose als bloße weitere UI-Modernisierung zu behandeln, setzte sich Meta ein ehrgeizigeres Ziel: die Codebasis und ihre Architektur so neu zu gestalten, dass sie von Grund auf auf KI ausgerichtet ist – und damit die Wirkung von KI um ein Vielfaches zu verstärken im Vergleich zu dem, was eine bloße Nachrüstung des bestehenden Codes gebracht hätte.

Die Ergebnisse wurden präzise gemessen. Jetpack Compose ermöglichte es Instagram Direct, den Gesamtumfang des UI-Codes um 50 % zu reduzieren, die Aufgabenausführung durch KI-Agenten um 35 % zu beschleunigen, die Zahl der Austausche zwischen Ingenieur und Agent um 32 % zu senken und den Token-Verbrauch pro Agentensitzung um 33 % zu verringern. Eine zentrale Rolle spielt dabei die deklarative Natur von Compose: Der Code wird knapp, vorhersehbar und strukturell verständlicher für KI-Modelle – weniger Seiteneffekte, weniger impliziter Zustand, klarere Komponentengrenzen. Genau diese Eigenschaften ermöglichen es der KI, qualitativ bessere Ergebnisse zu liefern, und der geringere Umfang des generierten Codes schlägt sich unmittelbar in einem niedrigeren Token-Verbrauch pro Aufgabe nieder.

Das Team zog harte Lehren daraus, was passiert, wenn KI auf gemischten Code angesetzt wird. In einer Codebasis mit viel RecyclerView gibt es eine verlockende Abkürzung — Compose-Komponenten in die bestehende View-Hierarchie einzubetten. Als kurzfristiger Migrationsschritt ist das vertretbar, doch langfristig nehmen KI-Tools den Weg des geringsten Widerstands: Wenn deklarativer und imperativer Code vermischt sind, beginnt die KI, sie falsch zusammenzuführen, und erzeugt so subtile Bugs, technische Schulden und Leistungsregressionen. Konkrete Beispiele: Ein Feature-Flag wird im imperativen Code gelesen und dann innerhalb einer Compose-Lambda eingefangen; oder ein veränderliches Feld liegt auf der Item-Klasse statt in ihrem UI-State — und überlebt dadurch das Rebinding und Recycling von RecyclerView zwischen den Zeilen, was Bugs verursacht, die mühsam zu reproduzieren sind. Guardrails und Skills helfen, reichen aber nicht aus, weil die KI, sobald sie auf Widerstand stößt, Umgehungen findet.

Die Lösung ist ein Paar praktischer Regeln. Ein Listeneintrag darf seine eigene Abstraktion behalten, aber sämtlicher Compose-Code muss im Konstruktor als Content liegen, und die Konstruktorargumente sind die einzige Datenquelle — ohne Zugriff auf Klassenmitglieder oder veränderlichen Zustand. Damit wird das Element äquivalent zu einer normalen @Composable-Funktion, bleibt aber im Rahmen der bestehenden Architektur. Die Migration erfolgte schrittweise, mit zwei Schritten pro Screen: Zuerst wurden gemeinsame Muster und Randfälle identifiziert, dann systematisch angewendet, wobei ein Ingenieur Architektur und knifflige Stellen im Voraus festlegte, während die anderen die Produktionsreife sicherstellten. Mehrere Ingenieure ließen ihre eigenen KI-Agenten über eine gemeinsame Wissensbasis mit wiederverwendbaren Skills und Konventionen laufen, was Arbeitsabläufe und Best Practices im gesamten Team synchronisierte und das erneute Herausfinden bereits getroffener Entscheidungen überflüssig machte.

Das Ausmaß war enorm. Einzelne UI-Komponenten können in mehr als 160 verschiedenen Zustandskombinationen gerendert werden, und ein einzelner Chat-Screen verarbeitet über 200 verschiedene Nachrichtentypen. Das Team migrierte nach und nach mehrere hundert Listeneinträge innerhalb der bestehenden RecyclerView-Architektur auf Compose und rollte sie in kleinen unabhängigen Gruppen unter A/B-Tests aus — mit null sichtbarer Auswirkung auf das Nachrichtenerlebnis. Die Performance blieb das oberste Ziel: Metriken wurden zur Laufzeit in Produktion erfasst, sodass das Team A/B-Tests durchführen konnte, die die migrierte Compose-UI mit der veralteten verglichen.

Eine interne Analyse verglich KI-Agenten-Sitzungen, die an Compose-UI arbeiteten, mit denselben Aufgaben auf Android Views, wobei ein Risiko-Score verwendet wurde, der die Codequalität und die Wahrscheinlichkeit bewertet, dass eine Änderung einen Vorfall in Produktion verursacht. Wenn sich der kumulierte Risiko-Score einer Datei verdoppelt, reduzierten Android Views die Ressourceneffizienz des Agenten — also Tokenverbrauch, Ausführungszeit und Anzahl der Interaktionen zwischen Ingenieur und Agent — um 30 % pro eingebrachtem Zeichen, während die Compose-UI nur um 9 % sank. Der nächste natürliche Schritt: Das Team ersetzt den RecyclerView-basierten Kern durch LazyColumn und hält die Compose-Komponenten vom umgebenden Framework abstrahiert und zur Laufzeit über Feature-Flags umschaltbar, um A/B-Tests und einen ununterbrochenen Kompositionsbaum zu erhalten.