The most honest description of what AI has changed in my daily work isn't "it writes my code." It does, sure. But that's not the point.
The point is: it lowers the barrier to trying new things. A different language. A different framework. A design system I don't yet know whether it fits me. An architectural variant I would have run through in my head and then discarded, because actually trying it out was too expensive.
That "too expensive" is exactly what has disappeared. And that has changed more than any tab completion ever did.
The old way first – on purpose
In late 2025 I dug into Flutter and Dart. A few demo projects, a few throwaway prototypes. Deliberately without Claude, using only the simple AI agents that sit in the IDE anyway.
That wasn't stubbornness. It was a decision. If I want to truly understand a new language, I have to go through it, not around it. I wanted to type Dart myself, nest Flutter widget trees wrong myself and untangle them again myself. Otherwise I'd have ended up with apps that run, but a framework I never actually internalized.
That phase was slow. That's precisely why it was valuable. Everything that came afterwards builds on that foundation.
Migrena – staying inside the Flutter universe
Early 2026 brought the first real app: Migrena, an app for tracking migraines. Here I stayed strictly inside the Flutter universe. One language, one framework, one mental model. No poaching from other ecosystems.
That was the right call for cementing what I had just learned. But it was also the last project where I committed to a stack out of convenience, without at least glancing at the alternatives.
DoomStop – a Flutter prototype becomes a Swift app
The next project, DoomStop, looked different. I've described the long road of suffering elsewhere – the short version: Apple's Screen Time API only works in native Swift extensions, so Flutter was the wrong path here.
The interesting part is the transition. I had a Flutter prototype. Instead of rebuilding it by hand for weeks, I had a native Swift variant generated from it, just to take a quick look. Not "the finished app at the push of a button" – that would be a lie. But a working entry point where I could judge whether the switch was worth it, without first investing three days of setup.
That's the core: the question "how would this actually look natively?" went from a weekend project to a matter of hours.
Zutato – where Flutter didn't want to come along anymore
And then came Zutato. I started with Flutter – the stack I knew best. Until I hit a wall that wasn't mine, but the framework's: Liquid Glass.
With iOS 26, Apple changed its design language. Liquid Glass is the new, translucent look that runs throughout the system. If you build an iOS app that shouldn't feel stuck in the past, you can hardly avoid it.
And this is where it gets awkward for Flutter. In the summer of 2025 the Flutter team publicly stated they would not update the Cupertino widgets to Liquid Glass for now – and that they would not accept contributions for those updates either. In their own words, from the official 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."
Translated: Material and Cupertino are being moved out of the framework core into standalone packages, and only there will the iOS 26 updates happen. Until then, Cupertino widgets simply look dated on iOS 26. The community has filled the gap with packages like cupertino_native, adaptive_platform_ui or cupertino_liquid_glass – some real native bridges, some recreated visuals. Usable, but workarounds for something the framework officially can't do (yet).
React Native is much further along here. Callstack's @callstack/liquid-glass brings the iOS 26 effect natively into React Native apps, and in the Expo world expo-glass-effect provides a GlassView component that sits directly on top of Apple's native effect. Both fall back cleanly to a regular view on older iOS versions and on Android. The requirement in each case is iOS 26 and a build with Xcode 26 – but the foundation is there, today, without tinkering.
The real test: do I feel at home there?
Instead of weighing this up theoretically, I just tried it. My Zutato prototype was still lean – some auth, a few screens. So I had a React Native variant generated from it, made a few architectural decisions and started typing.
And something happened that I hadn't planned for: I immediately felt more at home. Not because of Liquid Glass. Because of the language.
My backend is TypeScript. My admin is TypeScript. My web frontend is TypeScript. With React Native I stay in the same mental model, from server to app. No context switch between Dart and TypeScript several times a day. The same types, the same patterns, the same intuition for where a bug comes from.
This isn't an objective "React Native is better than Flutter." Flutter is a great framework, and for other projects I'd choose it again. It's a very personal realization about where I am productive. And without quick experimentation I'd never have had it – I'd have kept assuming Flutter was a given for me.
PetTrack – a project I'd otherwise never have touched
Perhaps the clearest example is PetTrack, a small web app I'd written myself a while back. Used purely privately, and it grew accordingly: everything hardcoded, no configuration layer, because I was the only user and knew exactly where every value lived.
I had Claude completely overhaul the app. A fresh design, and above all a full admin and configuration backend for something only I actually use. Today, what used to be hardwired is configurable.
With a good starting point and clean specs, this ran almost flawlessly. But the real point is a different one: I would never have done this work by hand. A configuration backend for a single-user app? Never. The effort wouldn't have been remotely proportional to the benefit. With AI, "not worth it" turned into "well, why not."
And that's exactly what shifts what you even dare to take on.
The pattern behind all of this
When I lay these projects side by side, the common thread isn't "AI builds my apps." It's: the cost of experimenting has collapsed.
Looking at a different language, stress-testing a design system, evaluating a library without first reading through the docs for hours, building an alternative component variant just to see whether the UX gets better – all of that used to come with so much friction that, in doubt, I just left it. Today it's a matter of minutes to hours.
This isn't naive hype. It's a magical tool – but only if you know how to use it. Whoever prompts away without a plan gets handed a bill that I've paid myself. AI doesn't take away the clarity about what should be built. It takes away the friction of finding out whether a path is even the right one in the first place.
I make more deliberate decisions today, because I've actually seen more alternatives instead of just guessing at them. That's the real win.
For this to hold up over time, it needs one constant: context. My next step was a self-hosted Outline wiki where I maintain my projects and a separate cookbook – so I don't have to make architectural decisions from scratch in every repo, and so Claude knows, via an MCP service, how my products work and what they can do. Exactly how that's set up will be its own article.
AI doesn't write my code. It takes away my excuse not to try something.