Die ehrlichste Beschreibung dessen, was AI in meinem Arbeitsalltag verändert hat, ist nicht "sie schreibt meinen Code". Das tut sie, klar. Aber das ist nicht der Punkt.
Der Punkt ist: Sie senkt die Hürde, Neues auszuprobieren. Eine andere Sprache. Ein anderes Framework. Ein Design-System, von dem ich noch nicht weiß, ob es zu mir passt. Eine Architektur-Variante, die ich früher im Kopf durchgespielt und dann verworfen hätte, weil das Ausprobieren zu teuer gewesen wäre.
Genau dieses "zu teuer" ist weggefallen. Und das hat mehr verändert als jede Tab-Completion.
Erst der alte Weg – mit Absicht
Ende 2025 habe ich mich in Flutter und Dart eingearbeitet. Ein paar Demo-Projekte, ein paar Wegwerf-Prototypen. Bewusst ohne Claude, nur mit den simplen AI-Agents, die ohnehin in der IDE sitzen.
Das war kein Trotz. Das war eine Entscheidung. Wenn ich eine neue Sprache wirklich verstehen will, muss ich durch sie hindurch – nicht an ihr vorbei. Ich wollte Dart selbst tippen, die Flutter-Widget-Bäume selbst falsch verschachteln und selbst wieder geradeziehen. Sonst hätte ich am Ende Apps gehabt, die laufen, aber ein Framework, das ich nicht durchdrungen habe.
Diese Phase war langsam. Genau deshalb war sie wertvoll. Alles, was danach kam, baut auf diesem Fundament auf.
Migrena – im Flutter-Universum bleiben
Anfang 2026 kam die erste echte App: Migrena, eine App zum Tracken von Migräne. Hier bin ich strikt im Flutter-Universum geblieben. Eine Sprache, ein Framework, ein Mental Model. Kein Wildern in anderen Ökosystemen.
Das war die richtige Wahl, um die frisch gelernten Dinge zu festigen. Aber es war auch das letzte Projekt, in dem ich mich aus Bequemlichkeit auf einen Stack festgelegt habe, ohne die Alternativen wenigstens kurz angeschaut zu haben.
DoomStop – aus einem Flutter-Prototyp wird eine Swift-App
Beim nächsten Projekt, DoomStop, sah es anders aus. Den ausführlichen Leidensweg habe ich an anderer Stelle beschrieben – die Kurzfassung: Apples Screen-Time-API funktioniert nur in nativen Swift-Extensions, Flutter war hier der falsche Weg.
Interessant ist der Übergang. Ich hatte einen Flutter-Prototypen. Statt wochenlang von Hand umzubauen, habe ich mir daraus eine native Swift-Variante erstellen lassen, um schnell reinzuschauen. Nicht "die fertige App per Knopfdruck" – das wäre gelogen. Aber ein lauffähiger Einstiegspunkt, an dem ich beurteilen konnte, ob der Wechsel sich lohnt, ohne erst drei Tage Setup zu investieren.
Das ist der Kern: Die Frage "Wie würde das eigentlich nativ aussehen?" ist von einem Wochenend-Projekt zu einer Stunden-Frage geworden.
Zutato – wo Flutter mich nicht mehr mitnehmen wollte
Und dann kam Zutato. Begonnen habe ich mit Flutter – der Stack, den ich am besten kannte. Bis ich auf eine Wand gestoßen bin, die nicht meine war, sondern die des Frameworks: Liquid Glass.
Mit iOS 26 hat Apple seine Design-Sprache umgestellt. Liquid Glass ist die neue, durchscheinende Optik, die sich quer durch das System zieht. Wer eine iOS-App baut, die nicht aus der Zeit gefallen wirken soll, kommt daran kaum vorbei.
Und hier wird es für Flutter unangenehm. Das Flutter-Team hat im Sommer 2025 öffentlich erklärt, die Cupertino-Widgets vorerst nicht auf Liquid Glass zu aktualisieren – und für diese Updates auch keine Beiträge anzunehmen. Im Originalton aus dem offiziellen GitHub-Issue:
"The material and cupertino libraries are being decoupled into standalone packages to accelerate feature development. ... All new work for iOS26 updates in Cupertino will happen in the new packages once established."
Übersetzt heißt das: Material und Cupertino werden aus dem Framework-Kern in eigenständige Packages ausgelagert, und erst dort sollen die iOS-26-Updates entstehen. Bis dahin sehen Cupertino-Widgets auf iOS 26 schlicht veraltet aus. Die Community hat die Lücke mit Paketen wie cupertino_native, adaptive_platform_ui oder cupertino_liquid_glass gefüllt – teils echte native Bridges, teils nachgebaute Optik. Brauchbar, aber eben Workarounds für etwas, das das Framework offiziell (noch) nicht kann.
React Native ist hier deutlich weiter. Callstacks @callstack/liquid-glass bringt den iOS-26-Effekt nativ in React-Native-Apps, und im Expo-Umfeld gibt es mit expo-glass-effect eine GlassView-Komponente, die direkt auf Apples nativen Effekt aufsetzt. Beide fallen auf älteren iOS-Versionen und auf Android sauber auf eine normale View zurück. Voraussetzung ist jeweils iOS 26 und ein Build mit Xcode 26 – aber das Fundament ist da, heute, ohne Bastelei.
Der eigentliche Test: Fühle ich mich da zuhause?
Statt das jetzt theoretisch abzuwägen, habe ich es einfach ausprobiert. Mein Zutato-Prototyp war noch schlank – etwas Auth, ein paar Screens. Also habe ich mir daraus eine React-Native-Variante erstellen lassen, ein paar Architektur-Entscheidungen getroffen und losgetippt.
Und da passierte etwas, das ich nicht eingeplant hatte: Ich fühlte mich sofort heimischer. Nicht wegen Liquid Glass. Wegen der Sprache.
Mein Backend ist TypeScript. Mein Admin ist TypeScript. Mein Web-Frontend ist TypeScript. Mit React Native bleibe ich im selben Mental Model, vom Server bis zur App. Kein Kontext-Wechsel zwischen Dart und TypeScript mehrmals am Tag. Dieselben Typen, dieselben Patterns, dieselbe Intuition dafür, wo ein Fehler herkommt.
Das ist kein objektives "React Native ist besser als Flutter". Flutter ist ein großartiges Framework, und für andere Projekte würde ich es wieder wählen. Es ist eine sehr persönliche Erkenntnis darüber, wo ich produktiv bin. Und die hätte ich ohne das schnelle Ausprobieren so nie gehabt – ich hätte weiter angenommen, Flutter sei für mich gesetzt.
PetTrack – ein Projekt, das ich sonst nie angefasst hätte
Das vielleicht klarste Beispiel ist PetTrack, eine kleine WebApp, die ich vor einer Weile selbst geschrieben hatte. Rein privat genutzt, entsprechend gewachsen: alles hartkodiert, kein Konfigurations-Layer, weil ich der einzige Nutzer war und genau wusste, wo welcher Wert steht.
Ich habe Claude die App komplett überarbeiten lassen. Frisches Design, und vor allem ein vollständiges Admin- und Konfigurations-Backend für etwas, das eigentlich nur ich benutze. Heute ist konfigurierbar, was früher fest verdrahtet war.
Bei guter Ausgangslage und sauberen Specs lief das nahezu fehlerfrei. Aber der eigentliche Punkt ist ein anderer: Diese Arbeit hätte ich von Hand nie gemacht. Ein Konfigurations-Backend für eine Ein-Nutzer-App? Niemals. Der Aufwand hätte in keinem Verhältnis zum Nutzen gestanden. Mit AI ist aus "lohnt sich nicht" ein "warum eigentlich nicht" geworden.
Und genau das verschiebt, was man sich überhaupt zutraut.
Das Muster hinter all dem
Wenn ich diese Projekte nebeneinanderlege, ist nicht "AI baut meine Apps" die gemeinsame Linie. Es ist: Die Kosten fürs Ausprobieren sind eingebrochen.
Eine andere Sprache anschauen, ein Design-System gegentesten, eine Library evaluieren, ohne mich erst stundenlang durch die Docs zu lesen, eine alternative Komponenten-Variante bauen, nur um zu sehen, ob die UX besser wird – all das war früher mit so viel Reibung verbunden, dass ich es im Zweifel gelassen habe. Heute ist es eine Frage von Minuten bis Stunden.
Das ist nicht naiver Hype. Es ist ein magisches Werkzeug – aber nur, wenn man weiß, wie man es benutzt. Wer ohne Plan drauflos-promptet, bekommt eine Rechnung präsentiert, die ich auch schon bezahlt habe. Die Klarheit darüber, was gebaut werden soll, nimmt einem die AI nicht ab. Sie nimmt einem die Reibung beim Herausfinden, ob ein Weg überhaupt der richtige ist.
Ich treffe heute mehr bewusste Entscheidungen, weil ich mehr Alternativen tatsächlich gesehen habe, statt sie nur zu vermuten. Das ist der eigentliche Gewinn.
Damit das auf Dauer trägt, braucht es eine Konstante: Kontext. Mein nächster Schritt war ein self-hosted Outline-Wiki, in dem ich meine Projekte und ein separates Cookbook pflege – sodass ich architektonische Entscheidungen nicht in jedem Repo neu treffen muss und Claude über einen MCP-Service direkt weiß, wie meine Produkte funktionieren und was sie können. Wie genau das aufgebaut ist, wird ein eigener Artikel.
AI schreibt nicht meinen Code. Sie nimmt mir die Ausrede, etwas nicht auszuprobieren.