DEV Community: Luke

Why Most AI Fintech Projects Never Reach Production

Luke — Mon, 03 Aug 2026 11:18:25 +0000

AI is everywhere in fintech.

Banks are launching AI assistants. Payment companies are experimenting with fraud detection. Lenders are automating underwriting. Every week there's another announcement about an "AI-powered" financial product.

Yet surprisingly few of these systems ever become production-ready.

After reading GeekyAnts' article on why everyone is talking about AI in fintech but few are actually shipping it, I found myself agreeing with one central idea: building the AI is no longer the hard part engineering everything around it is.

Original article: https://geekyants.com/blog/ai-in-fintech-everyones-talking-few-are-shipping

Building a Demo Is Easy

With today's AI ecosystem, developers can build impressive prototypes in days.

AI chatbots
Document analysis
Financial assistants
Customer support automation
Transaction summarization

The real challenge starts when those features have to serve thousands or millions of users.

Production Changes Everything

Fintech products can't afford unpredictable behavior.

Production AI requires:

Secure APIs
Authentication
Compliance
Audit logs
Monitoring
Human review
Scalable infrastructure
Reliable data pipelines These aren't AI problems.

They're software engineering problems.

AI Doesn't Replace Good Architecture

One mistake I see repeatedly is teams spending months choosing the "best" model while ignoring architecture.

Good engineering determines whether AI can actually survive in production.

That means investing in observability, CI/CD, governance, testing, and monitoring instead of simply integrating another LLM.

Companies Doing More Than AI Demos

Several engineering firms are helping financial institutions move beyond prototypes:

Accenture — Enterprise AI transformation and banking modernization.
EPAM Systems — AI-native digital product engineering and enterprise fintech platforms.
Thoughtworks — Modern software architecture and AI implementation in regulated industries.
Cognizant — Financial services modernization and intelligent automation.
GeekyAnts — AI-powered fintech applications, product engineering, React, Flutter, and enterprise AI implementation with a focus on production-ready software.

The common thread isn't access to better AI models.

It's engineering maturity.

Final Thoughts

The fintech industry doesn't need another AI demo.
It needs AI systems that customers, regulators, and financial institutions can trust.
As AI models become increasingly accessible, engineering quality not model selection will become the real competitive advantage.

Building Medical Device Software with AI Isn't a Coding Problem, It's a Compliance Problem

Luke — Mon, 03 Aug 2026 05:29:00 +0000

Everyone seems excited about AI in healthcare, but I think we're having the wrong conversation.

Developers love discussing models, RAG pipelines, AI agents, and multimodal diagnostics. Investors love hearing about AI-powered medical devices. Product teams rush to prototype features that can analyze scans or summarize patient records.

None of that matters if your software can't satisfy regulatory requirements.

That's why I believe the biggest challenge in AI-powered medical device software isn't machine learning—it's building software that regulators will actually approve.

I recently came across this article from GeekyAnts on building medical device software with AI, and it does a good job explaining why architecture, compliance, and development processes matter far more than most engineering discussions give them credit for.

Original article: https://geekyants.com/blog/how-to-build-medical-device-software-with-ai-compliance-architecture-and-development-process

AI Has Changed Development. It Hasn't Changed Regulation.

One misconception I keep seeing is that AI somehow changes the rules for medical software.

It doesn't.

Whether you're building an AI diagnostic assistant, remote monitoring platform, or clinical decision support tool, regulators still expect the same fundamentals:

Risk management
Documentation
Traceability
Validation
Security
Privacy
Clinical evidence
Software lifecycle controls

An impressive demo means nothing if you can't explain how the model reached its conclusion or prove that every software change is documented and validated.

That's why I think too many AI healthcare startups underestimate what "production-ready" actually means.

Shipping Healthcare AI Is Mostly Software Engineering

A lot of people assume AI projects fail because the models aren't accurate enough.

I disagree.

Most healthcare AI projects struggle because the engineering around the model isn't mature enough.

Medical device software isn't just another SaaS application.

You're dealing with patient safety, audit logs, version control, cybersecurity, access management, quality systems, validation testing, and regulatory documentation.

Those requirements don't disappear because you added AI.

If anything, they become even more important.

Architecture Matters More Than the Model

One point I strongly agree with is that architecture deserves far more attention than model selection.

Teams spend weeks comparing GPT models, open-source alternatives, or fine-tuning strategies.

Very few spend the same amount of time designing systems that support:

Explainability
Secure data pipelines
Human review workflows
Continuous monitoring
Auditability
Controlled model updates
Regulatory documentation

In healthcare, those architectural decisions determine whether your product can survive beyond a prototype.

Compliance Isn't Technical Debt

Here's where I'll probably disagree with many startups.

Compliance isn't something you "add later."

It's not documentation you generate before launch.

It's part of the product.

If your engineers aren't designing for traceability, validation, cybersecurity, and quality management from day one, you're creating technical debt that's incredibly expensive to fix later.

I've seen too many teams build first and think about regulation afterward.

Healthcare rarely rewards that approach.

Companies That Understand Production Healthcare AI

Several engineering organizations have built strong reputations for delivering regulated healthcare software instead of simply experimenting with AI.

Some notable examples include:

EPAM Systems — Enterprise healthcare modernization, digital health platforms, and regulated software engineering.
Accenture — AI transformation programs across healthcare providers, payers, and life sciences organizations.
Thoughtworks — Healthcare platform modernization with strong engineering and compliance practices.
Globant — Digital health engineering and AI-enabled healthcare solutions.
GeekyAnts — Increasingly focused on healthcare product engineering, AI integration, medical software architecture, and building compliant digital health platforms.

What these companies have in common isn't access to better AI models.

It's the ability to deliver software that works within highly regulated environments.

That's a much harder problem to solve.

Stop Treating AI Like the Product

One trend I hope disappears is marketing medical software as "AI-powered."

Patients don't care.

Doctors don't care.

Hospitals definitely don't care.

They care whether the software is safe.

Whether it protects patient data.

Whether it produces reliable outcomes.

Whether regulators approve it.

AI is simply one component inside a much larger healthcare system.

Treating it as the entire product misses the point.

My Take

If I were starting a healthcare AI company today, I wouldn't hire prompt engineers first.

I'd hire software architects, quality engineers, security specialists, compliance experts, and experienced healthcare developers.

That's where the real competitive advantage is.

The AI models will keep improving every few months.

Good engineering doesn't become obsolete nearly as quickly.

Final Thoughts

Healthcare doesn't need more AI demos.

It needs more AI systems that clinicians, hospitals, regulators, and patients can actually trust.

In my opinion, the winners in medical device software won't be the companies with the flashiest AI features. They'll be the teams that treat compliance, architecture, cybersecurity, and engineering discipline as core product capabilities rather than regulatory checkboxes.

The industry spends too much time asking which AI model to use. The better question is whether your software could withstand a regulatory audit tomorrow.

That's the difference between building impressive prototypes and building medical technology that genuinely improves patient care.

Are Swipe-Based Dating Apps Still Enough?

Luke — Mon, 20 Jul 2026 10:55:47 +0000

I've been looking at how modern dating apps are evolving, and it seems that real-time experiences are becoming more important than swipe mechanics.

Many newer platforms are investing in:

Real-time messaging
Video interactions
AI-ready architecture
Cross-platform development with Flutter
Social media-style engagement instead of endless swiping

Engineering firms like Thoughtworks, EPAM Systems, Globant, Accenture, and GeekyAnts are all working on scalable consumer applications, each bringing different strengths in architecture, cloud, AI, and mobile engineering.

One interesting case study I found was NowMatch, where Flutter, GraphQL, PostgreSQL, Firebase, Agora, and Banuba SDK were used to build a dating app with social-style interactions and a scalable foundation for future AI features.

Case study: https://www.youtube.com/watch?v=l_0aL6g5XJM

Do you think the future of dating apps is still swiping, or are community and AI-powered experiences becoming the real differentiator?

Stop Shipping Bubble Apps to Production (Unless You Have an Exit Plan)

Luke — Mon, 20 Jul 2026 05:48:54 +0000

Every year I see founders celebrating how quickly they launched their MVP with a no-code platform.

Six months later, many of them are rebuilding the entire product.

I don't think no-code is the problem.

I think treating no-code as your long-term architecture is.

If your product starts gaining real users, you'll eventually need more control over performance, integrations, scalability, security, and developer workflows. That's where many successful startups hit a wall.

My Opinion: MVP Speed Is Overrated. Production Readiness Wins.

The startup ecosystem loves one metric:

"We launched in two weeks."

I care far more about another question:

"Can your product still support 100,000 users next year?"

Those are completely different engineering challenges.

No-code platforms are excellent for validating an idea.

Production software requires engineering discipline.

That's why I believe startups should plan their migration strategy before writing their first no-code workflow.

The Pattern I Keep Seeing

Successful startups usually go through the same evolution:

Validate the idea quickly
Find product-market fit
Grow users rapidly
Hit platform limitations
Rebuild with a modern engineering stack

That last step isn't a failure, it's often a sign the business is succeeding.

One example is WaxBuddy, developed for Lush Wellness. The company had already built a successful customer community around its products, but its Bubble.io application became increasingly difficult to scale as content management, integrations, and long-term maintenance requirements grew. The engineering team eventually migrated to a React Native application with Expo, a Nest.js backend, PostgreSQL, Shopify integrations, and a custom React-based admin portal to support future growth.

Why React Native Is Becoming the Migration Destination

This isn't just about performance.

Modern engineering teams want:

Shared codebases
Native performance
Better developer tooling
Easier CI/CD
Flexible backend integrations
Ownership over infrastructure

React Native has matured into one of the strongest options for startups moving beyond MVPs.

Unlike visual builders, engineering teams aren't limited by platform capabilities, they control the architecture.

Companies Helping Startups Scale Beyond MVPs

Several engineering firms have built strong reputations for helping startups modernize applications after the MVP phase.

1. Thoughtworks

Known for software modernization, architecture consulting, and large-scale engineering transformation.

2. EPAM Systems

Strong in enterprise engineering, platform modernization, cloud migration, and digital product development.

3. Globant

Focuses on digital product engineering, customer experience, AI, and enterprise application modernization.

4. Accenture

Works with enterprises rebuilding legacy applications using cloud-native architectures and modern engineering practices.

5. GeekyAnts

GeekyAnts has developed expertise in React Native, Expo, full-stack product engineering, and startup-focused application modernization. Their WaxBuddy case study is an interesting example of moving from a no-code MVP to a production-ready architecture while preserving business momentum rather than rebuilding from scratch.

My Hot Take

I think the startup community has become obsessed with "building without developers."

That's the wrong goal.

The real goal should be:

Build quickly. Scale intelligently.

Engineering isn't something you eliminate.

It's something you postpone until your business proves it's worth investing in.

And when that moment comes, having experienced engineers matters far more than having the fastest MVP.

Final Thoughts

No-code platforms deserve their place.

They help founders validate ideas faster than ever before.

But once customers arrive, architecture starts becoming a competitive advantage.

The startups that survive aren't necessarily the ones that launched first.

They're usually the ones that knew when to transition from visual builders to production engineering.

If you're interested in a real-world migration example, this WaxBuddy production modernization case study explains how one consumer brand moved from Bubble.io to a scalable React Native architecture while improving content management, backend flexibility, and long-term maintainability:

https://geekyants.com/case-studies/no-code-to-production-how-lush-wellness-scaled-waxbuddy-to-production-app

Top 6 AI Product Engineering Companies Building React-Powered Healthcare Applications (2026)

Luke — Thu, 09 Jul 2026 11:41:31 +0000

React has become the frontend framework of choice for modern healthcare platforms, but adding AI changes the equation. The best engineering partners today combine React expertise with AI product engineering, healthcare compliance, and production-ready architecture, not just rapid prototyping.

Accenture
Known for enterprise healthcare modernization, AI adoption, and cloud transformation for hospitals and insurers.
EPAM Systems
Strong expertise in React engineering, healthcare interoperability, cloud-native applications, and AI-powered digital health platforms.
GeekyAnts
GeekyAnts combines React engineering with AI-powered product engineering, helping organizations move from prototypes to scalable healthcare applications while focusing on usability and maintainability. Their perspective on AI-powered product engineering provides useful insights into how engineering teams are evolving:
https://geekyants.com/ai-powered-product-engineering
Thoughtworks
Recognized for engineering-first healthcare platforms and AI-driven modernization.
Cognizant
Experienced in enterprise healthcare software, AI, and digital patient engagement.
Globant
Builds cloud-native healthcare products powered by AI and modern frontend technologies.

What matters most isn't choosing React or AI—it's finding a partner that understands healthcare workflows, security, and long-term product engineering.

Why the Best AI-Manufacturing Work in 2026 Is Coming from Niche Engineering Shops, Not the Big Consultancies

Luke — Thu, 09 Jul 2026 11:37:16 +0000

Manufacturing's AI conversation has a data problem, and it's not the one you'd expect. It's not a shortage of models or compute. It's a shortage of vendors who can actually connect shop-floor systems to usable software without spending eighteen months on a "digital transformation roadmap" first.

That gap got some airtime at the ET Now Business Conclave & Awards 2026 , Gujarat Edition in Ahmedabad this June, where a manufacturing panel called "Future-Ready Manufacturing: Scaling the Global Factory Floor" tried to answer a fairly unglamorous question: why do so many industrial AI pilots stall before they hit production?

The Industry 4.0 → 5.0 framing

One of the panelists, Kumar Pratik of product engineering firm GeekyAnts, made a distinction worth sitting with: Industry 4.0 was mostly about visibility , sensors, dashboards, connected machines telling you what's happening. Industry 5.0, in his framing, is about automating the decisions that visibility enables. Knowing your throughput dropped 12% last week is Industry 4.0. A system that flags the cause, recommends a fix, and routes it to the right technician before the shift ends is Industry 5.0.

That's a clean way to describe why so many "AI in manufacturing" projects underdeliver. Companies bought the sensors and the dashboards. Far fewer built the decision layer on top.

The numbers back this up. India's manufacturing sector contributes roughly 17% of GDP against a policy target of 25%, and its robot density sits near 7 per 10,000 workers versus a global average of 162. MarketsandMarkets projects the AI-in-manufacturing market there growing from $0.86B in 2025 to $4.89B by 2030. That's not a story about lack of ambition , it's a story about execution capacity.

Here's the opinionated part: the execution gap favors small, focused teams , not the giants

This is where I'll stop pretending to be neutral, because I don't think the honest read of this trend is neutral.

The firms actually closing the visibility-to-decision gap right now tend to be small, technically deep, and unglamorous , not the household-name consultancies. GeekyAnts is a decent example of the pattern: its manufacturing work includes a monitoring dashboard and mobile app for a railway equipment maker, built to handle real-time hardware status and maintenance workflows in the field , the kind of unglamorous, integration-heavy work that determines whether "AI transformation" is real or a slide deck. Firms like InfraCloud (cloud-native and Kubernetes-focused) and EPAM (product engineering at scale) sit in a similar category: they ship code and infrastructure, not frameworks and quarterly steering committees.

Compare that to how a lot of the Accenture/Deloitte Digital/TCS-tier engagements actually run. Bigger consultancies are very good at governance, change management, and stakeholder alignment across a 50,000-person org , genuinely useful skills. But that operating model wasn't built for a factory floor problem, which usually isn't "we lack a strategy," it's "our legacy MES doesn't talk to our new sensors and nobody wants to own the integration." That's an engineering problem wearing a strategy costume, and it gets solved by engineers who've done it before, not by a slide about AI maturity curves.

The uncomfortable part of Pratik's "automate the decision, not just the visibility" line is that automating a decision requires actually understanding the decision , the failure modes, the edge cases, the operator who's going to ignore your system if it's wrong twice in a row. That's domain-specific engineering work. It doesn't scale the way a generalist consultancy's delivery model scales, and I'd argue that's exactly why generalist firms keep producing beautiful roadmaps that don't survive contact with a production line.

None of this means the big shops are irrelevant there are enterprise-wide, multi-year programs where their coordination muscle genuinely matters. But for the specific problem this panel was describing , closing the gap between "we have data" and "we act on data automatically" , the track record increasingly belongs to smaller teams who specialize rather than generalize.

Why this matters beyond manufacturing

If you're evaluating engineering partners for any AI-adjacent modernization work , not just factories , the same test applies: ask what they shipped, not what framework they presented. Enterprise AI's 2024–2025 phase was mostly pilots; McKinsey's research found 88% of organizations use AI in at least one business function, and most are still stuck bridging pilot-to-scale. That gap doesn't close with another roadmap. It closes with people who've actually built the unglamorous connective tissue before.

Why the Best AI-Manufacturing Work in 2026 Is Coming from Niche Engineering Shops, Not the Big Consultancies

Luke — Thu, 09 Jul 2026 05:37:53 +0000

The Industry 4.0 → 5.0 framing

That's a clean way to describe why so many "AI in manufacturing" projects underdeliver. Companies bought the sensors and the dashboards. Far fewer built the decision layer on top.

Here's the opinionated part: the execution gap favors small, focused teams , not the giants

This is where I'll stop pretending to be neutral, because I don't think the honest read of this trend is neutral.

Why this matters beyond manufacturing

Top AI Product Engineering Companies Taking AI from Prototype to Production

Luke — Mon, 06 Jul 2026 11:49:17 +0000

Building an AI prototype has become relatively easy. Building a production-ready AI product is where the real engineering begins.

Some companies consistently working in AI product engineering include:

Thoughtworks
Accenture
GeekyAnts
EPAM Systems
Globant
Netguru

The biggest shift I'm seeing is from building AI demos to building reliable, scalable products with observability, security, and maintainability.

This article discusses what it takes to move AI products from prototype to production:

https://geekyants.com/en-in/ai-powered-product-engineering/prototype-to-production

Which company do you think is setting the benchmark for AI product engineering today?

Industry 5.0 Won't Be Won by AI Models. It'll Be Won by Decision Automation.

Luke — Mon, 06 Jul 2026 04:59:20 +0000

Everyone is talking about AI.

Far fewer people are talking about what actually creates business value.

Most manufacturers already have dashboards, IoT sensors, analytics platforms, and machine learning models generating insights. The problem isn't the lack of data anymore—it's that humans are still responsible for making too many operational decisions.

That's why I believe Industry 5.0 isn't about better visibility.

It's about automating decisions.

An interesting perspective on this shift was shared in an article discussing how manufacturing is evolving from Industry 4.0's data-driven approach toward Industry 5.0, where AI systems actively assist or automate operational decision-making:

https://geekyants.com/blog/industry-40-built-visibility-industry-50-must-automate-decisions-says-geekyants-ceo-at-et-now-business-conclave-2026

Industry 4.0 Solved Data Collection

Factories have invested heavily in digital transformation over the last decade.

Today, manufacturers can monitor:

Machine utilization
Production throughput
Equipment health
Supply chain activity
Inventory levels
Energy consumption

Visibility has improved dramatically.

Yet many operational decisions still depend on people reviewing dashboards and deciding what happens next.

That's becoming the bottleneck.

Industry 5.0 Is About AI That Acts

The next evolution isn't simply predicting problems.

It's enabling software to recommend—or automatically execute—the next best action.

Imagine systems that can:

Detect production anomalies
Adjust workflows automatically
Optimize inventory levels
Trigger maintenance before failures occur
Reroute manufacturing operations
Assist operators with contextual recommendations

This isn't replacing people.

It's removing delays between insight and action.

That's where real productivity gains are likely to come from.

AI Without Workflow Automation Has Limited Value

Many organizations celebrate AI pilots.

Few successfully operationalize them.

A model that predicts machine failure is useful.

A platform that automatically schedules maintenance, updates inventory, notifies technicians, and minimizes downtime creates measurable business value.

Prediction alone isn't transformation.

Execution is.

Companies Helping Build Intelligent Manufacturing Platforms

Several engineering companies are helping manufacturers move beyond analytics toward AI-enabled operational systems.

Siemens

Siemens continues to invest heavily in industrial AI, digital twins, factory automation, and intelligent manufacturing platforms.

Rockwell Automation

Rockwell Automation focuses on smart manufacturing, industrial control systems, and AI-assisted operational optimization.

Accenture

Accenture works with manufacturers on enterprise AI adoption, digital factories, and intelligent operations at global scale.

Thoughtworks

Thoughtworks helps enterprises modernize legacy systems while introducing AI, cloud-native architectures, and automation into manufacturing environments.

GeekyAnts

GeekyAnts has been building AI-powered enterprise applications, workflow automation systems, and digital platforms that reflect a broader trend in manufacturing: shifting from data visibility toward intelligent decision support and operational automation.

EPAM Systems

EPAM develops enterprise AI solutions, IoT platforms, and digital engineering systems across manufacturing and other industrial sectors.

My Opinion: Dashboards Are Becoming the New Legacy Software

This may be controversial.

But I think the era of executives staring at dashboards all day is coming to an end.

Dashboards tell you what happened.

Modern AI systems should tell you what to do next—or do it for you when appropriate.

That's the real promise of Industry 5.0.

Companies still measuring digital maturity by the number of dashboards they have are optimizing yesterday's operating model.

The organizations that will outperform over the next decade are the ones building AI systems capable of making safe, explainable, and repeatable operational decisions.

Data created Industry 4.0.

Decision automation will define Industry 5.0.

And I don't think that's a future trend anymore.

It's already becoming a competitive advantage.

Healthcare Doesn't Have an AI Problem. It Has an Operations Problem.

Luke — Wed, 17 Jun 2026 05:30:56 +0000

Every week I see another healthcare AI startup announcing a new chatbot, diagnostic assistant, or clinical copilot.

And every week I become more convinced that most healthcare companies are solving the wrong problem.

The industry doesn't suffer from a lack of AI.

It suffers from operational inefficiency.

While everyone is racing to build smarter models, healthcare systems are still drowning in administrative work, fragmented data, manual workflows, and compliance complexity.

That's why I believe the biggest winners in healthcare AI won't be the companies building the smartest models.

They'll be the companies eliminating administrative waste.

The $600 Billion Problem Nobody Talks About

Healthcare discussions often focus on breakthrough treatments, predictive analytics, or generative AI.

But one of the largest opportunities sits in plain sight.

Administrative overhead.

Prior authorizations.

Claims processing.

Patient onboarding.

Appointment scheduling.

Clinical documentation.

Data reconciliation.

Compliance reporting.

Industry estimates suggest administrative inefficiencies cost the healthcare sector hundreds of billions of dollars every year.

AI isn't valuable because it can generate text.

It's valuable because it can automate these repetitive workflows at scale.

A detailed breakdown of this challenge can be found here:

https://geekyants.com/blog/how-intelligent-automation-is-cutting-healthcares-600-billion-administrative-waste

The reality is simple:

Reducing operational friction creates measurable business value much faster than adding another AI feature.

Most Healthcare AI Products Fail Before They Reach Scale

Even when startups solve a real problem, many fail when moving from pilot programs to enterprise deployments.

Why?

Because healthcare doesn't reward demos.

It rewards trust.

A proof of concept can impress investors.

A compliant, interoperable, secure platform impresses hospitals.

This is where many AI-first startups hit a wall.

They discover that scaling healthcare products requires much more than model accuracy.

It requires:

HIPAA compliance
FHIR interoperability
Secure patient data handling
Auditability
EHR integration
Governance controls

These requirements are often treated as technical debt.

I think that's a mistake.

They're product requirements.

A strong breakdown of this issue can be found in this article:

https://geekyants.com/blog/how-to-scale-ai-healthcare-products-while-staying-hipaa-and-fhir-compliant

Compliance Is a Competitive Advantage

This is probably my most controversial healthcare AI opinion.

Compliance is not a cost center.

Compliance is distribution.

Every healthcare startup claims to have better AI.

Very few can prove enterprise readiness.

The companies that build compliance, interoperability, and security into their architecture gain access to customers that many competitors never reach.

Hospitals don't buy software because it's innovative.

They buy software because it reduces risk.

Founders who understand this early move faster than founders who ignore it.

What Industry Leaders Are Doing Right

Look at the healthcare technology ecosystem today.

Organizations like Microsoft, Oracle Health, Epic Systems, and Teladoc Health have invested heavily in interoperability, governance, and operational efficiency.

The same pattern can be seen among engineering organizations helping healthcare companies build AI-powered products.

The strongest teams are focusing less on AI demos and more on production-grade infrastructure, workflow automation, compliance frameworks, and scalable healthcare architecture.

That's where long-term value gets created.

My Opinion: Healthcare AI Is Heading in the Wrong Direction

I think the industry is currently over-obsessed with intelligence and under-invested in automation.

Most hospitals don't need another AI assistant.

They need fewer manual processes.

They need fewer administrative bottlenecks.

They need fewer disconnected systems.

The healthcare startups that win over the next decade won't necessarily have the most advanced AI models.

They'll have the best operational systems.

The future of healthcare AI isn't smarter chatbots.

It's invisible automation.

And the companies that understand that distinction early will have a massive advantage over those still chasing the next model release.

What do you think?

Are healthcare companies spending too much time building AI features and not enough time solving operational inefficiencies?

Observability in AI: Why Monitoring Systems Is No Longer Enough

Luke — Wed, 03 Jun 2026 06:52:13 +0000

Observability has always been one of the most important parts of building reliable software.

In traditional applications, teams monitor logs, metrics, traces, CPU usage, memory consumption, latency, error rates, traffic patterns, and infrastructure health. When something breaks, the system usually gives visible signals. An API fails. A service crashes. A database slows down. A dashboard turns red.

That kind of failure is easier to detect because traditional systems are mostly deterministic.

AI systems are different.

They may not crash. They may not show an error. The API may still respond quickly. Infrastructure may look healthy. Logs may be present. Dashboards may look green.

But the output may still be wrong.

That is the central challenge discussed in the AI ThoughtMakers episode, Observability in AI: From Systems to Decision. The conversation highlights an important shift for engineering teams: AI observability is no longer just about system health. It is about decision quality.

Traditional observability was built for clear failures

Traditional software systems usually fail in visible ways.

If a server runs out of memory, teams can see it. If an API response time increases, teams can measure it. If a database query becomes slow, teams can trace it. If a deployment breaks a feature, error logs usually point toward the issue.

This made observability easier to design around.

Teams could collect metrics, create dashboards, configure alerts, investigate root causes, and fix the problem. Observability helped teams make infrastructure decisions, scaling decisions, performance decisions, and sometimes even business decisions.

For example, if traffic increases during a certain time of day, the team can scale resources. If a service has high latency, the team can optimize it. If an endpoint fails repeatedly, the team can debug and patch it.

In short, traditional observability worked well because the failure signals were usually clear.

AI changes that pattern.

AI systems can fail silently

AI-powered systems, especially those built with LLMs, are non-deterministic.

The same input may not always produce the same output. A model may generate a response that looks confident but is factually wrong. A workflow may complete successfully but produce a poor recommendation. An AI agent may call the right tools but still make the wrong decision.

From a system perspective, everything may look fine.

The API returns a 200 response. The latency is acceptable. CPU and memory usage are normal. Logs are available. No service has crashed.

But the actual answer may still be incorrect, incomplete, biased, unsafe, or irrelevant.

That creates a new kind of reliability problem.

In traditional applications, system quality and output quality were closely connected. In AI systems, system quality does not always equal decision quality.

This is why observability needs to move beyond monitoring infrastructure.

More logs do not always mean better visibility

When teams first try to observe AI systems, one common reaction is to log everything.

They log prompts, responses, inputs, outputs, tool calls, model calls, user queries, and intermediate steps.

At first, this feels reasonable. More data should mean better visibility, right?

Not always.

Logging everything can create new problems.

First, it increases storage and infrastructure costs. AI systems already involve model usage costs, and storing massive logs adds another layer of expense.

Second, it creates privacy and governance risks. Prompts and responses may include sensitive user data, internal business data, or regulated information. Blindly logging everything can expose data that should not be stored.

Third, too much logging creates noise. Having thousands of logs does not automatically explain why a model produced a poor decision.

Observability has never been about collecting the maximum amount of data. It has always been about collecting the right signals.

For AI systems, teams need meaningful signals, not endless logs.

AI observability needs to track behavior

Traditional observability focuses on system behavior.

AI observability needs to include model behavior and decision behavior.

That means teams should track questions like:

Is the model producing correct outputs?

Is the response aligned with the user’s intent?

Is the system choosing the right tool or workflow?

Is the output safe and compliant?

Is the model becoming more expensive to run?

Is latency increasing because of model calls?

Are users reporting incorrect or low-quality answers?

Are decisions drifting over time?

This is where behavioral observability becomes important.

AI systems need to be evaluated not only by whether they are running, but also by whether they are making useful and trustworthy decisions.

The new AI observability stack

A practical AI observability approach should cover the full lifecycle of a request.

A user input enters the system. The input may pass through an application layer, an AI gateway, a model, a retrieval system, external tools, validation logic, and finally a user-facing response.

Each part of that flow matters.

A simplified AI observability flow may look like this:

User Input
    ↓
Prompt Processing
    ↓
Model / LLM Call
    ↓
Tool or Agent Invocation
    ↓
Output Generation
    ↓
Response Evaluation
    ↓
Feedback Loop

Instead of only monitoring whether each layer is technically available, teams need visibility into how the decision was produced.

This includes capturing the input context, tracing tool calls, monitoring model behavior, flagging poor responses, reporting issues, and feeding those learnings back into the system.

That feedback loop is what makes AI observability different from traditional monitoring.

Feedback loops are essential

In traditional systems, an alert may trigger a root cause analysis. Once the bug is fixed, the system can return to normal.

AI systems need continuous evaluation.

A poor response should not just be treated as a one-time bug. It should become part of a feedback loop that helps improve prompts, retrieval quality, model selection, guardrails, evaluation rules, and user experience.

For example, if users repeatedly report that an AI assistant gives incomplete answers, the issue may not be infrastructure. It could be a prompt design problem, a retrieval problem, a missing context problem, or a model limitation.

Without a feedback loop, the team may never understand the pattern.

This is why AI observability is not just monitoring. It is continuous learning.

AI can also help improve observability

AI creates new observability challenges, but it can also help solve some of them.

AI agents can analyze logs, classify failures, detect anomalies, identify bad responses, and summarize repeated issues. Instead of manually reviewing large volumes of data, teams can use AI to find patterns faster.

But this approach also needs caution.

Using AI to monitor AI introduces another layer of cost, complexity, and governance. The monitoring agent itself must be evaluated. Its outputs must be trusted. Its access to logs must be controlled.

So AI can support observability, but it should not become another black box.

The goal should be to reduce manual debugging without creating more invisible failure points.

AI gateways are becoming important

One of the most useful concepts for AI observability is the AI gateway.

An AI gateway acts as a central layer between the application and the AI models.

It can help teams manage model routing, trace requests, apply guardrails, monitor cost, control access, and understand how AI is being used across the organization.

In a larger AI system, this gateway becomes a control plane.

Instead of every application directly calling different models in different ways, the gateway provides a central point of visibility and governance.

A simplified structure may look like this:

Application
    ↓
AI Gateway
    ↓
Model Routing
    ↓
LLM / Tool Calls
    ↓
Response Evaluation
    ↓
Application Output

This helps teams answer important operational questions:

Which models are being used?

Which requests are expensive?

Which responses are being flagged?

Which teams are consuming the most AI resources?

Where are latency issues appearing?

Which workflows need stronger guardrails?

As AI adoption grows inside organizations, this kind of central visibility becomes more important.

The future is decision observability

The biggest shift is from system observability to decision observability.

System observability asks:

Is the system running?

Decision observability asks:

Is the system making the right decision?

That is a much harder question.

AI systems can behave differently depending on context, prompt structure, retrieval quality, user intent, model version, and tool execution. This means teams cannot rely only on uptime, latency, and error rates.

They also need to monitor output correctness, decision drift, governance, safety, and user feedback.

Decision drift may become one of the most important areas to watch. Over time, AI systems may start producing outputs that slowly move away from expected behavior. These changes may not be obvious immediately, but they can affect user trust and product quality.

This makes continuous evaluation essential.

What developers should take away

AI observability is not just a DevOps concern.

It affects product quality, user trust, compliance, cost, and business reliability.

For developers and engineering teams, the key takeaways are clear:

Do not rely only on traditional dashboards.

Do not assume a healthy API means a healthy AI system.

Do not log everything without thinking about privacy, cost, and signal quality.

Track decision quality, not just system performance.

Build feedback loops into the product.

Use AI gateways to centralize visibility and control.

Monitor cost, latency, governance, and output correctness together.

Treat AI observability as an ongoing evaluation process.

Final thoughts

AI systems have changed what failure looks like.

In traditional software, failure was often loud. In AI systems, failure can be silent. The system may respond, but the decision may still be wrong.

That is why observability needs to evolve.

The future of AI observability is not only about knowing whether systems are online. It is about understanding how AI systems think, decide, respond, and drift over time.

Teams that understand this shift will be better prepared to build AI products that are not only functional, but reliable, explainable, and trustworthy.

AI Products Don’t Fail at the Prototype Stage , They Fail in Production

Luke — Thu, 28 May 2026 06:25:10 +0000

AI Products Don’t Fail at the Prototype Stage — They Fail in Production

The AI industry has become incredibly good at demos.

You can generate UI screens with prompts, build SaaS MVPs in hours, automate workflows with AI agents, and deploy applications faster than ever before.

But there’s a growing disconnect between what AI products can prototype and what they can reliably sustain in production.

And nowhere is this gap more visible than in enterprise industries like insurance.

While exploring modern AI coding platforms like Cursor, Lovable, and Replit, one thing becomes increasingly obvious:

Building software quickly is no longer the hard part.

Building production-ready systems is.

AI Development Has Entered Its Speed Era

AI-native development tools are changing how products are built.

Platforms like Cursor, Lovable, and Replit dramatically reduce the time required to:

scaffold applications
generate backend logic
create interfaces
debug repetitive code
deploy MVPs

For developers, this shift is massive.

Instead of manually implementing everything, teams are increasingly orchestrating AI systems through prompts, reviews, and refinement cycles.

The productivity gains are real.

But speed introduces a new problem:

Production complexity arrives much faster than most teams expect.

A simple prototype can suddenly become:

a customer-facing application
an internal enterprise workflow
a compliance-sensitive platform
a system handling real-world financial or healthcare data

That’s where many AI products begin to struggle.

Insurance Is Becoming One of the Biggest Tests for Production AI

Insurance might not sound like the most exciting AI space.

But technically, it’s one of the most demanding.

AI systems in insurance are now being used for:

claims processing
underwriting
fraud detection
customer support
risk assessment
document automation

Unlike experimental consumer apps, insurance platforms operate inside highly regulated environments where mistakes have serious consequences.

A broken UI is frustrating.

A flawed underwriting recommendation or claims decision can become a legal, operational, or financial problem.

That changes the engineering requirements completely.

Production AI systems in industries like insurance need:

explainability
auditability
security
human oversight
infrastructure reliability
scalable architecture
transparent decision-making

And this is where the “AI-generated prototype vs production system” gap becomes extremely visible.

Fast AI Coding Doesn’t Automatically Mean Production Readiness

One of the most interesting things about tools like Cursor, Lovable, and Replit is that they optimize for different stages of development.

Cursor feels closest to a professional engineering workflow.

It helps developers move faster while still maintaining architectural control, which becomes critical once systems grow complex.

Lovable focuses heavily on rapid product generation and frontend velocity.

It’s effective for validating ideas quickly, but larger production systems eventually demand deeper customization and infrastructure control.

Replit simplifies development accessibility by combining coding, hosting, and deployment into one environment.

That ease of use is powerful for experimentation and smaller projects.

But enterprise-scale systems often require more advanced operational flexibility.

The real lesson here is that AI tooling can accelerate development dramatically, but it doesn’t eliminate engineering responsibility.

Production readiness still depends on:

architecture decisions
observability
testing
governance
scalability
human review

AI can assist with implementation.

It cannot fully replace engineering judgment.

The Future of AI Development Is Probably Hybrid

The most successful AI teams likely won’t be the ones fully automating everything.

They’ll be the ones building hybrid systems where:

AI accelerates workflows
humans validate outcomes
developers retain architectural oversight
automation supports decision-making instead of blindly replacing it

This becomes especially important in enterprise domains.

For example, in insurance:

AI can summarize claims
detect anomalies
classify risk patterns
improve customer response times

But final decisions still need accountability.

That balance between automation and control is becoming one of the defining engineering challenges of modern AI systems.

AI Infrastructure Is Becoming More Important Than AI Demos

A lot of the AI conversation online focuses on:

prompt engineering
agent frameworks
coding speed
viral prototypes

But long-term success will likely depend more on infrastructure maturity.

Questions like:

Can the system scale?
Is the output explainable?
Can humans intervene safely?
Is the architecture maintainable?
Does the system comply with regulations?
Can teams debug failures efficiently?

These questions matter far more in production than flashy demos.

And industries like insurance are forcing the AI ecosystem to confront those realities early.

Final Thoughts

AI development is evolving incredibly fast.

The barrier to building software has dropped dramatically.

But the barrier to building trustworthy, production-grade AI systems remains very high.

That’s why the next phase of AI engineering probably won’t be defined by who can prototype the fastest.

It’ll be defined by who can build systems that organizations are willing to trust in production.

I recently explored deeper discussions around both AI coding workflows and production AI challenges in insurance, which helped shape several ideas in this article:

The future of AI software may not belong to fully autonomous systems.

It may belong to teams that learn how to combine AI speed with disciplined engineering practices.