DEV Community: GeekyAnts

OpenClaw.ai — Your Personal AI That Actually Does Things

GeekyAnts Inc — 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 Inc — 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 Inc — 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 Inc — 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 Inc — 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.

AI Code Healer for Fixing Broken CI/CD Builds Fast

GeekyAnts Inc — Fri, 17 Jul 2026 13:16:12 +0000

The Problem Every Developer Knows

You are on vacation. Your phone buzzes. A build has failed.

You have no laptop, but the expectation is clear: find the problem and fix it. For developers who work with CI/CD pipelines, this scenario is routine. Pipelines fail at the worst moments, blocking releases and forcing engineers to sift through thousands of lines of diagnostic logs from wherever they happen to be.

Our internal engineering teams built a specialized Code Healer to address exactly this.

How the System Works

The solution is a centralized dashboard that connects to your GitHub or GitLab repositories. From this dashboard, developers can monitor their build pipelines, tracking progress, successes, and failures from any device, including a mobile phone.

The platform goes beyond simple monitoring. When a pipeline fails, the system analyzes the failure and guides developers toward a resolution, without requiring them to manually read through massive log files. It delivers AI-powered analysis and specific suggestions for fixing the problem at the code level.

The Two-Agent Architecture

At the heart of the Code Healer is a two-agent AI architecture — meaning two distinct AI systems that work in sequence to diagnose and solve build failures.

The two agents are:

A Local AI Agent: A lighter AI model that runs close to (or within) the developer's own infrastructure.
An Advanced AI Agent: A more powerful AI model capable of deeper reasoning.

When a developer clicks Analyze Failure, the full log from the failed build is sent to the backend. The first task is to strip out the "noise" — CI logs frequently run to thousands of lines, but only a fraction of that content is relevant to understanding what went wrong.

Once the log is cleaned and structured, it is passed to the Local AI Agent, which produces:

A failure summary: A plain description of what went wrong.
Impacted files: The specific files likely connected to the failure.
Possible solutions: Initial recommendations for fixing the issue.
A semantic prompt: A compressed, structured description of the problem context.

That semantic prompt is then forwarded to the Advanced AI Agent, which performs deeper analysis and returns refined failure summaries and detailed solution suggestions.

Code-Level Fixes

Once the initial diagnosis is complete, the developer can click Advanced Assist. At this stage, a specialized AI agent creates a code patch — a specific set of code modifications intended to fix the identified issue.

The same layered methodology is used in this patch generation process: the request goes via the Local Agent before arriving at the Advanced Agent. This ensures that the input the advanced model receives is well-structured, which in turn produces more precise and useful code fixes.

Why Use a Local Agent at All?

Our team implemented the Local Agent for two concrete reasons:

Cost and Speed: Build logs are massive. Sending them in their entirety to a sophisticated AI model results in high latency and costs. The Local Agent serves as a compression layer, extracting only the pertinent context.
Data Privacy: Many organizations are cautious about sending source code to external systems. The Local Agent can be deployed entirely within the client's own cloud environment, ensuring sensitive data never leaves the organization's infrastructure.

Continuous Improvement

The Local Agent is designed to operate independently, but the system also has a mechanism to improve its quality over time. When the Local Agent cannot resolve a problem with confidence, the system escalates to the Advanced Agent. The solution produced is then used as a training signal — feedback that gradually makes the Local Agent more capable.

The Broader Goal

The vision our team holds is that developers should build products, not spend their time diagnosing broken pipelines. By combining pipeline monitoring, AI-driven failure analysis, and code-level suggestions, we are moving toward a future where build systems can identify and resolve their own problems with minimal intervention.

This article was originally published on the GeekyAnts blog.

How We Built an AI System That Automates Senior Solution Architect Workflows

GeekyAnts Inc — Thu, 16 Jul 2026 11:21:17 +0000

30% of a senior architect's time goes into reading RFPs and writing proposals rather than designing systems or solving engineering problems.

A 50-page enterprise RFP lands in an inbox. Two hours later, the architect has concluded what they suspected on page three: React Native frontend, Node backend, PostgreSQL, and Stripe for payments. The decision was predictable, but the process was manual and time-consuming.

This manual work of extracting requirements, spotting contradictions, and drafting a coherent proposal repeats for each RFP. Our teams built an AI-powered co-pilot to change that.

What the AI Presales Co-Pilot Does

This system assists with the presales cycle. You upload a client's documents — PDFs, Word docs, Excel sheets, or emails — and the system produces a draft technical proposal that an architect can review and refine in 15 minutes instead of writing from scratch for 3 hours.

The value extends beyond document generation to reasoning:

Detects Contradictions: It flags tensions, such as a request for Native Mobile only paired with Critical SEO.
Surfaces Assumptions: It states the assumptions it is making (e.g., assuming Stripe for payments) so an architect can confirm or override them.
Confidence Scoring: It scores its own decisions, indicating where reviewers should focus attention.

How It Works: Four Specialized Agents

The system runs four specialized AI agents in sequence. The entire pipeline runs over a WebSocket connection, streaming progress to the dashboard in real time.

Agent 1: Requirement Interpreter

This agent parses raw, unstructured documents using format-specific tools (PyMuPDF, pandas, etc.). It extracts features, technical constraints, and non-functional requirements.

Pattern Enrichment: If a two-sided marketplace is mentioned, the system suggests features like ratings and booking based on a built-in knowledge base.
Conflict Detection: A rule engine identifies over-engineering or technical mismatches during initial analysis.

Agent 2: Solution Engine

This agent produces tech stack recommendations and effort estimates. It uses a hybrid approach: deterministic rules suggest the baseline stack (e.g., NestJS/PostgreSQL), while the LLM validates that choice against the specific client context. Effort estimation provides optimistic-to-pessimistic ranges (e.g., "120–210 hours") to reflect real-world uncertainty.

Agent 3: Self-Critique

Before a proposal is written, a critique agent reviews the solution for consistency. If an assumption contradicts a user input, the system sends a clarifying question back to the architect via WebSockets. Only when the critique approves does the pipeline proceed to generation.

Agent 4: Proposal Composer

The final agent selects a template (MVP, Enterprise, or Standard) and generates a Markdown proposal. The output covers Problem Understanding, Tech Stack, Architecture Overview, and Risk Mitigation.

The Pipeline at a Glance

Stage	Role	Output
1. Parse	Ingestion of any file type	Combined raw text
2. Extract	Conflict & pattern detection	Structured requirements JSON
3. Design	Rule-based stack matching	Solution + effort mapping
4. Review	Validation & User Clarification	Approved technical solution
5. Write	Template-based generation	Polished Markdown/PDF proposal

Engineering Insights

Rule-based systems and LLMs complement each other: Conflict detection and effort mapping do not need an LLM — they need deterministic rules. LLMs handle ambiguity and prose generation.

Transparency is the primary feature. The reasoning trace provides more value than the document itself. By showing why assumptions were made, the system enables architects to review proposals 5–10x faster.

The Technical Stack

Backend: Python with FastAPI for async orchestration.
AI Layer: OpenRouter (Claude, GPT-4, and Gemini) for multi-model reasoning.
Communication: WebSockets for real-time streaming to a React-based frontend.
Knowledge Base: JSON-based datasets for requirement patterns and stack decision rules.

Presales reasoning is repeatable. AI systems that make reasoning transparent and reviewable accelerate the path from RFP to proposal.

This article was originally published on the GeekyAnts blog.

From RFPs to Revenue: How We Built an AI Agent Team That Writes Technical Proposals in 60 Seconds

GeekyAnts Inc — Wed, 15 Jul 2026 11:30:29 +0000

The presales proposal process costs software services companies 3 to 5 days per deal. DealRoom.ai reduces that to under 60 seconds using a pipeline of four coordinated AI agents without compromising estimation accuracy or proposal quality.

A technical proposal is the first deliverable a software company produces for a prospective client. It sets scope, cost expectations, and credibility. The process of producing one has not changed in years.

An RFP arrives. A discovery call follows. Requirements are distributed across a PDF brief, a Word document, follow-up emails, and meeting notes. A solutions architect spends 3-5 days synthesizing these inputs into a proposal. The output is a static document that can be outdated by client review.

This is where deals are won or lost, and the process is a bottleneck that companies accept as fixed. DealRoom.ai was built on the premise that it is not.

Where does the time go

The time cost of presales is distributed unevenly. Analysis of the process across software services teams shows a consistent breakdown:

40% — Reading and reviewing source documents
25% — Feature estimation
20% — Formatting and assembly
15% — Review and revision

Estimation carries the highest risk. Review of actual project sheets from delivered engagements found the same feature assigned 40 hours by one architect and 120 hours by another. Not because of error, but because there was no shared knowledge base, no institutional memory, and no standard method.

For organizations running 20 or more active deals per month, that variance affects more than proposal quality. It limits revenue capacity.

The gap lies in execution

Every presales team has a list of use cases. Delivery pipelines break down. The AI use case gets handed to an existing engineering team. Generalist developers spend months learning new toolchains. The result is a prototype that works in a demo and breaks in production. The initiative stalls. The use case gets deprioritized.

DealRoom.ai closes that gap at the presales stage, producing proposals that are accurate, structured, and ready to send.

Four agents. One coordinated pipeline.

DealRoom is not a single model that reads a document and returns a summary. It is four specialized agents, each with a defined role, passing structured output through a coordinated pipeline.

01 — The Analyst ingests source materials — PDFs, Word documents, and follow-up emails — and extracts structured data: features, user roles, priorities, technical constraints, and integration requirements. It interprets intent. A reference to a map-based tracking feature is translated into its technical components: real-time data requirements, relevant APIs, and backend service dependencies.

02 — The Architect maps the Analyst's structured output into systems, modules, and a recommended technology stack. Each feature is enriched with hours and complexity data from a knowledge base built on historical actuals from delivered projects. Estimates reference what similar features took in production, not inference from a language model.

03 — The Estimator produces three delivery strategies. Conservative defines a minimum viable scope with a lean team. Balanced covers the full scope with a right-sized team and standard timeline. Aggressive deploys a larger parallel team to compress delivery at a higher cost. Each strategy includes a cost breakdown, timeline, team composition, and risk profile.

04 — The Devil's Advocate reviews the output of the preceding agents and challenges assumptions. It identifies timelines that do not account for third-party API stabilization, flags compliance requirements present in the brief that are absent from the feature set, and surfaces integration dependencies that were not addressed during architecture. The proposal survives internal challenges before it reaches the client.

The output is a working interface, not a static document

Most proposals are PDFs. Clients open them, scroll through, and send questions that take 48 hours to answer. That exchange delays decisions and adds friction to the close.

DealRoom produces a web-based proposal that clients can explore. A scope map presents project structure as an expandable hierarchy. A feature toggle table allows stakeholders to include or exclude individual features; each change updates cost, timeline, and team size in real time — no revised estimates, no back-and-forth.

The analytics section gives budget owners and technical decision-makers what they need to evaluate the proposal internally: cost distribution by system, effort by development phase, and team utilization across the delivery period. That data is part of the proposal itself, not a follow-up request.

Every estimate carries a confidence score. A high score indicates grounding in historical project actuals. A lower score flags features estimated without historical precedent — the areas a presales lead should review before submission.

Technical implementation

The frontend is built with Next.js, deployed on Vercel. The backend runs on Python with FastAPI, deployed on Railway, orchestrating agents through an asynchronous pipeline with Server-Sent Events streaming updates to the interface as work proceeds.

The architecture separates language model reasoning from deterministic computation. The Analyst and Architect use GPT-4.1 for document interpretation and system reasoning. The Estimator builds strategies through knowledge-base-driven computation. The Devil's Advocate runs on GPT-4.1-mini. Post-estimator agents execute in parallel via asyncio to maintain pipeline throughput.

The knowledge base underpins every estimate: feature libraries with historical hour ranges from delivered projects, pricing benchmarks by role and seniority, team composition templates, and overhead formulas covering QA, business analysis, tech lead, documentation, and deployment. When the system assigns 52 hours to a feature, that figure has a source in actual project data.

Three conclusions from development

1. Pure language model pipelines are not sufficient for production estimation.

Document interpretation and system reasoning require language model capabilities. Cost calculation and structured data assembly do not. Separating these concerns produces outputs that are analytic and contextually accurate. Conflating them produces outputs that are neither.

2. Internal challenge before client delivery is a quality mechanism, not an overhead.

Proposals processed through the Devil's Advocate review carried timelines 15 to 20 percent longer — and were more defensible. The review identified integration dependencies and compliance gaps that the Architect had not addressed. The cost of that review is low. The cost of a client finding those gaps after submission is not.

3. Presentation format determines how the analysis is acted upon.

An accurate proposal in a static document loses stakeholder attention before the scope is reviewed. The same content in an interactive format held attention through review and generated substantive questions from decision-makers. The format through which analysis is delivered shapes the quality of the decisions it produces.

Current scope and roadmap

DealRoom supports healthcare, e-commerce, and edtech domains, each with domain-specific knowledge bases and feature libraries. Fintech, logistics, and SaaS are next.

A feedback mechanism is in development to route accepted proposals back into the knowledge base. Each completed engagement would refine the estimation data available to future proposals. The objective is a system whose accuracy improves with use, not one that remains static after deployment.

GeekyAnts developed DealRoom.ai as part of the Age of Agents track. It applies multi-agent coordination to a high-frequency, high-stakes business process, demonstrating that autonomous agent pipelines can deliver production-quality outputs in commercial workflows where accuracy and consistency are non-negotiable.

This article was originally published on the GeekyAnts blog.

How Playwright Agents Are Changing the Way We Write and Maintain Tests

GeekyAnts Inc — Fri, 10 Jul 2026 08:10:24 +0000

Adapted from the original post on the GeekyAnts blog.

Ask any automation engineer what their week looks like and you'll hear some version of the same story: read the requirements, write the test cases, script the automation, watch a locator break, chase down why, fix it, run it again. That loop hasn't really gone anywhere — it just moved frameworks, from Selenium to Cypress to Playwright.

So here's a question worth sitting with: what if the framework didn't just run your tests, but actually helped plan them, write them, and repair them when they broke? That's the pitch behind Playwright's Test Agents.

Shipped in Playwright 1.56, these agents bring AI into three specific stages of the testing lifecycle — planning, writing, and healing — by looping against your actual running application rather than guessing from a prompt alone.

This piece walks through what the agents do, how a project gets wired up to use them, what a seed test is for, what comes out the other end, and where this genuinely differs from just asking ChatGPT or Cursor to write you a test script.

Why Playwright Alone Wasn't Enough

Playwright earned its popularity by killing off a lot of the pain that made older frameworks miserable — flaky waits, brittle timing, locators that broke for no obvious reason. Auto-waiting, role-based selectors, and built-in tracing meant engineers spent less time fighting the tool and more time actually testing.

But none of that touched the manual work upstream and downstream of running the tests: translating a requirement doc into concrete scenarios, turning those scenarios into actual code, rewriting tests every time the UI shifts, and chasing broken selectors after every release. Agents are Playwright's attempt to close that gap.

What the Three Agents Actually Do

Playwright Test Agents are AI workflows that live inside a project and split the job into three roles.

The Planner takes a plain-language description of what needs testing, then uses a "seed test" as its entry point into the app to explore flows and edge cases. It comes back with a structured written test plan — not code, but the kind of scenario breakdown a QA engineer would write by hand.

The Generator takes that plan and turns it into runnable Playwright code. Crucially, it does this while poking at the live app — checking that selectors actually resolve, that assertions match real UI state — rather than hallucinating locators from memory. Told to, it'll follow a Page Object Model layout too.

The Healer steps in when a test fails. It re-runs the failing scenario, looks at the current DOM, works out what changed, and tries to patch the selector, wait, or interaction logic itself, instead of leaving that job to whoever's on call.

Chain the three together and the loop becomes Planner, then Generator, then Healer — turning a sentence of intent into a working, self-repairing test suite.

Setting Up a Project

Getting started involves scaffolding a standard Node and Playwright project first, exactly as any engineer already familiar with Playwright would expect. From there, Playwright's own agent tooling can be initialized, which adds a new folder of agent definitions into the project alongside the usual test folders.

That new folder holds three files, one for each agent: the planner, the generator, and the healer, each written as a Markdown definition. Whatever AI assistant is driving the workflow, whether that's Claude Code, VS Code's Copilot, or another agentic coding tool, reads these definitions to understand how to behave in each role.

Alongside the agent definitions, a typical project ends up with a folder for the Markdown plans the Planner produces, a folder for the actual generated Playwright test files, and a single seed test that acts as the Planner's starting point into the application. This layout is the convention Playwright's own tooling expects, so sticking to it keeps things predictable.

The seed test matters more than it sounds like it should. It's the Planner's foothold: where to navigate first, what login step to run, what "home base" looks like for the application before any exploration begins. Alongside it, a small file of sample data (a couple of test user credentials, say — one valid, one intentionally invalid) gives the Planner enough grounding to write scenarios that are actually relevant to the app rather than generic boilerplate.

The Planner Agent in Practice

Think of the Planner less like a code generator and more like a QA analyst that happens to run on AI. Instead of jumping straight to code, it produces a Markdown test plan: scenarios, steps, expected outcomes, and the data each one needs.

A prompt as simple as asking for a test plan covering login with both valid and invalid credentials, using the seed test as context, is enough to get it moving. The Planner explores the app through that seed test and writes out a plan as a readable document, not a script, meant to be read and approved before any code gets written. This is the step where a bad assumption gets caught early, before it turns into a bad test.

The Generator Agent: Plan to Code

Once a plan looks right, the same assistant can be switched into Generator mode and asked to turn that Markdown plan into actual TypeScript tests, following a Page Object Model structure if that's the preference.

The Generator reads the plan, checks selectors and assertions against the live app as it writes, and produces test files — typically one for a straightforward happy path, one covering an edge case, and others built around shared helper functions. Each generated file maps back to a scenario from the plan. Because it's validating against the running app rather than guessing, the output tends to be noticeably more stable than what comes out of a plain prompt-to-code tool with no live context.

The Healer Agent: Fixing What Breaks

Tests fail. A button gets relabeled, a locator moves, and something that passed yesterday doesn't today. Normally that means opening the inspector, finding the new selector, and patching it by hand.

The Healer automates that chase. Pointed at a specific failing test, it re-runs it in debug mode, inspects the current DOM for an equivalent element or flow, proposes a fix such as a new selector or an adjusted wait, and re-runs until it either passes or the agent concludes the failure actually reflects a real product change rather than a stale test. That second outcome matters: the goal isn't to force a green checkmark at any cost, it's to cut down the routine busywork of chasing UI churn.

Under the Hood: What's Actually Happening

From the outside, all of this looks deceptively simple: type a sentence, get back a test plan or a fix. Underneath, the agents run a loop that reads project files, executes real test runs, drives the browser, and inspects the live DOM at every stage. The Planner explores through the seed test, the Generator checks selectors as it writes, the Healer replays failures to diagnose them. That complexity stays hidden — a prompt goes in, a plan, script, or fix comes out, and the orchestration in between isn't something anyone has to manage by hand.

Keeping the Output Organized with Page Object Model

If the generated code needs to stay maintainable long-term, and it should, it's worth being explicit about that in the prompt: asking for a Page Object Model structure with locators kept in separate page files. That nudges the Generator toward splitting locator definitions and reusable actions into their own files, separate from the test logic itself, which saves a lot of refactoring down the line.

The Full Loop, End to End

Run all three agents together and the shape of the workflow is: a seed test plus a prompt goes to the Planner, which writes a Markdown plan; that plan goes to the Generator, which writes the tests; those tests run, and any failures go to the Healer, which fixes what it can. What comes out the other side is a test suite that largely maintains itself. It's the same lifecycle a human QA team already runs, just with AI doing the first draft at every stage.

Where This Differs From Generic AI Coding Tools

It's tempting to lump this in with Cursor, ChatGPT, or any other "AI writes my code" tool, but the comparison doesn't hold up well. Generic AI code generation can write code from a prompt, but it doesn't run the tests it writes, doesn't fix failures on its own, and doesn't check the live DOM while generating. Playwright Agents do all three, and they do it wired directly into Playwright's own tooling through MCP (Model Context Protocol), staying in the loop with the running application throughout rather than generating code from a prompt in isolation.

A Few Things That Make This Work Better

Giving the agents real context matters more than clever prompting — a well-built seed test and structured seed data make a bigger difference than a cleverly worded instruction. Prompts should be specific about architecture preferences, data sources, and expected outputs rather than left open-ended. Generated tests are still worth a human read-through; good scaffolding isn't the same as a finished, reviewed test. And in CI, healed or freshly generated tests are best treated as drafts until someone's actually looked at them.

Wrapping Up

Between the Planner, Generator, and Healer, Playwright's agents take a real bite out of the manual overhead in test automation, turning a plain-language description into scenarios, code, and self-repair without cutting humans out of the review loop.

Anyone with basic Playwright experience already has most of what they need to try this. It's the same lifecycle, with AI doing more of the first draft. Worth trying on a small project first: set up the agents, write a decent seed test, and see how far a simple prompt actually gets.

Adapted from the original article on the GeekyAnts blog.

Building a Production-Ready Image Cropper in React Native

GeekyAnts Inc — Thu, 09 Jul 2026 07:13:15 +0000

Originally published on the GeekyAnts Blog.

Build a production-ready, gesture-driven image cropper from scratch — supporting circular profile crops, rectangular cover crops, draggable windows, resizable corners, and pixel-perfect coordinate mapping back to the original image.

Introduction

In modern mobile applications, image handling is a core experience. Whether uploading a profile picture or setting a cover image, users expect precision, control, and real-time feedback.

While third-party libraries exist, they often introduce heavy dependencies or limit customization. In this article, we'll build a fully custom, gesture-driven image cropper using React Native and expo-image-manipulator — supporting both circular profile crops and rectangular cover crops.

Why expo-image-manipulator?

expo-image-manipulator provides a native bridge for performing image transformations efficiently. All operations — crop, resize, rotate, flip — execute on the native thread, which means they don't block the JS runtime and scale well even on lower-end Android devices.

Compared to pure JS image-processing approaches, the native execution path avoids decoding the full bitmap into a JS array buffer, which can easily exhaust memory on high-resolution photos. The library also handles format conversion (JPEG, PNG, WEBP) and compression in a single pass, so you aren't writing a cropped image to disk and then re-encoding it for upload — the final manipulateAsync call produces the upload-ready file directly.

The package ships two API styles. The legacy imperative API (manipulateAsync) applies a list of transforms in a single async call — ideal for a one-shot crop like ours. The newer context-based API (useImageManipulator / ImageManipulator.manipulate) enables chainable, background-threaded transforms and shines when you need to compose many operations interactively without writing intermediate files to disk. We'll use the imperative API throughout this post.

Installation & Setup

Install via the Expo CLI so the correct native version is automatically matched to your SDK:

npx expo install expo-image-manipulator

For a bare React Native project (without Expo Go), also run the iOS pod install:

npx pod-install

No additional permissions are required. The manipulator operates entirely on local file URIs produced by your image picker — it never touches the camera roll or network directly.

expo-image-manipulator API Overview

We'll use the imperative API — it's perfectly suited to a one-shot crop operation.

Core Function

ImageManipulator.manipulateAsync(
  uri,        // local file URI or base64 data URI
  actions,    // array of transformation objects
  saveOptions // format, compress, base64
)

It returns a Promise which resolves to:

Field	Type	Description
url	string	Local URI to the new file (cached)
width	number	Width of the output image in pixels
height	number	Height of the output image in pixels
base64	string?	Base64 payload if base64: true was passed

Available Actions

Action key	Parameters	What it does
crop	originX, originY, width, height	Crops a rectangular region (in original image pixels)
resize	width, height	Scales the image; omit one dimension to keep ratio
rotate	degrees	Clockwise rotation
flip	"horizontal" \| "vertical"	Mirror along an axis
extent	originX, originY, width, height, backgroundColor	Canvas resize with optional padding fill

Save Options

Option	Type	Default	Description
format	SaveFormat	JPEG	JPEG, PNG, or WEBP
compress	0.0 – 1.0	1.0	1 = highest quality, 0 = maximum compression
base64	boolean	false	Include raw base64 in the result

Component Architecture

The component lives inside an action sheet and owns three pieces of state that together describe the current crop selection:

containerSize — measured width and height of the image container, captured via onLayout
cropPosition — the top-left corner of the crop window in container-space coordinates ({ x, y })
windowDimensions — the current width and height of the crop window in container space

All crop math operates in container space first, then gets converted to original image pixel space at the moment the user taps Crop. This separation keeps gesture handling fast and stateless — no expensive native calls happen during a drag.

Props

interface ImageCropProps {
  showCropper:        boolean;
  handleClose:        () => void;
  selectedUploadType: 'profile' | 'cover';
  uploadFunction:     (data: ImageManipulator.ImageResult) => void;
  tempImage:          string;  // local URI from image picker
}

On mount, two effects run in sequence: the first sets windowDimensions based on the upload type (square for profile, wide rectangle for cover), and the second centers the crop window inside the container once both sizes are known.

// Profile: square up to 200 px. Cover: full width × 150 px.
useEffect(() => {
  if (containerSize.width > 0) {
    if (selectedUploadType === 'profile') {
      const size = Math.min(containerSize.width, 200);
      setWindowDimensions({ width: size, height: size });
    } else {
      setWindowDimensions({ width: containerSize.width, height: 150 });
    }
  }
}, [containerSize, selectedUploadType]);

// Center the window once both sizes are known
useEffect(() => {
  if (containerSize.width > 0 && windowDimensions.width > 0) {
    setCropPosition({
      x: (containerSize.width  - windowDimensions.width)  / 2,
      y: (containerSize.height - windowDimensions.height) / 2,
    });
  }
}, [containerSize, windowDimensions]);

Building The Drag & Resize System

Dragging the crop window

The crop window is a positioned View sitting absolutely on top of the image. A PanResponder attached to its inner area tracks the gesture delta (dx, dy) and updates cropPosition, clamping it so the window never exits the container boundary.

One subtle requirement: the pan responder must not activate when the touch originates inside one of the 20 px corner zones — otherwise the drag and resize responders fire simultaneously and produce jittery, conflicting movement. We check touch coordinates in onStartShouldSetPanResponder and return false for corner touches.

const panResponder = useMemo(() =>
  PanResponder.create({
    onStartShouldSetPanResponder: (evt) => {
      const { locationX: x, locationY: y } = evt.nativeEvent;
      const cs = 20;
      const inCorner =
        (x <= cs || x >= windowDimensions.width  - cs) &&
        (y <= cs || y >= windowDimensions.height - cs);
      return !inCorner;
    },
    onMoveShouldSetPanResponder: (evt) => {
      // Mirrors onStartShouldSetPanResponder — keeps both predicates in sync
      const { locationX: x, locationY: y } = evt.nativeEvent;
      const cs = 20;
      return !(
        (x <= cs || x >= windowDimensions.width  - cs) &&
        (y <= cs || y >= windowDimensions.height - cs)
      );
    },
    onPanResponderMove: (_, { dx, dy }) => {
      setCropPosition({
        x: Math.max(0, Math.min(
          cropPosition.x + dx,
          containerSize.width - windowDimensions.width
        )),
        y: Math.max(0, Math.min(
          cropPosition.y + dy,
          containerSize.height - windowDimensions.height
        )),
      });
    },
  }),
  [containerSize, cropPosition, windowDimensions]
);

Why useMemo matters here

The pan responder captures cropPosition and windowDimensions in its closure at creation time. Without useMemo, a new responder is created on every render, but the gesture system holds a reference to the original — meaning your move handler reads stale state and the crop window drifts noticeably during a fast drag. Wrapping in useMemo with the correct dependency array ensures the responder is always reading current values.

Resizing with corner handles

Each of the four corner handles has its own PanResponder, created by a factory function. The geometry differs per corner: dragging bottom-right simply extends width and height, while dragging top-left must simultaneously shrink the window and shift its origin so the opposite corner stays anchored in place.

const createCornerPanResponder = (
  corner: 'topLeft' | 'topRight' | 'bottomLeft' | 'bottomRight'
) => PanResponder.create({
  onStartShouldSetPanResponder: () => true,
  onPanResponderMove: (_, { dx, dy }) => {
    let newW = windowDimensions.width;
    let newH = windowDimensions.height;
    let newX = cropPosition.x;
    let newY = cropPosition.y;
    switch (corner) {
      case 'bottomRight':
        newW = Math.max(minDimensions.width,  windowDimensions.width  + dx);
        newH = isProfile ? newW : Math.max(minDimensions.height, windowDimensions.height + dy);
        break;
      case 'topLeft':
        newW = Math.max(minDimensions.width,  windowDimensions.width  - dx);
        newH = isProfile ? newW : Math.max(minDimensions.height, windowDimensions.height - dy);
        newX = cropPosition.x - (newW - windowDimensions.width);
        newY = cropPosition.y - (newH - windowDimensions.height);
        break;
      case 'topRight':
        newW = Math.max(minDimensions.width,  windowDimensions.width  + dx);
        newH = isProfile ? newW : Math.max(minDimensions.height, windowDimensions.height - dy);
        newY = cropPosition.y + (windowDimensions.height - newH);
        break;
      case 'bottomLeft':
        newW = Math.max(minDimensions.width,  windowDimensions.width  - dx);
        newH = isProfile ? newW : Math.max(minDimensions.height, windowDimensions.height + dy);
        newX = cropPosition.x - (newW - windowDimensions.width);
        break;
    }
    // Commit only if the new geometry fits entirely within the container
    if (
      newX >= 0 && newY >= 0 &&
      newX + newW <= containerSize.width &&
      newY + newH <= containerSize.height
    ) {
      setWindowDimensions({ width: newW, height: newH });
      setCropPosition({ x: newX, y: newY });
    }
  },
});

For profile mode, height is always forced equal to width (newH = newW) regardless of which corner is dragged, preserving a perfect 1:1 aspect ratio at every resize step. Cover mode allows independent width and height resizing, subject to configurable minimum dimensions.

Coordinate Mapping: Display → Original Pixels

This is the most critical — and most commonly misunderstood — part of building a custom cropper. Your crop window lives in container space (screen pixels inside the View), but manipulateAsync expects coordinates in original image pixel space. The two are not the same.

When an image is rendered with contentFit="cover", React Native scales it so the shorter dimension fills the container exactly — and the longer dimension overflows and is clipped. This means part of the image is hidden off-screen, and any crop coordinate you compute from container space will be offset by exactly that hidden amount unless you correct for it.

The conversion has five steps:

Step 1 — Get the original image dimensions. Call manipulateAsync with an empty actions array. This is a lightweight metadata read with no transformation cost.

const imageInfo = await ImageManipulator.manipulateAsync(
  tempImage, [], { compress: 1 }
);

Step 2 — Determine the displayed dimensions. Compare aspect ratios to find which axis is the constraining one.

const imgAR       = imageInfo.width / imageInfo.height;
const containerAR = containerSize.width / containerSize.height;
let displayedW, displayedH;
if (imgAR > containerAR) {
  // Image is wider than container — height fills, width overflows left/right
  displayedH = containerSize.height;
  displayedW = containerSize.height * imgAR;
} else {
  // Image is taller than container — width fills, height overflows top/bottom
  displayedW = containerSize.width;
  displayedH = containerSize.width / imgAR;
}

Step 3 — Compute the overflow offset. The image is centered inside the container, so the hidden portion is split equally on both sides.

const offsetX = (displayedW - containerSize.width)  / 2;  // 0 when image is taller
const offsetY = (displayedH - containerSize.height) / 2;  // 0 when image is wider

Step 4 — Compute scale factors between the original image and the displayed image.

const scaleX = imageInfo.width  / displayedW;
const scaleY = imageInfo.height / displayedH;

Step 5 — Convert UI coordinates to image coordinates.

const actualCropX = Math.round((cropPosition.x + offsetX) * scaleX);
const actualCropY = Math.round((cropPosition.y + offsetY) * scaleY);

Executing The Crop — Profile & Cover

Profile Photo (square, resized to 200 x 200)

For a profile photo, we want a square crop. We clamp the crop size so it never requests pixels beyond the image boundary, then chain a resize to normalise all uploads to 200 × 200 regardless of how large the user's original photo was.

const actualCropSize = Math.round(windowDimensions.width * scaleX);
const finalSize = Math.min(
  actualCropSize,
  imageInfo.width  - actualCropX,
  imageInfo.height - actualCropY,
);
const croppedImage = await ImageManipulator.manipulateAsync(
  tempImage,
  [
    { crop: {
        originX: actualCropX, originY: actualCropY,
        width:   finalSize,   height:  finalSize,
    }},
    { resize: { width: 200, height: 200 }},
  ],
  { compress: 1, format: ImageManipulator.SaveFormat.JPEG }
);
uploadFunction(croppedImage);

Cover photo (rectangular)

The cover crop uses independent width and height scale factors and clamps each dimension separately so neither ever exceeds the remaining pixels after the crop origin.

const actualCropW = Math.min(
  Math.round(windowDimensions.width  * scaleX),
  imageInfo.width  - actualCropX,
);
const actualCropH = Math.min(
  Math.round(windowDimensions.height * scaleY),
  imageInfo.height - actualCropY,
);


const croppedImage = await ImageManipulator.manipulateAsync(
  tempImage,
  [{ crop: {
      originX: actualCropX, originY: actualCropY,
      width:   actualCropW,  height:  actualCropH,
  }}],
  { compress: 1, format: ImageManipulator.SaveFormat.JPEG }
);
uploadFunction(croppedImage);

The Darkened Overlay Cutout

Rather than a single semi-transparent layer with a punched-out hole (which requires SVG clip-paths or canvas rendering), we use four darkened Views — one for each side of the crop window. Their positions and sizes are derived directly from cropPosition and windowDimensions, so they update in real time as the user drags or resizes without any additional state.

{/* Top — spans full width, height = distance from top to crop window */}
<View style={{ position: 'absolute', top: 0, left: 0, right: 0,
  height: cropPosition.y, backgroundColor: 'rgba(0,0,0,0.5)' }} />
{/* Bottom — starts where the crop window ends */}
<View style={{ position: 'absolute', bottom: 0, left: 0, right: 0,
  height: containerSize.height - (cropPosition.y + windowDimensions.height),
  backgroundColor: 'rgba(0,0,0,0.5)' }} />
{/* Left — only spans the crop window's row to avoid double-darkening corners */}
<View style={{ position: 'absolute', top: cropPosition.y, left: 0,
  width: cropPosition.x, height: windowDimensions.height,
  backgroundColor: 'rgba(0,0,0,0.5)' }} />
{/* Right — mirrors left */}
<View style={{ position: 'absolute', top: cropPosition.y, right: 0,
  width: containerSize.width - (cropPosition.x + windowDimensions.width),
  height: windowDimensions.height,
  backgroundColor: 'rgba(0,0,0,0.5)' }} />

Inside the crop window, the border style switches between a full-radius dashed circle (borderRadius: 999, borderStyle: 'dashed') for profile mode and a plain solid rectangle for cover mode. A rule-of-thirds grid is drawn with four thin Views at 33% and 66% positions, giving users a professional alignment guide without any additional library.

Usage

import { ImageCrop } from './ImageCrop';


const MyScreen = () => {
  const [showCropper, setShowCropper] = useState(false);
  const [pickedImage,  setPickedImage]  = useState<string | null>(null);
  const handleUpload = (result: ImageManipulator.ImageResult) => {
    uploadToServer(result.uri);
    setShowCropper(false);
  };
  return (
    <>
      {/* ... rest of your screen ... */}
      {pickedImage &&
        <ImageCrop
          showCropper={showCropper}
          handleClose={() => setShowCropper(false)}
          selectedUploadType="profile"
          tempImage={pickedImage}
          uploadFunction={handleUpload}
        />
      }
    </>
  );
};

UX Enhancements

Grid lines (rule of thirds)
Corner handles for resizing
Loading overlay during processing
Auto-centered crop window
Dynamic resizing based on container

Performance Considerations

Avoid repeated manipulateAsync calls
Use useMemo for gesture handlers
Perform crop only on user confirmation
Use compression wisely (0.8–1)

Advanced Extensions

Pinch-to-zoom support
Rotation & flipping controls
Circular live preview
Cloud upload integration (S3/Firebase)
Combined zoom + crop gestures

Summary & Key Takeaways

Building a custom image cropper in React Native gives you full control over UX, performance, and flexibility.

Key learnings:

expo-image-manipulator handles heavy image processing natively
PanResponder is sufficient for complex gesture interactions
Coordinate mapping is the backbone of accurate cropping
Overlay-based masking provides a clean UI without extra dependencies
Supporting multiple crop modes requires thoughtful architecture

This approach is particularly valuable for applications handling user-generated content, where performance, flexibility, and consistent media output directly impact user experience and scalability.

Special thanks to Deepanshu Goyal for architectural guidance and review.

This article was originally published on the GeekyAnts Blog.

Geeklego: The Open-Source Design System Built to Work With AI

GeekyAnts Inc — Wed, 08 Jul 2026 11:02:49 +0000

Fork it. Define your 3-tier design system. Let Claude Code, Codex, Gemini CLI — or any AI coding tool — generate a consistent, accessible UI that can never break your design rules.

Originally published on the GeekyAnts Blog.

The Problem With Design Systems in the Age of AI

Design systems are supposed to bring consistency. But in practice, they are a document that developers mean to follow, a Notion page that's three months out of date, and a set of tokens that might or might not match what's actually in the code.

Now add AI coding tools to the picture. Claude Code, Codex, Gemini CLI, and Cursor — these tools generate components fast. Impressively fast. But fast without constraints is how you end up with hardcoded hex values, skipped token tiers, and five different ways to truncate text across a codebase that was supposed to be consistent.

The problem is structural: design systems are defined separately from the rules that enforce them. AI tools have no way to know that --color-brand-500 should never appear directly in a component, or that every spacing value must come from a semantic token, or that dark mode only works if you respect the semantic tier. No one told the AI. So it guesses — and it guesses consistently wrong in different ways.

Geeklego is our answer to this problem. And it's open source.

What Is Geeklego?

Geeklego is an open-source, AI-native design system built on Tailwind CSS v4. It ships three things:

A 3-tier design system — a single CSS file (geeklego.css) that defines every visual value across three strict tiers: raw primitives, purpose-driven semantics, and component-specific tokens. It is the authoritative, machine-readable source of truth for the entire project.
A skill layer — six AI skills (for Claude Code, Codex, Gemini CLI, or any agent-capable tool) that generate components, sync with Figma, audit for accessibility and security, and add internationalization — all while enforcing the 3-tier architecture automatically.
81 production-ready components — atoms, molecules, and organisms that are expressions of the design system, each generated by the skill layer and proven to follow the rules.

Geeklego is not a component library you install and override. It's a design system you own and extend — with an AI layer that makes extension fast, consistent, and safe.

The philosophy is simple: define the system first. Let AI build from it, not around it.

The Vision: A Design System That Teaches Itself to AI

Every AI coding tool — Claude Code, Codex, Gemini CLI, Cursor — is only as good as the context it has. Give it no context, and it invents conventions. Give it a good context, and it follows yours.

Geeklego's vision is to make the design system itself that context. Not a README that someone has to remember to reference. Not a Storybook that AI can't read. The actual architecture — the 3-tier token chain, the 5-file component structure, the 45 explicit rules — is encoded in a machine-readable spec (CLAUDE.md) that any AI coding tool can consume before it writes a single line.

AI that is constrained by your design system, not set loose on your codebase.

When any AI tool generates a component in Geeklego, it can't hardcode #6366f1. It can't use h-[40px]. It can't reference a Tier 1 primitive directly from a component. The architecture makes inconsistency structurally impossible — not a guideline someone has to remember, not a lint rule someone can suppress.

The long-term vision: you define the system once. Every AI that ever touches your codebase — today's tools, next year's tools, tools that don't exist yet — generates components that follow it perfectly. Hundreds of components, zero design drift. That's what Geeklego is building toward.

Design-System-First: The 3-Tier Architecture That Changes Everything

In every component library you've used, the design system emerges from component code. You build a Button, extract its colors into variables, build a Card, extract its spacing, and over time something resembling a design system appears.

Geeklego inverts this completely.

Before a single component is written, the design system is defined and published across three distinct tiers. Components are built as expressions of the system, constrained to use only what the system provides — and only in the order the system prescribes.

The 3-Tier Token Chain

This is the central idea in Geeklego. Everything else flows from it.

Tier 1 — Primitives are raw values: --color-brand-500: #6366f1, --spacing-4: 1rem. They are the foundation of the entire system. No component ever references a primitive directly. That's the rule.

Tier 2 — Semantics give purpose to primitives: --color-action-primary: var(--color-brand-500). This is where theming happens. When you switch to dark mode, semantic tokens update. Primitives stay unchanged. The semantic tier is the single mechanism that makes theme switching work correctly across every component in the library simultaneously.

Tier 3 — Component tokens bind individual components to semantics: --button-bg: var(--color-action-primary). A component token must always reference a Tier 2 semantic. Referencing a primitive directly — skipping Tier 2 — is forbidden. This is non-negotiable, encoded in the architecture, and enforced by the Claude Code skill before it writes a single line of component code.

Here's the full chain for a Button's background color:

/* Tier 1 — Primitives*/
/--color-brand-500: #6366f1;

/* Tier 2 — Semantics*/
/--color-action-primary: var(--color-brand-500);

/ Tier 3 — Component tokens*/
/--button-bg: var(--color-action-primary);

And in a component:

<button className="bg-[var(--button-bg)] ...">Submit</button>

Here's why all three tiers are necessary. When you toggle dark mode, you update one Tier 2 semantic:

[data-theme="dark"] {  --color-action-primary: var(--color-brand-400);}

That is the only change. Every component that reads --button-bg picks up the new value through the chain — automatically, correctly, everywhere. No per-component dark mode overrides. No !important patches. No missing cases discovered in production.

If a component token had skipped Tier 2 and referenced a Tier 1 primitive directly, that component would be invisible to theme switches. It would render the same color in light and dark mode, and you'd never know why until a designer filed a bug report.

The 3-tier chain is not a bureaucracy. It's the mechanism that makes the entire system coherent.

No Arbitrary Values. Ever.

The 3-tier chain only works if it's airtight. So Geeklego forbids Tailwind arbitrary values like bg-[#6366f1] or h-[40px]. Every value — every color, every size, every spacing unit — must flow through all three tiers and arrive as a Tier 3 component token.

The only permitted syntax is bg-[var(--button-bg)], wrapping a Tier 3 CSS variable in Tailwind v4's arbitrary value syntax.

This constraint has a profound side effect: AI can only generate valid, chain-compliant code. When Claude Code generates a component, there's nowhere to put a hardcoded value. The language doesn't permit it. Design integrity is enforced by architecture, not code review.

What Ships With Geeklego Today

81 Production-Ready Components

Geeklego currently ships three levels of the component hierarchy:

L1 Atoms (38 components) — the building blocks: Avatar, Badge, Button, Checkbox, Input, Select, Spinner, Switch, Tooltip, and 29 more. Atoms import nothing — they're pure expressions of the design system.

L2 Molecules (27 components) — combinations of atoms: AlertBanner, Breadcrumb, ButtonGroup, Calendar, Card, Combobox, DateInput, DropdownMenu, Fieldset, FormField, InputGroup, Navbar, NumberInput, Pagination, Popover, RadioGroup, SearchBar, StatCard, Stepper, Toast, Tooltip, TreeView, and more.

L3 Organisms (16 components) — full UI sections: Accordion, AreaChart, BarChart, Carousel, Chat, ColorPicker, DataTable, Datepicker, Drawer, Footer, Form, Header, Modal, PieChart, Sidebar, Tabs, and more in active development.

L4 Templates and L5 Pages are in active development. DashboardLayout, AuthLayout, and LandingLayout are coming next.

Every component in the fork ships with:

Full TypeScript types and JSDoc-annotated props
Light and dark mode support out of the box, via the 3-tier token chain
WCAG 2.2 Level AA accessibility (keyboard nav, ARIA, focus management)
Responsive design via Tailwind responsive prefixes
8 Storybook stories per component (used as automated tests via Vitest)
Optional Schema.org markup for SEO
Optional i18n string support

A Visual Token Editor

npm run dev opens a full React app at localhost:5176 for editing the design system without touching code.

A three-panel layout: a left NavRail organizes tokens into three tiers (Foundations with 8 sub-categories like color, spacing, typography, and shadow; Semantic with purpose-driven alias groups; Components listed by level) with drill-down sub-categories, a center pane shows the selected category or component, and a right Inspector panel displays token details with value editing and alias chain visualization. Export is available from the header bar. Changes preview instantly across Storybook via WebSocket. Full undo/redo history. Automatic backup. Token validation. Export as CSS or JSON.

This means designers can edit the design system directly. Not in a Notion doc that may or may not reflect the code. In the actual source of truth, with live preview.

Storybook as Living Tests

Geeklego treats Storybook stories as executable tests. Each .stories.tsx file becomes a Vitest test running headless in Chromium via Playwright. No separate test infrastructure. Stories serve double duty as documentation and automated regression tests.

Every component requires eight stories: default, variant A, variant B, size/scale, disabled state, loading state, dark mode, and an accessibility story tagged for WCAG audit.

The Skill Layer: AI That Knows the Rules

This is the part of Geeklego that has no equivalent in any other design system.

Geeklego ships with six skills — self-contained, machine-readable workflow definitions that any capable AI coding tool can execute. They work today with Claude Code, and are designed to be portable to Codex, Gemini CLI, or any agent-capable environment that can read a prompt file and call tools.

Each skill is not a prompt template. It's a disciplined workflow that reads the design system state first, validates the 3-tier chain, applies the change, then runs a verification pass. The AI doesn't guess. It follows a documented process.

The Six Skills

/component-builder — The flagship skill. Invoke it with any component description and the AI reads geeklego.css, verifies no token block already exists, writes Tier 3 component tokens (each correctly referencing a Tier 2 semantic), generates all five required files, then runs four sequential audits: accessibility, performance, SEO, and security. A component that takes a human two to three hours ships in two to three minutes — and is structurally guaranteed to follow the token chain.

/component-builder build a Tooltip atom/component-builder build a StatCard molecule/component-builder build a DataTable organism with sorting and pagination

/figma-sync — Sync your Tier 1–3 token definitions to Figma variable collections and text styles automatically. The skill diffs the current Figma state against geeklego.css, reports what's out of sync, then creates or updates variables to match. Design and code never drift apart.
/i18n — Add internationalization to any component without committing to a specific i18n library. Library-agnostic, prop-first architecture with RTL support via logical CSS properties. Reads the string inventory to know which system strings already have i18n coverage.
/state-handling — Audit and generate visual state patterns. Every interactive component needs correct loading, disabled, error, and selected states with proper ARIA attributes. This skill reads the state-handling reference, validates what exists, and generates what's missing.
/security-review — Audit components for XSS vulnerabilities, unsafe href handling, missing rel="noopener" on external links, and unsanitized user input. Runs against the full component tree.
/screenshot-workflow — Generate component screenshots automatically for documentation, changelogs, or CI/CD visual regression pipelines.

On-Demand Audit Commands

Beyond the skills, natural-language audit commands run across the entire codebase:

do a refactor check     # Memoization, hooks compliance, performance utility usagedo a reuse audit        # Find inlined markup that should use existing atomsdo an SEO audit         # Schema.org coverage, semantic HTML, heading hierarchy

The Machine-Readable Spec

The skills work because the design system's rules are encoded in a machine-readable spec — CLAUDE.md — that any AI coding tool reads before starting any task. It contains 45 explicit "never do" rules, 49 "always do" rules, naming conventions, the token chain hierarchy, component level definitions, and reference documents for worked examples, semantic HTML, ARIA patterns, and Schema.org mappings.

This is not a README for humans. It's a contract for AI. Every tool that reads it gets the same constraints. Design integrity is preserved not by hoping the AI guesses right, but by telling it exactly what right means — before it generates a single token.

How Geeklego Differs From Other Design Systems

Most design systems are collections of decisions: here are the colors, here are the spacing values, here is a Figma file. Implementation is left to the team. Consistency depends on culture, code review, and people remembering the rules.

Geeklego is a design system that enforces its own rules. Not through linting, not through code review, not through policy — through architecture. The 3-tier chain makes it structurally impossible to introduce a hardcoded value or skip a token tier, because the skill that generates components checks the chain before writing anything. And the machine-readable spec means any AI tool you bring to the project inherits those constraints immediately.

Feature	Typical design system	Geeklego
Token architecture	Ad hoc or flat	Strict 3-tier chain: primitives → semantics → component tokens
Dark mode	Per-component overrides	Automatic — update Tier 2 semantics, all components cascade
AI compatibility	Unstructured — AI must guess conventions	Machine-readable spec — AI reads the rules before generating anything
Component generation	Manual	Skill-driven with full 3-tier validation and audit pipeline
Figma integration	Manual, periodic sync	Automated sync skill, diff-aware
Token editor	External tools or none	Built-in visual editor with live preview
Accessibility	Depends on the team	WCAG 2.2 AA baked into the component-builder skill
i18n	Separate effort	Library-agnostic pattern, built into the skill layer
Multi-brand support	Fork and diverge	Fork and share component logic; only tokens differ

The shift is from "design system as document" to "design system as enforced architecture." One you reference. The other you can't break.

Real-World Use Cases

Rapid prototyping. Edit the design system in the token editor. Use /component-builder to generate components that match. Preview in Storybook. Sync tokens to Figma for designer feedback. When the design is locked, your production components are ready. Two days instead of two weeks.

Design system governance at scale. Define your tokens. Every team generates components via /component-builder — they can't deviate because the architecture prevents it. Run audits on PRs. The design system becomes enforceable by architecture, not by policy. Code reviews drop from 30 minutes to 5 minutes.

Multi-brand products. Fork Geeklego twice. Each fork has its own geeklego.css with its own colors, fonts, and spacing. Both forks share identical component logic. Update the logic once, both brands benefit. Maintain one codebase, support multiple brands.

Accessible component libraries. Accessibility is built into the component-builder skill — not bolted on after. Every generated component includes the right ARIA attributes, keyboard navigation patterns, touch targets, and semantic HTML. WCAG 2.2 AA by default, not by accident.

Getting Started: Fork and Make It Yours

Geeklego is designed to be forked, not installed. Forking gives you the full 3-tier design system, the visual token editor, all 81 components, and every AI skill — everything you need to customize the system and build from it.

# 1. Fork the repo on GitHub, then clone your fork
git clone https://github.com/YOUR-USERNAME/geeklego.git
cd geeklego

# 2. Install dependenciesnpm install

# 3. Start both the token editor and Storybooknpm run dev:all

Two apps open:

localhost:5176 — the token editor: customize your Tier 1–3 tokens visually, no code required
localhost:6006 — Storybook with all 81 components, live-connected to the token editor

Open your AI tool and start building:

# With Claude Code

/help                                # see all available skills
/component-builder build a [ComponentName]  # generate a new component end-to-end

# With Gemini CLI or Codex

# Point your agent at CLAUDE.md as system context,

# then trigger the same skill workflows from the .claude/skills/ directory

The machine-readable spec in CLAUDE.md is read automatically by Claude Code before every task. For Codex, Gemini CLI, or other agent-capable tools, pass CLAUDE.md as your system context — it's plain markdown and works with any tool that accepts instruction files.

Customize your design system:

Open the token editor at localhost:5176. Edit Tier 1 primitives (your brand colors, spacing scale, type sizes), Tier 2 semantics (what each primitive means in context), and watch every component in Storybook update in real time. When you're ready, export as CSS or JSON.

That's it. The design system is yours. The components follow it automatically. The AI skill layer keeps new components consistent with it, forever.

How to Contribute

Geeklego is open source and actively welcoming contributors. The remaining work on the roadmap includes HeroSection (L3), DashboardLayout, AuthLayout, and LandingLayout (L4 Templates).

Every contribution follows the same pattern — 5 files, the 3-tier token chain, 8 Storybook stories. The machine-readable spec and the skill layer make it straightforward to use your AI tool of choice to generate a contribution that meets the bar from the first commit. You don't need to memorize the rules — the spec teaches the AI, and the AI generates compliant code.

GitHub: https://github.com/GeekyAnts/geeklego
Website: https://geeklego.io
Issues & discussions: open a thread on GitHub

Give it a star, open an issue, or fork it — use /component-builder to generate your contribution and it'll follow the rules from the first commit. We'd love to see what you build.

Geeklego is open source under the MIT license. Built with React 19, Tailwind CSS v4, Vite 6, Storybook 10, and Vitest.

Originally published at geekyants.com/blog.

The Keyboard Bounce of Death: Handling Inputs on Complex React Native Screens

GeekyAnts Inc — Fri, 03 Jul 2026 13:01:37 +0000

Modern React Native has evolved significantly—Expo's new architecture is stable, Hermes is the default engine, layout rendering has improved, and libraries like Reanimated and React Native Screens are widely adopted. Yet one issue continues to frustrate even experienced engineers:

The Keyboard Bounce of Death

Your inputs jump, shift, or completely hide behind the keyboard—a frustrating experience that makes your app feel buggy and cheap.

If you are building login screens, onboarding flows, multi-step forms, or bottom-sheet-based UIs… you've likely seen this happen.

This article explains why this problem still occurs in modern React Native setups and provides battle-tested solutions you can confidently use in production.

Version Context

The examples and recommendations are written with current (2024–2025) React Native stacks in mind, commonly seen in production apps today:

React Native: 0.74+
React: 18
Expo SDK: 50+ (New Architecture enabled)
Hermes: Enabled (default)
react-native-keyboard-controller: 1.20.x
react-native-reanimated: 3.x
react-native-screens: 3.x
@shopify/flash-list: 1.x

These versions are provided for context rather than certification.

Exact behavior may vary depending on project configuration, cross-platform (iOS / Android), and library versions. Readers should validate keyboard behavior against their own application stack.

The Real Problem: Keyboard Handling Breaks at the Architecture Level

In modern React Native applications, keyboard issues are no longer caused by misconfigured props or missing offsets. The failure is architectural.

Classic solutions such as KeyboardAvoidingView assume a synchronous, stable layout model. That assumption no longer holds in React Native's current execution environment, where rendering, layout, and native events operate on partially decoupled timelines.

Where the breakdown happens

1. Layout virtualization (React Native Screens ~3.30.x)

Navigation stacks aggressively detach inactive screens to reduce memory and improve performance. This means:

The active screen's layout is often unresolved during transitions
Height measurements are stale at the moment keyboard events fire
Offset calculations are applied against incomplete layout data

Keyboard avoidance logic executes correctly—but against the wrong inputs.

2. Concurrent Rendering Changes Layout Timing (RN 0.74+)

With React 18 integration and the New Architecture, React Native now supports concurrent rendering. Unlike legacy synchronous rendering, concurrent rendering allows work to be interruptible and scheduled across frames.

This changes long-standing assumptions about layout timing:

Layout commits are no longer guaranteed to be synchronous.
Native keyboard events can fire before the React tree has fully committed.
Measurements taken during focus events may reflect intermediate layout states.

In complex screens (navigation stacks, bottom sheets, nested scroll views), this can produce visible misalignment:

Keyboard height is computed.
Offset is applied.
Layout commits afterward.
The UI shifts again.

The result appears as a "bounce," but the underlying issue is timing desynchronization between native keyboard animations and React layout commits.

This is not a bug in React Native — it is a natural consequence of concurrent rendering's scheduling model.

3. Android keyboard behavior is non-deterministic by design

On Android 12–14, keyboard behavior varies significantly by OEM:

Heights are percentage-based, not pixel-stable
Gesture navigation dynamically alters safe areas
Floating and split keyboards introduce transient viewports

React Native receives incomplete or rapidly changing inset information, making consistent keyboard avoidance mathematically unreliable.

4. Nested, stateful scroll containers amplify the problem

Most production forms are embedded inside:

Bottom sheets
Modals
Tab navigators
Collapsible or animated headers

These containers continuously mutate their layout constraints. Auto-scroll and focus calculations depend on deterministic container heights—conditions that no longer exist in deeply composed UI trees.

All this means classic keyboard handling methods break on multi-layered screens.

Example Problem Scenario (What Actually Happens)

You have a complex screen with a header, multi-section form inputs, a bottom CTA, all inside a ScrollView and wrapped inside a navigation stack.

When the user taps the last input:

The input jumps upward suddenly, OR
Gets partially hidden, OR
ScrollView auto-scrolls too late, OR
The keyboard overlaps your crucial bottom CTA button.

This is the reality of real-world apps, especially those built on the modern Expo/new architecture.

The Modern Solution Stack (Production-Proven)

These are the modern, recommended approaches that actually fix the issue in today's React Native architecture.

Solution 1 — Native Keyboard Synchronization with KeyboardProvider (react-native-keyboard-controller 1.20.x)

Modern React Native apps fail at keyboard handling not because of incorrect offsets or missing props, but because keyboard animations and layout updates are not synchronized at the native level.

react-native-keyboard-controller addresses this root cause by coordinating keyboard state, animation timing, and layout updates directly in native code.

Recommended Integration: Root-Level KeyboardProvider

The primary integration point is KeyboardProvider, which enables native keyboard synchronization across the entire application.

import { KeyboardProvider } from "react-native-keyboard-controller";
export default function App() {
  return (
    <KeyboardProvider>
      <RootNavigator />
    </KeyboardProvider>
  );
}

This enables native keyboard coordination for the entire app.

Scoped Keyboard Handling with KeyboardControllerView

KeyboardControllerView is an internal building block used by KeyboardProvider.

It should only be used when keyboard coordination must be explicitly scoped to a specific layout subtree.

Typical use cases include:

Forms inside modals or bottom sheets
Screens where only a portion of the UI should respond to keyboard movement
Preventing unnecessary re-layout of non-interactive UI

Why is it better

Computes keyboard height precisely
Works flawlessly with bottom sheets, tabs, and modals.
Better on Android 12–14
No layout jumps
Supports concurrent rendering

Runtime Control with useKeyboardController

useKeyboardController is a hook that gives access to the state of the react-native-keyboard-controller library. It returns two values:

enabled - a boolean value which indicates whether the library is enabled in the app;
setEnabled - a function that changes the state of the enabled property.

This hook is used only to enable or disable the native keyboard controller—primarily for gradual Android integration or fallback to adjustResize behavior when required.

Solution 2 — Native-Friendly Scroll Containers (Reanimated 3.10+, FlashList 1.7.x)

Keyboard issues on complex screens often occur when scroll position and keyboard movement are driven by JavaScript.

This causes delayed measurements and visible layout jumps during focus transitions.

To remove JavaScript from the critical layout path, use scroll containers that integrate cleanly with native animation timing:

Animated.ScrollView (Reanimated) for small, controlled layouts
FlashList for long, dynamic, or virtualized content

Both integrate better with native-driven keyboard animations.

Reanimated ScrollView Example:

<Animated.ScrollView
  keyboardShouldPersistTaps="handled"
  contentContainerStyle={{ paddingBottom: keyboardHeight }}
>
{children}
</Animated.ScrollView>

FlashList Example:

import { FlashList } from "@shopify/flash-list";
<FlashList
  data={data}
  estimatedItemSize={80}
  keyboardShouldPersistTaps="handled"
  contentContainerStyle={{
    paddingBottom: keyboardHeight,
  }}
  renderItem={renderItem}
/>

Solution 3 — If You Use Bottom Sheets (Reanimated / Gorhom)

Bottom sheets introduce an additional animated layer that can conflict with keyboard transitions and scrolling.

Without careful configuration, this often results in keyboard bounce, input focus jumps, or unstable drag behavior.

Bottom Sheet Gesture Configuration

Disable content panning only when:

The bottom sheet contains multiple text inputs
Nested scroll views compete with drag gestures
Keyboard interaction feels jumpy or unstable

enableContentPanningGesture={false}

Android Keyboard Mode

Use this only as a fallback when relying on the default Android window resizing behavior.

Forcing adjustResize can reintroduce layout jumps if combined with native keyboard synchronization.

android_keyboardInputMode="adjustResize"

Solution 4 — Use useWindowDimensions() Instead of Static Screen Height

Keyboard and screen size changes often break layouts that rely on static dimensions:

The problem:

Dimensions.get('window') is static
It does not update when the keyboard appears, the screen rotates, or the device enters split-screen
Any layout based on this value may be clipped, overlapped by the keyboard, or cause scroll jumps

Use this:

const { height } = useWindowDimensions();

It adapts when the keyboard reduces available height dynamically.

Solution 5 — Use KeyboardAwareScrollView for Automatic Input Scrolling

When your form contains multiple inputs, simply preventing layout jumps is often not enough.

You also want the focused input to scroll into view automatically.

react-native-keyboard-aware-scroll-view handles this efficiently.

Why This Works

Automatically scrolls the focused input above the keyboard
Works with nested forms and long lists
Supports Android and iOS, including safe handling of bottom tabs
Integrates well with native keyboard controllers (like react-native-keyboard-controller)
Minimal setup — reduces boilerplate scroll logic

Practical Real-World Implementation (Full Code Example)

This is a rock-solid implementation used in production onboarding flows:

import { KeyboardAwareScrollView, useKeyboardState } from "react-native-keyboard-controller";
import { TextInput, View } from "react-native";

export default function RegistrationForm() {
const keyboardHeight = useKeyboardState((state) => state.height);
return (
    <KeyboardAwareScrollView
      contentContainerStyle={{ paddingBottom: keyboardHeight + 20 }}
      bottomOffset={50} // optional offset for bottom CTA buttons
      keyboardShouldPersistTaps="handled"
    >
      <InputField />
      <InputField />
      <InputField />
    </KeyboardAwareScrollView>
  );
}
function InputField() {
  return (
    <TextInput
      style={{
        borderWidth: 1,
        marginVertical: 12,
        padding: 12,
        borderRadius: 8,
      }}
    />
  );
}

This handles:

iOS + Android
Gesture navigation
Variable keyboards
Concurrent rendering
ScrollView-based layouts
Bottom CTA buttons

ALL without layout jumps.

Debugging Checklist (What To Test Before Shipping)

Test split-screen mode on Android

Your input may be hidden due to reduced viewport height.

Test floating keyboard mode

TikTok/Samsung keyboards break height assumptions.

Test device rotation

Keyboard height changes drastically in landscape.

Test inside modals & bottom sheets

Most keyboard bugs occur inside nested containers.

Measure layout flicker using this:

adb logcat | grep "keyboard"

adb logcat → streams real-time Android system logs

grep "keyboard" → filters logs related to keyboard / IME events

What you will see

Logs like:

Keyboard show/hide events
IME height changes
Window resize calls
Focus changes

Why this matters

If you see:

Multiple keyboard show/hide events for one input focus
Rapid resize → unresize cycles
Keyboard height changing more than once

That's the root cause of flicker/bounce.

or for iOS:

xcrun simctl spawn booted log stream --level debug | grep "keyboard"

What this does

Streams iOS system logs from the Simulator
Filters keyboard-related notifications

What you'll see

UIKeyboardWillShow
UIKeyboardDidShow
Frame and height updates
Animation duration mismatches

Why this matters

If:

WillShow fires multiple times
Keyboard frame changes mid-animation

Your layout is reacting out of sync with the keyboard.

Conclusion: Keyboard Handling in Modern React Native Requires a New Approach

The assumptions behind KeyboardAvoidingView no longer hold up for modern React Native applications that rely on:

Concurrent rendering
react-native-screens
Bottom sheets and modals
The new architecture and Hermes
Deeply layered, animated UIs

In these environments, keyboard behavior becomes a cross-cutting concern, involving layout measurement, animation timing, gesture handling, and native window resizing.

To build reliable, input-heavy screens, production apps increasingly rely on a combination of:

Native keyboard synchronization (react-native-keyboard-controller)
Reanimated or FlashList-based scrolling
Dynamic keyboard height handling
Scroll-to-focused-input utilities
Intentional layout stabilization techniques

This layered approach reflects how high-quality production apps—including financial, social, and AI-driven products—handle keyboard interactions today.

This article was originally published on the GeekyAnts blog.