Ich habe eine React-Native-Chart-Bibliothek, die ich vor 9 Jahren erstellt hatte, nach 9 Jahren auf Version 2.0.0 aktualisiert und auf npm veröffentlicht. Den Großteil dieser Aktualisierung hat ein AI-Agent durchgeführt; den Prozess möchte ich hier teilen.
Zunächst zur Bibliothek selbst. Bei react-native-pure-chart ist der Name Programm: „pure“ ist ihre Identität. Sie verwendet weder react-native-svg noch ART noch das heute zum Standard gewordene Skia, sondern zeichnet Linien-, Balken- und Kreisdiagramme ausschließlich mit den reinen View/Text-Komponenten von RN. Das Rendering-Prinzip sieht so aus: Entfernung und Winkel zwischen zwei Datenpunkten werden per Trigonometrie berechnet, dann wird eine schmale, lange View per rotate-Transform gedreht, sodass sie wie ein Liniensegment aussieht; aus solchen Stücken wird das gesamte Chart zusammengesetzt. Der zentrale Wert ist Zero Dependency: keine native Drawing-Bibliothek linken, keine Angst vor Build-Brüchen beim pod install, sondern nutzbar mit einer einzigen Zeile npm install. In ihrer Hochphase hatte die Bibliothek 2.000 npm-Downloads pro Woche, wurde in rund 820 Projekten genutzt und hatte 289 Stars. Danach lag sie 9 Jahre lang brach, und es war unklar, ob sie mit aktuellem RN überhaupt noch funktioniert.
Da ich zufällig noch einen AI-Account hatte, dessen Limit bald zurückgesetzt werden sollte, ließ ich in der Mittagspause einen Prompt zurück.
„Ich habe das Repo geclont; bring es in einer aktuellen Expo/RN-Umgebung sauber zum Laufen. Sieh dir die Harness-Doku an.“
Mit „Harness“ ist hier eine vorab eingerichtete Selbstprüfungsumgebung gemeint. Sie ist so aufgebaut, dass sie mit einem mobilen E2E-Tool wie Maestro den iOS-Simulator und den Android-Emulator direkt bedienen, Screenshots aufnehmen und das Rendering-Ergebnis überprüfen kann. Darin lag der Kern dieser Arbeit.
Um eine 9 Jahre alte RN-Codebase in aktuellem Expo/RN lauffähig zu machen, gibt es viel anzupassen. Die damalige Art, Komponenten zu schreiben, und die alten APIs waren noch unverändert vorhanden, sodass es nicht nur um ein Versionsupdate ging, sondern faktisch um ein Modernisierungs-Refactoring. Solche Arbeiten sind einzeln nicht besonders schwierig, aber umfangreich; nach jeder Korrektur muss man auf dem tatsächlichen Bildschirm prüfen, ob nichts kaputtgegangen ist. Manuell kostet das erheblich Zeit.
Während ich an anderen Dingen arbeitete, lief der Agent mehrere Stunden lang allein in einer Schleife. Er änderte Code, startete die App im Simulator und Emulator, bediente den Bildschirm per E2E, machte Screenshots, beurteilte anhand dieser Screenshots Rendering-Probleme und änderte dann wieder den Code. Wichtig ist, dass diese Prüfung nicht nur auf dem Niveau von Compile-Fehlern oder bestandenen Tests stattfand. Bei einer Chart-Bibliothek ist ein erfolgreicher Build trotzdem ein Fehlschlag, wenn Linien versetzt oder Achsen verschoben sind. Weil die richtige Antwort in diesem Projekt „das ist auf dem Bildschirm zu sehen“ war, füllte eine visuelle Regression-Schleife mit Screenshots als Bewertungskriterium genau die Lücke, die Unit-Tests nicht abdecken können.
Die größte Änderung in dieser Version ist die Unterstützung für Kurvencharts (Smooth Lines). Tatsächlich konnte die Bibliothek vor 9 Jahren keine Kurvencharts unterstützen. Eine Gerade lässt sich zeichnen, indem man eine einzelne View dreht; eine Kurve muss man dagegen in viele kleine Abschnitte unterteilen, die Koordinaten und Winkel jedes Stücks berechnen und sie durch kurze Liniensegmente annähern. Damals konnte ich das Problem nicht lösen, dass zwischen den Stücken minimale Lücken entstanden oder die Kurve kantig wirkte, deshalb habe ich die Funktion gar nicht erst eingebaut. Diesmal beließ es der Agent nicht bei der Prüfung des gesamten Screenshots, sondern erfasste verdächtige Bereiche, in denen die Kurve unterbrochen wirkte, vergrößert und überprüfte sie. Anschließend passte er Variablenwerte an, die für die Berechnung der Koordinaten und Winkel der Stücke verwendet werden, renderte erneut und prüfte wieder vergrößert. Wenn ein Mensch diese Tuning-Schleife aus Parameteränderung und visueller Ergebnisprüfung manuell wiederholt, geht er irgendwann einen Kompromiss ein; der Agent wiederholte sie weiter, bis es konvergierte. So wurde schließlich ein glatter Kurvenchart als neue Funktion hinzugefügt. Eine Funktion, die ich vor 9 Jahren nicht umsetzen konnte, ist nun also enthalten.
Am Ende wurden die Kompatibilität mit aktuellen Expo/RN-Umgebungen, die neue Unterstützung für Kurvencharts, aktualisierte Chart-Screenshots im README sowie Build und Veröffentlichung von npm 2.0.0 abgeschlossen. Das ist das erste Update seit 9 Jahren.
Meine Erkenntnis aus dieser Arbeit: Der Flaschenhals beim Agentic Coding liegt meiner Meinung nach weniger in der Modellleistung als in der Verifikationsumgebung. Wenn ein Harness vorhanden ist, mit dem das Ergebnis selbst überprüft werden kann, konvergiert sogar visuelle Qualität ohne menschliches Review. Besonders bei Projekten wie UI-Bibliotheken, bei denen die richtige Antwort auf dem Bildschirm liegt, erwies sich die Kombination aus E2E-Bedienung und Screenshot-Bewertung als effektiv. Aufgaben wie die Modernisierung von Legacy-Code, die nicht sehr schwierig sind, aber hohe Kosten durch wiederholte Überprüfung verursachen, scheinen eine gute Kategorie zu sein, die man Agenten überlassen kann.
GitHub: https://github.com/oksktank/react-native-pure-chart
npm: https://www.npmjs.com/package/react-native-pure-chart
Noch keine Kommentare.