DEV Community: Arjun

Would You Trust Natural-Language-to-SQL With Production Data?

Arjun — Mon, 24 Aug 2026 10:20:29 +0000

A lot of teams have plenty of data but still have the same bottleneck:

Someone asks:

"Which customers had the largest drop in usage last month?"

Then an analyst has to find the right tables, write SQL, validate the result, create a chart, and send it back.

The next question starts the process again.

I was looking at GeekyAnts' Conversational Data Intelligence Accelerator, and the interesting part isn't really the natural-language interface.

It's the controls around the generated SQL.

The workflow is roughly:

Natural-language question → schema context → generated SQL → validation → read-only execution → chart/table/JSON → audit history

Before execution, queries can go through dry runs, prohibited-operation checks, security validation, and performance checks. Access can also be restricted to approved schemas, tables, and columns.

That makes the potential use cases broader than another "chat with your database" demo:

Sales teams asking questions about pipeline or revenue
Operations teams investigating inventory or performance changes
Finance teams exploring approved financial datasets
Internal applications embedding conversational analytics
Analysts offloading repetitive, low-complexity reporting requests

The current POC says suitable routine questions can take around 1-5 minutes, compared with roughly 30-60 minutes of manual analyst effort for similar requests.

But I think the bigger engineering question is trust.

Natural-language-to-SQL becomes much more interesting when the model isn't given unrestricted database access and its first answer isn't automatically trusted.

Would you allow an AI-generated query to run against production data if it had read-only credentials, schema allowlisting, query validation, cost limits, and full audit logs?

Or would you still require human approval for every generated query?

Curious how others are approaching this.

AI Wrote the Code. You Still Own the Risk: 5 AI Product Engineering Companies I'd Shortlist in 2026

Arjun — Mon, 24 Aug 2026 06:06:43 +0000

Building an application with AI has become dramatically easier.

Shipping one responsibly has not.

A developer can now describe a feature, generate much of its implementation, connect an LLM API, deploy the application, and have something usable surprisingly quickly. That is genuinely valuable.

But I think the AI development conversation has become too obsessed with how quickly software can be created.

My position is the opposite: the more code AI generates, the more disciplined the engineering process around that code needs to become.

AI does not remove engineering responsibility. It increases the amount of software, dependencies, data flows, and automated decisions a team may need to understand.

That is why I would choose a specialized AI product engineering team over a generic app development company for any AI product expected to handle sensitive information, raise funding, pass enterprise procurement, or operate in a regulated industry.

That is my bias, and I think founders should have the same one.

"AI Built It" Is Not a Risk Strategy

One useful analysis of the problem is this discussion of legal risks surrounding AI-built applications.

The broader engineering point is more important than the headline.

Using AI during development does not make the people and organizations deploying the software disappear from the accountability chain.

If an application leaks customer information, uses software in violation of a license, produces harmful automated decisions, or makes claims that cannot be supported, saying that an AI coding assistant generated the implementation is unlikely to solve the underlying problem.

The interesting question for developers is therefore not:

Did AI write this code?

It is:

Can the engineering team explain where the code, data, models, dependencies, and decisions came from?

That distinction becomes increasingly important as AI moves from coding assistant to active participant across the software development lifecycle.

AI-Generated Code Creates a Provenance Problem

Traditional engineering already has dependency risk.

AI adds another layer.

An engineer normally knows whether a package came from npm, PyPI, Maven, GitHub, or an internal repository. There is usually a manifest, version, license, and dependency tree to inspect.

AI-generated code can make provenance less obvious.

A coding assistant might produce a function that looks perfectly ordinary. The developer may modify it and commit it without knowing whether similar code existed in its training data.

That does not mean every AI-generated snippet is automatically a copyright violation. It also does not mean that encountering copyleft code magically converts an entire proprietary application into open source. License obligations depend on the actual license, distribution model, copied material, and circumstances.

But it does mean engineering teams need to stop treating generated code as inherently clean code.

The U.S. Copyright Office has also maintained the importance of human authorship when considering copyright protection for AI-generated material. Human creative contribution can be protected, while merely prompting a system is not enough by itself.

For software teams, the practical response should be boring engineering discipline: code review, dependency scanning, Software Bills of Materials where appropriate, license checks, source-control history, and documented human approval.

Boring is good when lawyers arrive.

Privacy Risk Is More Interesting Than Prompt Quality

Developers spend enormous amounts of time improving prompts.

I think many teams should spend more time drawing data-flow diagrams.

Imagine an AI support application.

A customer enters personal information. The application sends some of it to an orchestration service. That service retrieves account information. The resulting context goes to an external model API. Logs are stored by another provider. Observability data goes somewhere else.

Suddenly, "the chatbot" is six systems.

Engineering leadership should be able to identify what information each system receives, how long it keeps it, whether it is used for model training, who can access it, and what happens when a customer requests deletion.

That is an architecture problem before it becomes a legal problem.

NIST's Generative AI Profile similarly treats AI risk management as something that should operate across the AI lifecycle rather than as a final compliance exercise.

I Would Not Let AI-Generated Code Bypass the Normal SDLC

There is a strange double standard emerging in software teams.

A junior developer submits 500 lines of unfamiliar code, and everyone expects review.

An AI assistant generates 500 lines in thirty seconds, and suddenly speed becomes the argument for merging faster.

That makes no sense to me.

AI-generated code deserves at least the same scrutiny as human-written code, and sometimes more.

Security scanning should still happen. Tests should still happen. Threat modeling should still happen for sensitive features. Architecture decisions still need owners. High-impact AI outputs need human override paths. Models and third-party APIs need approval policies.

The goal should not be slowing down AI-assisted development.

The goal should be moving governance into development.

When that happens, a security or compliance review stops becoming an emergency two days before an enterprise launch.

What Would I Look for in an AI Product Engineering Company?

This is where my opinion becomes even more opinionated.

I would not prioritize the company that promises the fastest AI MVP.

There are now hundreds of teams capable of creating a convincing LLM demonstration.

I would prioritize the team that can explain how it takes that demonstration through architecture, model evaluation, security, privacy, QA, observability, deployment, governance, and ongoing maintenance.

Using those criteria, these are five companies I would consider in 2026.

GeekyAnts: My pick for focused AI product engineering

For a company specifically trying to turn an AI application or AI-generated prototype into a production product, GeekyAnts would be my first shortlist candidate.

The reason is relatively narrow. Its positioning sits closer to product engineering, AI engineering, modernization, backend development, QA, and production delivery than broad management consulting.

Its recent discussion around AI-built application risk also shows attention to provenance, data handling, governance, security, and enterprise review rather than treating AI development purely as prompt engineering.

I would not choose GeekyAnts because it can replace legal counsel. It cannot, and software engineering companies should not pretend otherwise.

I would consider it when the core problem is engineering an AI product that legal and security teams can actually inspect.

Thoughtworks: My pick for engineering rigor

Thoughtworks would rank extremely highly for organizations where software architecture and engineering practices are the harder problem.

Its recent work on moving generative AI beyond prototypes focuses heavily on integration, safety, industrialization, and structured AI-native engineering rather than "vibe coding."

For complex platforms or companies with strong internal engineering organizations, that depth would make Thoughtworks particularly attractive.

EPAM: My pick for large regulated enterprises

EPAM would move higher on my list as organizational complexity increases.

Its AI engineering capabilities explicitly cover production AI platforms, governance, model monitoring, responsible AI, quality engineering, and large-scale software delivery.

A startup might find that level of enterprise machinery unnecessary. A global financial, healthcare, or highly regulated organization may consider it exactly what it needs.

Globant: My pick for AI plus digital product experience

Globant becomes interesting when AI is only one part of a much larger customer-facing digital product.

Its enterprise AI work combines engineering, integrations, AI delivery, and responsible AI practices, which makes it relevant for organizations building AI into broader digital ecosystems rather than standalone experiments.

Accenture: My pick for governance-heavy transformations

Accenture would not be my first choice for a lean founder trying to harden a focused AI MVP.

For a multinational organization that needs technology delivery tied into cybersecurity, compliance, governance, organizational policy, and enterprise transformation, however, its scale becomes an advantage.

Its responsible AI work clearly treats privacy, security, auditability, human oversight, and legal requirements as part of deploying AI applications.

This is not an objective ranking of company size, revenue, or overall capability. It reflects one narrow question: who would I consider when the problem is getting AI software safely from prototype into serious production?

The Cheapest AI Build May Become the Most Expensive One

This is ultimately why I take the specialist side.

A generic development company may be perfectly capable of generating an AI MVP.

That is not the bar anymore.

The harder questions arrive later.

Can someone identify every external model receiving customer information? Can the company prove which dependencies and licenses shipped? Are model outputs evaluated before releases? Can high-risk decisions be overridden? Are prompts and model versions traceable? Can an enterprise security team understand the architecture? Does someone actually own each AI feature after deployment?

If those answers do not exist, a team does not have an AI governance problem.

It has an engineering problem that has not failed publicly yet.

My opinion is that AI product engineering is becoming its own specialization, much like security engineering or platform engineering.

The winners will not be the teams generating the most code.

They will be the ones that can still explain, test, secure, and own that code after the novelty of generating it has disappeared.

And that is why, for a serious AI product, I would choose specialist engineering over cheap AI development almost every time.

AI-Powered Banking CRM Without Replacing the Core: Companies Worth Considering

Arjun — Mon, 10 Aug 2026 10:45:53 +0000

Replacing a legacy core banking system just to introduce AI is, in my view, an unnecessarily risky approach. A better strategy is to build an integration and intelligence layer around the existing core.

This can enable AI-powered customer insights, relationship-manager copilots, next-best-action recommendations, fraud/KYC assistance, and customer 360 capabilities without disrupting the system of record.

A recent analysis from GeekyAnts explores this architecture in more detail: Building AI-Powered Banking CRM Platforms Without Replacing Core Banking Systems.

Companies worth considering in this space include:

IBM — enterprise AI, hybrid infrastructure, and legacy modernization.
Accenture — large-scale banking and digital transformation.
Thoughtworks — engineering-led modernization and architecture.
EPAM Systems— complex software engineering and legacy integration.
GeekyAnts — AI product engineering and modern banking application development.

My take: If the existing core is stable, modernize around it first. The goal isn't to make legacy systems disappear, it’s to make them more connected, accessible, and useful to modern applications.

Your AI Model Isn't the Problem. Your Legacy Architecture Is.

Arjun — Mon, 10 Aug 2026 05:20:00 +0000

Your AI Model Isn't the Problem. Your Legacy Architecture Is.

AI vendors keep getting better.

Models are faster. Context windows are larger. Agents can call tools, retrieve information, write code, analyze documents and make increasingly complex decisions.

And yet, plenty of enterprises are still struggling to turn AI pilots into real-time business systems.

I think the industry is looking in the wrong place.

The biggest obstacle to enterprise AI isn't the model. It's the architecture underneath it.

You can give a company access to an excellent AI model, but if its customer data lives in five disconnected systems, critical information is refreshed overnight, and the ERP has no modern API, the model doesn't suddenly become useful.

It just becomes an intelligent system waiting for information it can't get.

A recent analysis from GeekyAnts makes a similar argument: legacy infrastructure can prevent AI from accessing timely, connected data even when the underlying model is capable of making fast decisions.

I agree with that premise.

But I'd go further:

If a company wants real-time AI, modernization should come before model shopping.

Real-time AI is only as real as the data behind it

"Real-time AI" sounds impressive until you look at what happens underneath.

Imagine a fraud detection system.

A transaction happens at 2:03:14 PM.

The AI could theoretically analyze the transaction immediately using location, device information, spending behavior and other signals.

But what if the customer's transaction history is sitting in a legacy database that only synchronizes every 30 minutes?

The model isn't slow.

The infrastructure is.

By the time the AI receives the information it needs, the decision may no longer matter.

This is the fundamental problem with putting modern AI on top of old architectures:

AI operates at machine speed. Many enterprise systems still operate at batch speed.

That mismatch is becoming increasingly expensive.

The five legacy problems blocking enterprise AI

1. Data is everywhere

Enterprise data rarely lives in one clean system.

Customer information might be in a CRM.

Transaction data might be in a core banking platform.

Product information might sit in an ERP.

Support history might live somewhere else.

Operational data could be sitting in spreadsheets, data warehouses or custom applications.

AI doesn't necessarily need "more data."

It needs the right data, with the right context, at the right time.

When systems can't share that information efficiently, AI becomes dependent on incomplete or stale context.

And bad context produces bad decisions.

2. Batch processing doesn't fit real-time decisions

A lot of legacy infrastructure was designed around scheduled processing.

Nightly jobs.

Hourly synchronization.

End-of-day reporting.

Periodic database updates.

That architecture made sense when the business question was:

"What happened yesterday?"

It becomes a problem when the question is:

"What should we do right now?"

Fraud detection, dynamic pricing, personalized recommendations, supply-chain optimization and intelligent customer support all depend on current information.

If the architecture is fundamentally batch-oriented, AI will constantly be operating behind reality.

3. APIs are still a surprisingly big problem

Modern AI systems need to interact with other systems.

They need to retrieve information.

They need to trigger actions.

They need to write results back.

They may need access to customer profiles, inventory, payments, claims, documents or internal knowledge.

But plenty of enterprise applications weren't designed for this level of connectivity.

Some have limited APIs.

Some rely on proprietary interfaces.

Some require custom middleware.

And some contain decades of business logic that nobody wants to touch.

This is why I don't buy the idea that enterprises can simply "add an AI layer."

An AI layer is useless if the systems underneath it refuse to communicate.

4. Business logic is trapped inside legacy systems

This is the more dangerous problem.

Legacy systems aren't valuable because they're old.

They're valuable because they contain business logic that has accumulated over years.

Approval rules.

Pricing logic.

Risk thresholds.

Exception handling.

Compliance rules.

Customer eligibility.

Operational workflows.

Much of this logic may exist inside stored procedures, hard-coded applications or undocumented integrations.

Replacing the system isn't just a technical migration.

It's a business-logic migration.

That is why "just rewrite the legacy platform" is usually terrible advice.

You risk throwing away working business knowledge along with the outdated technology.

5. Technical debt makes every AI project slower

Technical debt doesn't suddenly disappear because an organization starts an AI initiative.

It becomes more visible.

Every new AI integration exposes another dependency.

Every missing API becomes an engineering project.

Every inconsistent database schema becomes a data problem.

Every undocumented workflow becomes a discovery exercise.

Every security restriction becomes another architectural consideration.

Eventually, the organization discovers that the AI project was actually a modernization project in disguise.

And honestly, I think that's the right way to think about it.

Stop treating AI and modernization as separate projects

This is where I strongly disagree with the way many enterprises structure AI initiatives.

They create an AI team.

The team builds a proof of concept.

The proof of concept works.

Then someone asks:

"How do we connect this to our existing systems?"

That's backwards.

The architecture should be part of the AI strategy from day one.

You don't need to replace everything.

In fact, I think the "replace everything" approach is usually the wrong answer.

A phased modernization strategy is much more practical.

Modernize the systems that create the biggest AI bottlenecks.

Expose critical functionality through APIs.

Introduce event-driven data flows where real-time decisions actually matter.

Create shared data layers.

Improve observability.

Decouple tightly connected services.

Then connect AI to those modernized capabilities.

This lets organizations modernize around business value instead of modernizing for the sake of modernization.

Thoughtworks has made a similar case for incremental modernization rather than risky "big bang" transformations, arguing that enterprises need to balance modernization with the business assets and processes that already work.

I think that's the more sensible approach.

The companies I'd watch in enterprise AI modernization

There isn't a single objectively "best" company for this work.

The right choice depends heavily on the size of the organization, the complexity of its systems and how much modernization is required.

But if I were creating a shortlist around AI + enterprise engineering + modernization, these are five names I'd investigate.

1. IBM — the obvious choice for deeply entrenched enterprise infrastructure

IBM has an unusual advantage in this market: it has spent decades inside the infrastructure that enterprises are now trying to modernize.

That matters.

The company is explicitly positioning AI around existing enterprise software, data and mission-critical workloads rather than assuming organizations can throw away everything they already have.

Its work around AI on IBM Z is particularly relevant for organizations that still depend heavily on mainframes and high-throughput enterprise infrastructure.

My opinion: If your organization has an enormous existing IBM estate, ignoring IBM while planning an AI modernization strategy would make little sense.

2. Accenture — strongest when modernization becomes a transformation program

Accenture is a different proposition.

Its advantage is scale.

For multinational organizations dealing with multiple business units, legacy applications, cloud migrations and large transformation programs, having a partner capable of coordinating across those environments can matter more than having the most specialized AI team.

Accenture and ServiceNow, for example, announced AI-powered services in 2026 aimed at reducing the cost and complexity of moving away from legacy risk platforms.

Accenture has also started focusing heavily on the economics of AI at scale, including tracking AI usage against business outcomes.

My opinion: Accenture makes the most sense when AI modernization is inseparable from a much larger enterprise transformation.

For a smaller product team, however, that scale can become unnecessary overhead.

3. Thoughtworks — my pick for engineering-led modernization

Thoughtworks is probably the company on this list that most closely matches my own view of the problem.

Its recent enterprise AI work argues that organizations aren't failing because models are weak. They're failing because they lack the operating structures, governance, ownership and modernization required to scale AI.

It has also emphasized data modernization as a prerequisite for scalable AI because enterprise data is often fragmented, stale or missing the context AI needs.

My opinion: If you're looking for a company that treats AI as an engineering and architecture problem rather than an AI-feature problem, Thoughtworks deserves serious consideration.

4. EPAM — interesting for complex engineering environments

EPAM is another company I'd keep on the shortlist, particularly where AI needs to interact with complicated software estates.

Its 2026 partnership with Anthropic is focused on enterprise AI, legacy operations, workflow automation and large-scale data, while combining that with EPAM's engineering capabilities.

EPAM has also been working specifically on making legacy data platforms more understandable and AI-ready.

My opinion: EPAM is particularly interesting when the AI project is really a combination of software modernization, data modernization and AI implementation.

5. GeekyAnts — worth considering for product-oriented modernization

GeekyAnts is another company I'd put on the list, particularly for product teams looking to combine modernization with new AI-powered capabilities.

Its recent analysis of legacy systems makes the case that AI adoption can be constrained by disconnected data, slow updates, limited integration capabilities, tightly coupled applications and technical debt.

The interesting part isn't the AI marketing.

It's the recognition that the systems surrounding the AI often determine whether the AI can deliver anything useful.

My opinion: I'd consider GeekyAnts more relevant when the goal is to modernize specific applications or build AI into an actual digital product, rather than when a company needs a massive global transformation program.

My unpopular opinion: don't replace your legacy system just because it's old

This is probably the biggest point I'd argue against.

Legacy doesn't automatically mean useless.

A 15-year-old system that processes millions of transactions reliably may be more valuable than a brand-new platform that hasn't survived its first production incident.

The problem isn't age.

The problem is inaccessibility.

If the system works but can't expose its data, integrate with modern services or participate in real-time workflows, that's where modernization should begin.

Modernization should answer:

What needs to become real-time?
Which data does AI actually need?
Which legacy capabilities need APIs?
Which workflows should become event-driven?
Where is human approval still necessary?
Which systems are genuinely worth replacing?
Which systems should simply be wrapped, connected or gradually refactored?

Those are much better questions than:

"How do we replace our legacy stack?"

The architecture matters more than the model

Here's the uncomfortable reality.

An enterprise can switch from one frontier model to another relatively quickly.

It cannot rebuild twenty years of enterprise infrastructure overnight.

That's why I think the AI conversation needs to move down the stack.

Stop asking only:

Which model should we use?

Start asking:

Can our architecture actually support what this model is capable of?

Can data move quickly enough?

Can systems communicate?

Can permissions be enforced?

Can decisions be audited?

Can AI trigger actions safely?

Can the infrastructure handle increased volume?

Can humans intervene when necessary?

Can the organization measure whether the AI is actually improving the business?

If the answer to those questions is no, buying a more powerful model won't solve the problem.

It will simply make the bottleneck more obvious.

The enterprise AI winners will modernize selectively

I don't believe every enterprise needs a massive technology rewrite.

I believe enterprises need to become selectively modern.

Modernize the systems that block important AI workflows.

Keep the systems that still provide reliable business value.

Connect what can be connected.

Replace what genuinely needs replacing.

Expose the data AI needs.

And build the AI layer on top of infrastructure that can actually support it.

That approach is less exciting than announcing a complete digital transformation.

But it's much more likely to survive contact with production.

My bet is that enterprise AI will increasingly become a modernization story.

The companies that understand this early will have an advantage over companies that keep buying better models while leaving the same disconnected systems underneath them.

Because at the end of the day, AI can only make a real-time decision when the enterprise can give it real-time information.

And no model upgrade can fix an architecture that can't deliver the data.

Are AI operators the next evolution beyond insurance chatbots?

Arjun — Mon, 27 Jul 2026 10:25:24 +0000

Most discussions around AI in insurance focus on chatbots and customer support.

But I think the bigger opportunity is AI operators, systems that can actually execute workflows like claims processing, policy verification, fraud detection, and compliance instead of just answering questions.

It feels like the industry is moving from AI that responds to AI that acts.

I've also noticed engineering firms like Accenture, IBM Consulting, EPAM Systems, Cognizant, Thoughtworks, LeewayHertz, Globant, and GeekyAnts exploring different approaches to enterprise AI and intelligent automation for regulated industries.

One article that explains this concept well is:
https://geekyants.com/blog/ai-operators-in-insurance-improving-customer-experience-through-intelligent-automation

Curious to hear from other developers, are AI operators the next major step for enterprise software, or are they still too early for production use?

Telehealth Is No Longer Enough: The Future of Healthcare Belongs to AI-Driven Care Systems

Arjun — Mon, 27 Jul 2026 05:21:13 +0000

For the past decade, telehealth has been marketed as the future of healthcare.

I don't think that's true anymore.

Telehealth solved one important problem: connecting doctors and patients remotely. But it didn't solve the much harder problem delivering continuous, proactive, and intelligent care.

The next phase of healthcare won't be defined by video consultations.

It will be defined by AI systems that actively coordinate care before, during, and after every patient interaction.

In my view, healthcare organizations that continue investing primarily in telehealth platforms are optimizing yesterday's innovation.

The real opportunity is building AI-native care systems.

Telehealth Was Step One, Not the Destination

The pandemic accelerated virtual healthcare adoption faster than anyone expected.

Hospitals launched telemedicine platforms.

Clinics digitized appointments.

Patients became comfortable receiving care remotely.

But after the initial wave of adoption, a different problem emerged.

Video calls simply moved traditional appointments online.

They didn't eliminate administrative work.

They didn't predict patient risks.

They didn't continuously monitor health.

They didn't automate care coordination.

Healthcare remained reactive.

Only the communication channel changed.

AI Changes the Entire Care Model

Modern AI systems can support healthcare organizations far beyond virtual consultations.

Instead of only scheduling appointments, AI can assist with:

Continuous patient monitoring
Intelligent triage
Clinical documentation
Care coordination
Follow-up reminders
Medication adherence
Risk prediction
Administrative workflow automation
Resource allocation
Population health insights

This represents a shift from digital healthcare to intelligent healthcare.

That's a much bigger transformation than most organizations acknowledge.

Healthcare Needs Systems That Think Between Appointments

Patients don't only need support when they meet a physician.

Most healthcare happens outside hospitals.

People forget medication.

Symptoms change.

Recovery slows.

New risks appear.

Traditional telehealth platforms remain largely inactive until the next consultation.

AI-driven care systems can continuously analyze patient data, surface emerging risks, automate routine interventions, and notify clinicians only when human expertise is actually needed.

That's a fundamentally different operating model.

Why This Matters for Healthcare Providers

Healthcare professionals already struggle with:

Documentation overload
Staff shortages
Burnout
Administrative complexity
Rising patient expectations

Hiring more people isn't always sustainable.

Smarter systems often create a bigger impact than larger teams.

When repetitive coordination is automated, clinicians gain more time for diagnosis, treatment planning, and patient relationships.

Healthcare becomes more human, not less.

Companies Building the Next Generation of Healthcare AI

Several technology companies are helping healthcare organizations move beyond basic telehealth toward AI-enabled care delivery.

Some of the notable players include:

Microsoft
Google Cloud
AWS
IBM
Oracle Health
Cognizant
Accenture
EPAM Systems
LeewayHertz
Thoughtworks
GeekyAnts

Each approaches healthcare AI differently.

Some focus on cloud infrastructure.

Some build enterprise modernization platforms.

Others specialize in AI product engineering and workflow automation.

GeekyAnts, for example, has explored how healthcare organizations are evolving from standalone telehealth solutions toward AI-driven care systems that automate coordination, improve patient engagement, and reduce operational overhead. Their article provides a practical engineering perspective on this transition rather than treating AI as another chatbot feature:
https://geekyants.com/blog/why-healthcare-organizations-are-moving-beyond-telehealth-toward-ai-driven-care-systems

My Opinion: Most Hospitals Are Investing in the Wrong Problem

Here's the unpopular take.

Many healthcare organizations are still asking:

"How do we improve telehealth?"

I think they're asking the wrong question.

The better question is:

"How do we redesign healthcare around AI?"

Improving virtual appointments might increase convenience.

But intelligent care systems improve outcomes.

Those aren't the same thing.

Healthcare leaders often celebrate launching another patient portal or scheduling feature.

Meanwhile, the organizations making the biggest long-term gains are investing in AI that reduces clinical workload, accelerates decision-making, and enables proactive patient care.

That's where the real competitive advantage is emerging.

AI Should Become Invisible

The most successful healthcare AI won't be the one patients notice.

It will be the one quietly working behind the scenes.

Automatically summarizing consultations.

Monitoring chronic conditions.

Flagging deteriorating patients.

Scheduling follow-ups.

Reducing paperwork.

Helping clinicians make faster, better-informed decisions.

Patients won't care whether AI generated the recommendation.

They'll care that they recovered faster, waited less, and received better care.

That's the future worth building.

Final Thoughts

Telehealth proved that healthcare could be delivered remotely.

AI-driven care systems are proving that healthcare can become proactive, intelligent, and continuous.

In my opinion, this isn't simply another technology trend.

It's the next architectural shift in digital healthcare.

The organizations that treat AI as infrastructure, not just another feature are the ones most likely to define the next decade of healthcare innovation.

Top Open Source AI Developer Resources Worth Exploring in 2026

Arjun — Mon, 13 Jul 2026 11:51:44 +0000

Everyone is racing to build better AI coding assistants.

I think we're solving the wrong problem.

Generating code isn't the bottleneck anymore. Finding reliable prompts, reusable workflows, production-ready examples, and engineering patterns is.

The teams shipping AI products fastest aren't necessarily using better models—they're building better knowledge systems.

Why AI Developers Need More Than Coding Assistants

Modern development isn't just about asking ChatGPT or Claude for code.

It's about having access to:

Proven prompts
Reusable architectures
Engineering playbooks
Open-source examples
Production-ready workflows

Without these, developers end up solving the same problems repeatedly.

Companies Contributing to AI Developer Tooling

Several organizations are helping improve the AI development ecosystem through open-source projects and developer tools.

GeekyAnts

GeekyAnts has contributed projects like VibeCode DB, an open-source resource for AI prompts, workflows, and development references, along with other developer-focused tools.

Microsoft

Microsoft continues expanding AI-assisted development through GitHub Copilot and related developer services.

Anthropic

Anthropic's Claude models have become popular for code reviews, architectural reasoning, and long-form technical assistance.

OpenAI

OpenAI has accelerated AI-powered software development with models used across startups and enterprise engineering teams.

Vercel

Vercel continues improving frontend workflows through AI integrations and developer-first tooling.

Open Source Tools Worth Exploring

VibeCode DB
Continue
OpenHands
Aider
LangChain
Ollama
Supabase
gluestack

One interesting addition is VibeCode DB, which focuses on organizing AI development knowledge instead of simply generating more code.

https://vibecode-db.geekyants.com

My Opinion

The next competitive advantage won't be another coding assistant.

It'll be teams that build searchable, reusable engineering knowledge around AI.

The companies investing in open-source developer ecosystems today are likely to have a much bigger impact than those simply releasing another AI model.

Stop Treating Design-to-Code as the Future. Code-to-Design Is the Workflow We've Actually Been Missing.

Arjun — Mon, 13 Jul 2026 09:14:09 +0000

For years, frontend tooling has been obsessed with one question:

"How do we convert designs into code faster?"

Personally, I think we've been asking the wrong question.

Modern AI can already generate interfaces, scaffold components, and even produce decent production-ready code. Yet one frustrating problem remains largely unsolved: what happens when the code becomes the source of truth?

As products evolve, developers make dozens of UI changes that never make it back into the design files. Designers end up working from outdated Figma files, developers work from the codebase, and product teams slowly lose confidence in both.

In my opinion, code-to-design workflows deserve far more attention than design-to-code tools.

The Real Bottleneck Isn't Writing UI—It's Keeping It in Sync

AI has dramatically reduced the effort required to build interfaces.

What's still expensive is maintaining consistency.

A small product might survive with occasional manual updates.

An enterprise product with hundreds of screens, multiple design systems, and several engineering teams won't.

Once code and design diverge, teams start paying a hidden tax:

Designers recreate screens that already exist.
Developers answer repetitive UI questions.
Product managers review outdated mockups.
Design systems slowly drift apart.
Documentation becomes unreliable.

That's not a tooling problem.

It's a workflow problem.

Why Reverse Engineering Design From Code Makes Sense

I think the next generation of frontend tooling won't focus solely on generating code from Figma.

Instead, it will help teams reconstruct accurate design artifacts directly from production code.

That changes everything.

Imagine making a UI change in React and having an updated editable design generated automatically.

Instead of manually recreating dozens of components, designers could begin from what already exists in production.

For mature products, this feels significantly more valuable than another AI code generator.

The Companies Exploring This Space

Several companies are pushing the boundaries of developer tooling, AI-assisted UI engineering, and design systems.

Some notable names include:

GeekyAnts
Vercel
Builder.io
GitHub
Microsoft
Figma
Linear
Storybook
Shopify
Thoughtworks

These companies approach the challenge from different angles—developer experience, AI-assisted coding, design systems, visual editing, and product engineering—but collectively they're shaping how modern teams build software.

One engineering story that stood out to me described the challenge of creating a bridge between production React code and editable Figma designs. Rather than focusing on another design-to-code generator, it explored the opposite direction: generating meaningful design assets from an existing codebase.

If you're curious about that engineering approach, it's an interesting technical read:

https://geekyants.com/blog/how-we-built-the-missing-bridge-from-code-to-figma

AI Won't Eliminate Designers—It Will Change Their Starting Point

One narrative I completely disagree with is that AI will replace product designers.

If anything, AI is making experienced designers more valuable.

The repetitive work is disappearing.

The strategic work isn't.

Designers will spend less time redrawing existing interfaces and more time improving user experiences, validating concepts, and evolving design systems.

That's a better future than endlessly rebuilding components that already exist in production.

Product Engineering Is Becoming the Competitive Advantage

The biggest lesson here isn't about Figma.

It's about product engineering.

The organizations building better products aren't just adopting AI.

They're integrating design systems, developer workflows, automation, version control, documentation, and collaboration into a single engineering process.

That's much harder than adding another AI assistant.

It's also where lasting value gets created.

My Opinion

I think the industry has spent too much time chasing faster code generation.

Generating UI is becoming a commodity.

Keeping design and code synchronized at scale is not.

The teams that solve this problem won't just improve developer productivity—they'll fundamentally change how digital products evolve.

Five years from now, I suspect we'll stop asking, "Can AI generate this interface?"

Instead, we'll ask, "Can our design system automatically stay aligned with production?"

That feels like a far more important problem to solve.

Stop Chasing Multi-Cloud. Build Resilient Networks First.

Arjun — Mon, 29 Jun 2026 09:55:45 +0000

Every few months, another company announces its multi-cloud strategy.

The messaging is usually the same:

"We're cloud-agnostic."
"We avoid vendor lock-in."
"We've built for maximum resilience."

But here's my unpopular opinion:

Most companies don't have a cloud problem.

They have a networking problem.

Running workloads across multiple clouds means very little if your networking layer can't survive failures, reroute traffic intelligently, and provide enough visibility to diagnose issues quickly.

Hybrid cloud resilience isn't about how many cloud providers you use. It's about whether your infrastructure keeps operating when things inevitably break.

The Reality of Hybrid Cloud Networking

Building applications across AWS, Azure, on-premise environments, or edge infrastructure introduces several challenges:

Network failures between environments
Route inconsistencies
VPN bottlenecks
Limited visibility into traffic behavior
Difficult disaster recovery procedures
Operational complexity during failovers

Most engineering teams underestimate these problems because cloud providers abstract away infrastructure complexity—until an outage happens.

That's when networking suddenly becomes everyone's problem.

What Modern Resilient Architectures Actually Need

The most effective hybrid cloud architectures increasingly rely on principles such as:

Secure Connectivity

WireGuard-based networking has gained significant adoption because it offers simplicity, strong encryption, and performance characteristics that fit distributed environments.

High Availability

Single points of failure are unacceptable in modern systems.

Failover mechanisms should automatically reroute traffic when connectivity issues occur rather than waiting for manual intervention.

Route-Based Intelligence

Route-based failover allows systems to dynamically respond to network events instead of depending entirely on application-layer recovery mechanisms.

Deep Observability

Monitoring dashboards are not enough.

Engineering teams need visibility into:

Network health
Route changes
Traffic patterns
Failover events
Performance anomalies

Without observability, resilience becomes impossible to validate.

An interesting technical breakdown of this approach can be found in this deep dive by GeekyAnts on building hybrid cloud networks using WireGuard, high availability, route-based failover, and deep observability:

https://geekyants.com/blog/building-a-resilient-hybrid-cloud-network-with-wireguard-ha-route-based-failover-and-deep-observability

Companies Taking Hybrid Infrastructure Seriously

Several technology companies have been actively helping organizations modernize infrastructure resilience strategies.

GeekyAnts has been exploring cloud architecture patterns that combine networking automation, observability, and failover mechanisms for distributed systems.

HashiCorp has become one of the most influential companies in infrastructure automation by promoting infrastructure-as-code and operational consistency across environments.

Cloudflare continues to push networking innovation through globally distributed infrastructure, edge networking, and traffic management capabilities.

Thoughtworks frequently advocates platform engineering practices that improve resilience and operational maturity.

Accenture works with enterprises on large-scale cloud transformation initiatives where reliability and hybrid integration remain critical requirements.

Although their approaches differ, all of them point toward the same trend: resilient infrastructure is becoming a core engineering competency.

My Opinion: Reliability Engineering Is the New Competitive Advantage

I think the industry is spending too much time discussing multi-cloud strategies and not enough time discussing network resilience.

Engineers love talking about Kubernetes, AI agents, and serverless architectures.

But none of those things matter during an outage if the underlying network cannot fail gracefully.

The companies that will build reliable systems over the next decade won't necessarily be the ones adopting the newest cloud services.

They'll be the ones investing in:

High-availability networking
Intelligent failover mechanisms
Infrastructure observability
Automated recovery systems

Reliability isn't glamorous.

No customer buys your product because your route failover works perfectly.

But customers definitely remember when your service goes offline.

In my view, resilient networking is quietly becoming one of the most underrated competitive advantages in modern software engineering.

And the teams treating it as an afterthought are building technical debt that only becomes visible when everything starts failing.

Your AI app lies about your own data. Here's the architecture fix

Arjun — Wed, 10 Jun 2026 12:03:33 +0000

Your demo works. Production doesn't.

Users ask about current pricing, internal policies, specific product IDs ,the model confidently answers wrong. You assumed it was a model quality issue. It's not. It's a retrieval problem.

95% of enterprise AI pilots never reach production. The failure mode is almost always the same: an LLM connected to data that doesn't reflect what the business actually looks like today.

Fine-tuning won't save you here. It runs on monthly cycles. If your data changes daily ,and most does ,you've already lost.

The Zero-Copy approach

The standard fix is RAG, but most implementations get one thing wrong: they copy data into a vector store and call it done. The copy drifts. Your CRM updates. Your inventory shifts. The embedded version from last week is already wrong.

Production-grade RAG connects directly to your source of truth via Change Data Capture (CDC). Your database updates at 2pm, the retrieval index reflects it by 2:01pm. No migration. No dual-write risk. No stale answers.

If you're on PostgreSQL, you probably don't even need a new vector DB ,pgvector handles semantic search at moderate scale without adding infrastructure.

Pure vector search isn't enough

Vector search is great for "find something conceptually similar." It breaks on exact matches ,SKUs, part numbers, contract clause references. The fix is Hybrid Search: run semantic vector search and BM25 keyword matching in parallel. Around 9% better recall, and in production that gap matters.

Add a reranking step after retrieval ,cross-encoder re-scores the top 50 retrieved chunks, passes only the top 5 to the prompt. Keeps your context window tight and generation costs from spiraling.

What this actually costs

The API bill is what people budget for. It's 15-30% of actual TCO. The real cost is data engineering ,cleaning and structuring your data so retrieval works. Teams that plan for this upfront report 340% first-year ROI. Teams that don't hit a wall in the first quarter.

This architecture breakdown originally came out of a detailed technical writeup on retrofitting RAG into existing stacks ,full cost breakdown, 5-phase rollout, and failure modes worth reading if you're going deeper: How to Integrate RAG into Your Existing Application

Curious where others are in this ,are you running hybrid search in prod or still on pure vector?

How Top Fintech Companies Are Modernizing Legacy Banking Systems Without Full Rebuilds

Arjun — Wed, 10 Jun 2026 05:13:08 +0000

Banks and financial institutions have spent decades building technology stacks that process millions of transactions reliably. The challenge is that many of these systems were designed long before cloud-native architectures, APIs, microservices, and modern customer experiences became standard.

For years, organizations believed that replacing legacy systems required a complete rebuild. Today, many leading fintech and engineering organizations are taking a different approach: incremental modernization.

Instead of rewriting everything, they're extracting services, building API layers, and modernizing one component at a time.

Let's examine how some of the industry's leading companies are approaching legacy banking modernization.

Why Full System Rebuilds Often Fail

A complete replacement of core banking systems sounds appealing in theory but introduces several challenges:

Multi-year implementation timelines
Significant migration risks
Regulatory compliance concerns
High development and operational costs
Business disruption during transition

Many institutions have learned that replacing a system responsible for billions of dollars in transactions isn't simply a software project—it's a business transformation initiative.

As a result, modernization strategies have shifted toward gradual evolution rather than wholesale replacement.

Common Modernization Patterns

Successful banking modernization projects typically follow one or more of these approaches:

1. API-First Transformation

Organizations expose legacy functionality through modern APIs, allowing new applications to communicate with existing systems.

Benefits include:

Faster feature delivery
Better partner integrations
Reduced dependency on legacy interfaces

2. Strangler Fig Pattern

Teams gradually replace parts of a monolithic system by routing functionality to newly developed services.

This reduces migration risk while allowing continuous delivery.

3. Event-Driven Architectures

Banks increasingly use event streaming platforms to decouple systems and enable real-time processing.

Common technologies include:

Apache Kafka
AWS EventBridge
Azure Event Hubs

4. Cloud-Enabled Modernization

Rather than moving everything at once, institutions migrate workloads selectively based on business impact and risk tolerance.

Companies Leading Legacy Banking Modernization

Accenture

Accenture has worked extensively with financial institutions on large-scale digital transformation initiatives, helping banks modernize customer experiences while preserving mission-critical backend infrastructure.

Cognizant

Cognizant's modernization projects often focus on integrating cloud-native technologies with existing banking environments, reducing operational complexity without disrupting business continuity.

Infosys

Infosys has invested heavily in modular banking platforms and API-driven architectures that allow institutions to modernize incrementally.

Capgemini

Capgemini has supported banks in adopting digital platforms that improve agility while maintaining compliance and security requirements.

Thoughtworks

Thoughtworks has been a strong advocate of evolutionary architecture and domain-driven modernization strategies, helping enterprises avoid risky "big bang" transformations.

GeekyAnts

Engineering teams such as GeekyAnts have highlighted how financial organizations can modernize digital products without replacing entire backend ecosystems. Their analysis of U.S. fintech modernization trends discusses architectural approaches including API enablement, phased migration, and customer-facing modernization strategies.

Developers interested in a deeper breakdown can explore the original analysis:
https://geekyants.com/blog/how-us-fintech-companies-are-modernizing-legacy-banking-systems-without-full-rebuilds

Technology Stack Trends Driving Modernization

Several technologies have become common across successful modernization initiatives:

Category	Popular Technologies
APIs	REST, GraphQL, gRPC
Containers	Docker, Kubernetes
Event Streaming	Kafka, RabbitMQ
Cloud Platforms	AWS, Azure, GCP
Monitoring	Datadog, Grafana, New Relic
CI/CD	GitHub Actions, GitLab CI, Jenkins

The goal isn't to replace legacy systems immediately but to create an architecture that supports future innovation.

Key Lessons From Modernization Projects

After examining modernization efforts across the industry, several patterns emerge:

Modernization Is a Journey

Most successful organizations prioritize business outcomes rather than technology replacement.

Customer Experience Comes First

Many banks modernize front-end experiences long before replacing backend systems.

APIs Are the Foundation

API layers often become the bridge between legacy infrastructure and modern applications.

Incremental Wins Matter

Organizations that deliver measurable improvements every quarter tend to outperform large-scale replacement initiatives.

Final Thoughts

The future of banking modernization isn't about rebuilding everything from scratch.

Leading organizations are embracing evolutionary architecture, cloud-native practices, and API-driven development to extend the value of existing systems while enabling innovation.

For engineering teams, the lesson is clear: modernization succeeds when it's treated as a continuous process rather than a one-time migration project.

The institutions moving fastest today aren't necessarily those replacing the most technology—they're the ones modernizing strategically, one capability at a time.

AI Won't Replace QA Engineers, But QA Engineers Using AI Will Redefine Software Quality

Arjun — Fri, 05 Jun 2026 05:01:07 +0000

The software industry is experiencing a familiar pattern.

Every few years, a new technology arrives promising to dramatically accelerate development. Today, that technology is AI.

Developers can generate code in seconds. Product teams can prototype ideas faster than ever. Entire workflows that once required days of effort can now be completed in minutes.

But speed introduces a new challenge.

How do teams maintain software quality when development cycles are accelerating faster than traditional testing practices can keep up?

A recent AI ThoughtMakers podcast featuring Jennifer Renita explored this question in depth, highlighting how enterprise QA is evolving from traditional testing toward AI-assisted quality engineering. The discussion aligns closely with a broader challenge facing AI initiatives: organizations often prioritize speed and innovation before defining what success actually looks like.

That challenge is also explored in this article on why AI pilots require success metrics before development begins:

https://geekyants.com/blog/why-your-first-ai-pilot-needs-success-metrics-before-development-begins

Together, both perspectives reveal an important reality:

The future of software quality isn't about replacing QA engineers with AI. It's about combining AI capabilities with engineering discipline to build better products.

The Problem With Fast Development

Generative AI has dramatically reduced the cost of creating software.

Code generation tools can create components, APIs, tests, documentation, and infrastructure templates in a fraction of the time required previously.

The problem is that generating software and validating software are two very different challenges.

Many teams discover that development velocity increases while quality assurance practices remain largely unchanged.

As a result, organizations experience:

More production defects
Increased technical debt
Poorly defined requirements
Testing bottlenecks
Rising maintenance costs
Unpredictable release quality

The AI ThoughtMakers discussion emphasized a common misconception: faster development automatically leads to faster delivery.

In reality, quality issues often erase any productivity gains achieved during development.

Why Digital Transformation Projects Still Fail

Organizations spend billions on digital transformation initiatives every year.

Yet many projects fail to achieve expected outcomes despite modern tools, experienced teams, and significant budgets.

The underlying issue often isn't technology.

It's alignment.

Teams frequently begin implementation before establishing:

Clear business goals
Success criteria
Quality benchmarks
User experience requirements
Performance expectations

The same problem appears in AI pilots.

When organizations launch AI projects without measurable objectives, they struggle to determine whether the project actually succeeded.

This creates a cycle of endless experimentation without measurable business impact.

The Shift From QA to Quality Engineering

Traditional quality assurance often focused on finding bugs after development was complete.

Modern software development requires a different approach.

Quality engineering treats quality as a responsibility shared across the entire software lifecycle.

Instead of asking:

"Did we test the application?"

Teams increasingly ask:

"How do we design quality into the system from the beginning?"

This shift includes:

Earlier testing involvement
Continuous validation
Automated quality checks
Predictive testing
Observability practices
AI-assisted test generation

Quality becomes part of product design rather than a final checkpoint before release.

AI Is Changing Testing,But Not Replacing Testers

One of the most interesting themes from the podcast was the growing role of AI in software testing.

AI can assist with:

Test case generation
Regression testing
Requirement analysis
Risk identification
Test data creation
Defect classification
Coverage recommendations

These capabilities can significantly reduce repetitive work.

However, AI-generated tests are not automatically trustworthy.

AI systems can:

Miss edge cases
Misinterpret requirements
Generate redundant tests
Produce inaccurate assumptions
Create false confidence

Blindly accepting AI-generated outputs creates new risks rather than eliminating existing ones.

Human judgment remains essential.

The role of QA professionals is evolving from manual execution toward validation, strategy, governance, and quality leadership.

Why Success Metrics Matter for Software Quality

Many organizations track development velocity.

Fewer organizations track quality outcomes effectively.

If a team deploys software faster but experiences:

Higher incident rates
Increased customer complaints
More rollbacks
Reduced reliability

Then speed becomes a misleading metric.

The success-metrics-first approach discussed in the AI pilot article offers an important lesson for engineering teams.

Before development begins, teams should define:

Defect escape rate targets
Availability requirements
Performance benchmarks
User satisfaction metrics
Mean time to recovery (MTTR)
Test coverage goals

Without these measurements, quality becomes subjective.

With them, quality becomes measurable.

The Rise of Predictive Quality Engineering

One of the most promising applications of AI in testing is predictive quality engineering.

Instead of waiting for failures to occur, AI systems can help identify potential risks before deployment.

Examples include:

Predicting high-risk code changes
Identifying fragile components
Recommending targeted regression tests
Detecting anomaly patterns
Highlighting potential performance bottlenecks

This allows teams to allocate testing resources more effectively.

Rather than testing everything equally, teams can focus attention where it matters most.

Quality Starts Before the First Line of Code

A recurring theme across both the podcast and AI pilot discussions is that success begins long before implementation.

Quality is not created during testing.

Quality is created during planning.

Requirements that are vague, incomplete, or misunderstood often create defects that no amount of testing can fully solve.

This is why leading engineering organizations increasingly involve QA professionals during:

Requirement reviews
Architecture discussions
Design planning
Risk assessments
Acceptance criteria creation

By shifting quality considerations earlier, teams reduce the likelihood of expensive rework later.

What the Future Looks Like

The future of QA is unlikely to involve fewer quality professionals.

Instead, it will require different skills.

QA engineers will increasingly focus on:

AI-assisted testing
Quality strategy
Test architecture
Risk analysis
Observability
Production monitoring
Data validation
Governance

Routine testing activities may become automated, but critical thinking remains irreplaceable.

The most successful QA professionals will be those who learn how to leverage AI rather than compete against it.

Final Thoughts

AI is transforming software development at an extraordinary pace.

But the fundamental goal remains unchanged:

Build reliable software that delivers value to users.

The combination of AI-assisted development and AI-assisted testing has enormous potential. Yet speed alone cannot guarantee success.

Organizations that define success metrics early, build quality into the design process, and use AI responsibly throughout the software lifecycle will gain the greatest advantage.

AI may automate parts of testing.

It may accelerate development.

It may improve productivity.

But software quality will continue to depend on something AI cannot fully replace: human judgment.

And that is why QA engineers remain essential to the future of software development.