From Coding to Orchestrating: What AI Agents Are Changing in Software Development
An experiment using an AI development agent to build a Flutter application — and what it taught me about the changing role of developers. For most of my career, software development meant one thing: writing code.
Choosing libraries, implementing features, fixing dependency issues, and debugging platform problems — that’s the everyday life of a developer. But recently I started wondering: What happens if an AI agent starts doing a lot of that work? Can a developer still build an application in a technology they’re not an expert in, just by guiding an AI tool?
To explore that idea, I decided to run a small experiment.
For about six weeks, I worked with Kiro, an AI-powered IDE, while building a mobile application with Flutter.
Flutter is not my main stack. I have some experience with Dart and Flutter, but I wouldn’t call myself a Flutter specialist. That actually made it a good test case. I wanted to see if AI could help close the gap between general engineering knowledge and framework-specific expertise.
The goal wasn’t to build a production system. I just wanted a realistic example. The application needed to:
- Log in a user with a Google account
- Fetch and show videos from a private YouTube channel
Nothing too complex — but enough to include authentication, APIs, and UI.
One Important Lesson: AI Needs Context, Not Questions
The first thing I noticed when working with an AI agent is that the interaction model is very different from how developers normally work. Usually, when we get stuck, we search for answers. We open Google, search for the problem, read Stack Overflow, and try different solutions until something works. That workflow is question-driven.
AI agents work differently. Instead of asking questions, describe the system you want to build. The clearer you describe it, the better the results. During this project, I started using a simple structure when interacting with the AI:
RCTO — Role, Context, Task, Output
Role
First, define the system's role. For example:
- a mobile application built with Flutter
- using Dart
- running on Android and iOS
This helps the AI understand the environment.
Context
Next comes the context, and this part is really important. Here, you explain the situation and the constraints. For example:
- Users log in with a Google account
- Authentication happens through OAuth
- The application retrieves videos from a private YouTube channel
If the context is not clear, the AI can easily misunderstand the problem.
Task
Once the role and context are clear, the AI can start breaking the problem into tasks. One thing I found interesting with Kiro is that it doesn’t jump directly into coding. It first generates things like:
- requirements
- architecture suggestions
- a task list
That structure actually helps a lot.
Output
After that, tasks can be executed step by step, and the AI generates the implementation. At this point, the developer mostly reviews and adjusts the output.
What the AI Did Really Well
One area where the AI was extremely helpful was choosing libraries and technologies. When you work in a framework you don’t know very well, a lot of time is spent on things like:
- finding the right packages
- Understanding common project structure
- integrating APIs
- following design patterns
These are exactly the areas where the AI helped a lot. For example, it helped with:
- Google authentication
- retrieving videos from YouTube
- structuring the Flutter project
- following Material Design patterns
In those parts, I honestly wrote almost none of the code myself. The AI handled most of the boilerplate and setup. For someone working in an unfamiliar stack, that kind of help saves a lot of time. In many moments, it felt like having a developer next to me who already knew the ecosystem.
Where the AI Was Not So Helpful
On the other hand, the AI struggled more with debugging complex issues. If the error is simple, it can sometimes help. But when the problem involves multiple systems or authentication flows, things get harder. At one point, we had an issue related to Okta authentication. The problem wasn’t only in the mobile code. It involved understanding how the authentication flow worked with backend configuration. In that situation, the AI couldn’t really identify the root cause.
Get Zohre Niayesh’s stories in your inbox
Join Medium for free to get updates from this writer.
I had to investigate the backend flow myself, understand how everything was connected, and then explain the correct structure to the AI so it could adjust the implementation. This made something very clear: AI tools are powerful, but they still depend heavily on developer understanding and context.
What This Means for Developers
After working with an AI agent like this, one thing became very clear to me. The role of developers is starting to change. Traditionally, a lot of our work is about implementation details:
- writing boilerplate code
- managing dependencies
- fixing platform issues
- integrating libraries
AI tools can now handle much of that work. They can generate scaffolding, connect libraries, and implement standard patterns very quickly. Because of that, developers start spending less time writing every line of code. Instead, the focus shifts to guiding the development process. That means thinking more about:
- architecture
- system design
- how components interact
- How to clearly describe the problem
Developers become less like pure coders and more like orchestrators of development systems. AI agents are not replacing developers. But they are definitely changing how we work.
Final Thoughts
Working with an AI agent changed the way I think about development. The biggest change wasn’t faster coding. It was realizing that modern development is starting to look more like collaboration between developers and intelligent tools. The better we get at describing systems, defining context, and guiding these tools, the more powerful they become. AI agents may not replace developers. But they are already changing what it means to be one.
