I recently experimented with developing Flutter applications using Kiro IDE. It was less about writing code and more about writing clear specifications, allowing Kiro to handle most of the technical implementation work. The experiment was very successful. I could go over the generated code not only in Kiro IDE but also in Xcode and Android Studio, and I found it very easy to deploy the app on both Android and iOS emulators.
What Flutter Actually Is
Flutter is Google’s open-source framework for developing applications from a single codebase. It allows developers to build apps for Android, iOS, web, and desktop using Dart, while keeping a shared UI and development model across platforms.
Specs Became the Main Interface
The development process felt surprisingly simple. Once the specifications were clear enough, I could stay focused on describing the expected behavior, while Kiro IDE translated these specs into working Flutter application code.
Letting Kiro Handle The Implementation
Instead of jumping between files, fixing boilerplate, and manually connecting components, I mostly stayed with the specs. Kiro handled the rest, including structure, implementation details, and many of the small technical decisions developers usually manage directly.
Android Studio Felt Familiar
Opening the Android application with Android Studio felt good at first. It created a small déjà vu moment, reminding me of the old days when I was coding directly for Android. However, I also had to spend time overcoming more than a few technical problems. Eventually, I followed the AI suggestion and ran the application from the terminal.
Xcode Was a Smooth Reminder
Opening the iOS application with Xcode also felt good. It was a reminder of how smooth this IDE is, even compared with Android Studio, although Android Studio has improved significantly over the years.
Technical Problems Became Kiro’s Work
Every technical problem that appeared during the process was handled by Kiro IDE. My work remained focused on the specifications, the expected behavior, and the product direction, rather than low-level implementation issues.
The Developer Role Keeps Changing
This experiment clearly showed how the role of the software developer is changing. Instead of writing most of the code manually, the main work is now explaining clearly what the software should do, so the AI-assisted tool can build it properly.
Now that we increasingly develop software by writing texts in English, this experiment also raises an interesting question: do we still need Flutter in the same way? After all, we could stay with the specifications and ask Kiro to develop two separate native applications: one for Android and one for iOS. This is also, by the way, the approach I am now taking while working on Jacado Games.







