Forem: Yashas Mahadev

AI-Assisted QA with Playwright Agents: Key Points Developers Should Remember

Yashas Mahadev — Fri, 15 May 2026 06:57:56 +0000

End-to-end testing has improved a lot with tools like Playwright, but maintaining tests is still painful.

Selectors break.
UI changes.
CI fails.

Someone has to debug the same flaky test again.

That is where Playwright Agents become interesting.

I recently came across this useful GeekyAnts article on AI-assisted automation with Playwright Agents. I’m not associated with GeekyAnts in any way, but the article gives a good overview of how AI can support modern QA workflows instead of just generating random test code.

What Are Playwright Agents?

Playwright Agents are AI-assisted helpers that support the testing lifecycle.

They mainly work through three agents:

1. Planner
The Planner explores the app and creates a test plan.

Instead of directly writing code, it helps define:

what should be tested
which user flows matter
what scenarios should be covered
what edge cases might be missed

This is useful because good automation starts with good test planning.

2. Generator

The Generator turns the test plan into actual Playwright test files.

This can save time when creating repetitive test cases, especially for flows like:

login
checkout
onboarding
dashboard validation
form submission

But generated tests still need review. AI can write code, but it does not always understand product intent.

3. Healer

The Healer helps fix failing tests.

For example, if a button text or selector changes, the Healer can inspect the failure and suggest updates.

This is powerful, but it should not be blindly trusted. Sometimes a failing test means the product is broken, not the test.

Key Points to Remember

AI can speed up test creation, but it should not replace test strategy.
Playwright Agents are useful because they interact with the real application, not just static code.
Seed tests help agents understand where to start.
The Planner is useful for coverage.
The Generator is useful for speed.
The Healer is useful for maintenance.
Human review is still required before merging generated or healed tests.
Prefer stable locators like getByRole() instead of brittle CSS selectors.
A healed test should preserve the original test intent, not weaken it.

My Take

The most exciting part of Playwright Agents is not that AI can write tests.

We already had that with general AI coding tools.

The real value is that Playwright Agents fit into a testing workflow:

Plan → Generate → Run → Heal → Review

That makes them more practical for developers and QA engineers.

I do not see this as AI replacing QA. I see it as AI reducing boring maintenance work so teams can focus more on coverage, reliability, and release confidence.

Final Thought

Playwright Agents are worth exploring if your team already uses Playwright or struggles with flaky end-to-end tests.

Just remember: AI-assisted testing is still software testing.

You need clear test intent, readable code, stable locators, and human judgment.

AI can help you move faster, but quality still depends on how carefully you use it.

You Can Wire Up a Flutter AI Chat in 30 Minutes. Getting It to Actually Work Takes Much Longer.

Yashas Mahadev — Tue, 12 May 2026 07:18:20 +0000

Most developers building an AI chat assistant in Flutter hit the same wall at roughly the same time. The prototype is done in an afternoon. LlmChatView, a GeminiProvider, an API key ,it's genuinely that fast. The Flutter AI Toolkit, introduced by the Flutter team in December 2024, makes the entry point low enough that almost anyone can get a working chat screen in one sprint.

Then the real requirements arrive: conversation memory that persists between sessions, graceful error handling when the API quota is hit, streaming responses that don't freeze the UI under load, and behavior that stays consistent across Android, iOS, and web without platform-specific hacks. That's a different project entirely.

As of 2025, 78% of global companies report using AI in their business, with 71% leveraging generative AI in at least one business function. Every product team with a Flutter app now has someone asking why theirs doesn't have an AI assistant yet. The pressure to ship fast is real. What's less visible is how much of the hard work happens after the first demo.

The gap is not a Flutter problem. It's a scoping and architecture problem that Flutter's excellent tooling makes easy to ignore until it isn't.

Where Flutter AI Assistants Break First

The first failure mode teams hit is state management during streaming. Gemini and other LLM APIs stream responses token by token ,which is exactly what makes chat UIs feel alive. But managing BLoC or Riverpod state while a streaming response is in flight, while also handling user interruptions, while also keeping the scroll position locked to the latest message, is not a solved problem with a clean tutorial.

Managing chat state while maintaining a smooth UX is genuinely tricky ,specifically: showing user messages immediately as an optimistic update, then entering a loading state, then streaming the AI response, all without jank or race conditions.

The second failure mode is error handling. LLM APIs fail in ways that native APIs don't: quota exhaustion, content policy blocks, network timeouts mid-stream. The Gemini API can fail for various reasons including network issues, quota limits, and content blocking ,and each case needs specific handling rather than a generic catch block. Teams that wire up a single try/catch and call it done discover this the first time a paying user hits the wall and gets a blank response with no feedback.

The third is memory. Long conversations consume significant memory in Flutter's widget tree if message lists aren't managed carefully. Large AI responses can freeze the UI during rendering ,the fix is using ListView.builder for efficient scrolling rather than building the entire message list upfront. It's a simple fix, but it's the kind of thing that only surfaces under real load, not in the demo with five test messages.

For teams working through these fundamentals, GeekyAnts' documented approach to Flutter and ChatGPT integration covers how AI capabilities layer onto the Flutter development workflow ,including where the integration points introduce new engineering constraints that teams need to plan for explicitly.

The Architecture Nobody Plans For

Once the basic chat UI is working, teams run into the architectural decisions they didn't make upfront: how conversation history is structured, how it persists between app sessions, and how the system prompt is designed to keep the assistant on-task.

The Flutter AI Toolkit handles multi-turn chat out of the box through its history management API ,but storing and retrieving that history between sessions is the developer's responsibility. Teams that don't plan the serialization layer from the start end up with a chat assistant that forgets everything when the app is killed. For B2B applications ,internal tools, support assistants, domain-specific copilots ,that's not a minor UX issue. It breaks the core value proposition.

System prompt design is the other underestimated layer. AI in Flutter apps works best when it complements rather than complicates ,the most effective implementations build experiences that feel consultative rather than transactional. Getting there requires a system prompt that constrains the model's behavior clearly, not just a bare API call. Teams that skip this ship assistants that answer anything, drift off-topic, and produce responses that don't fit the app's context or tone.

The GeekyAnts technical write-up on how LLM memory has evolved from context windows to knowledge graphs is worth reading here ,not because every Flutter chat app needs a knowledge graph, but because understanding how memory and context work in LLM systems changes how teams design their history management and session architecture. The decisions that matter are the ones made before the first sendMessageStream call.

For production architecture patterns in Flutter AI apps specifically, FlutterGeekHub's coverage of Flutter AI MVPs documents why teams building cross-platform AI products are choosing Flutter ,and what architectural patterns are proving durable in production versus those that work only in controlled environments.

Cross-Platform Is the Hidden Tax

Flutter's single codebase promise holds. What it doesn't eliminate is the testing surface across platforms. An AI chat assistant behaves differently on Android and iOS in ways that aren't always obvious until the app is in users' hands.

Voice input permissions work differently. File attachment handling varies. The keyboard behavior during streaming responses affects scroll position management differently on different platforms. Different behavior between Android and iOS is a real challenge during Flutter AI chat development ,particularly around input handling and rendering when streaming responses include formatted text like markdown or code blocks.

The flutter_ai_toolkit supports Android, iOS, web, and macOS ,the AI Toolkit is organized around an abstract LLM provider API that makes it easy to swap out the LLM provider while supporting cross-platform compatibility across Android, iOS, web, and macOS. But cross-platform support in a library doesn't mean cross-platform testing is free. Teams that test only on their primary platform ship platform-specific bugs to everyone else.

TensorFlow Lite models under 10MB provide excellent performance for on-device inference while maintaining reasonable app size constraints ,relevant for teams considering hybrid architectures where some AI processing happens on-device for latency or privacy reasons, rather than routing everything through a cloud API. That decision, made early, affects the entire delivery architecture.

FlutterGeekHub's reporting on cross-platform development in 2026 covers how enterprise teams are managing platform-specific delivery expectations while maintaining a single codebase ,including the testing infrastructure decisions that make this sustainable rather than a continuous firefight.

What Actually Ships

The Flutter AI chat assistants that reach production and stay reliable share a few observable patterns.

They separate the LLM provider configuration from the chat UI layer from the start ,so swapping from Gemini to another model, or from the Google AI endpoint to Vertex AI for production, doesn't require rearchitecting the app.
They build the history serialization layer in sprint one, not as a retrofit after the feature is "done."

Teams that GeekyAnts has documented working on Flutter AI applications consistently treat the offline-first architecture and session persistence decisions as foundational ,not features to add later. An AI chat assistant that loses context when a user switches apps is a support ticket waiting to happen.

The evaluation gap also matters here. Most teams test "does it respond?" They don't test "does it respond appropriately under all error conditions?" Building a test matrix that covers quota exhaustion, content blocks, mid-stream network drops, and empty retrieval results is unglamorous work that separates a demo from a deployable feature.

The real advantage of combining Flutter with AI integration is building once and running the AI logic and UI everywhere ,Flutter allows developers to write the AI logic and UI once and run it across Android, iOS, and web, which matters particularly for agentic apps that need to handle multi-step workflows with consistency across platforms.

The 30-minute version of this feature is real. The production version requires deliberate architectural decisions about state, memory, error handling, and platform behavior ,most of which need to be made before the first line of UI code gets written.

That's the actual scope of building an AI chat assistant in Flutter. The toolkit makes the easy part easier. The hard part is still engineering.

Scaling Flutter Apps Beyond 100K Users

Yashas Mahadev — Wed, 06 May 2026 07:28:14 +0000

You launch your Flutter app. It performs great in beta. Onboarding goes well. Then, somewhere between 50K and 150K users, things start breaking in ways your local tests never predicted.

API responses slow down. State updates trigger unnecessary widget rebuilds. App size complaints start showing up in reviews. Your CI pipeline begins to feel like it is held together with tape.

This is not a Flutter problem. It is an architecture and discipline problem. Flutter is fully capable of scaling,but only if your codebase is built with growth in mind from an early stage. Most teams do not plan for that, and they pay for it later.

Here is what actually goes wrong, and what you can do about it.

Why Scaling Flutter Is Harder Than It Looks

Performance Bottlenecks Surface Late
Flutter's widget tree is efficient by design, but "efficient by design" does not mean "efficient by default." As screens grow more complex and data volumes increase, you start seeing jank in animations, slow list rendering, and expensive layout passes. These issues rarely appear during development when you are working with mock data and a single test device.

State Management Becomes a Liability
Many teams start with setState or a basic Provider setup. That works fine for small apps. But as feature count grows, you end up with deeply nested state, scattered logic, and rebuilds that ripple through the entire widget tree. Debugging becomes painful. Predictability disappears.

API Latency Compounds
At a small scale, you can get away with blocking calls and simple HTTP requests. At 100K users, you need caching, retry logic, and background syncing. Without these, users on slow connections churn. And churn at scale is expensive.

App Size and Cold Start Time
Flutter's engine adds baseline weight to your binary. Add in unoptimized assets, unused packages, and debug symbols left in production builds, and you are looking at a bloated APK or IPA that hurts install rates,especially in markets with lower-end devices.

Commit to a Real Architecture

The single most impactful decision you can make is choosing an architecture that enforces separation of concerns. Clean Architecture is the most commonly adopted pattern in large Flutter codebases, and for good reason.

By separating your domain layer (business logic), data layer (repositories, APIs), and presentation layer (widgets, view models), you can test each layer independently, replace implementations without cascading changes, and onboard new developers without handing them a maze.

MVVM is a practical middle ground if full Clean Architecture feels premature. The key is that your widgets should not know where data comes from. They should only know how to display it.

Optimize Widget Rebuilds

The build method in Flutter is called far more often than most developers realize. Every setState call triggers a rebuild of the widget and its entire subtree.

Use const constructors wherever possible. Break large widgets into smaller ones,not for cleanliness, but so rebuilds are scoped to the smallest possible subtree. Use RepaintBoundary to isolate expensive rendering from the rest of the tree. Profile with Flutter DevTools' Performance overlay before assuming you know where the bottleneck is.

`// Instead of this:
class ProductCard extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        HeaderWidget(),  // rebuilds every time ProductCard rebuilds
        PriceWidget(),
        ActionButtons(),
      ],
    );
  }
}// Break them out and mark leaf widgets as const where possible
const PriceWidget({ super.key, required this.price });`

Choose State Management With Scalability in Mind

For apps beyond early stage, Bloc and Riverpod are the two most production-proven choices.

Bloc enforces a strict event-state model. Every state change is explicit, testable, and traceable. It adds boilerplate, but at scale that boilerplate is documentation. Teams can look at any Bloc and understand exactly what inputs produce what outputs.

Riverpod offers more flexibility with less ceremony. Its compile-time safety and provider scoping make it easier to manage feature-level state without global pollution. It is a good fit for teams that find Bloc's structure too rigid.

Avoid lifting everything to a global state. Use scoped providers or feature-level Blocs to keep state close to where it is used.

Handle API Calls Like a Production System

At scale, your data layer needs to handle failure gracefully. That means:

Implementing exponential backoff on retries
Caching aggressively with packages like dio_cache_interceptor or custom Hive-backed repositories
Using pagination instead of loading full datasets
Canceling in-flight requests when users navigate away

A pattern worth adopting early is the Repository pattern with a clear contract: your UI always talks to the repository, never directly to an HTTP client. This makes swapping caching strategies or API versions a single-file change.

abstract class ProductRepository {
  Future<List<Product>> getProducts({int page = 1});
}

class CachedProductRepository implements ProductRepository {
  final RemoteDataSource remote;
  final LocalDataSource cache;

  @override
  Future<List<Product>> getProducts({int page = 1}) async {
    final cached = await cache.getProducts(page);
    if (cached.isNotEmpty) return cached;
    final fresh = await remote.fetchProducts(page);
    await cache.saveProducts(fresh, page);
    return fresh;
  }

}

Monitor Performance in Production

You cannot fix what you cannot measure. Integrate Firebase Performance Monitoring or a similar tool from day one. Set up custom traces around critical user flows,checkout, search, auth,and track them as the user base grows. Pair this with Crashlytics or Sentry for error tracking.
Flutter DevTools is excellent for local profiling, but production behavior is different. Real devices, real network conditions, and real data volumes will surface issues your simulator never will.

How Production Teams Approach This

Teams that have shipped Flutter apps to hundreds of thousands of users tend to share a few common practices. Architecture decisions are made before feature development begins, not after performance problems appear. State management strategy is a team-wide agreement, not a per-developer preference. Testing is written at the unit and integration level for business logic, not just UI.

Agencies that specialize in cross-platform development at scale, like GeekyAnts, often front-load architecture reviews and establish code standards before any feature work starts. The reasoning is simple: refactoring state management across 80 screens is far more expensive than getting it right across 10.

The pattern holds regardless of team size,thoughtful early decisions reduce compounding technical debt.

Common Mistakes to Avoid

Rebuilding the entire tree on every state change. If your root widget holds all the state, every update rebuilds everything. Structure state to live as close to its consumers as possible.

Ignoring image optimization. Uncompressed assets are one of the fastest ways to bloat your app size and slow rendering. Use flutter_image_compress, cache network images with cached_network_image, and avoid loading full-resolution images in list views.

No separation between data and UI logic. When widgets contain business logic, you cannot test that logic in isolation. You also cannot reuse it. Keep widgets dumb and logic in dedicated classes.

Skipping performance profiling until something breaks. By then, the problem is structural and harder to fix. Run a profiling session at the end of every major feature sprint.

Treating architecture as optional. Small teams sometimes skip architecture in favor of speed. This works until about 20K lines of code, and then it does not.

Takeaways

Scaling Flutter is not about finding magic packages or following a rigid blueprint. It is about making deliberate decisions early: pick an architecture that enforces separation of concerns, choose a state management approach your whole team understands, treat your data layer like a production service, and measure before you optimize.
The apps that hold up past 100K users are not necessarily the ones built fastest,they are the ones built with the assumption that growth would happen.
Plan for it from the start. You will spend far less time debugging at scale.