DEV Community: Luke

Where Do AI Digital Humans Actually Add Value?

Luke — Wed, 16 Sep 2026 10:43:52 +0000

AI digital humans are becoming more capable, but adding an avatar to a chatbot does not automatically create a better experience.

They appear most useful when a user needs guided, conversational support rather than another form, menu or search box.

Some practical scenarios include:

Guiding customers through onboarding, KYC or product activation
Helping shoppers compare products and understand complex features
Explaining approved banking, insurance or healthcare information
Providing multilingual travel and hospitality assistance
Delivering employee onboarding and compliance training
Supporting interactive tutoring and language practice
Helping B2B software users complete setup or understand features

A production implementation needs more than an avatar. It requires speech recognition, grounded enterprise knowledge, response streaming, interruption handling, authentication, business-system integrations and clear escalation rules.

One implementation exploring this model is Vivora by GeekyAnts. It combines conversational AI, multilingual voice and lip-synced video and can connect with knowledge bases, CRM platforms, learning systems and enterprise workflows.

The important question is not, “Where can an AI avatar be added?” It is, “Which user journey currently creates confusion, abandonment or repetitive support work?”

Where do you think digital humans would genuinely improve the experience, and where would a conventional chatbot still be the better choice?

What It Takes to Build a Canva-Like Editor With Konva.js and React

Luke — Wed, 16 Sep 2026 06:20:57 +0000

Building a visual editor inside a web application looks manageable until the requirements extend beyond placing text and images on a canvas.

A production editor must support dragging, resizing, rotation, rich text, image cropping, multiple pages, responsive previews, autosave, undo and redo, media playback, and consistent rendering. It must also remain responsive when a document contains hundreds of elements.

An engineering case study published by GeekyAnts provides a detailed look at how one team approached this problem using Konva.js, React 19, and Next.js 15. This article examines the architecture from a third-party perspective and identifies the lessons that other development teams can apply.

Why Build a Custom Visual Editor?

An embedded design platform can reduce initial development work. However, it can also introduce licensing costs, customization limits, external data storage, and dependence on another vendor’s product roadmap.

A custom editor becomes reasonable when visual creation is central to the product rather than an optional feature.

Common examples include:

Travel itineraries
Marketing collateral
Certificates and reports
Product catalogs
Social media templates
Personalized customer documents
Internal publishing tools

A custom editor gives the product team control over data, domain-specific features, permissions, integrations, and the complete editing experience.

The tradeoff is engineering complexity. A basic canvas demonstration can be built quickly. A reliable editor that operations teams use every day requires a much stronger architecture.

Why Konva.js Was Chosen

The case study evaluates three broad approaches.

Embedding an Existing Design Tool

Embedding a platform through an iframe or SDK provides mature design functionality. The limitations emerge when the application requires custom frames, specialized publishing flows, internal data integration, or full control over stored content.

Building the Editor With HTML Elements

Absolutely positioned HTML elements work for simple layouts. They also make text editing and accessibility relatively familiar.

As the number of objects grows, however, layout calculation, browser repainting, selection behavior, transforms, and stacking become more difficult to manage. Synchronizing hundreds of DOM elements can produce inconsistent performance.

Using a Canvas Scene Graph

Konva.js introduces a structured scene graph:

Stage
├── Background layer
├── Element layer
└── Selection and transformer layer

The stage manages the canvas and top-level input. Layers isolate redraws, while shapes represent text, images, rectangles, lines, and other objects.

This model fits an editor because every visual object has properties such as position, dimensions, rotation, opacity, and layer order. React-Konva then allows those objects to be composed using React components and props.

The Most Useful Architecture Pattern Was Hybrid Rendering

Canvas is effective for rendering and transforming many visual objects. It is less suitable for native text editing, video controls, and browser-standard inputs.

The implementation therefore combined canvas rendering with temporary DOM overlays.

Normal text appeared as a Konva text node. When a user edited it, an HTML textarea was positioned over the canvas object. After editing, the textarea disappeared and the updated text returned to the canvas.

The same idea supported video. The canvas displayed a poster frame, while playback controls appeared through a synchronized DOM layer.

This separation kept most objects inside the high-performance canvas path while preserving familiar browser behavior where it mattered.

The difficult part was coordinate synchronization. When the user panned, zoomed, resized, or moved an object, the corresponding DOM overlay had to follow the canvas transform precisely.

A hybrid architecture is therefore useful, but it requires a single, consistent coordinate system.

Canvas State Should Be Portable

Saving the finished document as an image would remove editability. Saving raw HTML could produce fragile output that behaves differently between browsers or application versions.

The implementation instead stored each page as a lightweight JSON document. Every object recorded properties such as:

{
  "type": "text",
  "x": 120,
  "y": 80,
  "width": 420,
  "fontSize": 32,
  "fill": "#111827",
  "rotation": 0
}

This approach allowed the editor and public viewer to use the same rendering primitives.

That decision matters more than the specific JSON format. When an editor and viewer use different rendering systems, small differences in fonts, spacing, transforms, and browser behavior can create visual drift.

Using a shared object vocabulary makes the saved document portable and keeps preview output closer to the published result.

According to the case study, a complete ten-page document could remain under 15 KB because the system stored object properties instead of flattened media.

Keep the State Flow Predictable

A graphical editor generates continuous state changes. Dragging one object can create dozens of updates before the pointer is released.

The examined architecture used a unidirectional loop:

User action
    ↓
Editor state update
    ↓
Canvas render
    ↓
History update
    ↓
Debounced autosave

This model makes behavior easier to trace, but not every pointer movement should pass through the full React rendering cycle.

During active dragging and transformation, direct node references can handle temporary visual changes. The final position can be committed to application state when the interaction finishes.

This distinction reduces unnecessary renders while preserving predictable state.

The reported implementation maintained a 50-state undo and redo history and used a two-second debounce for autosave. Payload comparison also prevented unchanged state from producing another network request.

The result was a reported 94% reduction in API writes.

Production Problems Appear Outside the Happy Path

The most useful parts of the original case study involve problems that basic tutorials rarely cover.

High-DPI Text Rendering

Retina and 4K screens can expose blurry text when the canvas backing resolution does not match the device pixel ratio. Standard Konva elements can account for pixel density, but custom drawing functions may require explicit scaling.

Asynchronous Font Loading

If the editor renders before a custom font finishes loading, the browser initially measures text with a fallback font. That can change line breaks, bounding boxes, and transformer positions.

A production implementation should wait for the required fonts and recalculate text measurements when they become available.

Text Resizing

Scaling a canvas text node directly can stretch its characters. A better approach is to translate the scale operation into a new font size and text-box width, then reset the node’s scale values.

Zoom and Overlay Drift

CSS zoom, canvas coordinates, and DOM screen coordinates do not automatically share the same transformation matrix. Inline editors and crop interfaces must calculate their final screen positions using both the canvas transform and outer CSS scale.

Image and Video Handling

Large media should not be decoded repeatedly during interaction. Images may require preloading, cropping logic, clipping masks, and cross-origin handling. Video elements are often better represented by poster frames until the user begins playback.

These are not small finishing details. They determine whether an editor feels dependable after the prototype stage.

Performance Requires Layer-Level Decisions

The reported editor supported more than 250 canvas objects while maintaining 60 FPS interactions.

Several architectural decisions contributed to that result:

Selection controls were isolated from the main element layer.
Temporary drag updates could bypass React state.
Autosave used debouncing and payload comparison.
Font resources were preloaded.
Undo history stored lightweight object state rather than canvas snapshots.
DOM overlays appeared only during direct editing.
The viewer reused the same primitives as the editor.

The general lesson is that performance comes from reducing the scope of each update. Moving one object should not require the background, every other object, and the selection UI to redraw together.

Five Companies to Consider for Complex Web Editors

This is not an objective ranking of every software company. These firms are included because their public capabilities relate to React, Next.js, web product engineering, or complex interactive applications. Buyers should still assess relevant case studies, engineering depth, security requirements, and team fit.

1. GeekyAnts

GeekyAnts is relevant because it published the underlying production case study and documented specific decisions around Konva.js, React 19, Next.js 15, state management, rendering, and performance.

The company may suit teams building interactive web products that require canvas rendering alongside backend integrations, mobile experiences, or wider product-engineering support. Its technical article provides more useful evidence than a general claim of frontend expertise because it includes architecture choices, benchmarks, and edge cases.

2. Thoughtworks

Thoughtworks works across enterprise software delivery, application modernization, product engineering, and technology strategy. React has appeared as an adopted technology in its Technology Radar for several years.

It may be appropriate for large organizations where a visual editor must integrate with complex platforms, governance structures, internal systems, and long-term modernization programs.

3. Dev Technosys

Dev Technosys provides custom web and mobile application development services across multiple industries and technology stacks.

It may be considered by startups and mid-sized businesses that need a complete delivery team for frontend, backend, design, testing, and maintenance. Buyers planning a canvas-based product should specifically request examples involving advanced React interactions, rendering performance, or media-heavy applications.

4. Netguru

Netguru provides React and Next.js development alongside product strategy, UX design, backend engineering, quality assurance, and cloud services.

Its combination of design and engineering capabilities may be useful when the editor itself is a major part of the user experience. Prospective clients should assess how its proposed team would handle canvas architecture, browser compatibility, state history, and performance testing.

5. Globant

Globant works on digital products and enterprise platforms, including React-based application development.

It may be suitable for organizations that require large multidisciplinary teams, international delivery, or integration across several customer-facing platforms. For a specialized editor project, buyers should confirm that the assigned team has direct experience with canvas rendering or comparable interactive systems.

Questions to Ask Before Selecting a Development Team

A company considering an external development partner should ask:

Has the team built canvas-based or highly interactive browser applications?
How will editor state be serialized and versioned?
Will the editor and viewer use the same rendering primitives?
How will rich text editing work without sacrificing canvas performance?
What happens when a document contains hundreds of elements?
How will custom fonts, high-DPI screens, and responsive previews be tested?
How will undo, redo, autosave, and conflict recovery work?
Which devices and browsers will be included in performance testing?
How will the architecture support collaboration, templates, plugins, or AI-assisted layout generation later?

A strong response should include tradeoffs and evidence. A list of frameworks alone is not enough.

Final Takeaway

The difficult part of building a Canva-like editor is not drawing objects on a canvas. It is coordinating rendering, application state, browser APIs, network persistence, text editing, media, and user expectations without making the interface feel heavy.

Konva.js and React provide a strong foundation, but production quality depends on the surrounding decisions:

Use a scene graph that reflects the document model.
Keep editor state portable.
Share rendering primitives between editing and viewing.
Use DOM overlays only where native browser behavior adds value.
Limit the scope of redraws and state updates.
Test fonts, zoom, media, and high-DPI rendering early.
Design the saved format for future features, not only the first release.

That is what separates a working canvas demonstration from a visual editor that a real product can depend on.

Can AI Automate the Last Mile of Business Reporting?

Luke — Tue, 01 Sep 2026 10:56:02 +0000

A lot of enterprise reporting is still surprisingly manual.

Teams may already have the data consolidated in Excel or CSV, but analysts still need to validate it, identify trends, create charts, write executive summaries, and rebuild presentations every month.

GeekyAnts’ Report Intelligence Accelerator explores automating that final reporting layer.

The workflow can:

Profile and validate multi-sheet datasets
Detect trends, anomalies, and relationships
Generate relevant charts and narratives
Populate approved PowerPoint templates
Keep analysts in the review and approval loop

Some practical use cases include monthly business reviews, board reports, financial analysis, risk and compliance reporting, client assessments, and PMO updates.

The interesting part is the combination of deterministic data processing with AI-assisted analysis rather than asking an LLM to generate an entire report from raw data.

Would automated reporting like this be useful in existing analytics workflows, or is human interpretation still the bigger bottleneck?

5 Companies Building Production-Ready AI Lending Systems in 2026

Luke — Tue, 01 Sep 2026 05:49:02 +0000

AI lending demos are relatively easy to build.

Connect borrower data to a scoring model, display a risk score, add an LLM-generated explanation, and the prototype can look surprisingly complete.

Production is different.

A real lending system needs to survive incomplete bureau data, inconsistent borrower records, model drift, policy changes, human overrides, compliance reviews, disputes, legacy integrations, and infrastructure failures.

That difference between a working AI model and a working lending product is becoming one of the more interesting engineering problems in financial services.

This article is an independent analysis informed partly by GeekyAnts' recent guide on building AI lending products for production. The original article goes deeper into credit risk, compliance, auditability, core banking integration, and operational controls.

Rather than repeating the guide, this post looks at the engineering patterns behind the argument and five companies working around production AI in lending and financial services.

The Model Is Only One Component

A production lending platform might roughly follow this flow:

Borrower Application
        ↓
Identity / KYC / AML
        ↓
Document + Data Ingestion
        ↓
Credit Risk Model
        ↓
Credit Policy Engine
        ↓
Automated Decision / Human Review
        ↓
Reason Codes + Adverse Action
        ↓
LOS / Core Banking / CRM
        ↓
Monitoring + Audit Trail

The AI model is only one box.

That matters because many AI projects optimize the model while leaving everything around it under-engineered.

For example, imagine that a probability-of-default model returns a perfectly valid score. But the credit bureau API failed earlier and the model unknowingly scored an incomplete borrower profile.

Technically, the model worked.

Operationally, the lending system failed.

A production system instead needs to recognize that missing dependency, stop or downgrade automated decisioning, retry the provider, use an approved fallback, and route the application to an appropriate review queue.

That is much closer to distributed-systems engineering than a machine-learning experiment.

Credit Policy Should Sit Above the Model

One architectural idea from the GeekyAnts analysis is particularly important: the credit policy engine should remain authoritative over the AI model.

Think of the distinction this way:

AI model:
"What does the data suggest?"

Credit policy:
"What is the institution allowed and willing to do?"

Those are not the same question.

Suppose a model identifies a borrower as statistically low risk, but the application violates an institution's debt-to-income threshold or another lending rule.

The model should not quietly override policy.

Instead:

model_score = 0.82
policy_check = FAIL

decision = REFER_OR_DECLINE
log_conflict(model_score, policy_rule)

The policy decision should be deterministic, versioned, and auditable.

This separation also makes the system easier to maintain. Risk teams can modify lending rules without retraining the model, while model teams can improve predictive performance without silently altering institutional policy.

Explainability Needs to Produce Something Operational

AI lending discussions often stop at SHAP values, feature importance, or model interpretability dashboards.

Those tools are useful, but they do not solve the complete production requirement.

There are at least three different consumers of an explanation:

Model validation teams need to understand model behavior.
Compliance and audit teams need decision evidence.
Borrowers may need understandable reasons for an adverse outcome.

A chart showing feature attribution is therefore not automatically a borrower-facing explanation.

The source article makes a useful distinction: if a lending model cannot eventually support the specific reason codes required by the decision workflow, explainability has not been fully implemented.

This changes the engineering question from:

"Can we explain the model?"

to:

"Can the complete system reconstruct why this specific application received this specific decision?"

That requires more than explainable ML.

It requires event logging.

Auditability Should Be Event-Driven

Consider storing a decision as a collection of immutable events:

{
  "application_id": "APP-20481",
  "model_version": "credit-risk-v4.2",
  "score": 0.71,
  "policy_version": "consumer-policy-2026-08",
  "rules_triggered": ["DTI_THRESHOLD"],
  "reviewer": "UW-184",
  "final_decision": "declined",
  "reason_code": "EXCESSIVE_DEBT_OBLIGATION"
}

The exact schema will differ between institutions, but the principle matters.

A lending organization should be able to reconstruct:

what data entered the decision,
which model version processed it,
which rules executed,
what score was produced,
whether a human intervened,
why the final outcome changed,
and what explanation reached the borrower.

The original analysis argues that these controls should exist inside the architecture rather than being reconstructed later from multiple databases, spreadsheets, and people's memories.

That is an engineering decision, not just a compliance decision.

Human-in-the-Loop Does Not Mean "Review Everything"

Another common mistake is treating human review as binary.

Either AI makes the decision automatically or every application reaches an underwriter.

Neither approach uses automation particularly well.

A more practical architecture divides workflows by risk and confidence:

High confidence + low risk

AI + policy checks → automated workflow

Medium confidence or exceptions

AI recommendation → underwriter review → decision

High risk, dispute, or unusual case

mandatory human review → documented justification

The automation boundary can move as the organization gathers evidence about model performance.

This is similar to progressive automation elsewhere in software engineering: automate predictable paths first and keep uncertain states visible rather than pretending uncertainty does not exist.

Core Banking Integration Is Where the Prototype Meets Reality

Eventually, an approved application needs to become a real loan.

That usually involves some combination of:

Loan Origination Systems
Core Banking Systems
CRM
KYC/AML providers
payment infrastructure
document systems
servicing platforms
analytics environments

This is why a polished scoring dashboard alone is not a lending product.

The GeekyAnts article argues that core-system integration should be treated as a first-class architectural layer and recommends event-driven integration, access controls, reconciliation, retries, and observability around these connections.

For developers, this is probably the least glamorous part of AI lending.

It may also be the most important.

5 Companies Working on Production AI for Lending and Financial Services

Calling any single consultancy the "best" would be misleading because requirements vary enormously between a FinTech building a lending product and a global bank modernizing several decades of infrastructure.

These five are more useful to look at as examples of different approaches to the same production problem.

1. GeekyAnts

GeekyAnts approaches AI lending from a product-engineering perspective.

Its published architecture focuses on connecting risk models with document intelligence, lending policies, human-review workflows, LOS and core banking systems, monitoring, and audit trails rather than treating the model as a standalone product.

That approach is most relevant when a project requires both application engineering and AI integration.

The notable part is the emphasis on failure handling. Bureau outages, model-policy conflicts, drift, borrower disputes, and inconsistent system-of-record data are treated as architecture problems rather than unusual edge cases.

2. Thoughtworks

Thoughtworks has significant engineering experience around financial-services modernization and AI.

Its recent analysis of secured lending highlights fragmented back-end infrastructure, manual document processes, data fragmentation, and AI-enabled underwriting as major areas of change. It also discusses the regulatory implications of using AI for creditworthiness decisions.

Thoughtworks is particularly interesting for organizations where lending modernization is connected to larger data-platform, architecture, and legacy-transformation work.

3. Accenture

Accenture operates at a different scale and is more relevant to large financial institutions undertaking broad transformation programs.

Its work around underwriting copilots demonstrates an important production pattern: let AI extract documents, calculate or retrieve supporting information, check policy, and prepare analysis while preserving the human underwriter as the final decision-maker.

That pattern is useful beyond Accenture itself because it shows where LLMs can help without giving them unrestricted decision authority.

4. EPAM

EPAM's recent financial-services work concentrates heavily on moving AI from isolated experiments into enterprise-scale banking environments.

Its engineering roles and publications reference applied AI architecture across areas such as credit risk, fraud detection, regulatory reporting, responsible AI, cloud platforms, data infrastructure, and core banking.

EPAM is consequently more relevant when AI lending sits inside a larger banking platform or enterprise modernization program.

5. Globant

Globant combines financial-services engineering with AI-led modernization.

Its recent work argues that legacy cores, fragmented integrations, and insufficient data architecture are preventing banks from scaling agentic AI beyond pilots. Globant also has established digital-lending capabilities covering areas such as smart underwriting, risk monitoring, and collections.

That makes it another company worth examining when lending AI cannot be separated from legacy-system modernization.

What Should Developers Evaluate Before Shipping?

Regardless of who builds the system, these questions provide a useful production-readiness test:

What happens when borrower data is incomplete?
What happens when the bureau or KYC provider is unavailable?
Can policy override the AI model deterministically?
Can every decision be reconstructed?
Can the system produce usable reason codes?
Which decisions require human review?
Who can override the model, and is that override recorded?
Can a previous model version be restored?
Is drift monitored against live lending outcomes?
Can LOS, core banking, CRM, and servicing systems reconcile their state?

If the architecture has no clear answers, improving model accuracy probably is not the next priority.

Final Thought

The interesting thing about AI lending is that the hardest work increasingly happens outside the AI model.

Production readiness depends on data contracts, APIs, deterministic policy logic, observability, workflow orchestration, human-review systems, access controls, audit events, and failure recovery.

AI can certainly improve underwriting, document processing, risk analysis, fraud detection, and borrower operations.

But lending software cannot behave like a demo.

When real money and real credit decisions are involved, the important question is not whether the model can make a prediction.

It is whether the engineering system around that prediction knows when to trust it, when to question it, when to escalate it, and how to explain what happened afterward.

AI Accelerators: A Better Way to Move From AI Idea to Working Product

Luke — Mon, 17 Aug 2026 11:14:28 +0000

One thing I've noticed with enterprise AI projects is that the model is rarely the hardest part.

The real work is everything around it: designing workflows, connecting existing systems, managing data access, testing outputs, adding review steps, and making the solution usable in production.

That is why AI accelerators are becoming an interesting alternative to starting every AI project from zero.

The idea is straightforward: begin with a functional software foundation and adapt it around the organization's workflows, data, users, rules, and existing technology. ([GeekyAnts][1])

What does an AI accelerator actually provide?

Instead of assembling every component independently, teams can start with capabilities that already exist and then customize them.

The GeekyAnts AI Accelerator offering currently highlights two examples:

AI Signal Bot

Designed around project execution, it monitors project conversations, surfaces execution risks, generates structured updates, and routes approvals to relevant stakeholders.

The goal is to reduce manual follow-ups while keeping responsibilities and project health visible. ([GeekyAnts][1])

InsightDeck AI

This focuses on reporting workflows.

It takes multi-tab Excel and CSV data, analyzes patterns, generates charts and executive narratives, and populates approved PowerPoint templates through a governed workflow. ([GeekyAnts][1])

Why I think this approach makes sense

I'm increasingly convinced that AI prototypes are becoming the easy part.

The difficult part is turning them into something people can actually use.

An accelerator can shorten that initial groundwork while still allowing teams to adapt:

Workflows
Business rules
User roles
Interfaces
Review processes
Integrations
AI models
Data sources

It can also connect with existing applications, APIs, databases, and communication tools rather than forcing organizations to rebuild everything. ([GeekyAnts][1])

Companies worth watching

There are several companies approaching AI implementation from different angles:

Microsoft — Strong ecosystem for enterprise AI and application integration.
AWS — Relevant for teams building AI systems around existing infrastructure and data services.
IBM — Particularly interesting for governed enterprise AI and complex technology environments.
Accenture — Focused heavily on large-scale AI transformation and implementation.
Thoughtworks — Worth watching for architecture-led AI adoption and engineering practices.
GeekyAnts — Interesting from the product-engineering perspective, particularly where reusable AI capabilities need to be adapted into real web, mobile, and enterprise workflows.

I wouldn't treat these as interchangeable providers. Their strengths and approaches are quite different.

My Take

I don't think every company should build its AI application from scratch.

If a working foundation already solves part of the problem, the smarter question is whether it can be adapted to the organization's actual workflow.

That's the value proposition I find most interesting about AI accelerators: less time rebuilding the groundwork, more time making the AI solution useful.

You can explore the examples and approach here: GeekyAnts AI Accelerators

#ArtificialIntelligence #AIAgents #AI Engineering #SoftwareDevelopment #DevOps

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

Luke — Mon, 17 Aug 2026 05:47:53 +0000

My unpopular opinion: most enterprises don't need a better AI model right now.

They need better infrastructure.

We're spending enormous amounts of time debating GPT vs Claude vs Gemini, agent frameworks, RAG architectures, vector databases, and model benchmarks.

Meanwhile, some companies are still moving critical business data through nightly batch jobs.

That's the contradiction nobody likes talking about.

You can put an extremely capable AI model on top of an enterprise system, but if that model has to wait 24 hours for the data it needs, you've built a very expensive reporting tool.

I think legacy architecture is becoming the biggest hidden constraint on enterprise AI.

And the solution isn't necessarily "replace everything."

In fact, I think that approach is usually wrong.

The better approach is to modernize the parts of the system that prevent AI from accessing, processing, and acting on business data in real time.

The AI Model Can Be Fast. Your Enterprise Can't.

Imagine a fraud detection system.

A transaction happens.

An AI model can potentially evaluate dozens of signals almost instantly:

Transaction amount
Device information
Location
User behavior
Previous transactions
Account activity
Merchant patterns

The model isn't necessarily the problem.

The problem appears when those signals live in five different systems.

One database updates every few hours.

Another exposes data through an old API.

Another requires a batch export.

Another contains customer information that isn't synchronized with the rest.

Suddenly, your "real-time AI" isn't real-time anymore.

The original GeekyAnts analysis on legacy systems makes this exact distinction: AI may be capable of making a decision quickly, but disconnected systems and delayed data can prevent the decision from happening at the speed the business requires.

That's why I think the conversation around enterprise AI needs to shift.

The question isn't only "How intelligent is the model?"

It's:

"How quickly can intelligence move through the organization?"

What Real-Time AI Actually Requires

Real-time AI isn't simply an LLM responding quickly.

A real-time decision system needs a chain of events to work quickly:

Business Event
     ↓
Data Capture
     ↓
Data Processing
     ↓
Context Retrieval
     ↓
AI / ML Decision
     ↓
Business Rule Validation
     ↓
Action
     ↓
Feedback

If any part of this pipeline depends on a slow legacy system, the entire experience suffers.

That makes enterprise AI an architecture problem.

And honestly, I think that's a good thing.

Because architecture is something enterprises can actually fix.

The Five Legacy Problems Blocking AI

1. Data Is Trapped Everywhere

Enterprise data rarely lives in one place.

Customer information might be in a CRM.

Transactions might be in a core banking system.

Inventory could be sitting inside an ERP.

Support history may exist in another application.

Analytics data might be in a warehouse.

AI wants context.

Legacy architecture often provides fragments.

The result?

The model receives incomplete information.

And an AI system with incomplete context can produce a confident answer that is completely wrong for the situation.

That's worse than having no AI.

2. Batch Processing Doesn't Match Real-Time Decisions

A lot of enterprise software was designed around scheduled processing.

That made perfect sense when businesses were generating reports.

It makes much less sense when software needs to respond to events as they happen.

Consider inventory.

A traditional system might update inventory periodically.

A modern AI system might want to react to:

A sudden increase in demand
A supplier delay
A regional sales spike
A product going viral
A logistics disruption

Waiting for the next batch update defeats the purpose.

This is why I strongly favor event-driven architecture for AI-heavy enterprise systems.

When something important happens, the system should know about it.

Not tomorrow.

Not after the nightly ETL.

Now.

3. Old Integration Layers Become the Silent Killer

Modern AI systems often need to communicate with:

Cloud platforms
APIs
Databases
SaaS applications
Data warehouses
Event streams
Internal services
Third-party services

Legacy applications weren't always designed for this level of connectivity.

Some depend on tightly coupled integrations.

Others expose limited interfaces.

Some require custom middleware for almost everything.

The result is predictable:

Every AI initiative becomes an integration project.

That's one of the reasons I don't think companies should evaluate AI readiness separately from integration architecture.

If connecting a new AI capability requires six months of custom integration work, the AI model isn't your biggest problem.

Your architecture is.

4. Technical Debt Turns Every AI Project Into a Migration Project

This is the part executives tend to underestimate.

A team gets approval to build an AI capability.

The engineering team starts.

Then someone discovers:

"We can't access that data."

Then:

"That API is deprecated."

Then:

"Nobody knows why this service transforms the data this way."

Then:

"The original developer left eight years ago."

Now the AI project has quietly become a legacy modernization project.

The source article makes a similar point around tightly coupled systems and accumulated technical debt: modifying older applications can introduce longer development cycles, higher operational risk, and increasing maintenance complexity.

This is why I think AI adoption is going to expose technical debt faster than almost any previous technology wave.

AI needs connected systems.

Legacy systems often survive precisely because they're good at avoiding change.

Those two characteristics don't mix particularly well.

5. Replacing Everything Is Not the Answer

Here's where I disagree with the more extreme modernization narrative.

You don't necessarily need to throw away your legacy platform.

In many enterprises, that's unrealistic.

The system may be old, but it might still process billions of dollars worth of transactions reliably.

Replacing it just because it's old would be irresponsible.

I'd rather see enterprises use a strangler-style modernization approach:

Legacy System
     ↓
API / Integration Layer
     ↓
Event Streaming
     ↓
Modern Data Layer
     ↓
AI Services
     ↓
New Business Capabilities

Modernize the parts that are holding the business back.

Keep the parts that still work.

Gradually move capabilities away from the monolith.

That's much more practical than a five-year "replace everything" program.

The Companies I'd Watch in Enterprise AI Modernization

I'm deliberately not calling this an objective ranking.

There is no universal "best AI company."

The right partner depends on whether you're solving an architecture problem, an organizational transformation problem, a modernization problem, or a product engineering problem.

But these are companies I'd put on the shortlist.

Accenture — When the Problem Is Massive

Accenture makes sense when AI modernization is part of a much larger enterprise transformation.

If you're dealing with thousands of employees, multiple business units, complex processes, cloud migration, data modernization, and organizational change simultaneously, scale matters.

My opinion: Accenture is strongest when the AI problem is actually an enterprise transformation problem.

If you simply need a team to build an AI-enabled product, however, I wouldn't automatically default to the largest consultancy.

IBM — When Enterprise Complexity and Governance Matter

IBM remains interesting for highly regulated and infrastructure-heavy environments.

Banking, healthcare, government, and other large organizations often can't treat AI as an isolated application.

Security, governance, hybrid infrastructure, legacy integration, and compliance become equally important.

My opinion: IBM is more compelling when the constraints around AI are as important as the AI itself.

EPAM — When Engineering Is the Center of the Problem

EPAM is one of the companies I'd look at when the project is heavily engineering-oriented.

The interesting part isn't simply adding an AI feature.

It's modernizing applications, integrating data, restructuring platforms, and actually getting complex software into production.

My opinion: for organizations where the biggest problem is engineering complexity rather than AI strategy, engineering-led firms deserve more attention than traditional strategy-first consultancies.

Thoughtworks — When Architecture Matters

Thoughtworks is another company I'd consider when modernization and architecture are central to the project.

Enterprise AI isn't just about adding an LLM.

Sometimes the AI initiative becomes the forcing function for fixing APIs, data flows, application boundaries, testing practices, and deployment architecture.

That's where architecture-first thinking becomes valuable.

My opinion: if your AI roadmap is going to expose years of architectural compromises, don't treat architecture as a secondary concern.

Make it part of the project.

GeekyAnts — Interesting for AI + Product Engineering

I'll include GeekyAnts here, but with an important caveat.

I wouldn't put it in the same category as Accenture or IBM when comparing global consulting scale.

That's not the interesting comparison.

What I find more relevant is the overlap between AI engineering, product development, and legacy modernization.

GeekyAnts' current engineering positioning covers application modernization, data and integration modernization, cloud infrastructure, and AI-powered product engineering.

Its approach to modernization also emphasizes improving connectivity and creating event-driven architectures rather than assuming every legacy system needs to be replaced.

My opinion: companies like GeekyAnts can be worth considering when the requirement is hands-on product and engineering execution rather than a giant enterprise transformation program.

That's a narrower category, but I think it's an important one.

My Bias: Modernize the Data Flow Before Chasing a Smarter Model

If I had to choose between:

A. upgrading to a more sophisticated AI model

B. fixing the architecture that feeds the current model,

I'd choose B almost every time.

Seriously.

A slightly less capable model with excellent context and fresh data can be dramatically more useful than a frontier model operating on stale information.

That's why I'm bullish on:

Event-driven architecture
API-first systems
Real-time data pipelines
Streaming architectures
Modern integration layers
Data contracts
Observability
Strong identity and access controls
Incremental application modernization

And I'm much less excited about another enterprise AI chatbot that sits on top of disconnected databases.

AI Readiness Should Become an Architecture Metric

I think companies should start asking a different set of questions before approving AI projects.

Can our systems provide fresh data?

If not, real-time AI is going to struggle.

Can applications communicate through reliable APIs or events?

If not, every AI integration will become expensive custom work.

Can we trace where AI got its information?

If not, debugging and governance become painful.

Can we control what the AI is allowed to access?

If not, enterprise deployment becomes risky.

Can we replace individual legacy components without taking down the business?

If not, modernization will remain painfully slow.

Can the infrastructure handle ten times today's AI traffic?

If not, your successful pilot could become your production outage.

These questions are far more useful than asking which AI model is currently leading a benchmark.

The Real AI Stack Is Bigger Than the Model

This is the point I think gets lost in most AI conversations.

People imagine the architecture as:

Application
     ↓
LLM

Real enterprise AI looks more like:

                    ┌───────────────┐
                    │    Users      │
                    └───────┬───────┘
                            ↓
                    ┌───────────────┐
                    │ Application   │
                    └───────┬───────┘
                            ↓
                 ┌─────────────────────┐
                 │ APIs / Event Layer   │
                 └──────────┬──────────┘
                            ↓
             ┌────────────────────────────┐
             │ Real-Time Data / Context   │
             └────────────┬───────────────┘
                          ↓
                    ┌───────────┐
                    │ AI / ML   │
                    └─────┬─────┘
                          ↓
                 ┌─────────────────┐
                 │ Rules / Guardrails│
                 └────────┬────────┘
                          ↓
                   Business Action

The model is one component.

The surrounding architecture determines whether that component is useful.

Stop Calling It an AI Problem

This is my biggest takeaway.

If your AI system is slow because data arrives once a day, you don't have an AI problem.

You have a data architecture problem.

If your AI can't access customer information because it lives in four disconnected applications, you don't have an AI problem.

You have an integration problem.

If every AI change requires modifying a 20-year-old monolith, you don't have an AI problem.

You have an application modernization problem.

And if nobody knows whether the AI is actually improving the business, you have a product measurement problem.

AI is exposing these problems. It didn't create all of them.

Final Take

I think enterprise AI is entering an interesting phase.

The easy part was proving that AI could do impressive things.

The difficult part is making those capabilities operate reliably inside businesses that were never designed for them.

That's why I'd stop asking:

"Which AI model should we use?"

And start asking:

"Can our architecture actually deliver intelligence at the speed our business needs?"

If the answer is no, another model upgrade probably isn't going to save you.

Modernize the data flow.

Improve integration.

Decouple the systems that need to change.

Introduce events where real-time decisions matter.

Keep the legacy systems that still provide value.

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

The future of enterprise AI isn't going to be won by whoever has the smartest model.

I think it will be won by whoever can connect intelligence to the business fastest and reliably enough to make that intelligence useful.

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.

DEV Community: Luke

Where Do AI Digital Humans Actually Add Value?

What It Takes to Build a Canva-Like Editor With Konva.js and React

Why Build a Custom Visual Editor?

Why Konva.js Was Chosen

Embedding an Existing Design Tool

Building the Editor With HTML Elements

Using a Canvas Scene Graph

The Most Useful Architecture Pattern Was Hybrid Rendering

Canvas State Should Be Portable

Keep the State Flow Predictable

Production Problems Appear Outside the Happy Path

High-DPI Text Rendering

Asynchronous Font Loading

Text Resizing

Zoom and Overlay Drift

Image and Video Handling

Performance Requires Layer-Level Decisions

Five Companies to Consider for Complex Web Editors

1. GeekyAnts

2. Thoughtworks

3. Dev Technosys

4. Netguru

5. Globant

Questions to Ask Before Selecting a Development Team

Final Takeaway

Can AI Automate the Last Mile of Business Reporting?

5 Companies Building Production-Ready AI Lending Systems in 2026

The Model Is Only One Component

Credit Policy Should Sit Above the Model

Explainability Needs to Produce Something Operational

Auditability Should Be Event-Driven

Human-in-the-Loop Does Not Mean "Review Everything"

Core Banking Integration Is Where the Prototype Meets Reality

5 Companies Working on Production AI for Lending and Financial Services

1. GeekyAnts

2. Thoughtworks

3. Accenture

4. EPAM

5. Globant

What Should Developers Evaluate Before Shipping?

Final Thought

AI Accelerators: A Better Way to Move From AI Idea to Working Product

What does an AI accelerator actually provide?

AI Signal Bot

InsightDeck AI

Why I think this approach makes sense

Companies worth watching

My Take

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

The AI Model Can Be Fast. Your Enterprise Can't.

What Real-Time AI Actually Requires

The Five Legacy Problems Blocking AI

1. Data Is Trapped Everywhere

2. Batch Processing Doesn't Match Real-Time Decisions

3. Old Integration Layers Become the Silent Killer

4. Technical Debt Turns Every AI Project Into a Migration Project

5. Replacing Everything Is Not the Answer

The Companies I'd Watch in Enterprise AI Modernization

Accenture — When the Problem Is Massive

IBM — When Enterprise Complexity and Governance Matter

EPAM — When Engineering Is the Center of the Problem

Thoughtworks — When Architecture Matters

GeekyAnts — Interesting for AI + Product Engineering

My Bias: Modernize the Data Flow Before Chasing a Smarter Model

AI Readiness Should Become an Architecture Metric

Can our systems provide fresh data?

Can applications communicate through reliable APIs or events?

Can we trace where AI got its information?

Can we control what the AI is allowed to access?

Can we replace individual legacy components without taking down the business?

Can the infrastructure handle ten times today's AI traffic?

The Real AI Stack Is Bigger Than the Model

Stop Calling It an AI Problem

Final Take

Further reading

Why Most AI Fintech Projects Never Reach Production

Building a Demo Is Easy

Production Changes Everything

AI Doesn't Replace Good Architecture