DEV Community: GeekyAnts

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

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.

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.

OpenClaw.ai — Your Personal AI That Actually Does Things

GeekyAnts India Pvt Ltd — Thu, 30 Jul 2026 13:21:16 +0000

OpenClaw is a powerful, self-hosted AI assistant that connects to your tools to perform actions. Explore its Gateway architecture, real-world use cases, and security precautions.

There is a new kind of AI tool making waves. It is called OpenClaw, and it acts and does things.

OpenClaw is an open-source, self-hosted AI assistant created by Peter Steinberger. Launched as "Clawdbot" in November 2025, it is now called OpenClaw and has 145,000 GitHub stars. Nature, Wired, DigitalOcean, and VirusTotal have covered it.

But what exactly is it? And more importantly, is it something you should set up?

Is OpenClaw for Everyone? No.

OpenClaw is powerful, but it is not a plug-and-play consumer app. One of OpenClaw's own maintainers put it bluntly: "If you can't understand how to run a command line, this is far too dangerous a project for you to use safely."

Here is why. OpenClaw runs on your machine with access to your files, shell, browser, and messaging apps. It installs extensions called "Skills." In February 2026, security researchers found over 300 malicious skills on ClawHub (the skill marketplace), disguising malware as helpful tools. A Cornell audit found 26% of skill packages contained vulnerabilities.

OpenClaw partnered with VirusTotal for automated skill scanning and hired a security advisor. But they are clear: this is not a silver bullet. Prompt injection attacks—where malicious instructions hide in natural language—remain unsolved.

If you understand what's installed on your system, can audit code, and know command-line tools, OpenClaw is exciting. If not, wait until it matures or work with someone who can set it up for you.

How does OpenClaw Work—Through the Gateway?

At OpenClaw's core sits the Gateway—a Node.js process that controls everything.

Think of it as an Agent Server. The Gateway is responsible for managing all your channel connections (WhatsApp, Telegram, Slack, Discord, and more), routing messages to the right AI agent, maintaining session state and conversation history, coordinating tool execution (file operations, shell commands, browser automation), and providing a WebSocket interface for CLI tools, mobile apps, and the web UI.

Every message, whether from WhatsApp or Telegram, flows through the Gateway, gets routed to the right agent, and the response flows back. By default, it runs on localhost:18789, keeping everything local.

What makes this interesting: you can run multiple agents behind one Gateway, each with its own personality, workspace, model, and tool access. For example, route WhatsApp messages to Claude Sonnet and Telegram messages to Claude Opus, all from one Gateway.

It is microservices for personal AI.

For the Masses, What Does OpenClaw Actually Do?

OpenClaw is an AI assistant that performs actions. Unlike ChatGPT or Claude's chat interface, which respond with text, OpenClaw connects to your tools and systems. It reads and writes files on your computer, executes shell commands, browses the web, sends messages through your apps, and interacts with APIs.

This is organized through:

Agents: The AI brains with isolated workspaces and sessions
Tools: Built-in capabilities like exec, read, browser, cron, and message
Skills: Community or custom packages that teach the agent how to use specific tools and APIs, like GitHub, Notion, Slack, or Google Calendar

In plain language: You tell it what to do—through any messaging app you use—and it does it.

How Do You Talk to Your OpenClaw AI Assistant?

You do not need a special app to create an AI assistant with OpenClaw. This is one of OpenClaw's best design decisions. You use the messaging platforms you already have.

OpenClaw supports WhatsApp, Telegram (recommended for first setup), Slack, Discord, Signal, iMessage, Google Chat, Microsoft Teams, and WebChat. It also supports Matrix, BlueBubbles, Zalo, and more. It can speak and listen on macOS, iOS, and Android through companion apps.

The experience: message your bot on Telegram, and it responds. It does not respond with just words but with actions as well.

Can OpenClaw Schedule Things for You?

Yes. And it is built right in.

OpenClaw includes a powerful built-in scheduler called Cron, which runs inside the Gateway process itself. It supports full 5-field cron expressions with timezone awareness, one-shot reminders (e.g., "remind me at 4 PM"), recurring jobs (e.g., "every weekday at 9 AM, summarize my unread emails"), isolated agent turns where a scheduled job runs in its own session, and delivery to any connected channel — so the result can show up in your WhatsApp, Telegram, or Slack.

Jobs persist under ~/.openclaw/cron/, so even if the Gateway restarts, your schedules survive.

For example, you could set up a job that checks your email every 10 minutes. If it finds a message from a specific sender — say your manager or a key client — it immediately notifies you on WhatsApp. People are doing this today.

What About Webhooks and External Triggers?

OpenClaw's Gateway provides a WebSocket interface and can be integrated with external systems in multiple ways. You can trigger agents via CLI commands, connect through the WebSocket API, set up cron-based polling workflows, and use skills that integrate with external services and APIs. The architecture is deliberately open-ended, encouraging creative integrations.

Real Use Cases that People are Building

Here is where things get exciting. OpenClaw is a productivity multiplier. People are using it to manage their calendars by scheduling events, getting daily briefings, and rescheduling conflicts through a simple chat message. They are processing emails, with agents that scan your inbox, summarize important threads, draft replies, and flag urgent messages from specific senders.

Developers are running coding agents in the background, using skills for Claude Code, Codex, and other code-generation tools that build features, run tests, and open pull requests — while they sleep. One user described kicking off Claude Code sessions from his phone and waking up to completed PRs.

Early adopters are automating household workflows. One user configured OpenClaw to build a weekly meal planning system in Notion, saving his family an hour every week. Others are monitoring health data, connecting WHOOP and other services to track biomarkers and daily habits through chat.

Some have even built entire websites from their phones, controlling file operations and deployment through Telegram messages.

The pattern is that anything you would ask a skilled executive assistant to do. The assistants check information, draft content, and provide reminders. Anything you need to keep an eye on, it can be handled by OpenClaw.

Example of OpenClaw Usage

Wednesday, 6 AM: Your assistant checks email. Client needs a deliverable update. It drafts a reply and waits for your approval. Your accountant sent something about taxes - flagged as urgent. The newsletter you follow gets summarized and saved to Notion.

7 AM: Health check on your staging server. Green. No alert.

8 AM: Morning briefing hits your phone. "Three meetings today. First one at 10 AM. Two-hour focus block this afternoon. Your mom's birthday is tomorrow. Want me to order flowers?"

You are still in bed. You type: "Yes."

That is OpenClaw, running right now, on someone's laptop.

Can I run it Completely On-Premise?

Yes. This is a key differentiator from existing chatbot or assistant AI builders.

OpenClaw is model-agnostic. While it works beautifully with cloud-based models like Claude, GPT-4, and DeepSeek, you can run it entirely on local models using Ollama. This means zero data leaves your machine.

Supported local models include Llama 3.x, Mistral, Qwen, Phi, DeepSeek-R1, and more. The setup is straightforward: install Ollama, pull a model, point OpenClaw's config at your local endpoint (http://127.0.0.1:11434/v1), and you're running a fully private, on-premise AI assistant.

OpenClaw even supports hybrid configurations — use a fast local model as your everyday coordinator and fall back to a cloud model for complex reasoning tasks.

For organizations with strict data residency or compliance requirements, this is a game-changer.

A Word on Security — Take It Seriously

OpenClaw gives an AI agent real access to your system. That power comes with real risk.

In the past few weeks, researchers discovered 341 malicious skills in a campaign called "ClawHavoc" that targeted cryptocurrency wallets. Cisco's security team found third-party skills performing data exfiltration without user awareness. BitSight and CrowdStrike flagged exposed instances as enterprise security risks. 22% of enterprise customers in one study had employees running OpenClaw without IT approval.

OpenClaw is improving: VirusTotal partnership, sandbox modes for Docker-isolated execution, tool allowlists and denylists, DM pairing for access control, and a formal security program at trust.openclaw.ai.

But the responsibility falls on you:

Audit skills before installing them
Enable sandbox mode
Restrict tool access per agent
Keep sensitive credentials out of the agent's reach
If deploying for a team, treat it like privileged infrastructure—with governance, monitoring, and clear boundaries

The Mental Model Shift

The tool is only as useful as the workflows you design for it.

Setting it up is just the beginning. The real work—and the real value—comes from thinking about what you want automated. What tasks do you repeat every day? What decisions could be offloaded? What monitoring would save you from fire drills?

OpenClaw is not magic. It is infrastructure. And like any infrastructure, it rewards planning.

You need a mental model for what is possible, then build, iterate, and refine. The people getting the most out of OpenClaw are not the ones with the fanciest hardware—they're the ones who've thought about their workflows.

At GeekyAnts, we help people plan, build, deploy, and manage personal AI assistants—from initial architecture to production automation. Whether you want to run OpenClaw on-premise, integrate it with your existing tools, or build custom skills for your team, reach out.

This article was originally published on the GeekyAnts blog.

Exploring Anti-Design Through a Neo-Brutalist Product Experience

GeekyAnts India Pvt Ltd — Tue, 28 Jul 2026 13:12:30 +0000

A comprehensive article on customising design systems, experimenting responsibly, and designing with intention in 2026's most defining trend.

When Good Design Becomes Invisible

Most modern digital products are well designed. They are clean, usable, and follow best practices. Yet somewhere along the way, many of them started feeling interchangeable, polished to the point of sameness.

During our early project discussions, one question kept surfacing: How do we create something that feels distinct without sacrificing usability?

That tension became our entry point into anti-design—not as a visual trend to adopt, but as a design method to explore.

Why Anti-Design Is Defining 2026

Anti-design has emerged as one of the dominant design trends of 2026, representing a fundamental shift in how designers approach their craft. After years of algorithm-friendly, hyper-polished aesthetics, the design community is experiencing what many are calling a creative rebellion.

Industry leaders are witnessing a deliberate rejection of AI's overly smooth visual language in favour of work that feels unmistakably human. Designers are choosing imperfection, messiness, and rawness as proof that a person, not an algorithm, made this. This is not only an aesthetic preference; it is a response to digital saturation and a hunger for authenticity.

The data backs up this shift:

Searches for bold fonts have surged over 65%
Collage art and handmade textures continue to climb in popularity
Brands are moving away from safe, predictable design toward experiences that feel alive, emotional, and intentionally chaotic

This article documents how we rode this wave early by understanding anti-design as a principled methodology that could help us stand out in an increasingly homogenised market.

Why We Started With Anti-Design, Not Ended With It

Anti-design typically appears late in the process, applied as visual flair over an already-finished product. We took a different approach.

We chose to explore anti-design from the beginning, working at the system level rather than the surface level. Instead of discarding our design system, we used it as a foundation and began questioning its assumptions:

What happens when typography leads instead of layout?
What if spacing becomes expressive, not just consistent?
What if components feel editorial rather than purely functional?

These questions shaped our early explorations and helped us test boundaries without losing control.

Early explorations showing multiple variations of the same screen or layout concept

Customising a Design System Without Breaking It

The challenge was not to push boundaries; it was how to do it without creating chaos.

Rather than changing everything at once, we focused on small, deliberate experiments:

Modified Button types to start establishing the new brutalism softly on the screen
Introduced layout flexibility for content-heavy sections
Created component variants instead of entirely new patterns

For example, we did not build new card components from scratch. Instead, we experimented with existing ones by introducing heavier borders, uneven internal spacing, and Bolder and larger typographic contrast.

This kept us system-aligned while allowing the visual language to evolve.

Why Neo-Brutalism Worked in a Product Context

Neo-brutalism gave us a middle ground between expressive design and functional usability.

Unlike traditional brutalism, which can feel harsh or inaccessible, neo-brutalism allows you to use bold typography without harming readability, create visual tension without confusion, and embrace rawness while maintaining structure.

For us, this approach supported a magazine-inspired experience where content felt curated and intentional, not templated and generic.

Real-World Success Stories

Platforms like Figma and Gumroad have embraced neo-brutalist approaches, demonstrating how raw, unpolished aesthetics can succeed in commercial contexts.

Figma's brand refresh uses bold contrasts and unconventional typography to emphasize creative freedom and flexibility, perfectly aligning with their design tool's purpose. The visual language reinforces what the product enables—unrestricted creativity.

Gumroad's raw aesthetic aligns with its mission of empowering independent creators. The rebellious visual language communicates that it is a platform for people charting their own paths, not another corporate marketplace. The deliberately utilitarian interface becomes part of the brand promise.

These are strategic decisions that align visual identity with brand values, proving that neo-brutalism works when it serves a purpose beyond shock value.

Typography scale experiments or layout blocks showing editorial influence

The Psychology Behind Why It Works

There's solid research backing why anti-design captures attention. The Von Restorff Effect, a psychological principle documented by German psychiatrist Hedwig von Restorff in 1933, demonstrates that when multiple similar items are presented, the one that differs from the rest is significantly more likely to be remembered.

The 15-Second Window

In a world where users spend an average of 15 seconds on a webpage, shock value works. A brutalist design does not ask for attention it demands it. The distinctive nature of anti-design creates what psychologists call enhanced memory encoding, making experiences more memorable than conventional alternatives.

When users encounter something unexpected:

Their brain registers the deviation from the norm
Additional cognitive resources are allocated to processing it
The experience becomes more deeply encoded in memory
Recall is significantly improved compared to conventional alternatives

This is a measurable impact on user engagement and brand recall, translating to higher engagement metrics, stronger word-of-mouth sharing, and more memorable user experiences.

Anti-Design ≠ Careless Design

Anti-design that ignores fundamental principles is just bad design with a rebellious aesthetic. True anti-design respects these principles while finding new ways to express them.

Anti-Design Must Still Respect Accessibility

This is non-negotiable. WCAG (Web Content Accessibility Guidelines) organizes accessibility requirements under four principles: content must be Perceivable, Operable, Understandable, and Robust.

Anti-design does not exempt you from these standards—it challenges you to meet them creatively.

What You MUST Do for Accessibility:

Color Contrast (WCAG AA Standard)

Maintain a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text
Bold typography and heavy borders can work if contrast ratios are maintained
Use tools like WebAIM's contrast checker to verify compliance

Typography & Readability

Keep body text at minimum 16px
Ensure generous line height (1.5x minimum)
Avoid extremely condensed or decorative fonts for body copy
Bold, expressive headlines are fine—just keep body text readable

Keyboard Navigation & Focus States

All interactive elements must be keyboard-accessible
Visible focus indicators are required (not just on hover)
Logical tab order must be maintained even with unconventional layouts

Alternative Text & Screen Readers

All images need descriptive alt text
Ensure heading hierarchy (H1, H2, H3) follows logical structure
Do not break semantic HTML structure for visual effect

Sufficient Target Sizes

Interactive elements must be at least 44x44 pixels
Even if your design feels raw, buttons must be easily tappable/clickable

What NOT to Do:

1. Don not sacrifice contrast for aesthetics

Low-contrast text might look sophisticated but excludes users with visual impairments and violates legal standards.

2. Do not hide navigation or controls

Experimental layouts are fine, but users must always know how to navigate and complete tasks.

3. Do not rely solely on color to convey information

Use additional indicators like icons, labels, or patterns alongside color.

4. Do not break fundamental interaction patterns

Buttons should look clickable, links should be distinguishable, forms should be predictable.

5. Do not use motion without controls

If you include animations, provide pause/stop controls and respect prefers-reduced-motion settings.

Real-World Balance

Gumroad's raw aesthetic includes heavy borders and bold typography, but maintains proper contrast ratios and clear interactive states. The visual rebellion works because the accessibility fundamentals remain intact.

The principle is to push visual boundaries, not accessibility boundaries.

Anti-Design Still Follows Heuristic Principles

Jakob Nielsen's 10 Usability Heuristics, developed in 1990 and refined in 1994, remain the gold standard for interface design. Anti-design does not reject these principles—it interprets them differently.

How Anti-Design Aligns With Heuristics:

1. Visibility of System Status

Anti-design can actually enhance this through bold, unmissable feedback states. Heavy borders and strong typography make status changes more visible, not less.

2. Match Between System and Real World

Neo-brutalism often embraces real-world metaphors—raw materials, physical textures, tactile elements. This can create stronger connections than sterile digital interfaces.

3. User Control and Freedom

Unconventional does not mean confusing. Clear "undo" actions, visible navigation, and predictable controls still apply—they just might look different.

4. Consistency and Standards

This is where anti-design requires the most discipline. You can bend conventions, but you must be consistent within your own system. If one button has a heavy border, all buttons should follow a predictable pattern.

5. Error Prevention

Bold visual treatments can actually improve error prevention by making warnings more noticeable and actions more deliberate.

6. Recognition Rather Than Recall

Strong visual hierarchy and distinctive elements aid recognition. Anti-design's boldness can reduce cognitive load by making important elements impossible to miss.

7. Flexibility and Efficiency of Use

Power users benefit from predictable patterns. Anti-design can support efficiency through clear visual affordances and consistent interaction models.

8. Aesthetic and Minimalist Design

This seems contradictory, but it is not. The heuristic is about ensuring that visual elements support user goals, not about adhering to flat design. Bold typography can create a clearer hierarchy than minimalist layouts if used intentionally.

9. Help Users Recognise, Diagnose, and Recover from Errors

Heavy borders, bold text, and strong colour can make error messages more noticeable and actionable.

10. Help and Documentation

Even rebellious designs need clear documentation. The visual language might be unconventional, but the help content must remain accessible and searchable.

The Key Difference:

Traditional design applies heuristics conservatively. Anti-design applies them expressively—but it still applies them. The rebellion is in the execution, not the abandonment of principles.

When Should You Use Anti-Design?

Anti-design is not universally applicable, but it can be powerful when used intentionally.

It works well when:

Differentiation is a key product goal
Brand personality matters
Content needs to feel expressive or editorial
Your audience is open to visual experimentation

It is less effective when:

Speed and efficiency are the primary user goals
Accessibility constraints are extremely strict
Users rely on predictable patterns under high-pressure conditions

The key is knowing when expression adds value—and when it becomes noise.

How to Experiment Safely With Anti-Design

If you are curious about anti-design but hesitant to try it in live projects, here is how to start:

Experiment early: Explore unconventional ideas before the system becomes locked in.
Isolate risk: Test bold ideas on a few screens or components, not the entire product.
Use the system as a base: Bend components before you replace them entirely.
Document intent: Be prepared to explain every rule you break.
Balance expression with restraint: Not everything needs to be loud. Some elements should anchor the chaos.

What This Approach Taught Us

This project reinforced several principles worth carrying forward:

Design systems should enable exploration, not restrict it
Intentional experimentation leads to stronger outcomes than random novelty
Anti-design works best when grounded in purpose, not rebellion
Expression and usability do not have to compete—they can complement each other
Accessibility and heuristics are creative challenges

Riding the Wave of Biggest Design Shifts

Anti-design is the design philosophy defining 2026. As the industry moves away from algorithmic perfection and toward human authenticity, designers who understand this shift will create experiences that truly resonate.

Our exploration proved that anti-design is not about rejecting structure—it's about reshaping it with intention. When approached thoughtfully, it helps you move beyond visual sameness and create experiences that feel memorable, expressive, and purposeful.

In a market flooded with polished sameness, imperfection has become the new differentiator. The brands and products that will stand out in 2026 are not the ones with the cleanest interfaces—they are the ones with personality, emotion, and unmistakable human touch.

Sometimes, the most impactful design decisions begin with a simple question:

What if we did not do it the usual way?

In 2026, that question is essential.

This article was originally published on the GeekyAnts blog.

Building a Self-Healing CI/CD System with an AI Agent

GeekyAnts India Pvt Ltd — Fri, 24 Jul 2026 13:21:42 +0000

Engineering teams know when CI pipelines fail. What follows is the problem: a developer stops what they are doing, opens the logs, spends twenty minutes tracing the error, writes a fix, and waits for the pipeline to run again.

This pattern repeats 3-5 times per week per developer. Across a team of ten engineers, this compounds to 6-8 hours of interrupted work weekly.

CI failure detection exists. The gap is automated failure resolution.

The Hidden Cost of CI Failures

CI pipelines validate code changes before deployment. On each code push, the pipeline compiles the application, executes tests, and reports results. When everything works, developers barely notice it. Failures require immediate developer attention.

Most failures are not complex. A dependency version changed. A test assertion has been updated. A configuration value is absent. These are routine maintenance issues.

The cost lies in the interruption overhead. Interruption, context switching, and release cycle delays accumulate. For teams deploying 3-5 times daily, these delays compound.

Automated error resolution addresses this gap.

The Core Idea: A Pipeline That Fixes Itself

The systems built by GeekyAnts treat CI failures as programmatically solvable problems. On failure, the system follows standard debugging workflow: it reads the logs, identifies what went wrong, looks at the relevant code, generates a fix, tests it, and submits the patch for review.

This process follows systematic patterns recognizable across most CI failures. Error messages are structured. Stack traces identify affected files. Fixes are straightforward with proper context.

These characteristics enable automation. An AI agent with codebase access and failure context completes this process without context-switching overhead.

The result is a self-healing CI/CD system, a pipeline that not only detects failures but responds to them.

What the System Is Made Of

The platform is built across three layers, each with a distinct role.

The Application Layer is a Spring Boot backend service representing a simple product management system. It handles user role management, inventory updates, and discount calculations. A test suite validates these services and provides failure scenarios during CI execution. A GitLab CI pipeline runs on every push: compile, test, report. Stage failures trigger agent analysis.

The AI Agent Layer performs failure analysis and resolution. A Python service built with FastAPI monitors pipeline state. On failure detection, it fetches logs, analyzes them, queries the codebase structure, generates a fix, validates it, and creates a merge request.

The agent uses multiple data sources: a language model for reasoning, a structural codebase map, and historical failure memory. These improve accuracy beyond single-source analysis. The agent is backed by a Neo4j graph database for codebase relationships and a Qdrant vector database for failure memory.

The Monitoring Dashboard, built with Next.js, provides visibility into active investigations, processing stages, generated fixes, and escalated failures. The dashboard surfaces agent activity and decision rationale in real time.

How It Works: From Code Push to Merge Request

Pipeline failure sequence:

A developer pushes code. The GitLab pipeline starts: compile, test, report. The pipeline fails due to a broken test or a compilation error. The agent detects the failure event.

Rather than passing the full raw log to an AI model, which would be slow, expensive, and full of noise, the agent first cleans it. Dependency downloads, verbose build output, and unrelated stack traces are stripped out. What remains is signal: error messages, stack traces, failing test names, and affected source files. This reduces the search space and improves reasoning accuracy.

The agent performs deep analysis: it queries the codebase structural map to identify component relationships before proposing changes.

A fix is generated based on that full context. The fix is validated locally before pushing. If validation passes, the patch is pushed, and a merge request is created for developer review. If the agent cannot resolve the issue, it escalates with a structured diagnostic report rather than raw logs.

The developer's role shifts from debugging to reviewing.

What Makes It More Than a Script

Many CI automation tools detect failures and send alerts. This system differs through multi-layered analysis:

Log Intelligence

Raw CI logs sent to language models produce suboptimal results. Raw logs contain high noise-to-signal ratios.

The agent solves this with a dedicated cleaning stage. Before AI reasoning, deterministic parsing extracts error messages, stack traces, and test failures. The model then operates on a smaller, focused input, which improves both speed and accuracy.

Codebase Understanding Using AST and Graph Modeling

Knowing that a test failed is not enough context to fix it reliably. The system maintains a structural codebase map built through Java AST parsing.

This extracts structural elements such as classes, methods, imports, method calls, and dependencies, all stored in a Neo4j graph database as connected relationships. Class contains Method. Method calls Method. Service depends on Repository.

On failure, the agent traces affected components through the map before proposing fixes. This provides relationship context beyond error messages alone.

To keep this map accurate without rebuilding it from scratch on every commit, the system performs incremental updates. For each commit, modified files are reprocessed, their AST recalculated, and the graph updated. The map stays current without unnecessary computation.

Learning from Past Failures

CI failures repeat across commits and projects. Recalculating a solution that has already been found once is wasteful.

The agent maintains a searchable vector memory of historical failures using Qdrant. Each entry stores the error signature, failure context, and generated fix. When a new failure occurs, its error signature is embedded and the database is queried. If a similar failure is found, the system reuses the existing solution, reducing LLM token usage, response latency, and repeated reasoning costs.

The system improves through accumulated failure data.

Active Investigation, Not Passive Generation

The agent provides investigation tools rather than log-only input: it can call getGitDiff() to inspect recent code changes, readFile() to retrieve file contents, queryGraph() to explore code relationships in Neo4j, and blastRadius() to determine the impact scope of a change.

These tools enable hypothesis formation, evidence testing, and conclusion validation before fix generation. This shifts from single-shot generation to iterative investigation.

Real-Time Visibility Into an Autonomous System

Autonomous code changes require engineer visibility into system decisions.

The dashboard connects to the agent via WebSocket, streaming updates without page refresh. Engineers observe each analysis stage and decision rationale. Events streamed include agent activity, pipeline updates, and metrics updates.

The dashboard surfaces four key views:
The Overview shows aggregated metrics: total CI incidents, automated fix success rate, escalation rate, and recent pipeline activity.
The Live Monitor shows the current pipeline, the active agent stage, and logs streaming from the backend.
The History view lets engineers inspect past failures in detail: root cause analysis, generated patches, fix attempts, and merge request links.
The Escalations view displays unresolved failures with diagnostic reports.

The dashboard enables team adoption.

The Real Impact on Engineering Teams

The immediate benefit is straightforward: fewer interruptions. When the agent handles a routine failure, developers do not need to context-switch. A merge request appears, they review it, and they move on.

The downstream effects compound. Pipelines that recover faster stay green more often. Increased confidence enables more frequent deployment. Delivery cycles become predictable without debugging delays.

Longer-term benefits accumulate: Initially, the agent analyzes each failure independent. Over time, it builds a library of known solutions. Common failure patterns resolve through memory lookup. The system becomes more valuable the longer it runs.

For teams managing multiple projects, a single agent monitors all pipelines—coverage requiring multiple engineers to replicate manually.

Where This Goes Next

The current system is built around Java and Maven projects. The underlying architecture is not language-specific.

The log cleaning logic, the vector memory, the LLM reasoning layer, and the merge request workflow are all transferable. Node.js projects, Python services, Go microservices—the same approach applies. The primary adaptation required is language-specific AST parsing in the code graph layer. Other components transfer without modification.

The longer-term direction: a single agent monitoring polyglot organizations and handling CI failures across languages and building systems.

Beyond language support, the system can expand failure type coverage. The current scope covers test failures and compilation errors. Future iterations could address environment-specific failures, infrastructure misconfigurations, and dependency resolution issues.

From Reactive to Proactive: A Different Way to Think About CI/CD

Traditional CI/CD pipelines are built to report. They run when code is pushed, surface failures, and wait for a human to act.

That model made sense when diagnosis required human judgment at every step. It makes less sense now. The patterns are recognizable. The process is systematic. The tooling to automate it exists.

Self-healing CI/CD systems do not remove developers from the loop. The merge request step is deliberate. Human judgment belongs before fixes reach production. What changes is where developers enter that loop. Instead of starting with a raw log file and no context, they start with a proposed solution and a clear explanation of the problem.

That shift from debugging to decision-making is where engineering time should be spent.

Teams building this capability will resolve failures faster. They will compound that advantage with each independently resolved incident.

This article was originally published on the GeekyAnts blog.

Building an Autonomous Multi-Agent Fraud Detection System in Under 200ms

GeekyAnts India Pvt Ltd — Wed, 22 Jul 2026 13:14:13 +0000

Indian banks lose $1.49 billion USD to fraud every year. The systems built to stop it take 3 to 5 seconds to reach a decision. UPI payments settle in 2 seconds. By the time the fraud system responds, the money has already moved.

At GeekyAnts' internal event, we tackled this problem with a different kind of system. Instead of a single, all-purpose AI model, we built five specialized AI programs that work together in sequence.

Why Existing Fraud Detection Fails

Before understanding the solution, it helps to understand why current systems fall short. There are five structural problems, and each makes the others worse.

1. They are too slow.

A 3 to 5 second response time may seem reasonable in isolation. But when payments settle in 2 seconds, a fraud decision that arrives after settlement is record-keeping instead of prevention.

2. They cover too little ground.

Most legacy systems were built to catch credit and debit card fraud. Today's threats include deepfake identity verification (where criminals use AI-generated faces to pass ID checks), social engineering over UPI, corporate email scams, and fake loan applications using fabricated identities. These largely go undetected.

3. They cannot adapt quickly.

When a new fraud pattern emerges, traditional systems need weeks of work before they can recognize it: data collection, model retraining, testing, and deployment. Criminals exploit that window across thousands of transactions.

4. They generate too many false alarms.

False positive rates, meaning legitimate transactions wrongly flagged as fraud, hover around 40%. Analysts spend the majority of their time investigating genuine payments while actual fraud slips through in the background.

5. They are expensive to implement.

Connecting a new bank to a fraud system is typically a six-month custom project.

The Architecture: Five Specialists, One Pipeline

Our multi-agent fraud detection system replaces a single overloaded model with five agents (specialized AI programs), each responsible for one task. A transaction enters the system, passes through all five in order, and exits with a decision in under 200 milliseconds.

A shared context object, think of it as a growing document, travels through the entire pipeline. Each agent adds its findings. By the end, this document contains the full record of how the decision was made, and it is stored as a permanent, tamper-proof audit log.

Here is what each agent does:

Agent 1: Signal Processor

Cleans and standardizes the raw transaction data. Banks send information in different formats, currencies, and time zones. This agent converts everything into a consistent form so the agents that follow can work reliably.

Agent 2: Category Classifier

Routes the transaction into one of nine fraud categories: account takeover, general transaction fraud, card-not-present fraud, mobile fraud, deepfake identity fraud, UPI fraud, loan fraud, wire/business email fraud, and insider fraud. Each category has its own specific rules. A social engineering scam over UPI looks nothing like a corporate wire fraud, and treating them the same wastes both computing resources and accuracy.

Agent 3: Risk Scorer

The core of the system. This agent assigns a risk score using the three-tier process described in detail below.

Agent 4: Decision Agent

Applies the risk score to a decision. Scores below 0.30 result in APPROVE. Scores between 0.30 and 0.70 trigger a CHALLENGE, a step-up verification request sent to the customer. Scores above 0.70 result in DECLINE. Each bank can configure its own thresholds.

Agent 5: Explanation Agent

Produces a plain-language summary of why the decision was made: the top five contributing factors, the reasoning, and a confidence level. Indian and international financial regulations, including RBI, PCI-DSS, and GDPR, require that automated decisions be explainable, so this step is not optional.

The Three-Tier Risk Engine

Most AI fraud systems send every transaction through the most powerful and most expensive model available. Our agent takes a different approach: start with the simplest tool, and only escalate when necessary.

Tier 1: Rules (10 milliseconds)

Forty-eight configurable rules check things like transaction velocity (how many payments were made in quick succession), amount limits, device recognition, and time-of-day patterns. A routine ₹2,500 UPI payment from a recognized device to a known recipient resolves here in 10 milliseconds with no AI involved. Tier 1 handles 60% of all transactions.

Tier 2: Machine Learning (25 milliseconds)

When Tier 1's confidence falls below a threshold, the transaction escalates to an XGBoost model (a type of machine learning algorithm known for speed and accuracy on structured data). It evaluates 65 or more factors and produces a score alongside an explanation of which factors drove it, using a technique called SHAP. This tier runs on standard computer processors with no specialized hardware required. Tier 2 handles 30% of all transactions.

Tier 3: AI with Memory (100 milliseconds)

Only the genuinely ambiguous 5% reach here. A large language model (an AI capable of reading and reasoning over text, similar to the technology behind chatbots) receives the transaction data, the factors from Tier 2, and the three most similar past cases retrieved from a database called ChromaDB. This grounds the AI's reasoning in real precedent rather than guesswork. Tier 3 handles 5% of all transactions.

The end-to-end result is under 200 milliseconds. Because 95% of transactions never reach the large language model, the multi-agent costs 15 times less per transaction than systems that process everything through one.

Self-Learning Without Retraining

Traditional machine learning operates on a fixed cycle: collect data, retrain the model, validate, and deploy. This can take weeks, but the agent closes that gap in seconds.

When a human analyst overrides a system decision, for example, approving a transaction that was flagged because the customer was using a VPN while traveling abroad, three things happen at once:

The transaction details, the original decision, the override, and the analyst's note are converted into a vector embedding (a mathematical representation that captures meaning) and stored in ChromaDB.
A permanent audit entry is created.
The pattern library is updated.

The next time a similar transaction arrives from a different customer but matches the same pattern, the system retrieves the previous case and uses it as evidence. The AI now knows that a human verified this pattern as legitimate. No retraining. No data science work. The system learned in seconds.

Over time, every analyst interaction adds to the system's institutional knowledge, and false positive rates fall continuously.

Deployment: One Configuration File

The Agent deploys through a single configuration file written in YAML (a simple, human-readable format for settings). A bank provides its field mappings, data source, and preferred risk thresholds. One infrastructure command provisions the entire stack, including databases, data pipelines, and monitoring dashboards, in approximately 15 minutes.

Rollout follows three phases:

Days 1 to 2: Configuration and testing.
Weeks 2 to 3: Shadow mode, where the Agent logs decisions without enforcing them, allowing the bank to validate accuracy.
Go-live: Enabled with a single toggle, with no code changes required on the bank's side.

The Technical Stack

The system is built on Python for agent logic, PostgreSQL for logs and configuration, Redis for caching, ChromaDB for vector storage, Apache Kafka for data ingestion, XGBoost for Tier 2 scoring, GPT-4o-mini for Tier 3 reasoning, Docker and Kubernetes for deployment, Terraform for infrastructure, and Prometheus with Grafana for monitoring.

Here are the metrics from our system:

Metric	Value
P50 Latency	18ms
P95 Latency	85ms
P99 Latency	145ms
Fraud Categories	9
Configurable Rules	48
Signals per Transaction	87+
Config to Shadow Mode	~15 minutes
Production Cost (1M txn/day)	~$68K+/year

The cost figure reflects the tiered design. Because 60% of transactions resolve at ₹0.001 each and only 5% reach the large language model at ₹0.12 each, the weighted average cost is approximately ₹0.002 per transaction. For a bank processing 1 crore (10 million) transactions per day, that is ₹64 Lakh per year against the potential to prevent hundreds of crores in losses, representing a roughly 785x return on investment.

What the Team Learned

Decompose before you model. Fraud detection is five distinct tasks. Splitting them across specialized agents produced better accuracy, lower latency, and lower cost than any single model could.
Speed is not a performance metric. It is a product feature. For real-time payments, the difference between 200 milliseconds and 3 seconds is the difference between preventing fraud and documenting it.
Human oversight is the learning mechanism. Analyst overrides were designed for error correction. They turned out to be the most powerful component of the system, each one a training signal that propagates in seconds.
Technical depth requires clear communication. The team rehearsed seven times and prepared answers to 16 anticipated questions. When judges pressed on token consumption, caching, and data segregation, the team had precise answers ready.

What Comes Next

The roadmap includes replacing the external AI API with a self-hosted open-source model to eliminate external dependency, an agent that automatically proposes new Tier 1 rules based on patterns identified in Tier 3, real-time testing between competing rule versions, and cross-bank federated learning where banks collectively benefit from shared fraud pattern knowledge without sharing individual customer data.

The architecture is designed for production.

This article was originally published on the GeekyAnts blog.

A Real-Time AI Fraud Decision Engine Under 50ms

GeekyAnts India Pvt Ltd — Mon, 20 Jul 2026 06:36:18 +0000

Inside a high-performance Real-Time AI Fraud Decision Engine, a system that reviews a financial transaction and returns a decision in under 50 milliseconds.

Every time you tap your phone to pay for something, a quiet competition is taking place. On one side are fraudsters looking to steal money. On the other side are detection systems trying to stop them in the time it takes to blink.

At GeekyAnts, a team of engineers set out to build a fraud detection engine that could make that split-second call. The result is an Autonomous Multi-Agent Pipeline, a system capable of analyzing a financial transaction and deciding whether to approve, challenge, or block it in under 50 milliseconds.

The Problem With Fraud Today

Digital payments have grown at a pace that has outrun traditional fraud prevention. The scale alone is staggering: large financial platforms process tens of thousands of transactions every minute. No team of human analysts can review that volume in real time.

Four problems sit at the heart of the challenge:

Volume. Thousands of transactions arrive every minute, far beyond human review capacity.
False alarms. Many older systems block payments from real customers. These false declines push people away from digital banking.
Speed of attack. Once a fraudster gains access to an account, funds can be moved within minutes.
No clear explanations. Legacy systems often return error codes with no reasoning behind them, making it hard to communicate decisions to customers or regulators.

Three Layers of Intelligence

Rather than rely on a single tool, the team built a system that combines three distinct layers of decision-making:

A machine learning model that scores the risk of each transaction based on behavioral patterns.
A rules engine that checks transactions against known fraud patterns.
AI reasoning agents that generate written explanations of why a transaction was flagged.

Together, these layers handle what none could do alone: catch fraud at speed, explain decisions in plain language, and remain functional even when one component is unavailable.

How a Transaction Gets Reviewed

When a transaction arrives, it passes through a sequence of specialized processes, each one focused on a specific task.

Step 1: Signal Collection

The system gathers and organizes the raw data attached to the transaction: device information, location, transaction amount, and account history. These are converted into a standard format the system can work with.

Step 2: Fraud Category Identification

Not all fraud looks the same. The system checks which of nine fraud categories the transaction might belong to, such as account takeover, card misuse, or wire transfer fraud. Identifying the category helps apply the right detection logic.

Step 3: Risk Scoring

A machine learning model evaluates fifteen risk signals to produce a fraud probability score. These signals include device risk, transaction speed, geographic location, and whether a VPN or proxy is in use, among others.

Step 4: The Decision

Using the risk score and pattern matching against 27 known fraud scenarios, the system decides one of three outcomes: approve the transaction, challenge it (for example, by requesting additional verification), or decline it.

Step 5: The Explanation

In the background, an AI reasoning process generates a written summary of why the decision was made. This explanation is stored for compliance teams, auditors, and customer support — anyone who needs to understand the reasoning later.

Two Paths, One Decision

The architecture separates speed from depth. The fast path handles the core decision in 5 to 15 milliseconds using the machine learning model and the rules engine. This is what keeps the payment experience smooth for the end user.

The enrichment path runs in the background and completes within 200 milliseconds. It produces a fuller picture: threat severity, attack patterns, and recommended actions, all written in plain language rather than code.

Splitting the two paths means the payment does not have to wait for deep analysis. Both can happen without slowing each other down.

Why A Single Method Is Not Enough

Machine learning is good at identifying unusual behavior — transactions that deviate from a user's normal patterns in ways that are hard to put into words. Rules, on the other hand, are good at catching specific, well-documented attack patterns with high confidence.

This decision engine uses both. The rules catch what is known. The machine learning model catches what is unusual. The AI reasoning layer explains what was found. Each method covers the gaps of the others.

The Nine Fraud Types the System Covers

The system is built to recognize a wide range of fraud types common in digital finance:

Account Takeover. When a fraudster gains access to someone else's account, often through stolen credentials.
Transaction Fraud. Unauthorized payments made from a legitimate account.
Card-Not-Present Fraud. Fraud that occurs when a physical card is not required, common in online purchases.
Mobile Banking Fraud. Attacks that target users through mobile apps or devices.
Onboarding and Identity Fraud. False identities used to open new accounts or pass verification checks.
Digital Wallet Fraud. Unauthorized use of payment apps and wallet services.
Loan and Credit Fraud. Applications for credit or loans using false information.
Wire Transfer and Business Email Fraud. Attackers impersonating executives or vendors to redirect payments.
Internal Employee Fraud. Misuse of system access by people within an organization.

Across these nine categories, the system models 27 distinct fraud scenarios — specific attack patterns that the decision engine checks for during each review.

The performance targets were set with real payment flows in mind. A decision that takes several seconds is too slow; customers expect near-instant responses.

Core decision time: 5–15 milliseconds
Full analysis with explanation: under 200 milliseconds
Fraud categories covered: 9
Fraud scenarios modeled: 27

What Building This System Taught Us

The project produced five practical conclusions about fraud detection systems:

Speed is not optional. In payment flows, a slow decision is as disruptive as a wrong one.
Explainability matters as much as accuracy. A system that cannot explain its decisions is a liability for compliance and customer communication.
Hybrid systems outperform single-method systems. Rules and machine learning cover different failure modes.
Observability is essential. Being able to trace each decision through the pipeline makes debugging complex systems possible.
Rules remain necessary for critical decisions. AI reasoning is a valuable layer, but deterministic logic still provides the reliability that high-stakes decisions require.

The Bigger Picture

This multi-agent architecture reflects the direction that real-world fraud prevention is taking. Financial institutions increasingly depend on layered systems that combine structured rules, statistical models, and AI-generated reasoning to keep pace with attackers.

As digital payments accelerate, systems built for the intersection of speed, accuracy, and transparency are no longer just a technical aspiration — they are a necessity. This project is a prime example of what that looks like in practice.

This article was originally published on the GeekyAnts blog.