DEV Community: GeekyAnts India Pvt Ltd

From Prompting to Process: What Changed When Flutter Shipped Agent Skills

GeekyAnts India Pvt Ltd — Mon, 28 Sep 2026 11:44:01 +0000

Google is starting to ship Flutter's engineering workflows as machine-readable guidance for AI agents. It may look like another AI feature, but it hints at a much bigger shift in how teams build with Flutter.

The Consistency Problem

Over the past few years, AI coding tools like Cursor, Claude Code, Copilot, and OpenCode have become part of many developers' daily workflows. They produce code, explain unfamiliar APIs, write tests, and navigate large codebases with impressive accuracy.

But if you have been using them on a reasonably large project, you have probably noticed something.

They are not very consistent.

Ask an AI to implement the same feature in two different sessions, and there's a good chance you will get two different approaches. Switch models, and the implementation changes again. Sometimes it follows the latest framework recommendations. Other times, it relies on outdated patterns.

Most teams respond the same way: write better prompts, add repository rules, or create a custom skill.md files to steer the agent toward the right decisions.

We took the same approach by documenting our architecture, coding conventions, review expectations, and engineering practices as custom Skills. They made the agent noticeably more consistent.

So when Flutter announced official Agent Skills, my first reaction was not: "How do we use them?" It was: "If we already have our own Skills, what problem are Flutter's official Skills actually solving?"

That question turned into a couple of experiments.

Three Layers of AI-Assisted Development

Looking back, Flutter's recent AI investments weren't isolated features. They were building on each other.

First came Rules, giving teams a way to define project-specific conventions and preferences.

Then came Model Context Protocol (MCP), allowing AI agents to inspect, debug, and interact with running Flutter applications instead of reasoning purely from static code.

And then came Agent Skills.

If Rules tell an agent how your team works, and MCP tells it what's happening inside your application, Agent Skills answer a different question: how does Flutter itself recommend solving this problem?

That is the important shift.

Flutter is now versioning its engineering workflows alongside the framework itself. Instead of relying entirely on what an AI model happened to learn during training, agents can follow workflows maintained by the Flutter team.

Today, those workflows cover areas like:

Localization
Responsive layouts
Routing
Widget and unit testing
Static analysis
JSON serialization
Platform integration
Architecture best practices

In other words, Flutter is shipping its engineering knowledge as structured workflows.

That naturally led to the next question: does this actually change how an AI agent behaves?

I ran two experiments to find out.

First Experiment: Declarative Routing

It is one of those features where there is not just one thing to do. Depending on the prompt, an AI could jump straight into writing routes, miss platform-specific configuration, skip deep linking altogether, or recommend an approach based on what it learned during training rather than Flutter's latest guidance.

So I kept the prompt intentionally simple:

"Set up declarative routing for this Flutter application."

I wanted to see how the agent would approach the problem before I told it how to solve it.

The first thing it did caught my attention.

Before generating an implementation plan, it explicitly selected the flutter-setup-declarative-routing skill.

Show Image

From that point on, it was not about figuring out a solution; it was following Flutter's own workflow.

That was the interesting part.

Without Agent Skills, the implementation depends on the model's reasoning and whatever Flutter knowledge it has internalized. With Agent Skills, the framework itself becomes the starting point.

What happens when Flutter's Skills and our own Skills are both available?

I tested this with a login screen.

It needed:

Flutter's localization workflow
Our project conventions for authentication, repositories, dependency injection, and state management

I kept the prompt simple and let the agent decide how to approach it -

"Implement a login screen for this application. Follow the existing project architecture and add localization for all user-facing strings.

It picked the right source every time.

For localization, it used Flutter's official Skill. For everything related to our application architecture, it followed our custom Skills. I did not have to tell it which one to use or write a carefully engineered prompt.

The two sets of Skills worked together naturally. Flutter handled the framework guidance, while our repository continued to define how our application was built.

Show Image

Why This Matters: A Floor, Not a Finish Line

So, what actually changed?

Flutter is taking ownership of its engineering expertise.

Engineering teams no longer need to teach AI how Flutter expects routing, localization, responsive layouts, or testing to be implemented. Flutter now ships that knowledge itself.

That removes a significant amount of duplication. Instead of every team maintaining its own version of Flutter best practices inside prompts or custom Skills, the official workflows become the source of truth.

Even better, those workflows evolve alongside Flutter. As recommendations change, the official Skills change too, and every compatible AI agent benefits automatically.

Of course, that's only half the story.

Flutter's Agent Skills provide a strong foundation, but they do not replace your organization's architecture, coding standards, or business-specific workflows. Those remain your responsibility, and that is exactly how it should be.

Final Thoughts

Looking back, Flutter's recent AI features fit together surprisingly well.

Rules capture how your team works. MCP gives agents runtime context. Agent Skills teach them how Flutter itself expects problems to be solved. Custom Skills layer on everything unique to your organization.

Together, they reduce the amount of engineering knowledge an AI has to infer. That is the real significance of Flutter's recent AI investments. Engineering knowledge is becoming explicit, versioned, reusable, and maintained by the people best positioned to own it.

Today's skill library covers foundational workflows, but it already hints at what's possible. Imagine Skills for performance profiling, DevTools workflows, accessibility audits, plugin development, migrations, or advanced rendering patterns. Every new skill moves another piece of framework knowledge out of documentation and into a reusable workflow.

The answer to how much of Flutter an agent should really guess keeps shrinking with every release.

Feature Flags as Technical Debt: The Cleanup Nobody Schedules

GeekyAnts India Pvt Ltd — Mon, 28 Sep 2026 08:46:47 +0000

Feature flags are one of the cheapest tools in engineering to adopt and one of the most expensive to leave unmanaged. Teams use them for gradual rollouts, A/B tests, kill switches, and gating unfinished work, but few teams have a matching process for removing them once they have served their purpose. As a result, flags that were meant to be temporary become permanent, adding unnecessary complexity to the codebase.

This article explains why flag cleanup gets skipped and why it creates a real engineering cost. It also walks through a staleness-detection implementation, a flag-removal exercise, and a practical checklist for managing flags across their full lifecycle, from creation to removal.

Why Flags Are Easy to Add and Hard to Remove

Adding a flag is a small, fast PR. Wrapping a block of code in a conditional and wiring it to a config value takes minutes, and it ships in the same PR as the feature it gates — there's no separate approval step, no extra review, no reason for anyone to push back. Removing a flag involves a different kind of work. You have to find every place it is checked, including references in logging, analytics, and monitoring code, confirm which branch is now permanently "on" or "off," delete the dead branch, update or delete the tests that covered it, and verify that nothing downstream depends on the old behavior. This multi-step effort competes with new feature work for the same sprint capacity, so cleanup often gets pushed to a later sprint until the flag becomes a permanent part of the codebase.

There's also a confidence problem. Once a flag has been live for months, the person who added it may have moved teams, changed roles, or forgotten why it was added. Removing the conditional can feel risky when its dependencies are unclear, so teams may leave it in place. That decision can turn a two-week release flag into a permanent part of the codebase.

Underneath both of these is a structural gap: a flag rarely comes with a ticket, an expiry date, or a named owner responsible for its removal. By default, creating a flag does not create a corresponding task to revisit it later. Without documented future work, the flag can remain in place. Meanwhile, teams add new flags every sprint while removing few of the old ones, so the backlog grows and cleanup becomes more complex as additional flags enter the same code paths.

The Flag Lifecycle

The diagram below lays out the full path a flag should take, from creation to retirement. The critical fork sits in the middle of the diagram: once a flag reaches "stable at 100%," it either gets caught by an automated staleness check and routed to a removal PR, or it gets ignored and drifts into permanent technical debt. Most flags fail at exactly this point — not because removal is technically difficult, but because nothing in the default engineering workflow forces the question to be asked. Without an automated trigger, a flag can sit at "stable" for years with nobody ever explicitly deciding to leave it that way; it simply never comes up.

Figure 1: The feature flag lifecycle, from creation through rollout to either scheduled removal or stale limbo.

Why This Is a Real Cost, Not Just Clutter

Each independent binary flag can double the number of possible runtime states. A function gated by three independent flags can have up to eight possible states, but teams may have designed or tested only a subset of those combinations. The remaining states can introduce interactions that were not considered during development or testing.

Stale flags can create bugs through untested interactions. Two flags that are each considered "basically always on" can still interact in a combination the team did not anticipate. If the team assumes that only one meaningful state is live, that interaction may not be covered during testing or code review and can surface only under production traffic.

New engineers may avoid code affected by unfamiliar flags. When it is unclear which flags are critical and which can be removed, team members may work around that code rather than risk breaking an unknown dependency. This can slow down simple changes and introduce workarounds that add further complexity.

The number of dependencies can grow the longer a flag remains in place. Flag checks can extend into related systems, including analytics events tied to flag state, log lines that reference the flag, monitoring dashboards built around it, and configurations in other services. As these dependencies accumulate, removing the flag can require changes across several parts of the system.

Not All Flags Are the Same

A major reason cleanup gets mishandled is that teams treat every flag the same, even though the appropriate lifespan depends on why the flag exists. Classifying a flag at creation establishes its expected lifespan and removal requirements before the original context is lost.

A release flag usually lasts from a few days to a few weeks and is used to gate an in-progress feature during development and rollout. Its cleanup urgency is high, so it should be removed once the feature has reached 100% rollout and the release has stabilized. An experiment flag typically remains active only for the duration of a test, such as an A/B experiment or a gradual, data-driven rollout. Its cleanup urgency is also high, and it should be removed as soon as the experiment concludes, regardless of the outcome. An ops or kill-switch flag, by contrast, is designed to remain in place indefinitely. It acts as a manual override for risky dependencies or emergency controls, so it does not need immediate removal. Instead, it should be reviewed periodically to confirm that it is still necessary and working as intended.

This highlights a common cleanup problem: a release or experiment flag with a short intended lifespan can receive the same caution as an ops kill switch designed to remain in place. That mismatch can turn a two-week flag into a permanent one.

Building the Staleness Detector

The checklist below recommends automating staleness detection, so it helps to show what that implementation looks like. The following example presents the core logic, simplified for readability. In practice, it receives data from the flag provider in use, such as LaunchDarkly, Unleash, or a homegrown configuration table, with each flag providing a rollout percentage, type, and the length of time its state has remained unchanged.

Two design choices here matter more than the code itself:

Thresholds are per-type, not global. A single "flag unchanged for 90 days" rule either fires constantly on ops flags that are correctly untouched, or lets release flags rot for far too long. Splitting the threshold by type — pulled directly from the classification the team should already be doing at creation — makes the report something people trust instead of something they learn to ignore.

The report identifies UNASSIGNED owners. An unowned stale flag has no person or team responsible for acting on the report, which can leave it in the codebase without a clear path to removal. Surfacing that ownership gap instead of defaulting to "team lead" makes responsibility for cleanup visible.

Wiring this into a weekly Slack post or a lightweight internal dashboard, including a spreadsheet as a starting point, turns staleness into something the team reviews on a fixed cadence rather than discovers during an unrelated investigation.

Removing a Stale Flag: A Worked Example

Detection is only half the problem. Deleting a flag safely requires a defined procedure because missed dependencies can create production issues. The sequence below shows how to remove a release flag that has remained at 100% for several weeks, using a checkout-discount flag as an example.

Confirm the resolved state, not just the current one. Check the flag's rollout history, not just its current value — a flag sitting at 100% today that was flipped back to 0% twice in the last month is not actually stable, regardless of what the staleness report says this week.
Search for every reference, not just the obvious one. A project-wide search for the flag's key (checkout_discount_v2) can reveal references beyond the if branch in the checkout service, including a log line that prints the flag's value, an analytics event property, and a conditional in a monitoring dashboard's alert query. All of these references need to be accounted for so the cleanup does not leave dead references behind.
Delete the dead branch, not just the flag check. Before removal, the code checks the flag and branches between apply_discount_v2(cart) and apply_discount_legacy(cart). After removal, it calls apply_discount_v2(cart) directly, with both the flag check and the unused branch removed. Leaving both branches as dead code "just in case" preserves unnecessary code outside the flag inventory. If apply_discount_legacy has no other callers, remove it as well.
Remove the tests for the dead branch, not just add tests for the surviving one. The legacy-path test coverage is now testing code that no longer exists in any reachable state; leaving it in the suite either silently rots (mocking a function that's been deleted) or keeps a maintenance burden alive for behavior nobody can trigger anymore.
Ship it as its own PR, reviewed as a deletion. Bundling flag removal into an unrelated feature PR can reduce the attention given to the search results from step 2. A standalone "remove checkout_discount_v2" PR keeps the review focused on deletion. Any addition in that diff warrants additional review. This procedure is often undocumented, which can make cleanup PRs feel riskier than they are.

When Cleanup Doesn't Happen: A Technical Walkthrough

The scenario below illustrates a failure pattern common enough that most teams running flags at any scale will recognize a version of it, even if the specifics differ. A team adds checkout_discount_v2 to gate a new checkout flow. The rollout succeeds within two weeks and reaches 100% — by every functional measure, the flag has done its job. But it stays in the code for over a year, because removal was never written into any ticket and nobody was assigned to come back to it.

Months later, a second flag, checkout_pricing_experiment, is added to the same checkout path for an unrelated pricing test. It runs after the discount flag: it takes whatever total the discount logic produced and applies an experimental pricing adjustment on top. Individually, each flag was tested and behaved correctly. However, apply_experimental_pricing was written and reviewed under the assumption that total came from apply_discount_legacy. By that point, checkout_discount_v2 had remained at 100% long enough that engineers working on the checkout path no longer considered it a meaningful variable, even though it remained in the code and continued to execute.

apply_discount_v2 returned a total that had already been floored to two decimal places; apply_discount_legacy had not. apply_experimental_pricing applied a percentage multiplier and then rounded. This worked with apply_discount_legacy's unrounded output but could produce an off-by-one-cent total with apply_discount_v2's pre-rounded output for a narrow set of cart values. This type of bug can escape testing when no test covers the combination of two flags operating on the same code path. The fix required a two-line change to apply rounding consistently in one place. The greater cost came from the bug reaching production and requiring someone to identify a cent-level discrepancy in reconciliation data and trace it through a code path that was not expected to contain two active flags. This is the pattern the checklist below is designed to prevent: the gradual accumulation of untracked complexity that can lead to production issues.

Build vs. Buy: Tooling Trade-offs

Teams generally use one of three approaches for flag management, and the right choice depends less on team size than on how comfortable the organization is with an external SaaS dependency in the request path.

A managed feature flag platform, such as LaunchDarkly, provides rich targeting rules, built-in audit logs and change history, and features for identifying stale flags or monitoring usage with relatively little setup. The tradeoff is recurring cost, which can increase with seats or monthly active users. It also introduces another network dependency into the request path, and while the platform may identify stale flags, someone still needs to own and act on that cleanup.

An open-source, self-hosted platform, such as Unleash, avoids per-seat licensing costs and gives teams greater control over data residency and customization. However, the engineering team becomes responsible for operating the flag service, including uptime, upgrades, maintenance, and scaling. These platforms may also provide fewer built-in insights than managed alternatives unless additional monitoring and reporting are configured.

A homegrown configuration table keeps the setup simple because it does not require introducing a separate feature flag platform. Teams can query the data directly and build custom staleness reports, such as the automated cleanup check described above. The downside is that there is usually no dedicated interface or audit trail unless those capabilities are built intentionally. Targeting logic can also spread across the codebase over time if it is not kept centralized.

The staleness detector shown earlier works with all three approaches because it requires only a list of flags with a rollout percentage and a last-modified timestamp. This keeps the implementation compatible with each approach. Managed platforms may expose this information through a report or webhook, while the other two approaches can use the script above or a similar implementation. The tooling decision affects how much the team needs to build, but each approach still requires a process for detecting stale flags and assigning cleanup work.

A Practical Checklist for Managing Flag Lifecycle

Each step below maps directly to a stage in the feature flag lifecycle. Together, they turn the lifecycle from a diagram into a process that teams can follow consistently.

1. Classify at creation. Every flag should be tagged as a release, experiment, or ops flag when it is created. This establishes the expected lifespan and removal requirements from the beginning.

2. Assign an owner and expiry. Each flag should have a named person or team responsible for it, along with a target removal date, even if that date is approximate. Without clear ownership or a deadline, a flag can remain in the codebase indefinitely without a defined cleanup path.

3. Bake removal into the ticket. Flag removal should be included in the original story's definition of done. This prevents cleanup from becoming a separate task that has to compete for priority later.

4. Automate staleness detection. Teams should run scheduled checks for flags that have remained at 0% or 100% rollout beyond their type-specific staleness threshold. This makes stale flags visible without relying on someone to remember them manually.

5. Maintain a flag inventory. A central dashboard should track every live flag, including its type, owner, and age. This gives teams a quick answer to questions such as how many flags are active and which ones may need attention.

6. Establish a recurring review cadence. Teams should review flag ownership and staleness data monthly or quarterly. Regular reviews help catch neglected flags before they accumulate into a larger cleanup backlog.

7. Prioritize removal PRs. Pull requests that remove obsolete flags should be treated as focused cleanup work. Because these changes primarily remove code rather than add new behavior, they can often have a narrower review scope while reducing unnecessary complexity in the codebase.

A note on step 2: individual ownership can become outdated when the named owner changes teams or leaves the company. Tying ownership to a service or feature area rather than a specific person provides continuity when personnel change and reduces the risk of flags becoming orphaned.

Closing Thought

Feature flags are useful, but flag creation represents only part of their lifecycle. A temporary flag without a removal plan can become a permanent addition to the codebase and increase its complexity over time.

Closing that gap requires a per-type staleness threshold, a script that checks it on a schedule, and a removal procedure that treats deletion PRs as part of planned engineering work. This approach builds removal into the same process as creation, classifies flags by type when they are created, and uses automated staleness checks to identify flags that require attention. Together, these changes make flag removal part of the same engineering process as flag creation.

Make Feature Flag Cleanup Part of the Engineering Lifecycle

Feature flags work best when removal is treated as part of the same engineering lifecycle as creation and rollout. Clear ownership, type-specific staleness checks, scheduled reviews, and focused removal PRs help teams prevent temporary controls from becoming permanent technical debt. For teams looking to strengthen these practices across deployment, automation, monitoring, and production operations, GeekyAnts’ DevOps consulting services provide support across the software delivery lifecycle.

The Bug That Doesn't Show Up in Code Review: Why Your Flutter Web App Reloads on Safari

GeekyAnts India Pvt Ltd — Mon, 28 Sep 2026 06:46:46 +0000

Demo example app*:* github.com/manuindersekhon/flutter-image-memory-demo

AI-assisted teams now ship correct code faster than ever. But this article is about a class of failure that is not in the code at all. It lives in the gap between what the code says and what the device actually does. And that gap is exactly where all the velocity we gained gets eaten back.

The Bug Report That Made No Sense

Some time back, one of our production apps had a leaderboard. A simple, scrollable list of 100+ players, each row with a name, a score, and a 50x50 profile picture. Nothing fancy.

Then the bug reports started coming in.

“The leaderboard page keeps refreshing on Safari.” “The app closed by itself on my iPhone while scrolling.” No error in the console. No crash log with a stack trace. Nothing reproducible on our development machines. The page would simply reload on Safari as if the user had pressed refresh, and on iOS the app would just disappear.

Two different platforms, two different symptoms, and as it turned out, one single bug. One that no code review could have caught.

The Code That Passed Review

Here is the code at the centre of it. This is roughly what our leaderboard row looked like:

ListTile(
  leading: CircleAvatar(
    radius: 25,
    backgroundImage: NetworkImage(user.avatarUrl),
  ),
  title: Text(user.name),
)

Take a moment and review it. It compiles. It is an idiomatic Flutter, straight from the documentation. The analyzer is happy. It renders perfectly on the MacBook and in every demo. Whether a teammate wrote it or an AI agent generated it, any of us would have approved this diff.

Nothing in the code is wrong. The defect only exists at the intersection of three layers that no code-level reviewer is looking at: what the backend serves, what the image decoder does with it, and what the device does when memory runs out.

Layer One: What the URL Actually Returns

Our users uploaded their profile pictures from their phones. A modern phone camera produces a 12-megapixel image, around 4032x3024 pixels, a few MB of JPEG. Our backend stored it exactly as uploaded, and the avatar URL served it exactly as stored.

The UI contract says “50 pixel avatar”. The API contract says “whatever the user uploaded”. There is no type system, no lint rule, and no review checklist that connects these two, and that mismatch travels silently all the way to the user's device.

Layer Two: File Size Is Not Memory Size

This is the part of image handling that is easy to forget. A JPEG is a compressed format, but a screen cannot draw compressed bytes. Before anything is rendered, the image is decoded into a raw bitmap: four bytes for every pixel.

So that 3 MB JPEG from the user's phone becomes 4032 x 3024 x 4 bytes, which is about 46.5 MB of memory. For one avatar. In a 50-pixel circle.

And here is the key Flutter behaviour: unless you tell it otherwise, Flutter decodes an image at its full intrinsic size, not at the size of the widget displaying it. The CircleAvatar's 50-pixel constraint never reaches the decoder. The full bitmap is decoded, kept, and scaled down on every frame.

To verify this, we built a small demo app that recreates the leaderboard and prints what the engine actually holds for each image. This is not theory, this is the app reporting its own image cache:

The demo leaderboard in Chrome. The bar at the bottom is the app reporting its own decoded image memory: avatar #1 is held at 4032x3024, 46.51 MB, for a 50px circle.

Multiply that by a leaderboard. Scrolling through 100+ entries asks the engine for several gigabytes of decoded bitmaps. Flutter's built-in image cache has a 100 MB budget, but that budget only applies to images that are no longer on screen. Images that are currently visible, or kept alive by the layout, are held regardless of it. The cap we were all silently relying on was never going to save us.

Layer Three: Every Platform Has a Ceiling, and They Are All Different

Here is where the story splits by platform, and where “works on my machine” stops being a joke and becomes the actual mechanism of the bug.

Chrome survives this abuse. It decodes images through a dedicated browser API into memory it can discard and re-decode at will. When we scrolled our naive leaderboard in Chrome, the tab stayed around a few hundred MB and nothing bad happened. This is exactly why the bug never appeared on our development machines.

Safari has no such decode path. The decoded bitmaps land inside the tab's own web content process, and WebKit enforces a hard memory budget on that process. On the same page, same scroll, Safari's process climbed to four times what Chrome used. Push further, and WebKit does exactly what its source code says it will do: it kills the web content process and reloads the page.

In our stress test, the process crossed 7 GB and was terminated, and the page came back fresh, exactly the “random refresh” our users reported. Safari even tells the user politely: “This webpage was reloaded because it was using significant memory.”

There is also a subtler symptom on iPads and iPhones. Before killing the page, WebKit fights back by purging decoded images. We watched the iOS Safari process balloon, get purged, and keep running with the leaderboard text intact but every avatar blank:

iOS Safari after WebKit's memory purge: the page survives, but the avatars are silently gone.

And the native iOS app? Same bug, different executioner. iOS enforces a per-app memory budget through a system called Jetsam. The budget depends on the device, community measurements put it under 1 GB on older iPhones and around 2 GB on mid-range ones. A leaderboard holding a few dozen 46 MB bitmaps alive walks into that limit within a couple of screen-heights of scrolling. The app is killed by the OS, not by your code. There is no Dart exception and no useful stack trace, and your crash reporting tool shows an “out of memory session” at best. That was our mysterious iOS crash.

One bug. Three ceilings. Three completely different symptoms.

Why Review Never Had a Chance

Now go back to that CircleAvatar snippet and ask: where in the diff is this bug?

It is not there. The reviewer sees idiomatic widget code. The tests see an image that renders. CI is green. The 46.5 MB number exists only at runtime, on a real device, with real production images. The defect is spread across three systems whose owners never appear in the same pull request: the upload pipeline that stores 12-megapixel photos, the framework default that decodes at intrinsic size, and the platform policy that kills the process.

This is also why the AI angle matters to us. An agent will write you this exact code, and it will be right by every static standard. An AI reviewer will approve it for the same reason a human does: the evidence is simply not in the artifact being reviewed. As AI compresses the cost of writing code, the defects that survive migrate to the layers that neither the agent nor the reviewer can see. The cost does not disappear. It moves to a production incident three weeks later, on a device you do not own.

The Fix Is One Parameter (and a Better One Upstream)

The immediate fix is embarrassingly small. Flutter lets you tell the decoder what size you actually need:

Image.network(
  url,
  width: 50,
  height: 50,
  fit: BoxFit.cover,
  cacheWidth: (50 * MediaQuery.devicePixelRatioOf(context)).round(),
)

// CircleAvatar has no sizing hook, so wrap the provider:
CircleAvatar(
  backgroundImage: ResizeImage(
    NetworkImage(url),
    width: 150,
  ),
)

With cacheWidth set, the same avatar decodes at 150 pixels instead of 4032. In our demo, that took each image from 46.51 MB down to 0.06 MB, roughly 775 times less memory, with zero visible difference in a 50-pixel circle. The whole leaderboard now fits in less than one megabyte of decoded images:

The fixed build: same leaderboard, same photos, 0.8 MB of decoded images in total. The probe shows avatar #1 now decodes at 150x112, 0.06 MB.

But honestly, the client-side parameter is the band-aid. The real fix is to never ship a 12-megapixel file to a 50-pixel widget in the first place: serve resized images from your CDN or an image proxy. That also fixes what cacheWidth cannot, because the full-size download and the browser-side decode of the original file still happen either way. Fix it at the source and every client, including the ones you have not written yet, gets it for free.

Making Sure It Never Comes Back

A bug that review cannot catch needs guardrails that do not depend on review.

The one we wish we had turned on earlier is built into Flutter itself. Set debugInvertOversizedImages to true in your debug builds, and the framework will flip and invert the colours of any image that was decoded significantly larger than its display size, and log the wasted bytes. Our leaderboard lit up like this:

debugInvertOversizedImages in action: the framework flags every avatar that was decoded far larger than the size it is displayed at.

Beyond that flag, a few habits close the loop:

Wrap remote images in one shared widget (an AppAvatar of your own) that requires a decode size, so the naive version cannot be written casually.
Test on the smallest-RAM device you actually support, with production images, not neat little asset placeholders.
When a “random refresh on Safari” or an “app just closed” report comes in, put memory on the suspect list before routing and state management.

Final Thoughts

The most interesting thing about this bug is how ordinary the code was. No clever trick went wrong, no obscure API was misused. A default did exactly what it was documented to do, on inputs nobody in the pull request could see, on devices with limits nobody in the pull request was thinking about.

AI has made the code layer cheap. It has not made the other layers cheap. The asset pipeline, the decoder, the memory ceilings of a five-year-old iPhone, someone on the team still has to own those. The teams that move fastest with AI will not be the ones that generate the most code. They will be the ones who know exactly which questions the diff cannot answer, and go looking for the evidence themselves.

The demo app used for every number and screenshot in this article is open source, and reproduces the whole story, including the Safari reload: github.com/manuindersekhon/flutter-image-memory-demo

What a PHP-to-NestJS Banking Migration Taught Us About Architecture, Security, and Trust

GeekyAnts India Pvt Ltd — Mon, 28 Sep 2026 06:12:26 +0000

Every digital banking platform eventually hits the same wall: the monolith that shipped a decade ago still works, still processes real money for real account holders every day, and still cannot be touched without fear. Ours was a PHP application built with Laravel, serving multiple financial institutions from a single, tightly coupled codebase. It had grown feature by feature, bank by bank, for years. The rewrite wasn’t optional. Every new institution we onboarded meant another branch of conditional logic, another set of hacks specific to one bank bolted onto shared controllers, and another opportunity for one institution’s change to break another’s production environment.

This article covers the architecture decisions we made while rewriting that platform as a multitenant system driven by configuration, and what the migration process taught us about verifying legacy behavior instead of assuming it.

The core decision: separate “what the UI looks like” from “what the business logic does”

The biggest architectural decision was splitting the platform into three layers instead of one: a thin frontend driven by configuration; a backend for frontend (BFF) that owns all business logic, session state, and vendor orchestration; and a config service that serves server-driven UI (SDUI) definitions per institution.

In the legacy system, “multitenant” meant if ($bank === 'X') scattered across views and controllers. Every institution’s quirks lived inside the same PHP files as everyone else’s, which meant every deployment carried the blast radius of every tenant at once. The new architecture inverts that. The mobile and web clients render forms, layouts, and copy from JSON served by the config service, merged through three layers: platform defaults, core banking provider defaults, then tenant-specific overrides. A new institution’s branding, field visibility, or feature flags become a config change, not a code change. The frontend contains no logic specific to an institution. It renders what the configuration defines.

That decision to push all business logic into a backend service and make the frontend a renderer let us migrate in stages. We could stand up new BFF endpoints one feature at a time behind the same configuration-driven client without a single cutover event. Legacy and new systems ran side by side for months, split by institution and feature, and nobody outside the engineering team could tell which backend was serving a given screen.

The security decision: stop letting the client hold the keys

The second major decision came from an audit of the tokens flowing between the client and the backend. Like many systems that grow over time, the legacy platform’s API responses included internal identifiers and session tokens issued by the core banking system for a given member or account. These appeared in payloads that the client held and replayed on subsequent calls. The approach worked, but it meant an artifact sitting on the client carried a token minted by the core banking system itself, and every downstream service had to trust whatever the client sent back.

We restructured this so the BFF never lets a core banking session token leave the server. On initial resolution, the BFF holds the real token on the server, keyed by its own session identifier, and the client sees only that opaque session UUID. Every subsequent request resolves the real token from server-side session state rather than trusting anything replayed from the client.

The mechanical part of this change was straightforward. The challenge was scope: identifying every place where a value shaped like a real token was flowing, not just fields with an obvious name such as memberToken. We found aliased fields carrying the same sensitive value under a different property name. A search based on field names missed them because the value mattered, not the label attached to it.

We also found flows that broke a simpler mental model. A couple of endpoints cached resolved session context across two separate HTTP requests: an MFA challenge and its resumption. A migration that always resolved the token from server-side session state would have broken authentication resumption the next time that challenge fired. Unit tests would not have exposed the failure because they typically mocked the layer where the gap lived.

The fix in those cases was to carry an explicit internal object, never exposed to the client, through the cached challenge state and reseed server-side session context from it before resuming. This was a deliberate design decision rather than a mechanical rename, and one worth flagging for review rather than treating as a routine migration change.

The performance decision: let Redis carry the weight of session state

Moving the real token off the client solved the trust problem, but it introduced a new one. The BFF now had to resolve that token, the member’s profile, and account-level context on every request that needed them. Calling the core banking system each time would have made the new platform slower than the one it was replacing. The third decision was to cache resolved session state rather than fetch it on every request.

Once a session is established, the BFF writes the real token and the resolved member and account context into Redis under the opaque session identifier, with a time to live tied to the permitted session duration. Every later request in that session reads from Redis instead of paying the round-trip cost of a call to a core banking system that, in most deployments, is the slowest and most rate-limited dependency in the request path. What used to require a network call to an external system on every screen became an in-memory lookup, reducing fetch times for requests that depended on member or account context.

The cache keys are never a flat string. Each one is built from three parts: what is being cached, which tenant it belongs to, and an optional subkey for the specific record. This structure prevents a cached profile for one institution from colliding with an identically shaped record for another. It also means an entire tenant’s cache can be cleared or inspected without touching anyone else’s data, which matters when a single Redis instance serves every institution on the platform.

The same pattern caches the merged three-layer configuration for a tenant because recomputing that merge on every request would reduce the latency gains Redis provides. The result for account holders was fewer round trips per screen and lower dependence on fresh core banking lookups for each action.

The methodology lesson: documentation is something you build, not something you inherit

One constraint shaped the migration process: there was no migration specification handed down from the old system. Nobody had written a document describing what the legacy application did feature by feature. The old codebase itself was the only complete record of the business rules. Institutional memory had faded, the original authors were gone, and the Blade templates and controllers were the closest thing to a specification that existed.

The practice became clear: for every feature we migrated, we read the legacy implementation rather than relying on a summary and documented what we learned as we went. That growing set of documents became the migration’s specification, built one feature at a time instead of inherited on day one. The documentation became valuable, but we learned that it was not equivalent to the source itself.

During one debugging session, three separate “bug fixes” based on our migration notes turned out to be wrong once checked against the legacy source. Each one moved behavior away from what the old system did in production rather than back toward it. In each case, the notes had conflated two separate legacy checks or described a distinction that sounded reasonable but that the original code didn’t make.

The documentation was written in good faith by someone summarizing a page of PHP in a sentence, but the summary lost a detail that mattered.

The corrective habit was clear but easy to skip under time pressure: treat every internal document, including the ones we wrote ourselves, as a working hypothesis about the legacy system rather than a fact about it. Before relying on a written description of “what the old system does” to justify a fix, reread the legacy implementation. Plausibility is not evidence. A behavior that “seems right” for a banking flow is worth only as much as the source code confirms.

Every time the source and documentation disagreed, we corrected the documentation, so the record improved as the migration progressed. It never replaced the source as the final authority. The principle also works in the other direction. Not every divergence from legacy behavior is a bug. Some are intentional improvements that have received explicit approval. The discipline lies in knowing which is which before acting rather than assuming either case.

What carried over

None of these decisions were exotic. UI driven by configuration, a BFF that owns business logic, and server-side token indirection are well-established patterns. What made them work in a live, regulated, multitenant banking system was discipline in the implementation details: treating the legacy source, not a document about it, as the final authority; scoping security fixes by the value flowing through a field rather than its name; and building the migration documentation alongside the code instead of waiting for a finished specification that was never coming.

The architecture gave us the seams to migrate safely. The process discipline kept the migration honest.

Building a Safer Path for Banking Modernization

Legacy banking systems can be modernized without forcing a single high-risk replacement. Phased migration, clear service boundaries, secure session management, and careful verification of existing behavior can help teams modernize while protecting critical banking operations. For teams working through similar architecture challenges, explore our core banking modernization services.

Why Legacy Systems Make Business Growth More Expensive: Navigate A Smarter Path to Legacy Modernization

GeekyAnts India Pvt Ltd — Wed, 23 Sep 2026 11:53:55 +0000

Learn how legacy systems make business growth more expensive and how edge-first modernization can remove constraints without replacing the existing system.

Six Brands, Six Rebuilds, Until We Changed the Equation

A North American restaurant group came to GeekyAnts with six casual-dining brands and a digital estate. The system encountered challenges every time it needed to change as per the business requirements.

There was an aging JSP web application, a separate native mobile app for each brand, and separate build and release pipelines for each of the systems. Each brand also had its own web and mobile development teams. A change that should have been made once had to be implemented six times.

Adding another brand took two to three months, and most of that time was going into creating another app, another pipeline, and duplicated work across the web and mobile teams. The core systems were not the issue since some of the routine tasks like ordering, menus, pricing, and availability were already working in a functional manner.

The cost was actually spent in the existing digital layer around the system, where every additional brand meant another application, another pipeline, and more duplicated work. We started with a two-page proof of concept. The question that needed to be answered was if the same components could genuinely be shared between web and native mobile. Once this assumption was tested, it gave us the basis to replace the edge while keeping the core systems in place.

Bringing Changes to One Digital Platform Instead of Adding Six New Rebuilds

We focused on the layer where the duplication was happening and built one platform for web and mobile, so that the changes could be made once instead of across six separate brand applications. A shared component library removed repeated development work, while a single mobile app shell let the team configure and roll out new brands instead of building another app from scratch. Over-the-air updates also meant changes could reach users without repeating the full app release cycle for every brand.

The first brand went live in 6-8 months. After that, a new brand was onboarded in 2-3 weeks instead of 2-3 months. The per-brand teams were consolidated into one web team and one mobile team, freeing them from rebuilding the same screen and flow.

The seventh brand was added after the platform existed, without recreating the old setup. The goal was to remove the multiplication that came with every new brand.

When Does Legacy Infrastructure Become a Business Problem?

Aging infrastructure alone is not the best reason to replace a system. In actuality, business constraints are one of the crucial reasons why legacy infrastructure needs to be replaced.

McKinsey estimates that technical debt can account for 20-40% of the value of an organization’s technology estate. So when a system becomes a problem, the business starts paying for its limitations. A release that once took two weeks can stretch into a quarter. Adding a new brand, region, or product can mean adding another technology stack. An integration task that should be a simple process becomes a whole project if the system doesn’t connect with it the right way.

The same pattern shows up in other business operations where a compliance change that should take weeks takes months, engineering teams spend more time keeping duplicated experiences running than building the next product, and each new unit of growth costs more as the business has to repeat the work it has already done.

The better question ideally would be “What is this system preventing the business from doing, and what is that constraint costing us?” because it changes the modernization conversation from replacing old technology to removing the things that hold business growth back.

Why Did We Modernize Edge Before the Core System?

When a core system starts holding the business back, the first instinct would be to replace it, which may be a risky process.

Most of the business processes may not be documented in one place, as some may exist in code, some in old integrations, and some may only be known by the people who have worked with the system for years.

The edge is different. It is where customers, employees, and partners interact with the business: web and mobile experiences, APIs, integrations, workflows, automation, and deployment pipelines.

Modernizing the edge gives the businesses enough room to be adaptive to changes without immediately disrupting the logic on which the systems run. You can improve how customers place an order, connect a new channel, or streamline an employee workflow without interrupting the system that handles ordering or pricing tasks.

The risk, however, changes as you move closer to the core system. The more business logic and dependencies you have to uncover, the more you risk finding rules nobody remembered were there.

Needless to say, modernization risk increases with the amount of business logic you have to rediscover.

Seven Decisions To Be Considered for Modernization of Legacy Systems

Every part of the legacy system can have a different path forward. Depending on what it does and where it creates friction, you can:

Retire the system when nothing depends on it anymore.
Retain when it works and creates no business constraint.
Expose when the capability is useful but trapped behind poor interfaces.
Augment when the core works but the surrounding experience does not.
Re-platform when the application works but the underlying runtime has become the problem.
Refactor when the business logic is worth keeping but the architecture prevents change or scale.
Replace when the economics no longer make sense or the system's business logic no longer matches how the company operates.

Modernization Should Create Room for Business Growth

The best place to begin the modernization process often starts from navigating which business process is actually hindering its growth. The real opportunity in legacy modernization lies in making room for business’s growth without creating unnecessary risks.

Planning a legacy modernization initiative? Talk to GeekyAnts about identifying what is actually constraining growth and modernizing it without replacing the existing system.

From Prompting to Process: What Changed When Flutter Shipped Agent Skills

GeekyAnts India Pvt Ltd — Wed, 23 Sep 2026 10:52:52 +0000

Google is starting to ship Flutter’s engineering workflows as machine-readable guidance for AI agents. It may look like another AI feature, but it hints at a much bigger shift in how teams build with Flutter.

The Consistency Problem

Over the past few years, AI coding tools like Cursor, Claude Code, Copilot, and OpenCode have become part of many developers’ daily workflows. An AI coding tool can produce code, explain unfamiliar APIs, write tests, and navigate large codebases with impressive accuracy.

That capability now stretches across stacks and workflows, from Node.js, TypeScript, and React to Python projects. It can help with debugging, boilerplate automation, integrations with services such as Stripe’s API, and work involving MongoDB or AWS tools.

But if you have been using these tools on a reasonably large project, you have probably noticed something.

They are not very consistent.

Ask an AI to implement the same feature in two different sessions, and there’s a good chance you will get two different approaches. Switch models, and the implementation changes again. Sometimes it follows the latest framework recommendations. Other times, it relies on outdated patterns. The same problem can appear whether the agent is changing a Flutter feature, a React app, a fintech prototype, or larger Enterprise apps.

Most teams respond the same way: write better prompts, add repository rules, or create custom skill.md files to steer the agent toward the right decisions.

At GeekyAnts, we took the same approach by documenting our architecture, coding conventions, review expectations, and engineering practices as custom Skills. They made the agent noticeably more consistent.

So when Flutter announced official Agent Skills, my first reaction was not: “How do we use them?” It was: “If we already have our own Skills, what problem are Flutter's official Skills actually solving?”

That question turned into a couple of experiments.

Three Layers of AI-Assisted Development

Looking back, Flutter's recent AI investments weren't isolated features. They were building on each other.

First came Rules, giving teams a way to define project-specific conventions and preferences.

Then came Model Context Protocol (MCP), allowing AI agents to inspect, debug, and interact with running Flutter applications instead of reasoning purely from static code.

And then came Agent Skills.

If Rules tell an agent how your team works, and MCP tells it what’s happening inside your application, Agent Skills answer a different question: how does Flutter itself recommend solving this problem?

That is the important shift.

Today, those workflows cover areas like:

Localization
Responsive layouts
Routing
Widget and unit testing
Static analysis
JSON serialization
Platform integration
Architecture best practices

In other words, Flutter is shipping its engineering knowledge as structured workflows.

That naturally led to the next question: does this actually change how an AI agent behaves?

I ran two experiments to find out.

First Experiment: Declarative Routing

So I kept the prompt intentionally simple:

“Set up declarative routing for this Flutter application.”

I wanted to see how the agent would approach the problem before I told it how to solve it.

The first thing it did caught my attention.

Before generating an implementation plan, it explicitly selected the flutter-setup-declarative-routing skill.

Flutter Agent Skill Selection for Declarative Routing

From that point on, it was not about figuring out a solution; it was following Flutter's own workflow.

That was the interesting part.

Without Agent Skills, the implementation depends on the model’s reasoning and whatever Flutter knowledge it has internalized. With Agent Skills, the framework itself becomes the starting point.

What happens when Flutter's Skills and our own Skills are both available?

I tested this with a login screen.

It needed:

Flutter's localization workflow
Our project conventions for authentication, repositories, dependency injection, and state management

I kept the prompt simple and let the agent decide how to approach it:

“Implement a login screen for this application. Follow the existing project architecture and add localization for all user-facing strings.”

It picked the right source every time.

For localization, it used Flutter’s official Skill. For everything related to our application architecture, it followed our custom Skills. I did not have to tell it which one to use or write a carefully engineered prompt.

The two sets of Skills worked together naturally. Flutter handled the framework guidance, while our repository continued to define how our application was built.

Flutter Localization Workflow Using Agent Skills

Why This Matters: A Floor, Not a Finish Line

So, what actually changed?

Flutter is taking ownership of its engineering expertise.

Engineering teams no longer need to teach AI how Flutter expects routing, localization, responsive layouts, or testing to be implemented. Flutter now ships that knowledge itself.

Even better, those workflows evolve alongside Flutter. As recommendations change, the official Skills change too, and every compatible AI agent benefits automatically.

Of course, that’s only half the story.

Flutter’s Agent Skills provide a strong foundation, but they do not replace your organization’s architecture, coding standards, or business-specific workflows. Those remain your responsibility, and that is exactly how it should be.

This distinction matters across software development, whether teams are building for the web, mobile, or domains such as cybersecurity. Framework guidance can standardize common implementation patterns, while teams still need to define the context that is specific to their products and systems.

Final Thoughts

Looking back, Flutter’s recent AI features fit together surprisingly well.

Rules capture how your team works. MCP gives agents runtime context. Agent Skills teach them how Flutter itself expects problems to be solved. Custom Skills layer on everything unique to your organization.

Together, they reduce the amount of engineering knowledge an AI has to infer. That is the real significance of Flutter’s recent AI investments. Engineering knowledge is becoming explicit, versioned, reusable, and maintained by the people best positioned to own it.

The same idea is becoming increasingly relevant as teams work with LLMs and AI-driven automation. The more implementation knowledge can be made explicit and reusable, the less an agent has to guess from prompts or training data alone.

Today’s skill library covers foundational workflows, but it already hints at what’s possible. Imagine Skills for performance profiling, DevTools workflows, accessibility audits, plugin development, migrations, or advanced rendering patterns. Every new skill moves another piece of framework knowledge out of documentation and into a reusable workflow.

The answer to how much of Flutter an agent should really guess keeps shrinking with every release.

How To Build AI Chatbots Using ChatGPT API - With Live Demo Video

GeekyAnts India Pvt Ltd — Wed, 23 Sep 2026 09:53:07 +0000

Editor's Note: This article was originally written by Priyamvada and published in March, 2024. It was revised and updated by Shivangi Agarwal in July, 2026 to include current technologies, implementation practices, industry requirements, and examples. The technical content was reviewed by Ahona Das, Senior Technical Content Writer.

Key Takeaways:

Build a functional AI chatbot using the OpenAI API and Python.
Use clear prompts to improve response accuracy, consistency, and relevance.
Integrate the chatbot into web or mobile applications through a backend API.
Test, monitor, and refine the chatbot to improve performance and user experience.

Prompt communication is one of the keys to running a successful business. In recent times, brands have radically transformed the ways in which they choose to communicate with their customers. Customer queries today are being answered by live chats, through social media, online forums or communities, and, most notably, AI-powered chatbots. Chatbots are AI software that can converse naturally with customers through text or audio, freeing up precious time for resources to handle more complex tasks.

This move is well reflected in the evergrowing industry. The global chatbot market was valued at approximately $9.6 billion in 2025 and is estimated to reach $11.8 billion in 2026- Report. Customer service remains to be the biggest application segment in 2025, showing the growing use of chatbots to automate support and improve digital interactions.

In this article, we walk you through the steps to creating interactive and dynamic chatbots that can engage in natural language conversations with users using ChatGPT API.

Understanding the Basics of ChatGPT API

![ ](https://dev-to-uploads.s3.us-east-

OpenAI has introduced the ChatGPT API, which is designed specifically for building conversational agents and chatbots. It allows developers to integrate ChatGPT into their applications, enabling dynamic and interactive conversations with users. ChatGPT is based on the GPT model but fine-tuned specifically for conversational AI applications.

It can handle long conversations with up to 4096 and 8000 tokens for GPT-3 and GPT-4, respectively, facilitating in-depth interactions between users and chatbots in mobile apps. With the ChatGPT API, developers can integrate interactive chatbots, virtual assistants, or customer support agents into their mobile apps. Users can engage in meaningful conversations with these AI-powered entities, receiving personalized and contextual assistance within the app.

Some OpenAI APIs to Know:

Response API: The core API used for creating text, handling multiple conversational turns, creating structured responses and connecting models with integrated or third-party applications.
Real Time API: Used to enable voice and multimodal conversations, this is the best option for voice assistants and live customer-support use cases.
Function Calling: Enables chatbots to interact with external systems to perform certain tasks such as checking order details, scheduling appointments and fetching account information.
File Search: This feature helps chatbots search for information in uploaded files or company repositories before responding.
Embedding API: This API translates text into numeric representations that help in performing tasks such as semantic search, recommendation and retrieval augmented generation.
Moderation API: Identifies and filters out any potentially dangerous or inappropriate text and images.

Creating an AI chatbot using the ChatGPT API can enhance your applications with conversational AI capabilities. The next section outlines a step-by-step approach to integrating the powerful functionalities of ChatGPT into your projects.

Build AI Chatbots with ChatGPT API (A Step-by-Step Guide)

Before we start, let us take a look at the steps involved:

Step 1: Understand the Basics

Before diving into development, familiarize yourself with the fundamentals of AI, chatbots, and the ChatGPT model. ChatGPT, developed by OpenAI, is a variant of the GPT (Generative Pre-trained Transformer) model tailored for generating human-like responses in a conversational context. Knowing the capabilities and limitations of ChatGPT will help you design a better chatbot experience.

Step 2: Define Your Chatbot's Purpose

Determine what you want your chatbot to do. ChatGPT can be adapted for various uses, such as customer service, education, entertainment, or personal assistants. Defining the purpose will guide the customization and integration process.

Step 3: Setup Your Development Environment

Ensure you have a suitable development environment. You will need:

Programming knowledge (Python is commonly used for interacting with the ChatGPT API).
An IDE or text editor.
Access to the ChatGPT API, which requires an OpenAI API key.

Step 4: Obtain OpenAI API Key

Sign up for an OpenAI account and access the API key. The API key is essential for authenticating and interacting with the ChatGPT API. Handle your API key securely to prevent unauthorized access.

Step 5: Install Necessary Libraries

Install the OpenAI Python library to interact with the ChatGPT API easily. Use pip or any other package manager to install it:

pip install openai

Step 6: Create Your Chatbot Script

Start coding your chatbot. Here's a simple Python script to interact with ChatGPT:

import openai

#  set your OpenAI API key
openai.api_key = 'your-api-key-here'

# Using GPT-4 with the ChatCompletion endpoint for a direct query
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": "I am an AI language model."},
        {"role": "user", "content": "What is AI?"}
    ]
)

# Printing the response message content
print(response.choices[0].message['content'])

Replace 'your-api-key-here' with your actual OpenAI API key. Modify the prompt and max_tokens as needed to suit your chatbot's purpose.

Step 7: Test and Iterate

After creating your initial script, test it thoroughly. Experiment with different prompts and settings to refine the chatbot's responses. Pay attention to the chatbot's accuracy, responsiveness, and ability to handle unexpected queries.

After creating your initial script, it is crucial to test it thoroughly. For example, if your chatbot's purpose is to provide customer support for an online electronics store, you should prepare a variety of prompts related to common customer inquiries, such as:

"How can I track my order?"
"What is your return policy for a laptop?"
"Do you have the latest model of XYZ smartphone in stock?"

Experiment with these prompts and adjust the settings to refine the chatbot's responses. Observe how well the chatbot understands the context, provides accurate information, and guides the user to the next steps. You might also introduce unexpected queries to see how the chatbot handles them, such as "Can you tell me a joke?" or "What's the weather like?" This can help you gauge the chatbot's versatility and ensure it remains helpful without veering off-topic.

Additionally, you may want to simulate different customer temperaments by altering the tone of the inquiries from polite to frustrated to ensure your chatbot maintains a consistent and appropriate response style.

Understanding the Concept of Prompt Engineering

Prompt engineering can significantly enhance the performance of a chatbot by:

Increasing Accuracy: By clearly specifying the context and the expected response format, the chatbot can more accurately address the user's intent.
Improving Consistency: Structured prompts ensure that the chatbot's responses are consistent, both in tone and structure, which is essential for user experience.
Enhancing User Satisfaction: User satisfaction increases when a chatbot reliably provides information in a useful format.

Example: Electronics Store Customer Support Chatbot

Let's say we're building a chatbot for an electronics store that handles queries about product specifications and availability. We want the chatbot to accept queries about any product and return information in a specific format: "Product Name - Availability Status - Main Features."

Step 1: Define System Prompts

We define system prompts that guide the chatbot on how to structure its responses. For example:

When asked about a product's availability: "Respond with the product name, followed by its availability status, and then list its three main features."
For product recommendations: "Suggest three products based on the user's query, including the product name, a brief description, and the price."

Step 2: Example Code with Prompt Engineering

Here is a Python code snippet that uses prompt engineering with the OpenAI API to handle a query about a smartphone's availability:

import openai

openai.api_key = 'your-api-key-here'

def query_chatbot(product_query):
    # Prepare the messages for the chat context
    messages = [
        {"role": "system", "content": "This is a chatbot that provides information about products."},
        {"role": "user", "content": f"Can you tell me about {product_query}?"}
    ]

    # Using GPT-4 with the ChatCompletion.create method
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=messages,
        max_tokens=200
    )

    # Extracting and returning the chatbot's response
    return response.choices[0].message['content']

# Example query
product_query = "the latest iPhone model"
response = query_chatbot(product_query)
print(response)

This script sends a structured prompt to the ChatGPT API, directing it to provide a response in the desired format. The system_prompt variable is crafted to include instructions for the chatbot, integrating both the user's query and the expected response format.

Considerations for Prompt Engineering

Clarity and Specificity: The clearer and more specific your prompts, the better the chatbot's responses will be. Tailor your prompts to guide the AI towards the type of answer you're looking for.
Experimentation: Different formulations of prompts can lead to different outcomes. Experiment with variations to find the most effective prompts for your use case.
Feedback Loop: Use real-world interactions as feedback to continually refine your prompts. This iterative process will improve the chatbot's performance over time.

Prompt engineering is both an art and a science, requiring iterative testing and refinement to perfect. By applying these concepts, your chatbot can more effectively serve users, providing them with information in a consistent and helpful format.

Step 8: Integrate With Your Application

Once satisfied with the chatbot's performance, the next step is to integrate it into your application. This process can involve various tasks, such as developing a user-friendly frontend interface, setting up webhooks for dynamic interactions, or creating APIs for seamless integration across different platforms, including web and mobile applications.

Creating a Flask API for Backend Integration

To exemplify backend integration, we will develop a simple Flask API. This API will act as an intermediary between your application and the ChatGPT model, facilitating the sending of queries and receiving of responses without a direct user interface.

Install Flask: Ensure Flask is installed in your development environment. Use pip for installation if Flask is not already installed:

pip install Flask

Setup Your Flask Application: Begin by creating a new Python file for your Flask app. This app will specifically include an API endpoint for processing chatbot queries.
Example Flask API Code: Let's adapt the Flask app to provide an API endpoint. This endpoint will accept JSON payloads containing user queries and return the chatbot's responses in JSON format.

from flask import Flask, request, jsonify
import openai

app = Flask(__name__)

# Replace 'your-api-key-here' with your actual OpenAI API key
openai.api_key = 'your-api-key-here'

@app.route('/chat', methods=['POST'])
def chat():
    data = request.get_json()
    user_query = data.get('user_query')

    # Using GPT-4 with the ChatCompletion endpoint
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[
            {"role": "system", "content": "This is a chatbot that can converse on a wide range of topics."},
            {"role": "user", "content": user_query}
        ]
    )
    chatbot_response = response.choices[0].message['content']

    return jsonify({'response': chatbot_response})

if __name__ == '__main__':
    app.run(debug=True)

In this modified code:

The Flask app defines a /chat endpoint that exclusively handles POST requests.
It expects a JSON payload with a user_query field.
The chatbot's response is returned in JSON format, making it easily consumable by any frontend or service that calls this API.

Testing Your API: To test the API, you can use tools like Postman or a simple curl command from the terminal. Here's an example curl request:

curl -X POST http://127.0.0.1:5000/chat -H "Content-Type: application/json" -d '{"user_query": "What is AI?"}'

This command sends a POST request to the /chat endpoint with a JSON payload containing the user query. The response will be the chatbot's answer to the query in JSON format.

This approach demonstrates how to integrate the ChatGPT model into your application's backend using a Flask API. By providing a dedicated endpoint for processing queries, this setup allows for flexible integration with various frontends, offering a seamless way to enhance your application with AI-powered conversational capabilities.

Step 9: Deployment and Monitoring

Deploy your chatbot and monitor its performance. Collect feedback from users to identify areas for improvement. Regularly update the chatbot to refine its responses, expand its capabilities, and incorporate the latest advancements in AI from OpenAI.

The final demo video shows us the frontend interaction with LLM-based chatbot, via API calls:

Benefits of Using ChatGPT API for Building AI Chatbots

At the risk of sounding cliche, ChatGPT really is a game-changer when it comes to building AI chatbots. It is great at understanding and chatting in human language. No matter what the user throws at it, ChatGPT can handle it and respond in a way that feels human. Plus, it is pretty flexible - developers can tweak it to suit whatever they are working on, making the chatbot's responses fit perfectly with the task.

ChatGPT can keep up with long chats without getting lost, so its responses always make sense in the conversation. This means chatbots can give personalized and detailed answers.
By using ChatGPT, chatbots can chat more naturally and effectively, making them better at helping users out.
Whether you dream up advanced chatbots, want to automate customer support, or want to generate creative content, the ChatGPT API covers you.
OpenAI has a range of models to choose from, depending on what you need and your willingness to spend. You can pick what works best for your project, from the top-of-the-line GPT-5.6 to the more budget-friendly GPT-5 versions.

So, if you are excited to start playing around with this cool tech, this guide is a great place to start!

Enhance Customer Service: Build AI Chatbots with GeekyAnts

With a robust portfolio of 500+ projects, GeekyAnts is well-known in the mobile and web app development space, executing end-to-end solutions with our signature touch.

Our Key AI Offerings

Enhanced Customer Service: Employ our 24/7 AI-powered chatbots for immediate customer assistance, ensuring unparalleled service quality.
Product Growth: Elevate your products with our AI-infused solutions, driving innovation, user-centricity, and market relevance.
Accelerated Development: Experience streamlined processes, from ideation to delivery, using AI for faster, more efficient project completion.
Decision Making: We leverage AI-driven data analysis for actionable insights, enabling informed and strategic business decisions.
Operational Efficiency: We help identify and rectify inefficiencies with AI, significantly reducing costs and enhancing overall performance.

Our Work Highlights

HR Bot: Our AI-driven HR bot is designed to simplify tasks, automate workflows, and enhance employee satisfaction. It can handle a variety of HR functions, such as answering FAQs, managing leave requests, and providing updates on company policies. It's designed to boost productivity and streamline HR operations.
Database Generator: A powerful tool that can manage and organize your data more effectively. It allows you to set up and manage databases with intuitive commands, saving you time and reducing the risk of errors. The automated setup process makes it easy to get your database up and running quickly.
FitnessGPT: FitnessGPT is a personalized fitness guide powered by AI. It provides tailored exercise routines and nutritional insights based on user's goals and preferences. Whether you're a beginner trying to get fit or an athlete looking to optimize your training, FitnessGPT can help you achieve your fitness goals.

GeekyAnts is committed to integrating cutting-edge AI solutions into businesses, transforming operations, and driving growth. We invite you to leverage our expertise and innovative AI offerings to accelerate your business transformation journey.

Frequently Asked Questions

What is the difference between ChatGPT and the OpenAI API?

ChatGPT can be used to create AI applications for individuals and teams instantly, whereas OpenAI API developers need to embed OpenAPI models into their websites, apps, chatbots and workflows. ChatGPT includes its own interface and product features. The API provides programmable access, so teams control the user experience, business logic, data connections, model selection, and usage-based operating costs.

Should new AI chatbots use the Responses API or the Chat Completions API?

New chatbots that incorporate AI technology should primarily make use of the Responses API, especially if multi-turn reasoning, tool calling, file search, web search, and system connection features are needed. According to the OpenAI guidance on model recommendations, the Responses API is recommended in cases that require reasoning and tool calling. While Chat Completions is still supported, it would not provide the robust base needed.

How much does it cost to build and operate an AI chatbot using the OpenAI API?

The price will depend on the scope of development, model selected, number of tokens used, length of responses, tools, hosting, integration, monitoring, and support. The OpenAI API costs vary depending on whether it is an input or output token with cheaper and more capable models. There might be extra costs for services like searches and hosted runtime. Teams should determine their monthly conversations and number of tokens per conversation.

How should developers secure OpenAI API keys and protect user data?

It is vital that developers keep their API keys for OpenAI on the server side, without revealing it on any browser-side code, mobile app code, in any public repositories, or any client-side configuration files. The keys need to be stored in the environment variables or managed secret storage systems, production access needs to be limited, and production and staging projects need to be separated, along with spending and rate limits.

Can an OpenAI chatbot connect with CRMs, databases, and business applications?

Yes. Function calling, connectors, or remote MCP servers allow the connection of the OpenAI chatbot with CRM, database, ticketing, and business apps. In addition, the language model could get information, execute permitted actions, or send structured requests to perform certain functions in apps. It is necessary to ensure strict permissions, validated tool input, and approval for performing critical actions without providing the chatbot with excessive system access.

How can teams reduce hallucinations and improve chatbot response accuracy?

Teams can minimize instances of hallucinations through reliance on official business data, file search or retrieval, providing accurate system commands, limiting the scope of the chatbot to appropriate tools, and asking for citations in all facts provided. Teams should also test their chatbot with appropriate questions, assess unproven claims made, create backup answers for lack of proof, and direct high-risk questions to human assessment. OpenAI file search provides both semantic and keyword searches of uploaded knowledge bases.

The Agent Can See Your App. How Often Can It Look?

GeekyAnts India Pvt Ltd — Wed, 23 Sep 2026 05:08:43 +0000

The question about AI coding agents on mobile used to be whether one

could even drive your app. That question is increasingly settled. The

one that now determines how useful an agent can be is how quickly it

gets to try, observe the result, and try again. In React

Native, that

number depends heavily on whether a change can stay inside the

JavaScript feedback loop or requires rebuilding the native

app.

JavaScript vs Native Feedback Loops in React Native

We keep seeing the same scene. A team wires a coding agent into its

React Native repo, expects the numbers everyone's been quoting, and the

agent writes reasonable code, but the whole thing feels flat next to

what the web team is getting. The easy read is that agents just aren't

good at mobile yet.

That read misses a major part of the problem, and it can be an expensive

miss because it talks teams out of fixing something they can actually

influence.

The capability gap has closed

For most of the last two years there was a real gap. An agent could

write mobile code but had limited ability to see what happened next. It

couldn't easily boot a simulator, tap a button, read a native crash, or

notice a keyboard sitting on top of the submit field. On the web, much

of that loop was already straightforward: start a dev server, hit a URL,

inspect the page, and read the console. Mobile agents had far less

visibility.

That gap has narrowed dramatically.

On iOS, getsentry/XcodeBuildMCP gives an agent access to builds,

simulators, log capture, debugging, screenshots, and snapshot_ui, which

exposes the on-screen view hierarchy with element references that can be

used for interaction. On Android, ADB-based tooling provides similar

capabilities, while mobile-next/mobile-mcp supports both platforms

through accessibility-driven snapshots and device interaction.

metro-mcp connects to a running React Native

app

through the Chrome DevTools Protocol for runtime, component, and network

inspection. Callstack has published React Native conventions written

specifically for AI

agents,

and tools such as SootSim are also targeting faster React Native

development and agent-driven feedback loops.

So the agent can increasingly see your app. The more useful question now

is how quickly it can act on what it sees.

The number that actually decides this

Agentic coding works because of a loop: generate, run it, look, fix, and

go again. What that loop is worth depends on how cheaply the agent can

get through each iteration.

On the web, application feedback after many common edits can arrive

almost immediately. In React Native, the feedback time depends heavily

on the kind of change being made.

The ranges below are illustrative rather than benchmarks. Exact times

vary by project size, hardware, build configuration, caching,

dependencies, and development environment. That variation is also why

the last section asks you to measure your own.

Change type	Feedback loop
JavaScript only — Metro Fast Refresh, state preserved	about a second
Incremental native rebuild	30 seconds – 1 minute
Cold native build	2 – 5 minutes, often longer

That can leave a large gap between JavaScript-only iteration and a

change that requires recompiling the native application.

The important dividing line isn't whether your JavaScript uses native

functionality. React Native applications do that constantly without

requiring a rebuild. The slower path appears when an edit changes native

source code, native dependencies, generated native code, or build

configuration in a way that requires the native binary to be rebuilt or

reinstalled.

That distinction matters.

A JavaScript change that Fast Refresh can apply may become visible

almost immediately. A native change that requires compilation may take

tens of seconds or minutes before the agent can observe the result.

The JavaScript-to-native architecture line used to be primarily a

portability and performance decision. In an agent-assisted workflow, it

can also become an iteration-speed decision.

Why the loop cost sets the ceiling, not the model

An agent gets through a real task by trying, checking, and correcting.

Give it one shot and it has to get the thing right immediately. Give it

repeated opportunities to inspect the result and make corrections, and

it has room to recover.

Cheap iteration is one of the things that pushed agentic coding beyond

autocomplete.

So feedback-loop cost isn't an ergonomic footnote. It affects how many

experiments an agent can make within the same amount of engineering

time.

Reducing the cost of an iteration doesn't translate neatly into a fixed

multiple of output. In some cases, faster feedback can make a category

of task practical that previously required too much waiting between

attempts.

Same agent. Same model. Same engineer. Different feedback loop.

In our experience, teams can budget mobile AI work as if the iteration

pattern will match what they see on the web. Often it won't, and part of

the reason is architectural rather than a question of choosing a better

model.

The obvious pushback is to run multiple agents in parallel and let

throughput hide the latency. Parallelism can help, but it doesn't remove

the underlying cost of an individual feedback cycle.

Shared build infrastructure can also become a bottleneck as more agents

request native builds, simulators, or test environments at the same

time. Additional agents give you more concurrent attempts, but they

don't automatically make each native-touching attempt cheaper.

The native boundary is a velocity budget

Once a native rebuild takes substantially longer than a JavaScript

refresh, "let's just add a small native change" becomes an

iteration-speed decision that teams may not have priced into the

development loop.

A few habits follow from that:

Reach for JavaScript first, and stay there until native code

genuinely provides something you need. The decision should still be

based on product requirements, platform capabilities, performance,

and maintainability, but iteration cost now belongs in that

calculation too.
Batch related native changes where practical instead of dripping

them in. Every native-touching edit that requires recompilation

incurs the slower feedback cycle again.
Treat a new native API or dependency as a planned architectural

decision, rather than something that slips into a routine ticket

without considering its development and build implications.
Settle native boundaries deliberately. Teams already do versions of

this for maintainability and build speed, keeping appropriate

product logic in JavaScript and using tools such as Expo Prebuild to

generate and manage native projects rather than hand-editing every

native configuration. Prebuild doesn't remove the need for native

rebuilds when native dependencies or configuration change, but it

can make that boundary easier to manage.

None of this is anti-native. Some capabilities genuinely belong in

native code.

The narrower point is that the amount of native surface you change, and

how frequently those changes require recompilation, can have a direct

and measurable effect on how quickly agents receive feedback.

That cost was easier to ignore when a developer was making a handful of

deliberate iterations. Agents make iteration count much more visible.

In fairness, native-build time is also a moving target. Precompiled

frameworks, configuration caching, compiler caching, and better build

tooling continue to reduce it.

But making the slower side faster does not eliminate the difference

between a Fast Refresh and a native rebuild. For agent-assisted

development,

the ratio between those feedback paths is worth measuring.

An agent navigates by labels, not by pixels

A fast loop is necessary, but it isn't enough on its own. The agent

still has to find things on the screen, and that depends partly on how

well your UI describes itself.

Tools that expose an accessibility or UI hierarchy can give an agent

structured references to elements on the screen. But an element without

useful text, roles, identifiers, or accessibility information may

provide the agent with very little semantic context.

The agent can be looking at the right screen and still struggle to

determine which element it should interact with. It may then fall back

to less reliable approaches such as screenshot coordinates.

Every failed identification wastes another inspection and interaction

cycle. If the task already includes slower native rebuilds, those

additional mistakes compound an already expensive loop.

So here's the reframe.

testID and accessibility metadata aren't interchangeable, and

accessibility labels should still be designed first for the people who

depend on them. But together, well-structured identifiers, roles,

labels, and semantic UI information also make an application easier for

automated tools and agents to navigate.

The work teams do to make interfaces addressable turns out to benefit

agent tooling too.

Two more cheap wins fall out of the same idea:

Deterministic launch states. Six taps to reach a bug are six

opportunities for the workflow to go off course on every cycle. A

deep link, test fixture, or debug launcher that drops the app

directly into a known state can reduce that setup cost dramatically.
Typed native boundaries. An agent has more structure to reason

about when working with a well-specified TurboModule and generated

interfaces. Give it a hand-rolled bridge built around loosely

structured payloads and there are fewer guarantees for both the

agent and the developer to rely on. The New

Architecture

has an additional benefit here: its typed contracts make the

JavaScript-native boundary easier to inspect and reason about.

What The Loop Still Can't Do

A screenshot proves something rendered. It says nothing about whether

the app is any good.

Closing more of the execution loop doesn't remove the human. It changes

where human judgment matters most.

A simulator can hide the things that actually damage a mobile

experience: dropped frames under realistic load, thermal throttling as

the device heats up, physical-device performance, haptics, hardware

behavior, and keyboard interactions that don't behave exactly as

expected.

Passing in a simulator and passing on a device are two different claims.

Any honest workflow keeps a person involved where product judgment and

real-device validation matter.

It's also worth pricing the harness honestly.

XcodeBuildMCP plus an Android automation layer plus metro-mcp, with the

right workflows enabled, session defaults configured, simulators

available, and code signing sorted for real devices, still requires

setup and maintenance.

Available doesn't mean zero-cost to operationalize.

The investment may be modest compared with the engineering work it

enables, but it is still part of the cost of running an agent-assisted

mobile

development

environment.

What To Measure This Week

The argument here ultimately comes down to numbers you can produce on

your own codebase in an afternoon.

Measure them before putting a budget behind any mobile AI plan.

Instrument the feedback loop. On one representative screen, run

an agent through a JavaScript-only change and a change that requires

a native rebuild. Measure both the edit-to-observable-result latency

and the total end-to-end time required for the agent to inspect and

respond.
Find the cliff on your own codebase. Compare JavaScript-only

feedback with native-rebuild feedback. That ratio is one of the

factors determining how much useful iteration an agent can complete

in a given period.
Test addressability. Compare similar tasks on screens with clear

semantic labels and stable test identifiers against screens where

elements are harder for automation to identify. Count the extra

inspection or interaction cycles.
Test launch determinism. Add a deep link or debug route directly

to the target state and run the workflow again. Measure how much

repeated setup time disappears.

Agents are non-deterministic, so run each condition several times and

report a range rather than a single figure.

A range you actually measured is more useful than a generic benchmark,

and technical audiences will trust it more.

The Point For Leaders

Mobile isn't shut out of the gains you're seeing from AI-assisted

development on

the web.

But the size of those gains can be strongly influenced by architecture

choices that, on the surface, appear to have little to do with

AI.

And you can measure their effect before committing a larger budget.

When code generation becomes cheap, feedback and iteration become

increasingly important constraints. One valuable asset is therefore a

codebase that an agent can understand, execute, inspect, and move

through quickly.

You don't simply buy that capability. You design for it.

The teams that pull ahead will be the ones that start treating agent

iteration speed as another engineering characteristic of the system and

make those architecture decisions deliberately.

Sources

getsentry/XcodeBuildMCP

--- iOS build, simulator, log, debugger, screenshot, and snapshot_ui

tooling for agents
XcodeBuildMCP project site
mobile-next/mobile-mcp

--- cross-platform (iOS + Android) mobile automation via

accessibility snapshots
metro-mcp --- React Native runtime

inspection over the Chrome DevTools Protocol
SootSim --- browser-based React Native

simulator built to be driven by agents
Callstack --- React Native Best Practices for AI

Agents
Callstack --- Giving AI Agents Hands: Mobile Feedback Loops with

Agent

Device
React Native --- Build speed

documentation --- on

native build times, and Fast Refresh applying edits within a second

or two
React Native --- Fast

Refresh
Codex CLI for mobile development: iOS with XcodeBuildMCP, Android

CLI, and React

Native

--- background on the agent-driven mobile toolchain

How We Built an AI Agent That Fixes CI/CD Pipeline Failures Automatically

GeekyAnts India Pvt Ltd — Thu, 17 Sep 2026 12:06:54 +0000

Engineering teams spend between 15 and 25% of their development time responding to CI/CD pipeline failures. This figure represents hours that do not go toward product work, architecture, or anything a team ships. The cost compounds further when context-switching comes into the frame: Microsoft's Developer Productivity research found that each interruption to debug a build failure costs an average of 23 minutes of recovery time. Multiply that across a team and a sprint, and the number becomes an operational liability.

The pattern that makes this problem solvable is its predictability. Seventy-three percent of pipeline failures fall into automatable categories: type errors, broken imports, dependency conflicts, and test regressions. Google's SRE handbook advocates automating any repetitive operational task that scales linearly with growth. To solve this, we built a Stateful Agentic Remediation System—an autonomous agent designed to watch your pipelines and act the moment something breaks.

What the AI Agent Does

The system is a stateful agentic remediation system. When a CI/CD pipeline fails, it detects the failure, diagnoses the root cause using AI, generates a targeted code fix, and opens a pull request—all without requiring a developer to act. The fix is then validated against the same CI pipeline, running on GitHub runners, that surfaced the original failure.

If the fix does not pass after three attempts, the system escalates to the engineering team via Slack with full context: the original error, every attempted fix, and the agent's reasoning at each step. It is not a chatbot; it is an always-on agent that watches your pipelines and acts the moment something breaks.

Architecture Overview

The system runs as a distributed, event-driven architecture with three separated layers: Detection, Reasoning, and Orchestration. The entire codebase lives in an Nx monorepo containing:

A NestJS backend API that handles webhook intake and orchestration.

A BullMQ worker process that processes jobs asynchronously.

A Next.js frontend dashboard that provides visibility into every repair cycle.

The Tech Stack

The backend runs on NestJS with TypeScript at maximum strictness. Data persistence uses Drizzle ORM against PostgreSQL, extended with pgvector for embedding-based semantic search. Redis powers both the caching layer and the job queue. The AI layer routes through OpenRouter to Claude Sonnet 3.5, using LangChain.js for structured prompting and LangGraph for stateful agent execution.

How it Works: End-to-End

Detection

GitHub sends a webhook event to the controller on pipeline failure. All processing happens asynchronously via BullMQ.

Log Parsing

The agent strips noise (ANSI codes/timestamps) and isolates the specific TypeScript or build errors. It enriches these with source code snippets fetched directly from the GitHub commit.

Semantic Search

Every past fix is stored in PostgreSQL with vector embeddings. The system performs a similarity search to see if a similar problem was solved before, improving accuracy and reducing token usage.

AI Diagnosis

An error classifier categorizes the failure (e.g., syntax, dependency). The agent generates a structured JSON fix with a confidence score.

Fix & Validate

The agent commits changes and opens a PR. If the pipeline passes, it’s ready for review. If it fails, the agent captures the new logs and retries with an adjusted strategy (capped at three attempts).

Safety and Security The system operates on the principle of least privilege:

Write access is restricted to temporary branches; no direct access to main.

It never auto-merges; a human reviewer must approve every PR.

Loop prevention ensures the agent never attempts to fix its own generated branches.

The Dashboard

The Next.js frontend provides a single visibility layer for the entire system. On landing, it displays all connected repositories. Drilling into a repository reveals its branches; drilling into a branch shows individual commits with their pipeline statuses, passed, failed, in progress, or under repair. For each pipeline run, the dashboard shows the exact changes the agent made. Engineering teams gain full transparency without switching between tools or parsing logs.

Results

Metric	Without an AI Agent	With an AI Agent
Mean Time to Recovery	30–60 minutes	3 minutes
Cost per Incident	$150 (developer time)	$0.05 (tokens)
Developer Interruptions	High	None
Night / Weekend Failures	Block releases	Auto-resolved

What Comes Next

The roadmap addresses several key areas: converting the system into a platform any team can adopt with one click, real-time pipeline status surfacing, cross-repository learning, and multi-language support (Python, Go, Java, Rust).

The goal of this project was to return the hours they spend on routine build failures so they can concentrate on what matters: building software that ships.

From Manual Testing to AI-Assisted Automation with Playwright Agents

GeekyAnts India Pvt Ltd — Thu, 17 Sep 2026 10:53:01 +0000

For years, automation engineers have followed a familiar rhythm. Requirements come in, test cases are written, scripts are automated, locators break, scripts fail, and debugging begins. Fix, re-run, repeat.

This cycle hasn't changed much, even though frameworks have evolved from Selenium to Cypress to modern tools like Playwright.

What if your automation framework didn't just execute tests --- what if it planned them, wrote them, ran them, and even fixed them when they broke? That's exactly what Playwright Test Agents bring to the table.

Playwright introduced these AI-powered agents in version 1.56 to automate key parts of the testing lifecycle --- planning, generating, and healing tests --- using an agentic loop that interacts with your live application.

In this blog, we'll explore what Playwright Agents are, how to set them up, how to use seed tests and prompts, what files they generate (like in your screenshot), and how each agent works in the development lifecycle. We'll close with practical tips on prompt design and real differences versus generic AI coding tools like Cursor or ChatGPT.

The Evolution of Automation with Playwright

Playwright became popular by addressing common automation challenges like flaky tests and synchronization issues. With features like automatic waiting, semantic locators such as getByRole, and built-in tracing, it reduced the effort required to stabilize tests. This allowed QA engineers to focus more on test coverage rather than debugging framework issues. However, even with these improvements, designing and maintaining test scripts still remained a manual effort.

We still had to:

Translate requirements into scenarios
Convert scenarios into code
Refactor when UI changes
Fix broken locators

Playwright Agents aim to assist in exactly those areas.

Introducing Playwright Test Agents

Playwright Test Agents are AI-assisted automation workflows embedded directly into your Playwright project, designed to help you:

Explore an application and produce a test plan
Transform that plan into executable Playwright test code
Run tests and automatically repair failures

There are three core agents:

The Planner Agent takes natural language input and converts it into structured test scenarios. It uses the seed test as context to explore the application, understand user flows, and identify possible edge cases. The output is a detailed test plan with steps and expected outcomes, similar to how a QA engineer would design test cases.

The Generator Agent takes these structured scenarios and converts them into executable Playwright scripts. While generating code, it interacts with the live application to validate selectors, identify stable locators, and ensure assertions reflect actual UI behavior. It can also follow architectural patterns like Page Object Model, producing manageable and scalable test code.

The Healer Agent focuses on maintaining test stability. When a test fails, it replays the scenario, inspects the DOM, and identifies what caused the failure. It then attempts to fix the issue by updating selectors, adjusting waits, or modifying interaction logic, reducing the manual effort required for test maintenance.

These agents can be invoked independently or chained together in a complete "agentic loop":

Planner → Generator → Healer

This turns a natural language description of test requirements into a stable test suite with minimal manual coding.

Project Setup --- Step by Step (Beginner Friendly)

If you already know basic Playwright automation, this should feel like an extension of that knowledge. If not, stick with it. By the end, you will understand how these agents help even if you're new to automation.

1. Create a Playwright Project

Start by creating a new directory and initializing a Node project:

mkdir playwright-agent-demo
cd playwright-agent-demo
npm init -y

Now install Playwright:

npm install -D @playwright/test
npx playwright install

You now have a basic Playwright project.

2. Initialize Playwright Agents

To add agent definitions to your project, run:

npx playwright init-agents --loop=vscode

This command generates agent files in your project --- which you'll recognize in the screenshot below:

A folder named .github/agents contains:

.github/
└── agents/
    ├── playwright-test-planner.agent.md
    ├── playwright-test-generator.agent.md
    └── playwright-test-healer.agent.md

These are the agent definitions that your AI tool (like Claude Code, VS Code Copilot, or OpenCode) uses to understand how to plan, generate, and heal tests.

Under the root folder, you also see:

specs/ -- for Markdown plans
tests/ -- for generated Playwright test files
seed.spec.ts -- a seed test that bootstraps the environment

This exact file structure is aligned with Playwright's agent conventions: .github/agents, specs/, and tests/.

A seed test is essential because it provides a starting context that the planner uses to understand where to begin exploration, including any setup required (like logging in or navigating to a landing page).

Create tests/seed.spec.ts:

import { test, expect } from '@playwright/test';

test.describe('Test group', () => {
  test('seed', async ({ page }) => {
    // generate code here.
    await page.goto('http://www.amazon.in');
    await expect(page).toHaveTitle(/Amazon.in/);
    await page.click('text=Amazon Basics');
  });
});

Next, add dummy seed data to a JSON file (optional but recommended):

testdata/seed.json

{
  "validUser": {
    "username": "qa_user",
    "password": "Password@123"
  },
  "invalidUser": {
    "username": "user_qa",
    "password": "wrong_pass"
  }
}

The seed test and seed data help the Planner understand context and scenarios, which makes its output far more relevant and accurate.

How the Planner Agent Works

The Planner Agent is like a QA analyst powered by AI. Rather than immediately writing code, it first produces a structured Markdown test plan that describes required test scenarios, user flows, steps, expected outcomes, and test data.

You can review this file before moving to code generation.

Generator Agent: Turning Plans into Code

Once you have a test plan, it's time to generate actual automation scripts.

Switch your AI assistant to Generator mode and provide a prompt such as:

Generate Playwright test code in TypeScript for the test plan in specs/amazon-search-add-to-cart.plan.md. Use Page Object Model where appropriate and use test data from testdata/seed.json.

The Generator reads the Markdown plan, actively interacts with the browser to verify selectors and assertions, and produces test scripts under the tests/ directory. Similar to this:

For example, provide a prompt like:

Create a test plan for login functionality with valid and invalid user scenarios using the seed test context.

The Planner will explore your live application (through the seed test) and generate a Markdown file under specs/ such as:

specs/login-plan.md

This file contains detailed, human-readable test plans, not code, but instructions for how you want the generator to build tests.

This step mirrors the typical QA process of writing test case documentation, except that the agent generates it automatically.

Each test should mirror a scenario from the plan.

Because the Generator interacts directly with the live app and evaluates selectors as it writes code, the tests it generates are often more stable and accurate than typical prompt-only AI output.

Healer Agent: Using AI to Fix Failing Tests

Inevitably, tests fail. It might be due to UI changes, such as an updated locator or changed button label.

Traditionally, you would open your editor, inspect the DOM, update selectors, and re-run tests. With Playwright's Healer Agent, this can be assisted by AI.

Invoke the healer with a prompt like:

Run and fix the failing test tests/amazon-search-add-to-cart-edge.spec.spec.ts.

The healer will:

Replay the failing test in debug mode
Inspect the DOM to find equivalent elements or flows
Propose updates to locators or waits
Re-run until the test passes, or decide that the test really reflects a broken feature.

This reduces repeated manual debugging cycles, especially for tests that only break due to minor UI refactors.

From Prompt to Execution: Inside the Agent Workflow

While using Playwright Test Agents feels simple from a user perspective, there is significant processing happening in the background.

The agents operate through an agentic loop where they can read project files, execute tests, interact with the browser, and inspect the live DOM. For example, the Planner uses the seed test to explore the application and understand flows, the Generator validates selectors in real time while generating scripts, and the Healer replays failing tests to identify and fix issues.

In the foreground, this complexity is abstracted into simple inputs and outputs. Users provide prompts and receive structured test plans, executable test scripts, or suggested fixes without directly interacting with the underlying processes. This separation is what makes Playwright Agents both powerful and easy to use.

Structuring Tests with Page Object Model

One of the biggest benefits of designer prompts is instructing the generator to produce maintainable code, and that starts with architecture.

If you prompt:

Use Page Object Model and store locators in separate page files.

The generator will output something like:

pages/login.page.ts
tests/login/login.spec.ts

Where:

login.page.ts contains locator definitions and reusable page actions
login.spec.ts uses the page object and seed data for test logic

This results in a clean, maintainable automation framework that scales well.

The Agentic Loop: From Plan to Stable Tests

When you use all three agents together, you get:

Seed Test + Prompt
       ↓
Planner → Create Markdown Plan
       ↓
Generator → Create Tests
       ↓
Healer → Fix Failures
       ↓
Stable Automation Suite

This mirrors a full human automation lifecycle, except now it is assisted by AI and deeply integrated with Playwright's tooling.

How Playwright Agents Differ from Generic AI Tools

Feature Regular AI Code Generation Playwright Agents

Feature	Regular AI Code Generation	Playwright Agents
Generates code based on prompts	Yes	Yes
Runs tests	No	Yes
Fixes failing tests autonomously	No	Yes
Understands live DOM while generating code	No	Yes
Integrated into the Playwright ecosystem	No	Yes

Generates code based on prompts Yes Yes Runs tests No Yes Fixes failing tests autonomously No Yes Understands live DOM while generating code No Yes Integrated into the Playwright ecosystem No Yes

It's easy to confuse Playwright Agents with other AI coding tools, such as:

Cursor AI
ChatGPT code generation
Generic AI assistants

But there is a fundamental difference:

Playwright Agents integrate with MCP (Model Context Protocol) and interact with your application and tests as part of the lifecycle. This makes them far more context-aware and useful than simple prompt-to-code generation.

Best Practices for Using Playwright Test Agents

Here are some practical tips based on real usage trends:

Provide Good Context

Always include a clear seed test
Use structured seed data
Reference environment details

Write Clear Prompts

Make sure your prompts include architecture preferences, test data references, and expected outputs.

Review Generated Tests

AI can generate great boilerplate, but human review is still important.

Integrate into CI Carefully

Treat healed and generated tests as drafts until fully reviewed.

Conclusion

Playwright Agents, Planner, Generator, and Healer bring AI directly into the automation lifecycle. They:

Plan test scenarios from natural language
Generate well-structured automation code
Check and repair failing tests
Help QA teams move faster with less manual overhead

For any QA engineer with basic Playwright knowledge, these agents unlock productivity leaps, from planning without code to generating and healing tests with AI.

If you want to experiment with this in your own project, run the agent setup, build a seed test, and start with simple prompts. You will be amazed at how much of the automation lifecycle can now be AI-assisted.

Building a Production-Ready Canva-like Editor with Konva.js, React 19 and Next.js 15

GeekyAnts India Pvt Ltd — Thu, 10 Sep 2026 10:31:18 +0000

This blog explains how to build a production-ready canvas editor with
Konva.js, React, and Next.js, covering architecture, performance, and
key engineering decisions.

Author: Priyanka Rokhade, Software Engineer III
Subject Matter Expert: Deepanshu Goyal, Senior Software Engineer -
III

Executive Summary: Why Build an In-App Canvas Editor?

Modern SaaS
applications
increasingly require users to create visually rich documents directly
inside the browser. Whether it is travel itineraries, reports,
certificates, brochures, or marketing collateral, users expect the same
drag-and-drop experience offered by tools like Canva---but without
leaving the application.

Our challenge was straightforward:

"How do we build a Canva-like editor that feels native, performs
smoothly, and integrates seamlessly with our product?"

After evaluating multiple approaches---including embedded design
tools,
HTML-based editors, and a fully custom canvas engine---we built our
editor on Konva.js + React-Konva.

The result was a production-ready editor capable of:

60 FPS interaction

250+ canvas objects

Rich text editing

Autosave

Multi-page documents

Responsive previews

Pixel-perfect rendering between editor and viewer

This article presents the architecture, design
decisions,
production challenges, and engineering lessons behind building a
production-ready canvas editor.

Business Objectives

Beyond replicating Canva-like functionality, the primary objective was
to eliminate dependence on external design tools and bring document
creation directly into our platform. By integrating editing, previewing,
and publishing into a single workflow, the editor reduces operational
overhead, shortens content turnaround time, and enables teams to create
production-ready documents without switching between multiple
applications. This also gives the product team complete control over the
editing experience, data ownership, and future feature development.

Why We Chose Konva.js Over Other Alternatives

When we started designing the editor, we evaluated three possible
approaches.

At first glance, embedding a tool such as Canva or Figma looked
attractive because this approach reduced implementation effort. However,
licensing costs, limited customization, and data ownership concerns
quickly ruled it out.

Next, we experimented with HTML-based editors built using absolutely
positioned

elements. Although this worked for simple layouts,
performance degraded significantly as documents became more complex.

Ultimately, we chose Konva.js because it provided a scene graph
architecture, high-performance rendering, and complete control over the
editing experience.

When evaluating how to build this visual editor, we assessed three
architectural paths:

Architectural Approach How It Works Why It Succeeded or
Failed in Production

Third-Party Embeds Embeds an external Failed: High recurring
(e.g. Canva / Figma SDK design tool inside our per-user licensing
via iFrame) web page using an fees; user data lives
iFrame. on external servers;
inability to build
custom domain features
such as custom torn
image frames, Unsplash
search panel, and
specific Google Font
pickers.

HTML/DOM-Based Editors Renders elements as Failed: When a document
(e.g. GrapesJS / standard HTML

contains 50+ elements
Absolute CSS Divs) tags positioned with with rotations, drop
CSS. shadows, and masks, DOM
repaints cause
noticeable lag during
dragging. Rotation and
corner resize handle
math also glitch across
different web browsers.

Practical Benefits of Our Konva.js Architecture

100% Visual Fidelity (Zero Rendering Drift): Both the admin
design editor and the public viewer application use the exact same
Konva shape primitives (Konva.Text, Konva.Image, Konva.Rect). What
the creator designs on their screen is 100% identical to what
end-users see---no displaced text, shifting margins, or
browser-specific rendering bugs.

Lightweight Universal Canvas Format (UCF JSON): Instead of
saving heavy image files or fragile HTML, our editor serializes
document pages into clean, portable JSON, including item
coordinates, font size, and fill colors. A complete 10-page document
is under 15 KB, loads instantly, and is stored securely in our cloud
database and object storage.

Production Impact: Beyond the technical architecture, the editor
delivered measurable improvements to our internal workflow: reduced
document creation time from 1--2 days to under 15 minutes by
eliminating external design tools; supports 250+ canvas objects
while maintaining smooth 60 FPS interactions; replaced fragmented
designer-to-operations workflows with a fully integrated in-app
editing experience; and enabled creators to design, preview, and
publish documents without leaving the platform.

Customer Value: Enables operations teams to publish customer
documents 95% faster. Eliminates dependence on external design
tools. Keeps customer data inside the platform. Reduces onboarding
time for non-design users.

What the Editor Does

The editor operates inside the web
application
workspace and enables users to:

Compose multi-page visual documents featuring text, vector shapes,
high-resolution photography, video clips, buttons, and hyperlinks.

Drag, resize, rotate, and layer elements with pixel-level precision
on an interactive 2D canvas.

Apply custom Google Fonts, decorative frames (torn edge, square
borders), mask clippings (circle, star, heart, diamond), image
cropping, and character-level rich text formatting.

Preview responsive layouts in real-time across web and mobile
device
viewports.

Autosave design state with debouncing and publish completed
documents directly to the client viewing application.

Primary users: The editor is designed for internal operations teams,
content creators, and administrators responsible for producing
customer-facing documents. Instead of relying on external design
software, users can create, review, and publish visual content directly
within the application, reducing context switching and simplifying
day-to-day workflows.

Application scope: Integrated visual design module within the Admin
Web Workspace.

Why Konva?

Konva provides decisive technical advantages for our production
requirements:

Scene Graph Hierarchy: A clean Stage → Layer → Group → Shape
tree that maps 1:1 to document pages and layered canvas items.

Built-in Drag, Transform & Hit Detection: Accelerated
mathematical routines for drag-and-drop, multi-node rotation, corner
scaling, and pointer hit detection.

Interactive Transformer: Customizable bounding box with 8 anchor
handles, rotation anchor, and aspect-ratio constraints out of the
box.

Declarative React Bindings: Allows canvas elements to be
composed declaratively with standard React props, state hooks, and
component lifecycles.

Universal Canvas Format Serialization: Rather than storing the
document as an image, we store every object as JSON. Each element
records information such as position, size, color, font, rotation,
and opacity. This lightweight format allows us to recreate the exact
same document anywhere using Konva.

Konva Fundamentals

For developers exploring Konva, four foundational primitives form the
foundation of our canvas architecture:

Konva Concept Core Responsibility Implementation in Our
Editor

Stage The root canvas One Konva Stage per
container managing document page inside
global dimensions, our canvas container.
viewport scaling, and
top-level mouse/touch
events.

Layer An independent HTML5 2D Three discrete layers:
canvas drawing surface Background layer,
with isolated redraw elements layer, and
loops. transformer/UI overlay
layer.

Shape Drawable nodes on the One Konva shape per
canvas (Text, Rect, document element
Circle, Line, Arrow, dispatched dynamically
Image, Star, etc.). via our shape rendering
engine.

Shape Registration: All required Konva shapes are registered at app
initialization---including Rect, Circle, Ellipse, Text, Image, Line,
Arrow, RegularPolygon, Star, Wedge, and Arc---ensuring tree-shaking
keeps bundle size minimal while guaranteeing all element types render
without runtime errors.

Editor Architecture at a Glance

The editor is engineered as a hybrid Next.js/React application wrapped
around a high-performance Konva canvas. React governs the outer UI
chrome, toolbar actions, sidebar panels, and state management, while
Konva drives the 2D visual layout surface.

Figure: High-Level Architecture: React UI Chrome, State Layer, Canvas
Engine, and Output Pipeline

The Hybrid Canvas Model

One of the biggest engineering decisions was not using the canvas for
everything. At first, we tried rendering every interaction directly
inside Konva. It quickly became obvious that some browser features
simply work better in the DOM.

Examples include:

Blinking text cursor

Spell check

Video controls

Copy/paste

Text selection

Instead of fighting the browser, we built a Hybrid Canvas Architecture
where Konva renders graphics while temporary HTML overlays handle
editing.

To combine the performance of canvas with the rich UX of the DOM, our
editor implements a Hybrid Canvas Architecture:

Figure: The Hybrid Canvas Architecture: Synchronized Konva Canvas and
HTML DOM Overlays

Why the Hybrid Model Matters

Inline Text Editing: When a user double-clicks a text item, an
invisible HTML is mounted at the exact bounding box and rotation of the Konva text node---providing native cursor blinking, typing, and keyboard shortcuts. Rich Text Formatting: Multi-range formatted text (bold, italic, underline per character slice) is painted directly onto the canvas via a custom sceneFunc (drawFormattedTextOnCanvas)---ensuring correct z-ordering without persistent DOM elements. Video Playback: Video items display a poster thumbnail on canvas, while interactive playback, trimming, and audio controls appear in a synchronized DOM overlay. Real-Time Overlay Synchronization: Floating toolbars and editing inputs continuously recalculate their CSS transforms during canvas panning, zooming, and item dragging. Architectural Takeaway: By keeping DOM overlays transient (active only during direct editing) and painting all normal elements inside Konva, we preserve 60 FPS canvas performance while giving users full browser editing ergonomics. How a User Action Becomes Canvas State Every user interaction follows a strict unidirectional loop: UI event → Global Editor State → Konva re-render → history push → debounced autosave Interaction Loop Steps User Triggers Action: User clicks "Add heading" in the sidebar or drags an element on canvas. Context Mutation: The action invokes addItem() or updateItem() in the global editor state. History Recording: The history manager pushes the previous snapshot onto the 50-state undo stack. Canvas Re-draw: React-Konva receives updated props and re-renders the modified shapes on the elements layer. Debounced Serialization: The autosave pipeline serializes canvas items to JSON and dispatches a debounced (2-second) PATCH request to the backend API. Key User Flows Flow 1 --- Adding and Editing Text Figure: Flow 1: Adding, Rendering, and Inline-Editing Text Elements (Vertical Workflow) Konva Touchpoints: Konva.Text node, custom sceneFunc for formatted character ranges, and Transformer with scale-to-fontSize baking (scaling corner anchors adjusts fontSize directly to avoid pixelated text). Flow 2 --- Adding an Image from Unsplash Figure: Flow 2: Searching, Loading, and Rendering Unsplash Images (Vertical Workflow) Konva Touchpoints: Konva.Image node with HTMLImageElement source; mask clipping via custom clipFunc; aspect ratio preservation during transform handles. Flow 3 --- Selection, Transform, and Snap Figure: Flow 3: Single/Multi-Selection, Transformer Attachment, and Snap Grid Guides Konva Touchpoints: Canvas Transformer with 8 anchor handles, real-time snap grid logic calculating alignment guidelines against canvas edges and sibling elements; arrows bypass Transformer and use 2-point anchor handles. Flow 4 --- Save, Preview, and Publish Figure: Flow 4: Autosave, UCF Serialization, Live Preview, and Production Publish Konva Touchpoints: Serialization transforms page scenes into Universal Canvas Format (UCF) JSON. The same Konva shape vocabulary is reused in the client viewer for 100% visual fidelity between editor preview and production viewer. Supported Element Types The editor supports 12 distinct element types, each mapped to a Konva primitive or custom renderer: Element Type Konva / Custom Renderer Technical Implementation Notes Text Konva.Text + custom Inline HTML textarea sceneFunc editing; rich formatted character ranges (bold/italic/underline) painted on canvas. Rectangle Konva.Rect Solid and gradient fills, border strokes, customizable corner radius, opacity. Circle / Ellipse Konva.Circle / Uniform and non-uniform Konva.Ellipse radial scaling with aspect lock support. Line Konva.Line Point coordinate array scaling and rotation handling during transform. Arrow Konva.Arrow Custom 2-point anchor editing (head and tail moved independently). Polygon / Star Konva.RegularPolygon / Configurable vertex Konva.Star count, inner/outer radius ratio. Wedge / Arc Konva.Wedge / Konva.Arc Custom selection overlay with start/end angle dragging. Image Konva.Image Crop rectangle math, shape masks (circle, star, heart, diamond), opacity, filters. Video Konva.Image frame + Video poster on canvas; HTML overlay synchronized DOM player (max 3 videos per document). Button / Link Custom Group (Rect + Clickable interactive Text) hotspot, URL navigation, document action binding. Frame SquareFrameRenderer / Decorative organic image TornFrameRenderer container with clipping masks. Dispatch logic operates using a clean TypeScript discriminated union (CanvasItem). What Worked Well & Architectural Strengths Dev--Prod Parity for Rendering Designs export to UCF JSON and render in the client viewing app with the identical Konva primitives. Creators see in preview exactly what end-users experience---zero rendering drift or font mismatches. Hook-Based Interaction Logic Complex canvas behaviors are decomposed into dedicated, testable custom React hooks rather than one monolithic component: Custom React Hook Core Responsibility useDragHandlers Single-item drag, multi-selection drag, and transformer drag coordination. useTransformHandlers Resize, rotate, scale commit per item type with aspect ratio constraints. useSelectionHandlers Single click, shift/cmd multi-select, background click deselect. useTextEditing Double-click text editing activation, textarea placement, keyboard commit. useArrowHandlers Two-point arrow anchor handle dragging and coordinate calculation. useSnapGridLines Real-time alignment guide calculation and snapping against canvas & elements. useCanvasEffects Transformer attachment lifecycle, keyboard nudge handling (arrow keys). useHistory 50-state undo/redo stack with state compression and debounced push. useAutosave Debounced 2-second canvas serialization and PATCH API save pipeline. This modular structure keeps canvas orchestration clean, readable, and maintainable. Production Performance Benchmarks & Metrics To maintain smooth interactions on resource-constrained client machines, the canvas engine underwent rigorous benchmarking: Performance Dimension Production Metric Engineering Mechanism Achieved Interaction Frame Rate Solid 60 FPS across Node ref mutations 250+ canvas elements bypass React virtual DOM during active dragging and transform cycles. Transformer Rotation < 12 ms per frame Layer splitting: Latency redraw cycle transformer anchors render on an isolated canvas layer without invalidating elements. Autosave Network 94% reduction in API 2-second debounce timer Reduction write volume on state mutations; payload diffing prevents redundant PATCH requests. History Heap Memory < 14 MB for 50-state Structured cloning of undo/redo buffer lightweight UCF state trees with debounced 300ms snapshot intervals. Production War Stories & Solved Edge Cases Building a production canvas editor revealed complex graphics and browser synchronization edge cases that standard documentation overlooks. Challenge 1: Solving Text Blurriness on High-DPI / Retina Displays Symptoms: Vector shapes rendered crisply, but canvas text and stroke borders appeared slightly blurry on Apple Retina screens and 4K displays. Root Cause: Browser window.devicePixelRatio (2x or 3x) scales canvas CSS display dimensions without automatically scaling the underlying canvas backing buffer resolution. Production Fix: Konva automatically handles pixel ratio scaling, but custom formatted text painted via HTML5 2D Canvas context (sceneFunc) required explicit scale normalization: ctx.scale(pixelRatio, pixelRatio) to ensure sub-pixel font anti-aliasing matching native DOM text. Challenge 2: The Google Fonts Asynchronous Loading Race Condition Symptoms: When opening a document with custom fonts such as Playfair Display and Montserrat, text elements briefly measured with default fallback fonts, resulting in incorrect line wraps, clipped bounding boxes, and transformer handle misalignments. Root Cause: Konva renders immediately on mount before document.fonts.load() resolves webfont TTF files. Production Fix: We implemented a font management provider that prefetches document fonts, listens to document.fonts.ready, and triggers an atomic stage batchDraw() with text node bounding box recalculations once font glyphs are resident in GPU memory. Challenge 3: Transformer Corner Scaling vs. Text Box Aspect Distortion Symptoms: Dragging a transformer corner handle on a text box caused font characters to stretch non-uniformly (ovaled glyphs) instead of reflowing text naturally. Root Cause: Konva Transformer applies scaleX and scaleY matrix multipliers to the target node during transform. Production Fix: On transformend, our transform handling hook intercepts the event, resets node.scaleX(1) and node.scaleY(1), and bakes the scale multiplier directly into the text element's fontSize and width properties: newFontSize = Math.round(oldFontSize * scaleX) This guarantees crisp, undistorted font rendering. Challenge 4: CSS Zoom Matrix Decoupling Symptoms: When users zoomed the viewport using the footer slider (50% to 200%), inline text editing text areas and crop overlays drifted away from their target shapes. Root Cause: Canvas pan and CSS scale zoom apply outside Konva's internal coordinate matrix. Production Fix: In our UI position calculator, overlay screen coordinates are computed by multiplying the shape's absolute Konva transform matrix by the stage's parent CSS transform scale factor: clientPos = shape.getAbsolutePosition() * zoomScale + stageOffset Exporting UCF JSON into High-Resolution Image Views for End Users Once a visual document is designed and saved as Universal Canvas Format (UCF) JSON, end users need to view, share, and consume it across various client devices. Our architecture supports two distinct consumption modes. Real-Time Interactive Canvas Rehydration In web applications across desktop and mobile devices, the document viewer mounts a lightweight, read-only Konva Stage. It consumes the UCF JSON directly and renders the scene graph using the same shape dispatchers---with zero editor overhead (no toolbars, no transformer handles, no editing textarea overlays). This enables smooth interactive page flips, video playback, and clickable hyperlink hotspots. Headless Offscreen Image Generation (PNG/WebP/PDF) For generating static thumbnails, social sharing cards, downloadable PNGs, and print-ready PDFs, the application executes a client-side headless rendering pipeline: Offscreen Stage Mount: An invisible DOM container is dynamically created outside the visible viewport (left: -10000px) with the exact width and height of the document page. Asset Preload Verification: The headless viewer renders the UCF scene graph and pauses capture until all remote assets (Unsplash images, Google Fonts TTF files, custom shape masks) have fully resolved. Frame Settling: Double requestAnimationFrame() cycles allow font kerning, image decodes, and canvas clipping paths to paint completely. High-DPI Raster Capture: We execute stage.toDataURL({ pixelRatio: 2, mimeType: 'image/png' }) on the rendered Konva stage. Setting pixelRatio: 2 produces ultra-sharp, publication-grade raster images without blurriness or distortion. Automatic Cleanup: Once the image data URL / Blob is resolved for download or preview, the offscreen root is safely unmounted to prevent browser memory leaks. Engineering Lessons After building this editor, five lessons stood out: Don't fight the browser. Use the DOM for text editing. Keep rendering deterministic. The editor and viewer should use the same rendering engine. Performance starts with architecture. Optimizations matter less than choosing the right rendering model. Serialize state, not pixels. JSON scales better than images. Invest in reusable interaction hooks. Hooks kept our codebase maintainable as the editor grew. Tech Stack & Further Resources The editor is built on a modern React ecosystem centered around Next.js 15 (App Router) and Konva.js with React-Konva, which together provide a scalable foundation for high-performance 2D canvas rendering, scene graph management, and interactive editing. React Context manages editor state, selections, history, and document metadata, while TanStack Query and an internal API client handle data fetching, caching, and debounced autosave operations. The interface is styled with Tailwind CSS, typography is powered by the Google Fonts API with a custom TTF loader for accurate font rendering, and media assets are sourced through the Unsplash API and stored in cloud storage backed by a CDN. Documents are serialized into a lightweight Universal Canvas Format (UCF) JSON, enabling fast persistence, portability, and pixel-perfect rendering consistency between the editor and viewer. Developers interested in exploring the underlying technologies can refer to the official Konva.js documentation, including the Getting Started guides, React-Konva integration guide, API Reference, Performance Tips, Select & Transform documentation, Interactive Sandbox examples, and the Konva and React-Konva GitHub repositories. Core Engineering Takeaways Building a production-grade canvas editor requires coordination across rendering, state management, browser APIs, networking, and user experience. Konva.js provided the rendering engine, while the surrounding architecture handled hybrid editing, history management, autosave, performance optimization, and rendering fidelity across the editor and viewer. Beyond solving interesting engineering problems, the editor transformed our document creation workflow. Tasks that previously required external design tools and lengthy collaboration can now be completed entirely within the application in minutes, while maintaining consistent rendering between editor and viewer. The current architecture was intentionally designed for extensibility. Planned capabilities include collaborative real-time editing, reusable templates, version history, AI-assisted layout generation, reusable design components, and plugin-based extensibility. Because the editor is built around a scene graph and serialized document model, these features can be introduced without fundamental architectural changes. The architecture and lessons shared in this article can help engineering teams avoid similar pitfalls when building scalable, production-ready canvas applications. For teams building web applications with complex interactions and demanding performance requirements, the right frontend architecture can shape how the product scales. Our Next.js Development Services support teams in building web applications designed for performance, maintainability, and growth. Original article: GeekyAnts

The Next Wave of Mobile Apps is The Instant Prototype

GeekyAnts India Pvt Ltd — Thu, 06 Aug 2026 10:45:04 +0000

By Amrit Saluja, Technical Content Writer at GeekyAnts. Originally published on GeekyAnts.

Is the local IDE becoming optional? Sanket Sahu discusses the rise of vibe-coding and how browser-native tools such as RapidNative are reshaping mobile app development.

Editor's note
Sanket Sahu, co-founder of GeekyAnts and creator of gluestack, recently explored how to build an entire development server inside the browser. The engineering is interesting, but the larger question is what this architecture means for founders, product managers, and the future of enterprise AI.

We spoke with Sanket about the reasons behind the build, the browser-native technologies that make it possible, and the product opportunities created by near-instant feedback. The conversation below has been edited for clarity.

Is the local IDE becoming optional?
Amrit Saluja: We hear a great deal about vibe-coding. Does browser-native architecture make the local IDE optional, or are we moving toward a hybrid future?

Sanket Sahu: Vibe-coding is growing because browser-based tools remove setup friction and make building apps more accessible. Development is moving toward a hybrid model rather than abandoning local tools altogether.

What did RapidNative change?
AS: For readers who have not seen the technical deep dive, what did you build?

SS: I rebuilt the development server inside the browser. RapidNative does not require npm run dev, a CLI, or an external server. A code change appears in the preview in under 100 milliseconds while preserving application state.

AS: Why replace the earlier approach?

SS: The previous version ran a sandbox in the cloud. That architecture worked, but an AI tool that streams code in real time makes every network round-trip visible. The goal was not merely a fast response. It was an instant one.

How can a development server run in a browser tab?
AS: A traditional development server handles a lot of work. How did you move those responsibilities into the browser?

SS: A server such as Metro watches the file system, transpiles code, bundles modules, and serves the result over HTTP. We replaced each responsibility with a browser-native capability. Service Workers take the place of the HTTP server. IndexedDB and a virtual file system replace the physical file system. Babel Standalone performs transpilation, while Import Maps remove the need to bundle modules during development.

AS: That sounds similar to Vite. Was it an influence?

SS: Yes. Both approaches begin with the same observation: modern browsers understand ES modules, so development does not always need a bundling step. Vite still relies on Node.js and a CLI. RapidNative extends the idea by moving the full development loop into the browser.

Why use two virtual file systems?
AS: What makes the dual-VFS architecture necessary?

SS: The two file systems have separate responsibilities. The Source VFS holds the original TypeScript and JSX files. When a source file changes, the browser transforms it and writes plain JavaScript into the Destination VFS. The Service Worker serves only from that destination. Keeping source and output separate makes the pipeline predictable and fast.

What does a sub-100ms preview mean for founders?
AS: How does that preview speed help a founder or a non-technical decision-maker?

SS: Fast iteration protects the creative flow. It helps teams produce better MVPs, test their thinking sooner, and reach a first paying user faster. For many people, seeing an app idea running on a phone in less than two minutes is the moment the product becomes real.

AS: How is RapidNative different from Expo Snack?

SS: The products serve different purposes. Snack is a browser-based REPL that helps developers test snippets and run them on devices. RapidNative focuses on building full apps with AI assistance and instant browser feedback. Its sub-100ms update loop matters when an AI is continuously streaming code changes.

Who is RapidNative for today?
AS: Is the current product aimed at startups or enterprises?

SS: Today, it is best suited to individuals and startups that want to turn an idea into a working app. Customization, team features, and compliance capabilities are on the roadmap so that agencies and enterprises can adopt it as well.

What comes next?
AS: What remains on the technical roadmap?

SS: Three major additions are planned: a TypeScript Language Server for editor autocomplete, browser-native Git operations through isomorphic-git, and native-device support through Expo Go. Together, they should combine instant browser feedback with the advantages of running an app on a real device.

AS: You have built NativeBase, gluestack, and now RapidNative. Has AI changed your goal?

SS: The goal remains the same: remove friction for developers, designers, founders, and product managers. AI is an enabler and an accelerator. It shortens the distance between imagining an idea and seeing it work on a screen.