DEV Community: Harsha

Core Banking Modernization: Engineering Trade-offs and 5 Companies to Evaluate

Harsha — Thu, 24 Sep 2026 09:54:32 +0000

Modernizing a banking platform means changing systems while customers continue making payments, checking balances, and completing onboarding. A migration can deliver new functionality while still failing operationally if transactions become inconsistent or incidents become harder to diagnose.

The GeekyAnts video Modernizing Core Banking Without Downtime discusses phased migrations, payment orchestration, mobile security, and observability. This article uses its transcript as a starting point and examines the engineering questions behind those approaches.

What Does Phased Modernization Actually Require?

The transcript describes a strangler fig approach: gradually replacing legacy functionality while the existing system continues operating.

For example, a bank could introduce a new onboarding service while retaining its existing account ledger. Subsequent stages might replace other capabilities once their dependencies and behavior are understood.

The difficult part is managing the transition between systems. Teams need clear answers to questions such as:

Which system owns each piece of data during migration?
How are requests routed between old and new services?
How are incomplete or duplicated operations detected?
What happens to transactions already in progress during a rollback?

A phased approach limits the scope of each change. It still requires testing, reconciliation, and explicit recovery procedures.

Payment Orchestration Needs More Than Gateway Routing

The video also highlights multi-gateway payment orchestration.

Routing payments through different providers can offer operational flexibility, but a timeout creates an important ambiguity: the provider may have processed the payment even though the application did not receive confirmation.

Immediately retrying through another gateway could create a duplicate charge.

A design review should therefore examine idempotency, transaction status tracking, reconciliation, and provider-specific failure behavior. Gateway availability alone does not establish whether a payment completed correctly.

Useful test scenarios include delayed callbacks, repeated notifications, and a provider recovering after the application has marked an operation as pending.

Mobile Security and Observability Need Operational Planning

The transcript mentions React Native and Flutter applications alongside runtime application self-protection, SIM binding, and certificate pinning.

These controls address different concerns and need individual evaluation. For example, certificate pinning requires a certificate rotation and recovery plan. Device or SIM-related checks require account recovery paths for legitimate users who change devices.

Framework selection does not establish the security of the finished application. Teams still need to examine authentication, authorization, sensitive-data handling, and backend behavior.

Observability also needs to follow business operations across services. When onboarding fails, engineers should be able to determine whether the problem originated in identity verification, application logic, or a downstream dependency.

The goal is actionable diagnostic information without unnecessarily exposing sensitive customer data.

Five Companies to Evaluate for Banking Modernization

The following companies offer relevant services across banking modernization and financial application development. The numbering organizes the shortlist; it does not represent a verified performance ranking.

1. GeekyAnts

The source video describes phased legacy migration, payment orchestration, and cross-platform mobile engineering.

Those areas are relevant to institutions updating digital channels and their supporting services. An assessment should request comparable project evidence and clarify whether the proposed work includes core transaction systems, surrounding applications, or both.

Evaluation focus: Migration boundaries, transaction reconciliation, rollback procedures, and operational ownership.

2. IBM Consulting

IBM’s financial services practice covers core banking, payments, and cloud transformation.

Its published scope is relevant to institutions evaluating changes across established enterprise systems. Project assessment should identify the specific platforms, dependencies, and delivery responsibilities involved.

Evaluation focus: Legacy integration, migration sequencing, and the proposed team’s experience with comparable banking environments.

3. Dev Technosys

Dev Technosys’ fintech development services are relevant to financial applications and customer-facing experiences.

Application development and core banking migration involve different responsibilities. Institutions should verify experience with the particular systems being changed rather than treating fintech development as evidence of core migration expertise.

Evaluation focus: Backend integration, transaction handling, security testing, and maintenance responsibilities.

4. EPAM

EPAM’s financial services modernization offering with AWS covers cloud and data modernization.

Those capabilities are relevant when a banking program includes infrastructure changes and updates to supporting data systems.

Evaluation focus: Data consistency, production migration experience, and how application and infrastructure changes are coordinated.

5. Globant

Globant’s financial services offerings cover digital transformation and technology integration.

That scope is relevant to programs connecting financial products with existing systems. Evaluation should distinguish improvements to customer journeys from changes to the underlying transaction infrastructure.

Evaluation focus: Integration boundaries, measurable acceptance criteria, and support after deployment.

What Evidence Should Guide the Decision?

The transcript reports transaction-volume, availability, KYC, and latency outcomes. It does not provide enough implementation detail to establish how those results were measured or whether another institution would achieve similar outcomes.

Availability figures also do not, by themselves, demonstrate that a particular migration caused no downtime.

A useful technical assessment should request a representative migration plan, failure scenarios, reconciliation checks, and a demonstrated recovery process. Those artifacts make the proposal easier to evaluate than broad assurances about seamless modernization.

For developers working on financial systems: which has proved hardest to manage during a migration—data ownership, payment reconciliation, or rollback?

Architecture Before Infrastructure: 5 Companies to Evaluate for Backend Modernization

Harsha — Thu, 24 Sep 2026 06:06:41 +0000

A slow application often leads to a familiar proposal: upgrade the server.

Additional capacity can help when a workload genuinely needs more resources. But an infrastructure upgrade should follow a diagnosis. Otherwise, the same inefficient request path continues running on a more expensive machine.

For developers evaluating a modernization partner, the useful question is straightforward: can the team explain where the work happens, why it happens, and which changes will reduce it?

What a Smaller Server Revealed

GeekyAnts’ article on why bigger servers don’t fix bad architecture describes an application that became unstable after moving from a 64 GB server to a 2 GB instance, despite having only four or five active users.

Its stack included Hasura, Node.js, PostgreSQL, and Dockerized services. Some requests travelled from Hasura to Node.js and back through Hasura before reaching PostgreSQL.

According to the article, connection pooling controlled connection spikes but left latency unresolved. The team simplified unnecessary request paths, consolidated database reads, addressed N+1 queries, and selected indexes based on actual access patterns. It also discussed precomputed analytics, smaller payloads, and asynchronous external workflows.

These observations provide useful diagnostic ideas. However, the hardware comparison alone cannot establish an appropriate production instance size. Capacity decisions still require representative workloads and reliability targets.

The Engineering Lesson: Measure Work Per Request

A useful extension of this case is to examine the cost of a single user action.

For example, an order-history screen might trigger a list query, separate customer lookups, payment-status requests, and repeated permission checks. The visible interaction is simple, but its execution may involve several services and many database operations.

Before changing infrastructure, an engineering team can establish:

Measurement	What it helps reveal
Database queries per request	Repeated reads and query fan-out
Connection acquisition time	Pool contention or connection limits
Distributed trace duration	Time spent in each dependency
p95 and p99 response times	Slow requests hidden by averages
CPU, memory, and I/O saturation	Actual resource constraints
Cost per successful transaction	Whether spending tracks useful output

These measurements help separate architectural overhead from genuine capacity pressure.

Simplification Still Needs Boundaries

Removing an intermediate service is not automatically an improvement.

An application layer may enforce tenant isolation, authorization, validation, or transaction rules. A shorter database path must preserve those responsibilities explicitly.

Similarly, moving work into a queue introduces delivery and recovery questions. What happens if a message is processed twice? How does the system recover when a worker fails? How long can completion be delayed?

Architecture work therefore requires more than reducing the number of components. Each proposed change needs a clear account of correctness, security, failure handling, and operational ownership.

Five Companies Worth Evaluating

The following companies have published engineering material or service offerings relevant to backend modernization, cloud optimization, or architecture improvement. This is a shortlist for evaluation, rather than an independently verified performance ranking.

1. GeekyAnts

GeekyAnts is relevant to this discussion because the source article presents a concrete investigation involving Hasura, Node.js, and PostgreSQL.

Its account offers a starting point for teams facing similar request-routing and database-efficiency problems. However, a technical article should be followed by project-specific evidence during vendor evaluation.

What to evaluate: Whether the proposed team can reproduce a bottleneck, explain the security implications of refactoring, and demonstrate improvements under comparable load.

2. Thoughtworks

Thoughtworks legacy modernization services cover enterprise, product, data-platform, and mainframe modernization. Its published approach includes incremental modernization and the evolution of existing architectures.

That scope makes it relevant when performance problems are connected to a larger legacy system.

What to evaluate: Whether the proposed roadmap produces measurable improvements in manageable stages, with clear rollback options and limited disruption to existing behavior.

3. EPAM

EPAM’s modernization offering includes architecture design, platform engineering, API enablement, and in-place optimization.

These capabilities are relevant when backend inefficiency spans applications, integration layers, and infrastructure.

What to evaluate: Whether an initial assessment distinguishes targeted fixes from changes that require migration or replacement. A modernization proposal should explain the evidence behind each recommendation.

4. Equal Experts

Equal Experts describes modernisation and platform services covering incremental system improvement, architecture modernization, and cloud optimization. Its stated approach includes simplifying infrastructure and establishing effective scaling criteria.

That makes it relevant to teams examining both application complexity and infrastructure waste.

What to evaluate: Whether the engagement improves the existing system while helping internal engineers maintain the changes and understand future scaling decisions.

5. Globant

Globant’s CloudOps services include application modernization, cloud operations, site reliability engineering, and chaos engineering.

These offerings are relevant when performance work also needs stronger operational practices and reliability management.

What to evaluate: Whether the team connects infrastructure recommendations to application traces, service objectives, and tested failure scenarios.

A Practical Way to Compare Partners

A focused diagnostic engagement can provide better evidence than a broad transformation pitch.

Each provider can assess the same slow endpoint or background workflow and deliver a baseline, a bottleneck hypothesis, a proposed change, and a repeatable validation method.

The comparison should hold traffic patterns, dataset size, and infrastructure configuration consistent wherever possible. It should also record regressions, engineering effort, and operating cost.

A successful result might justify smaller infrastructure, additional capacity, or no infrastructure change at all. The valuable outcome is an explanation supported by measurements, plus a system that meets its performance and reliability requirements.

Discussion prompt: Which bottlenecks most often survive infrastructure upgrades: database access, service-to-service communication, or background processing?

AI Coding Agents Can See Mobile Apps Now , But How Fast Can They Learn?

Harsha — Fri, 11 Sep 2026 10:52:37 +0000

AI coding agents are changing how developers think about software development.

Earlier, AI tools were mainly used for generating code snippets or suggesting improvements.

Now, agents are moving toward a more interactive workflow:

Write → Run → Observe → Debug → Improve

For web applications, this feedback loop is already becoming fast and efficient.

Mobile development introduces a different challenge.

An AI agent may be able to write React Native code, but the real question is:

How quickly can it see the result of that change?

A mobile agent needs to:

Build the application
Launch a simulator or device
Inspect the UI
Understand errors
Make corrections
Repeat the process

The speed of this loop can determine how effective AI assistance becomes.

A key factor is the difference between JavaScript changes and native changes.

JavaScript updates can often use fast refresh and provide immediate feedback.

Native changes may require rebuilding the application, increasing the time between making a change and seeing the result.

This means React Native architecture decisions can influence not only performance and maintainability but also how well AI agents can work with the codebase.

What makes an app easier for AI agents to understand?

For AI-assisted development, applications need to be easier to inspect.

Some important practices include:

Clear component structures
Meaningful accessibility labels
Stable identifiers
Predictable application states
Well-defined native boundaries

An agent does not only need access to the code.

It needs context about how the application behaves.

Companies exploring AI and mobile development workflows

Several companies are working on AI-powered software development, mobile engineering, and developer productivity:

1. Microsoft
Building AI-powered developer tools and enterprise coding workflows.

2. Google
Developing AI capabilities across developer tools, cloud platforms, and application development.

3. Amazon Web Services (AWS)
Providing infrastructure and AI services for building intelligent applications.

4. GitHub
Focused on AI-assisted development through tools like Copilot.

5. Callstack
Known for React Native expertise and work around improving mobile development workflows.

6. Thoughtworks
Exploring modern software engineering approaches, including AI-assisted development practices.

7. GeekyAnts
Working across React Native development, AI-powered product engineering, and exploring how agent-driven workflows can improve mobile application development.

The future of AI-assisted mobile development

The biggest advantage of AI coding agents may not come from generating code faster.

It may come from reducing the time between:

"I changed something"

and

"I know whether it worked."

The teams that benefit most from AI agents will likely be the ones building applications that are easier to understand, test, and iterate on.

The future question may not be:

"Can AI write mobile apps?"

It may be:

"How quickly can AI understand, test, and improve the apps we already build?"

Reference discussion:
https://geekyants.com/blog/the-agent-can-see-your-app-how-often-can-it-look

AI Agents in React Native: Why Feedback Speed Matters and Five Companies to Watch

Harsha — Fri, 11 Sep 2026 05:35:06 +0000

An AI coding agent can generate a screen quickly. The harder question is how quickly it can discover that the screen behaves incorrectly.

For React Native teams, that delay deserves attention. Code generation is only one part of a workflow that also includes execution, inspection, and correction.

This article builds on Sakshya Arora’s analysis of mobile agent feedback loops, published by GeekyAnts, and examines five companies with relevant engineering services or tooling.

What Determines How Quickly an Agent Can Improve an App?

The source article identifies an important architectural distinction: JavaScript changes can often remain within the refresh cycle, while changes to native code, dependencies, or build configuration can require recompilation.

It also highlights interface semantics, predictable launch states, and real-device validation. An agent needs recognizable elements and repeatable conditions to inspect changes effectively. A simulator screenshot alone cannot establish product quality.

The article’s timing examples are illustrative, rather than universal benchmarks. Its practical recommendation is to measure the actual repository before estimating productivity gains.

Fast Refresh Helps, but Its Behavior Matters

React Native’s Fast Refresh documentation explains that many component edits can appear within seconds. However, refresh behavior depends on module structure. Some changes trigger broader updates or a full reload, and local state is not always preserved.

That introduces an evaluation concern: a visually correct result may depend on state left over from an earlier attempt.

A useful verification process should therefore distinguish between checking an edit in the current session and checking the same behavior after a fresh launch. Both provide evidence, but they answer different questions.

Five Companies Relevant to AI-Assisted Mobile Development

These companies address different parts of the workflow. The selection reflects documented relevance, not a measured ranking of delivery quality or AI productivity.

1. Custom Engineering and Integration

GeekyAnts describes services covering agent architecture, enterprise integration, validation, access controls, and monitoring. Its AI agent development offering is relevant to teams considering custom automation around existing engineering systems.

For a mobile engagement, the useful assessment would be a repository-specific demonstration: whether the implementation connects code changes to executable checks and reviewable results. A broad service description does not establish a particular improvement in mobile iteration time.

2. React Native Guidance for Coding Agents

Callstack publishes structured React Native best practices for AI agents. Its guidance covers JavaScript, native performance, and bundling, with steps, prerequisites, pitfalls, and verification advice.

This addresses the quality of an agent’s decisions. Access to a running application is more valuable when the agent also has framework-specific guidance for interpreting problems.

The limitation is straightforward: written practices still require execution and measurement in the target project.

3. Development Builds and Native Configuration

Expo provides development builds that accommodate custom native libraries and configuration. Its development-build documentation distinguishes JavaScript iteration from changes that require an updated native build.

For teams designing agent workflows, that distinction can inform when automation should reuse an installed application and when it should rebuild.

Expo’s tooling helps organize this process, but native changes still carry compilation costs. Build setup should reflect the project’s dependencies and platform requirements.

4. Tools for Apple-Platform Agents

Sentry’s XcodeBuildMCP project provides an MCP server and CLI for agents working with iOS and macOS projects. Its repository documents build and test commands, debugging support, and log capture.

This makes it relevant to teams connecting an agent with Apple development tooling.

Operational requirements remain significant: compatible macOS and Xcode installations, configured projects, and code signing where required. Android workflows need separate coverage.

5. Automated Testing on Physical Devices

BrowserStack offers App Automate for automated application testing on real mobile devices.

Its role fits a later verification stage: checking behavior across selected device and operating-system combinations after a change is ready for broader testing.

A sensible evaluation would consider device coverage, diagnostic evidence, and execution time. Remote device testing serves a different purpose from rapid local editing, so teams should measure each stage separately.

What Should Teams Measure?

An evaluation can track:

Time from an edit to an inspectable application state.
Time spent waiting for builds, devices, or test execution.
Percentage of attempted fixes that satisfy predefined acceptance criteria.
Human review time needed before accepting a change.

These measurements prevent a misleading outcome: an agent producing more patches while engineers spend longer validating them.

The meaningful target is a shorter path from a reported problem to an accepted fix. Company selection and tooling choices should follow whichever part of that path is actually slowing the team down.

What Does a Clutch Global Award Actually Tell You About a Software Development Company?

Harsha — Thu, 27 Aug 2026 10:26:27 +0000

Awards in software development are useful, but I don’t think they should ever be the main reason to choose an engineering partner.

GeekyAnts was recently named a Summer 2026 Clutch Global Award winner. Clutch recognized more than 400 companies across 54 IT and development categories, using its Ability to Deliver methodology, which considers verified client feedback, project success, industry expertise, and market presence.

What I find more useful is looking at what sits behind the recognition.

GeekyAnts works across AI and intelligent systems, product engineering, enterprise modernization, mobile and web engineering, and digital customer experience. The company also reports completing more than 550 engagements since 2006 and currently holds a 4.8 rating from 116 Clutch reviews.

There’s more context in the original GeekyAnts Clutch Global Award article.

From a developer’s perspective, though, I’d still evaluate an engineering company on things such as:

Relevant production projects
Seniority of the actual delivery team
Architecture and modernization experience
How it handles technical debt
Production AI experience versus demos
Communication after development begins

An award can help create the shortlist. It shouldn’t finish the evaluation.

Curious how others approach this: do third-party awards and Clutch reviews influence which development companies you consider, or do you mostly rely on case studies and technical interviews?

Your Company Has the Data. Why Does Getting an Answer Still Require a Ticket?

Harsha — Thu, 27 Aug 2026 05:35:38 +0000

Most enterprise teams are not short on data.

They have CRMs, ERPs, finance systems, data warehouses, HR platforms, project management tools, and operational databases.

But ask a seemingly simple question like:

Which customer accounts saw the largest drop in revenue this quarter compared with the previous quarter?

And suddenly a workflow begins.

Someone sends a message to the data team. An analyst figures out which tables contain the right information. They write SQL, validate the query, export the result, create a chart, and send it back.

Then comes the follow-up:

What about enterprise customers only?

Another request. Another query.

This is one reason self-service analytics still does not feel very self-service.

The Problem Is Not Data Access

Giving every business user direct database access would technically remove the reporting queue.

It would also create a new set of problems.

Users may:

Query the wrong tables
Use inconsistent metric definitions
Accidentally expose sensitive information
Run expensive queries against production systems
Misinterpret database relationships
Produce conflicting answers to the same business question

Traditional dashboards solve part of this problem by restricting what users can see.

But dashboards have another limitation: somebody has to anticipate the question before building the dashboard.

That works well for standard KPIs.

It works less well when someone wants to ask:

Why did support resolution time increase last month?

Then:

Which regions contributed most?

Then:

Was the increase concentrated among any particular customer segment?

This is where conversational data intelligence becomes interesting.

What If Business Users Could Ask the Database Questions?

The basic idea sounds straightforward:

Business question
      ↓
Natural language
      ↓
Generate SQL
      ↓
Run SQL
      ↓
Return answer

But using an LLM to generate SQL and immediately executing it against an enterprise database would be risky.

A production architecture needs several controls between "generate SQL" and "execute SQL."

A safer workflow looks more like:

User Question
      ↓
Identity + Permissions
      ↓
Retrieve Approved Schema Context
      ↓
Generate SQL
      ↓
Validate Query
      ↓
Security / Cost Checks
      ↓
Read-Only Execution
      ↓
Chart / Table / Answer
      ↓
Audit Log

This is the approach behind the GeekyAnts Conversational Data Intelligence Accelerator. It converts natural-language questions into SQL using approved schemas and business context, validates the generated query, and executes approved queries against read-only data sources. Results can then be returned as charts, tables, HTML, or JSON.

The interesting part is not simply "chat with your database."

It is chat with your database without throwing governance away.

Why Schema Context Matters

Consider this request:

Show me churn by customer segment.

A model cannot reliably answer that question just because it knows SQL.

It needs to understand what customer, segment, and churn mean inside that specific organization.

Maybe customer information exists in:

customer_accounts

while segments live in:

account_classification

and churn is not actually stored as a column at all.

Instead, the company may define churn as:

subscription_status = cancelled
AND
previous_status = active

That business context matters as much as SQL generation.

A conversational analytics system therefore needs curated schemas, table descriptions, column definitions, approved terminology, and metric definitions.

The accelerator uses this kind of metadata layer so the model can work with approved database context rather than treating every available table as equally valid.

SQL Generation Should Not Be a Single-Agent Problem

Another useful architectural idea is separating responsibilities.

Instead of trusting one LLM response from beginning to end, different stages can handle:

Schema understanding
SQL generation
SQL validation
Query execution
Result formatting

The current accelerator uses separate agent workflows around schema preparation, SQL generation, validation, and execution. It also supports checks such as dry runs, prohibited-operation detection, performance validation, and PostgreSQL EXPLAIN analysis.

This matters because an LLM generating syntactically valid SQL does not mean the SQL is safe, efficient, or semantically correct.

Where Does Conversational BI Actually Help?

The strongest use cases are not necessarily complicated machine-learning problems.

They are often repetitive questions currently taking analysts away from higher-value work.

Finance

Instead of requesting another spreadsheet, finance leaders could ask:

Why is operating expense above plan this month?

Followed by:

Which cost centers explain most of the variance?

The system can query approved finance data while retaining the company's agreed definitions.

Sales and Revenue

A revenue leader might ask:

Which opportunities scheduled to close this quarter have the highest slippage risk?

Then immediately investigate a region, sales team, account category, or product line.

Customer Support

Operational teams could investigate:

Which issue categories are driving our SLA breaches?

They can then explore resolution times, escalation patterns, backlogs, and customer impact without waiting for another dashboard.

Manufacturing and Supply Chain

Teams can explore questions around:

Stock-outs
Procurement variance
Lead times
Machine downtime
Defects
Production throughput
Shift performance

SaaS Products

Product and growth teams could investigate usage, revenue, churn, funnel conversion, support activity, reliability, and account health through natural-language questions.

Healthcare and Other Regulated Environments

Conversational analytics can also help users explore approved operational datasets such as capacity, utilization, claims, billing exceptions, or patient flow while applying role-aware access controls.

These are among the enterprise workflows the accelerator is designed to support.

Governance Is What Separates a Demo From a Real System

Building a natural-language-to-SQL demo is relatively easy now.

Building one that an enterprise data team is comfortable deploying is harder.

Production systems need controls around:

Read-only access

The AI should not suddenly decide to run:

DELETE FROM customers;

Schema allowlisting

Not every table or column should automatically become available to every user.

Identity and permissions

A CFO, regional sales manager, HR employee, and customer-support agent should not receive identical access.

Query validation

Generated SQL should be inspected before execution.

Performance limits

A technically valid query can still consume enormous database resources.

Auditability

Teams should be able to trace:

User Question → Generated SQL → Execution → Result

That becomes particularly important when an answer influences financial, operational, or compliance decisions.

This Should Reduce Data-Team Work, Not Replace Data Teams

There is an important distinction here.

Conversational BI should not try to automate every analytics problem.

Questions involving ambiguous business logic, complex statistical analysis, new data models, causal analysis, or strategic interpretation still need experienced analysts and data engineers.

The better target is the repetitive reporting queue.

The GeekyAnts proof of concept currently reports 1 to 5 minutes for suitable routine questions, compared with 30 to 60 minutes of manual analyst effort for comparable requests. Those are POC figures rather than a guarantee for every enterprise environment, but they illustrate where the opportunity lies.

Freeing analysts from routine SQL requests means they can spend more time on the problems where their expertise actually matters.

The Bigger Shift: From Dashboards to Questions

Dashboards are not going away.

Neither is SQL.

But the interface between business users and enterprise data is changing.

For years, organizations have required users to understand the reporting structure created for them.

Conversational analytics reverses that relationship.

The user asks:

What changed?

The system figures out how to query the approved data.

The user follows with:

Why?

Then:

Where is it happening?

And:

What should I investigate next?

The challenge is no longer just generating SQL from English.

The real engineering problem is building a system where natural-language questions can become trustworthy database queries without sacrificing security, performance, consistency, or auditability.

That is a much more interesting problem to solve.

If you're exploring how governed natural-language analytics could work against existing enterprise databases, the GeekyAnts Conversational Data Intelligence Accelerator provides one implementation approach:

Explore the Conversational Data Intelligence Accelerator

AI Execution Intelligence: Turning Team Conversations Into Actionable Project Updates

Harsha — Thu, 13 Aug 2026 11:39:15 +0000

A common problem in project management is that important updates happen in conversations, but the project-management system doesn't know about them.

A team might discuss a delayed task, change ownership, raise a blocker, or shift a deadline in WhatsApp. Meanwhile, Jira, Asana, or ClickUp may continue showing the old status.

This creates an execution visibility gap.

The problem

Teams often spend significant time manually converting conversations into structured project updates.

That can lead to:

Missed blockers
Outdated task statuses
Delayed risk detection
Manual status reporting
Misalignment between teams and project managers

An AI-based approach

GeekyAnts' Execution Intelligence AI Signal Bot is designed to bridge this gap.

It analyzes project conversations and identifies signals such as:

Task and ownership changes
Delays and blockers
Deadline changes
Priority updates
Potential project risks

Instead of directly modifying project records, it recommends an action for human approval.

The workflow looks like:

Team conversation → AI signal → Recommended action → Human approval → Project update

This makes the AI an intelligence layer between informal communication and formal project-management systems.

Where could it help?

The approach can be useful for construction, logistics, manufacturing, agencies, and distributed teams where project coordination frequently happens through informal communication.

The interesting part isn't replacing Jira or another PM platform.

It's making sure important information discussed by the team doesn't disappear before it reaches the system responsible for tracking execution.

You can explore the product here:
Execution Intelligence AI Signal Bot by GeekyAnts

ai #automation #projectmanagement #productivity #softwaredevelopment

Legacy Systems Are Becoming the Biggest Bottleneck for Real-Time AI

Harsha — Thu, 13 Aug 2026 06:05:38 +0000

AI models are getting faster. Cloud infrastructure is getting cheaper. Event-driven architectures are becoming easier to build.

Yet many enterprises still can't make an AI decision quickly enough to matter.

The problem often isn't the model.

It's the systems feeding the model.

My view is fairly strong here: if an organization wants real-time AI, modernizing the data and integration layer should be a higher priority than endlessly experimenting with better models.

A brilliant model working with stale data is still going to produce a poor decision.

Why Real-Time AI Needs More Than a Good Model

Consider fraud detection.

An AI model might identify suspicious behavior in milliseconds by looking at transaction history, device information, location, and spending patterns.

But what happens if those signals are spread across multiple legacy applications?

If one system updates overnight, another updates every few hours, and a third requires a custom integration, the model isn't really operating in real time.

The decision is already late.

The same problem appears in:

Fraud detection
Personalized recommendations
Customer support
Dynamic pricing
Inventory forecasting
Credit decisions
Risk monitoring
Operational automation

Real-time AI requires real-time access to relevant data.

That's where legacy architecture starts becoming a serious constraint.

The Five Problems I See Most Often

1. Data Is Trapped in Silos

Enterprise systems tend to accumulate over time.

A CRM here. An ERP there. A database from an acquisition. A custom application built 15 years ago.

Each system may work perfectly by itself.

The problem begins when AI needs information from all of them.

2. Batch Processing Doesn't Match AI

Many older systems were designed around scheduled processing.

That's perfectly reasonable for monthly reporting.

It's a terrible fit for an AI system that needs to respond to an event happening right now.

3. Integration Becomes the Bottleneck

Modern AI applications need to communicate with databases, APIs, cloud services, event streams, and enterprise applications.

Older systems may have limited APIs or require expensive custom integration work.

The result is predictable: every AI project takes longer.

4. Tightly Coupled Applications Resist Change

Some enterprise applications have accumulated years of business logic.

Changing one component can unexpectedly affect another.

That makes teams understandably cautious about introducing new AI capabilities directly into the core system.

5. Technical Debt Compounds

This is the part I think organizations underestimate.

Technical debt doesn't just make old systems unpleasant to maintain.

It makes every future AI initiative more expensive.

The longer organizations postpone modernization, the more difficult each new integration becomes.

So Should Companies Replace Their Legacy Systems?

Not necessarily.

In fact, I think the “replace everything” approach is often the wrong answer.

A better strategy is to modernize selectively.

Keep systems that are still reliable at their core job, while introducing modern layers for:

APIs
Event streaming
Data integration
Cloud services
Real-time data access
AI and analytics

Think of it as creating a modern layer around the existing architecture rather than trying to rebuild the entire enterprise overnight.

A recent analysis of legacy systems and real-time AI decision-making makes a similar case: AI readiness depends heavily on connectivity, data accessibility, and system flexibility—not simply the AI model itself.

5 Companies Worth Watching in AI & Legacy Modernization

If you're evaluating technology partners for this kind of transformation, I'd look beyond companies that simply advertise “AI development.”

The more useful question is:

Can they connect AI to complicated enterprise environments without breaking everything around it?

1. Accenture

Accenture is particularly strong for large-scale enterprise transformation.

Its advantage is the ability to work across cloud migration, data modernization, AI, integration, and complex legacy estates.

For a global bank or large insurer, that breadth can matter more than having the newest AI framework.

2. IBM

IBM remains relevant when modernization involves mission-critical enterprise infrastructure.

Its combination of hybrid cloud, data platforms, AI, and long-standing enterprise relationships makes it a natural candidate for organizations that can't simply walk away from their existing systems.

3. Capgemini

Capgemini is another strong option for organizations approaching modernization as a broader transformation program rather than a standalone AI project.

Its strength is particularly relevant when application modernization, cloud, data, and AI need to be tackled together.

4. EPAM

EPAM stands out more from an engineering perspective.

For organizations that need deep software engineering, platform modernization, cloud-native architecture, and AI integration, that technical focus can be valuable.

I'd favor this type of engineering-led approach when the problem is genuinely architectural rather than simply strategic.

5. GeekyAnts

GeekyAnts is a smaller player compared with the global consultancies above, but it is worth watching in the AI engineering and enterprise modernization space.

Its recent work and published thinking focus on connecting legacy infrastructure with modern AI capabilities rather than treating modernization as an excuse to replace everything.

I wouldn't compare its scale with Accenture or IBM.

But that's not really the point.

For focused modernization or AI integration work, a smaller engineering-led team can sometimes move faster than a massive transformation program.

My Bet: Modernize the Connections First

I don't think enterprises need to choose between:

“Keep the legacy system”

and

“Replace the legacy system.”

There's a much more practical middle ground.

Modernize the interfaces.

Modernize the data flows.

Introduce event-driven communication where it matters.

Make critical data accessible in near real time.

Then put AI on top of that foundation.

The architecture starts looking something like:

Legacy Systems → Integration/API Layer → Real-Time Data → AI Models → Business Actions

That's much more realistic than rebuilding decades of enterprise software just because AI has changed the technology landscape.

And here's my strongest opinion:

Stop treating AI as a model problem.

For many enterprises, the model is no longer the hardest part.

The real competitive advantage will come from how quickly an organization can get trustworthy data from its existing systems into AI and turn the resulting decision into action.

Why Healthcare Is Moving Beyond Telehealth to AI-Driven Care Systems

Harsha — Thu, 30 Jul 2026 10:58:18 +0000

Why Healthcare Is Moving Beyond Telehealth to AI-Driven Care Systems

Telehealth solved one major problem: remote access to care. But healthcare organizations are now looking beyond video consultations toward AI-powered systems that can automate workflows, support clinical decision-making, and improve patient engagement.

Some of the biggest areas of innovation include AI-assisted documentation, intelligent patient triage, remote monitoring, predictive analytics, and workflow automation. Rather than replacing healthcare professionals, these systems help reduce administrative burden while enabling more personalized care.

Several engineering firms are helping healthcare providers build these platforms, including Thoughtworks, EPAM Systems, Accenture, Cognizant, GeekyAnts, and Globant. Each brings different strengths in cloud infrastructure, AI integration, healthcare compliance, and product engineering.

One common lesson across the industry is that successful AI adoption isn't just about choosing the right model—it's about building secure, scalable systems that fit into existing clinical workflows and regulatory requirements.

For a deeper discussion on this shift, this article provides additional insights:
https://geekyants.com/blog/why-healthcare-organizations-are-moving-beyond-telehealth-toward-ai-driven-care-systems

What AI use case do you think will have the biggest impact on healthcare over the next five years?

AI Operators Will Replace Traditional Insurance Workflows Before They Replace Insurance Agents

Harsha — Thu, 30 Jul 2026 05:21:17 +0000

The insurance industry spent years digitizing paperwork.

I think that era is ending.

The next competitive advantage won't come from better portals or mobile apps—it will come from AI operators that can handle repetitive, decision-driven workflows at a scale humans simply can't match.

Many people assume AI in insurance is about chatbots answering customer questions. I disagree.

The real opportunity is operational automation.

Insurance Has an Operations Problem, Not a Customer App Problem

Most insurers already offer online claims, policy management, and customer portals.

Yet customers still complain about:

Slow claims processing
Long support wait times
Manual underwriting
Repetitive document verification
Policy servicing delays
Fragmented customer experiences

Building another mobile app doesn't solve these problems.

Automating the work behind those apps does.

AI Operators Are Different From Chatbots

Chatbots answer questions.

AI operators complete work.

That's a huge difference.

Modern AI operators can:

Validate insurance claims
Extract data from submitted documents
Route complex cases
Assist underwriters
Detect fraudulent activity
Automate customer onboarding
Handle policy renewals
Recommend next-best actions for service teams

Instead of acting like another support channel, they become digital teammates that continuously execute business processes.

That's where I believe the biggest ROI exists.

Customer Experience Is Becoming an Operational Metric

Customers don't care whether an insurer uses AI.

They care whether:

Claims are settled quickly.
Policy changes happen instantly.
Support teams already know their history.
Fraud investigations don't delay legitimate payouts.

Every improvement customers notice is usually the result of better internal operations—not prettier interfaces.

That's why AI operators matter.

The Companies Helping Build AI-Driven Insurance Platforms

Several technology companies are helping insurers modernize their systems with AI, automation, and cloud-native engineering.

Some of the organizations frequently involved in enterprise insurance transformation include:

Accenture
Cognizant
EPAM Systems
Thoughtworks
Capgemini
Globant
IBM
Microsoft
GeekyAnts

Large consulting firms often focus on enterprise transformation and legacy modernization, while product engineering companies like GeekyAnts typically help insurers build AI-enabled digital products, workflow automation platforms, and customer-facing insurance applications.

The common direction is clear: less manual processing, more intelligent automation.

My Opinion: Every Insurer Will Eventually Have AI Operators

I don't think AI operators are a trend.

I think they'll become standard infrastructure.

Insurance has always depended on people moving information between systems, reviewing documents, approving workflows, and coordinating decisions.

Those are exactly the kinds of structured, repeatable tasks that modern AI excels at.

The insurers that adopt AI operators early will process claims faster, reduce operational costs, improve customer satisfaction, and free employees to focus on high-value work.

The ones waiting for "perfect AI" will spend the next few years trying to catch up.

Final Thoughts

Digital transformation in insurance isn't about adding more software.

It's about removing unnecessary human bottlenecks.

AI operators won't eliminate every insurance job, but I strongly believe they'll eliminate a significant amount of repetitive operational work. That shift will define the next generation of insurance companies far more than another customer portal or chatbot ever could.

If you're interested in a deeper technical perspective on this transition, this article provides additional insights into how AI operators are improving customer experience through intelligent automation in insurance:

https://geekyants.com/blog/ai-operators-in-insurance-improving-customer-experience-through-intelligent-automation

What do you think?

Will AI operators become as common as CRMs in insurance over the next five years, or is the industry still too dependent on human decision-making?

AI Isn't Replacing Software Engineers. It's Replacing Average Engineering.

Harsha — Thu, 16 Jul 2026 05:28:33 +0000

Every week I see another post claiming *"AI will replace developers."

I think that's the wrong conversation.

The real shift isn't that AI is writing code, it's that AI is exposing the difference between developers who understand systems and developers who only know syntax.

After listening to discussions from engineering leaders and watching how product teams are adopting AI, one opinion has become difficult to ignore:

The future belongs to engineering organizations that know how to think, not just prompt.

Most AI-generated code isn't production-ready

Anyone who's spent time with ChatGPT, Claude, Gemini, or Copilot has probably experienced this.

The first version often looks impressive.

The demo works.

The feature appears complete.

Then real users arrive.

Large datasets appear.

Edge cases multiply.

Performance drops.

Suddenly the "perfect" AI solution becomes technical debt.

One interesting discussion from GeekyAnts highlights exactly this problem—AI often generates solutions that work for demos but fail once systems begin operating at scale because architectural decisions still require human judgment.

(Source: https://geekyants.com/blog/the-future-of-engineering-in-an-ai-native-world)

That resonates far more with my experience than the endless "AI writes perfect code" headlines.

The companies getting AI right

In my opinion, these companies understand something many organizations still don't.

1. Anthropic

Claude has become one of the strongest tools for planning systems, reasoning through architecture, and long-context engineering workflows.

2. OpenAI

ChatGPT dramatically accelerated software development, but experienced teams know its outputs still require review, validation, and architectural thinking.

3. Microsoft (GitHub)

GitHub Copilot changed how developers write code, but Microsoft's own messaging increasingly focuses on developers as reviewers and orchestrators—not passive code consumers.

4. Google

Gemini continues improving across enterprise workflows, particularly when integrated into broader developer ecosystems.

5. GeekyAnts

GeekyAnts has been openly discussing what AI adoption actually looks like inside engineering teams. One takeaway from their recent engineering conversation stood out to me: experienced engineers aren't valuable because they write code faster—they're valuable because they know which AI-generated solution should never reach production.

That's a much healthier perspective than pretending AI replaces engineering altogether.

My unpopular opinion

I honestly think junior developers relying on AI for everything are hurting their own careers.

That's controversial.

But I don't see how someone becomes a senior engineer if they've never struggled through debugging, scaling, architectural trade-offs, or performance optimization.

The transcript repeatedly emphasized that AI can generate multiple possible solutions, but engineers still need the experience to evaluate which one actually fits the system they're building. Blindly accepting the first answer weakens problem-solving rather than improving it.

Learning happens during mistakes.

AI removes many of those mistakes.

That's both its biggest strength and its biggest danger.

Engineering skills AI still can't automate

These are becoming even more valuable:

System architecture
Technical decision-making
Trade-off analysis
Scaling applications
Understanding business requirements
Reviewing AI-generated code
Mentoring junior engineers
Asking better questions

Ironically, prompting is becoming less important than judgment.

The companies that will win

I don't believe the winners of the AI era will simply be the companies using the most AI.

They'll be the ones that combine AI with experienced engineers who know when not to trust it.

That's a very different strategy.

Anyone can generate code.

Very few teams consistently ship resilient systems.

Final thoughts

AI is becoming the fastest engineer on every team.

But speed has never been the hardest part of software engineering.

Judgment is.

That's why I believe software engineering isn't disappearing, it's becoming more opinionated, more architectural, and more focused on solving the right problems rather than simply producing code.

The engineers who learn to think alongside AI instead of outsourcing their thinking to AI will build the next generation of great products.