I Shipped 3x More Features with One AI Agent, All Production Ready

Who’s this for: Developers exploring AI agent in software development for real coding work. Especially those struggling with hallucinated code, unclear task boundaries, or when to keep a human in the loop.

TL;DR

With a scoped workflow, my AI agent delivered code up to 6× faster but only when the task matched its strengths.

• 6× in app UI, 4.5× in business logic, 1.7× in platform code.
• 1× in publishing and UI design. Still fully manual.
• Net result: solid 3× productivity increase

The key? A 4-step flow:

1. Pick the right coder - me or the agent
2. Define the task clearly
3. Talk before code - ask, plan, refine
4. Code only after approval

Series progress:

Control ▇▇▇▇▇ Build ▇▇▇▇▇ Release ▢▢▢▢▢ Retrospect ▢▢▢▢▢

Welcome to Part 2 of my honest deep-dive: does an AI agent really hold up when you move from one code framework to a completely different tech stack?

In Part 1, I showed how the Planner → Executor → Validator loop + /rules folder kept my AI agent from rewriting files it shouldn’t touch.
Now it’s time for the real test:

• Set up a real Flutter project, App Store Connect and Google Play Console.
• Stress-test Flutter quirks, native iOS / Android bridges, OS-level permissions.
• Measure what the agent did fast and where it wasted my time.

Even though this series uses a Flutter mobile app as the demo project, everything here - from the agent control loop to testing, PR review, and CI/CD - maps directly to backend, web or other SW dev work.

Spoiler: Pure Flutter work? Lightning-fast. Native iOS / Android? Still half manual and parts where you’ll still crack open Xcode and Android Studio.

Series Roadmap - How This Blueprint Works

1. Control - Control Stack & Rules → trust your AI agent won’t drift off course (Control - Part 1)
2. Build - AI agent starts coding → boundaries begin to show
3. Release - CI/CD, secrets, real device tests → safe production deploy
4. Retrospect - The honest verdict → what paid off, what blew up, what’s next

Why care?

Give your AI agent the wrong job, and it’ll cheerfully break your build at lightning speed. Your role? Decide what the AI agent should do, what to protect from it, and when to step in as a teammate.

👉 Let’s break it down - this is Part 2.

1. Task.md - The Agent’s Single Source of Truth

Before I wrote a single prompt, I wrote a real blueprint planning.md (a.k.a Product Requirements Document - PRD): what I wanted to build, high level architecture, coding principles that I want to follow, folder structure, technical requirements, and what my delivery looked like.

Then I turned that blueprint into a detailed task.md (IDs, subtasks, clear acceptance notes). The AI agent was never in charge of defining scope. That’s still my job. I also bolted Jira to GitHub and linked to my task list, so I could see how well the agent was tracking my tasks.

task.md is where the whole Planner → Executor → Validator loop keeps the state in practice. In the Control phase, it keeps the AI agent on a tight leash: every task starts here, every plan gets approved here, and every bug or test failure loops back here. In Build phase, it turns the blueprint into concrete commits: it tracks what the AI agent built, what needed manual fixes, and what code parts still demanded human tweaks. By the Ship phase, task.md is still the single source of truth. PR reviews, CI/CD pipeline checks, and real-device test results all feed back into it, creating new tasks when blockers pop up.

It’s not just a to-do list. It’s the living playbook that ties blueprint, AI agent, and CI/CD pipeline together.

💡 Pro tip: Treat task.md like a living log - never let it freeze.
Whenever the agent spots edge cases, test failures, or blockers, make it write them back to task.md. That way your blueprint always matches reality, not just the plan on day one.

1.1 Designing a Project to Reveal AI Agent Boundaries

I didn’t want a hello‑world demo app. From day one, I scoped my mobile app so that the AI agent had to touch native iOS and Android code. You can’t cheat that with pure Dart. You need native Swift for iOS and native Kotlin for Android.

• Home Widget on both OSs – a SwiftUI WidgetExtension for iOS, a Kotlin AppWidgetProvider on Android.
• Platform-channel glue – JSON method channels moving data between Dart and native layers.
• OS-level permissions & new targets – schedule tasks.

This setup helped me push the AI agent to its limits, shape a blueprint for splitting tasks the right way, and define when to bring in human hands and where to draw that line.

💡 Pro tip: When you kick off a new project, map out which parts are likely to trip up your AI agent (native glue, tricky permissions, platform quirks). Watch these spots closely and be ready to jump in yourself when the agent hits its limits.

2. Project and Firebase Studio’s setup

2.1 Cloud vs. Local environment

Local dev is fast and familiar: my Mac runs Flutter, emulators, and real devices just fine. But local isn’t built for agents that run around the clock.

That’s why I used a cloud setup from day one:

• The agent stays live 24/7, not tied to any laptop.
• Bugs go from Jira → webhook → Planner → Executor → Validator → PR. No manual wake-ups.
• Adding more devs or agents? Everyone shares the same environment. No “works on my machine” issues.

🔍 Why Firebase Studio?
It supported Flutter and Android emulator well enough for a single sprint, but lacks full 24/7 agent support. (Next time I’ll likely use All Hands built for continuous agents from day one)
💡 Cloud setup tip: Private or public? Just make sure your agent can stay live, productive, and compliant with your org’s data rules.

2.2 Firebase Studio’s Flutter Setup - Avoiding the Trap

When I hit “Start coding an app” in Firebase Studio and picked Flutter, the Firebase scaffolded every wrong default: MyApp, a useless web/ folder, no iOS target (🚫 Firebase Studio does not support iOS), and the classic com.example.myapp package ID. I spent some time cleaning that up, but it was waste of time and decided to try another approach.

This was my mistake: I should have started at the first place with a clean Flutter project locally, then imported it into Firebase Studio. But I get why Firebase Studio does this: it’s meant as a playground setup, not production-ready.

I created a clean Flutter project locally, then imported it into Firebase Studio via Git. See the details below for how to do this.

# local init (tweak org "fi.awave" & name "sampleapp" for your own use case) flutter create --platforms=android,ios \ --org fi.awave \ sampleapp 

 android { compileSdk = 36 ndkVersion = "27.0.12077973" defaultConfig { minSdk = 30 targetSdk = 36 } } 

// skip signing on Firebase Studio val keystoreProperties = Properties() val keystorePropertiesFile = rootProject.file("key.properties") if (keystorePropertiesFile.exists()) { keystoreProperties.load(FileInputStream(keystorePropertiesFile)) } else { println("⚠️ Note: key.properties not found – release, staging build not possible to be signed.") } ... buildTypes { getByName("debug") { // uses default debug signing config located in: ~/.android/debug.keystore } getByName("staging") { if (keystorePropertiesFile.exists()) { signingConfig = signingConfigs.getByName("staging") } } getByName("release") { if (keystorePropertiesFile.exists()) { signingConfig = signingConfigs.getByName("release") } } } 

⚠️ Heads-up: you’ll still create the app shells in Google Play Console and App Store Connect manually.

💡 Pro tip: Skip the boilerplate trap. Create & clean the project locally, push to Git, then import from Git to Firebase Studio. Firebase will create required environment dev.nix files when you import your project.

3. Initial Prompt - First the Plan, Then the Code

Before the AI agent could write a single line of code, I loaded a clean and complete context. This started with loading four critical pieces:

• /rules/ - to activate the full System Prompt: coding rules, feedback loops, commit strategy, testing discipline (Control - Part 1)
• planning.md - to understand the big picture and architecture, and avoid writing code that would later conflict with future features
• task.md - to get context on what’s already done, what’s in progress, and any known constraints
• Task ID - to know exactly which feature to focus on and avoid scope bleed

This reset was not optional, it was the countermeasure to context drift.

As covered in Part 1 → Context Hygiene, long-running chats quickly spiral into hallucination territory. Each task was treated as a clean slate with fresh context.

But context alone wasn’t enough. The agent wasn’t allowed to just start coding.

Instead, the first step was scoping the task properly. The agent had to pause, reflect, and write down every question or uncertainty it still had. No assumptions. No guessing silently.

This up-front conversation was the foundation for building the User Prompt, our shared understanding of what we’re about to build.

Example of the first prompt to start new feature development

- Read `/rules/airules.md` and other instruction files that are defined in the `airules.md`. - Read `task.md` for the implementation context. - Now we are working with the task: ID-123 Implement Feature X - Think step by step how to make implementation. - Write an implementation plan and ask my approval before starting the implementation. - _Before you start, list anything unclear. If you don’t know, ask now._ - Do not start coding before I approve your plan. 

This small ritual turned the agent from a prompt follower into a planning partner. Only after this plan was reviewed and approved by me did the Planner begin its work and that up-front clarity meant fewer surprises and less cleanup later.

3.1 User Prompt - What to Build, Together

An AI agent can’t guess what to build. Every task begins by establishing a shared mental model. A short-lived but precise agreement on what the feature is, how it should behave, and how we’ll know it’s done. That’s the User Prompt, and it’s where tactical reasoning happens.

The User Prompt is built from three sources:

• planning.md + task.md these define the overall scope and architecture, but only the relevant slices are pulled in for the current task.
• Initial prompt and conversation an active dialogue with the agent to review the scope, clarify anything unclear, and co-create the plan.

Unlike the System Prompt (Part 1 → System Prompt), which can always be reloaded from /rules/ to restore the same mindset, the User Prompt exists only in memory for the current conversation. When the chat ends, it’s gone, and must be rebuilt from scratch the next time.

But this isn’t a top-down instruction set. The agent has to ask, clarify, and plan and I have to approve. That shared clarity is what keeps the Planner focused, the Executor scoped, and the Validator relevant.

When the AI agent stumbles, it’s almost always because the User Prompt was vague or incomplete. That’s why I force the agent to ask questions and write a plan before it writes a single line of code. The implementation must be explicit, not assumed.

3.2 The Power of Two Prompts - Behavior Meets Implementation

When you combine a System Prompt with a task-specific User Prompt, you give the AI agent both its job description and its exact mission.

• System Prompt shapes how the agent works: how it commits, how it asks questions, how it tests.
• User Prompt defines what to build right now: the logic, constraints, edge cases.

Together, they turn the AI agent into a real teammate. By keeping the rules persistent and the scope specific, I could trust the agent to move fast without breaking things that weren’t part of the current task.

Without both, the agent either forgets the bigger picture or gets lost in implementation details.

4. Flutter Development - How the Agent Held Up

To test how far an AI agent could really go - in terms of code quality, delivery speed, and handling edge cases - I deliberately picked two tricky features from a fully built-out app. The goal was to push the agent in real-world scenarios and see if this workflow could actually save serious dev hours in practice:

1. An analog clock widget that ticks every second - constant UI and state updates, custom painter logic.
2. Riverpod-powered state management - scoped providers and reactive rebuilds keep the architecture clean but can trip up less experienced setups fast.

4.1 Speed & code quality

• Analog clock: The AI agent drew the full custom-painter dial, hands and smooth tick animation in ≈ 10 minutes. A couple of follow-up prompts polished the details. Doing this by hand would have been hours of work.
• State management: The AI agent didn’t make solid architectural choices on its own. I mapped out the high-level graph up front. After a fresh start and a few rounds of tweaks and clarifications, the raw wiring went smoothly and the AI agent handled the repetitive parts well.

The result: On pure Flutter UI tasks the AI agent outpaced me 6–0. On architectural decisions, it needed my direction but once pointed, it did the heavy lifting.

4.2 Where It Struggled

These tests also revealed clear weak spots.

• No eyes: The AI agent can’t see what’s happening in the Firebase Studio Android emulator screen. Screenshots were mandatory: I captured the UI, dropped it into the chat and asked for pixel tweaks.
• No design instinct: Without explicit references, the AI agent’s visual taste is pretty much 90s terminal style. Only after I shared reference images did the styling improve.
• No architecture awareness: The AI agent had no real sense of what helper methods or reusable patterns were already in the codebase. It often rewrote logic that existed elsewhere or missed calling shared utils, unless I pointed it to the right files and explained how similar code was structured.

4.3 Key Takeaway

These tricky features were perfect to test real limits. For Flutter code generation and Riverpod wiring the AI agent is a monster accelerator - minutes instead of hours. But it stays blind and tasteless. You’re still the art director feeding it screenshots and clear visual direction. With that human guidance, though, the AI agent can paint pixels and write Dart faster than you can open Figma.

One more thing: always guide your AI agent to refactor code systematically. This is how you can catch duplicated logic and keep your codebase clean over time. Add regular refactoring checkpoints to your task.md or set clear /rules for how often and where the AI agent should look for patterns to merge.

5. Native iOS and Android development

Flutter part proved the AI agent could handle coding fast. But mobile apps need native code, here's where things got interesting.

I knew that adding new targets is a task that you must do manually in Xcode and Android Studio, so I didn’t even try to ask the AI agent to do that. Instead, I created the targets manually and then let the AI agent focus on writing the code that runs in those targets.

At first, the AI agent treated the native code like it was just another SwiftUI / Android screen. Ignoring all the platform-specific quirks related to newly added targets: permission, entitlements, manifest tweaks.

So I did the one thing AI agent does well when you nudge it right: I told it to read Apple’s and Google’s docs first, then come back with a plan.

Once it read the docs, it surprised me. The AI agent wrote decent Swift and Kotlin glue. Not perfect, but runnable.

In native-heavy features I broke the work into four crystal-clear stages, each one nudging the AI agent to focus on a single layer at a time:

Each stage flows into the next: Flutter first, so the AI agent nails down method channel contracts and data shapes. Then Android glue connects to Flutter. Finally, iOS mirrors the same bridge, patching up any extra parameters the AI agent spots during build.

By carving it up this way, I kept the AI agent focused, the commits clean, and the cross-platform glue tight, one layer at a time.

💡 Pro tip: Don’t just run the agent. Decide who does what, guide the architecture, and split tasks so each side plays to its strengths.

6. Where Native Code Still Needs You

People underestimate this. Flutter won’t do it for you, and your AI agent won’t either.
Some things are still better to do in Android Studio or Xcode (or there are no other ways to do these).

6.1 Native Glue Code - 40% AI, 60% Me (Both Platforms)

The moment we crossed into Swift or Kotlin, the speed advantage dropped. The AI agent could write glue code (small methods, platform channels, a bit of SwiftUI). But when it came to signing, entitlements, deployment targets, Xcode project tweaks, it didn't have possibilities to do these or didn't have up-to-date info what / how to do these. But this was easily solved by me doing these manually in Xcode and Android Studio, or instructing AI agent to read the latest docs.

Available tools in Firebase Studio just doesn’t match Xcode or Android Studio for native tools. So even when the agent gave me runnable Kotlin, I found plenty of deprecated calls, outdated syntax, or just missing parts.

internal fun scheduleNextUpdate(context: Context) { ... val backgroundColor = Color.parseColor("#FF121212") ... try { alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, nextUpdateTime, pendingIntent) } catch (e: Exception) { Log.e("ClockWidget", "[$timestamp] Failed to schedule alarm", e) } } 

@RequiresPermission(Manifest.permission.SCHEDULE_EXACT_ALARM) internal fun scheduleNextUpdate(context: Context) { ... val backgroundColor = "#FF121212".toColorInt() ... try { alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, nextUpdateTime, pendingIntent) } catch (e: Exception) { Log.e("ClockWidget", "[$timestamp] Failed to schedule alarm", e) } } 

So the AI agent got me 40% there. That last 60% (making it follow native Android & iOS coding style & annotations) still needed my own eyes and Xcode + Android Studio.

6.2 Branding, Permissions & The Final Manual Mile

Some things just stay manual. Visual assets and OS-level entitlements still live in Xcode and Android Studio, not in an AI agent prompt.

My rule? Do these by hand once, commit, then keep the agent busy where it adds real value.

7. Where the Agent Saved (and Didn’t) My Time

The numbers below tell the whole story. Whenever the work stayed inside pure Flutter territory (widgets, Dart models, lightweight state and their unit tests) the AI agent chewed through tasks ~5 × faster than I do by hand.

As soon as we crossed into native Swift/Kotlin glue the boost shrank to 1.7 ×, and for signing, entitlements or full end-to-end runs the speed-up vanished: those steps are still human-only.

Notes on What’s Not in These Hours 🔍

The table above covers only the hands-on coding and test work I clocked directly related to work with the AI agent.

• CI/CD pipeline & release automation → Not included in the hours. This part was 100% manual, but absolutely critical: the full pipeline work (versioning, signing flows, App Store / Play Console configs, GitHub Actions) is covered separately in Part 3.
• UI / UX design work → Not counted here. The design (screens, flow, user journeys, final mockups) were assumed done up front. This breakdown focuses purely on implementing those assets in code.

If you’re reading this as a dev planning your own agent setup: don’t underestimate these “invisible” hours. A clean CI/CD flow will save you weeks later, and no AI agent yet replaces a good human designer with good taste 🎨.

💡 Pro tip: A disciplined agent can absolutely deliver a 7× “wow” factor for well structure SW dev work, but the minute you need to do something else than coding, you’re back on the tools. Net result: a very real 3× productivity jump as long as your task blueprint is crystal-clear and you keep the AI agent focused on the parts it excels at.

That moment when you realize you’re just watching your AI agent write, test, commit, push, open a PR and pass checks - all while you sip your coffee - is both magic and just a tiny bit unnerving. More than once I caught myself staring at my screen for 5 minutes doing… nothing. The code just… shipped.

8. Firebase Studio Issues

My overall verdict on Firebase Studio as an AI-coding sandbox: usable, but slower and quirkier than a local setup.

Day-to-day friction

• Sluggish Android emulator - Boot times were glacial; I often fell back to local setup for testing.
• GitHub auth hiccups - Setting correct access rights was hard. (I’ll dig into the hacky fix in the next article.)
• Nice touch: the agent pipes terminal output straight into the chat pane, so I didn’t need to tail logs in a separate window.

Below some of the quirks I hit:

Bottom line: Firebase Studio works, but expect sluggish Android emulator, storage quotas, and the occasional phantom SDK glitch. Keep your repo pushed, caches light, and patience handy.

9. Key Takeaways - Part 2 ✅

• Keep task.md alive. It’s the agent’s working brain, every plan, blocker, and fix lives here. Keep it up-to-date so the Control loop never loses track.
• Split tasks smart. Identify where the AI agent really shines and steer your task list to match its strengths.
• Manual native setup. You handle iOS/Android configs, signing, and entitlements.
• Feed visuals. The agent is blind → give UI references and screenshots.
• Tight commits. Small, atomic steps keep bugs cheap to fix.

These aren’t magic switches the AI flips by itself, they all rely on clear rules and scoped tasks you write up front in /rules and task.md. It’s human work first, every project, every time.

Next Up - Keep It Safe:

So the AI agent can blast through mobile code but shipping it means locking secrets tight and keeping your pipeline bulletproof.

In Part 3, I’ll break down how I managed GitHub PATs, Firebase configs, signing keys, and real device testing. You’ll see exactly how my CI/CD flow kept the agent honest and my keys secure.

💬 I’m still refining how I scope tasks and split what the agent does vs. me. What’s worked (or backfired) in your dev flow? Might borrow a trick!

👉 Stay tuned - Part 1 → Here | [Part 3 → Coming Soon] | [Part 4 → Coming Soon]