DEV Community: Arjun

Beyond Shift Scheduling: Reliability Lessons from a Flutter Workforce App

Arjun — Tue, 06 Oct 2026 11:39:24 +0000

A workforce management app can look straightforward: assign a worker, confirm a shift, and calculate payment. The complexity appears when connectivity drops, a submission times out, or a shift crosses a daylight-saving change.

The ShiftPilot case study published by GeekyAnts describes modernizing an existing Flutter and Firebase application for flexible workers in Belgium. Its scope included scheduling, payroll, notifications, and DIMONA employment declarations.

For developers, the useful part is how these connected workflows shape reliability requirements.

Modernization can start within the existing architecture

According to the case study, the team extended the existing Flutter and Firebase architecture rather than adding another backend stack. A shared Flutter codebase continued to support iOS and Android.

This approach raises a useful question for any modernization project: which problems require architectural change, and which require better workflow design?

An unreliable filing process, for example, may need explicit state transitions and recovery behavior before it needs a different framework.

Retrying a request requires duplicate protection

One reported challenge involved reliable government submissions. The implementation used Cloud Tasks and Firestore state management for durable retries and recovery, alongside idempotency controls to help prevent duplicate declarations.

The general engineering lesson is that a timeout does not necessarily mean an operation failed. A remote system might accept a request before the application receives confirmation.

A reliable implementation therefore needs answers to questions such as:

How is each logical operation identified?
What happens when the same operation runs again?
How is an uncertain result reconciled?
When does automated recovery require manual intervention?

These questions also apply to payment processing, invoicing, and other workflows with external side effects.

Connectivity and time handling belong in the requirements

The case study identifies weak venue networks, long shifts, time zones, and daylight-saving changes as engineering concerns.

For mobile developers, this suggests testing beyond successful requests on a stable connection. Consider a worker confirming a shift just as connectivity disappears. The interface needs to communicate whether the action is pending, confirmed, or requires attention.

Time handling deserves similar care. A recurring shift represents a local scheduling intention, while payroll depends on the correct interpretation of worked time. Those assumptions should be explicit and tested.

These are broader implementation considerations drawn from the reported challenges, rather than details of ShiftPilot’s internal code.

Release controls matter around sensitive workflows

The project also introduced stronger observability, pull-request standards, CI checks, staging validation, and release controls.

A practical takeaway is to prioritize verification around operations where errors have downstream consequences. Changing a screen layout and changing payroll calculations call for different validation depth.

Useful scenarios include repeated submissions, interrupted requests, failed dependencies, and recovery after a partially completed operation.

The published case study describes the approach, but does not provide enough implementation detail to independently assess its full test coverage or failure guarantees.

For teams building similar applications, which has been harder to get right: duplicate-safe retries, mobile synchronization, or time-zone-aware scheduling?

ISO 42001 Readiness: 5 AI Governance Companies and What Engineering Teams Should Evaluate

Arjun — Tue, 06 Oct 2026 05:54:44 +0000

An AI feature passes evaluation, reaches production, and receives a model update a month later.

At that point, several questions become important: Who approved the change? Which evaluation results supported it? Did the provider’s data-handling terms change? Who can disable the feature if its behavior deteriorates?

These questions connect AI governance directly to engineering work.

ISO/IEC 42001 provides a framework for establishing, maintaining, and improving an Artificial Intelligence Management System, or AIMS. It applies to organizations developing, providing, or using AI. Independent certification bodies assess certification; purchasing a governance platform or hiring an implementation partner does not itself confer certification.

For teams comparing external support, the useful distinction is between governance advice, technical implementation, and the tools used to maintain evidence.

What does ISO 42001 preparation involve?

The GeekyAnts ISO 42001 implementation guide outlines a sequence covering executive ownership, scope and AI inventory, gap and impact assessments, implemented controls, operating evidence, internal audit, management review, and independent certification assessment.

Two points are especially relevant to developers:

Governance evidence should emerge from normal approval, evaluation, deployment, monitoring, and change workflows.
Certification concerns a defined management-system scope, rather than blanket approval of every model or product.

The guide also treats supplier reviews, incident handling, and ongoing improvement as continuing responsibilities.

The engineering implication is practical: governance requirements need identifiable implementation tasks and maintainable records.

Five companies to evaluate for AI governance support

The following shortlist compares published capabilities. It is not a ranking based on independently measured project outcomes, and the companies’ offerings are not interchangeable.

1. GeekyAnts: Engineering and operational implementation

GeekyAnts describes support for translating readiness gaps into changes across AI inventories, lifecycle workflows, monitoring, supplier processes, and evidence-producing systems.

Its published scope includes remediation planning and implementation across engineering functions. It distinguishes that work from the independent certification decision.

Evaluation focus: Whether the proposed engagement identifies concrete system changes, acceptance criteria, responsible owners, and evidence handover.

A useful question is whether a requirement such as “maintain model-change evidence” results in an implemented workflow that the internal team can continue operating.

2. IBM: Governance tooling and lifecycle records

IBM’s watsonx.governance offering combines capabilities for AI governance across the lifecycle. Its documentation describes AI Factsheets, evaluation and monitoring capabilities through Watson OpenScale, and model risk governance features associated with OpenPages.

These capabilities make IBM relevant to a tooling comparison, particularly where teams need to organize governance information across multiple AI assets.

Evaluation focus: Integration with existing model infrastructure, the evaluations supported for the intended use case, and the ability to export evidence.

A platform can help maintain records, but teams still need to define who reviews those records and what action follows a failed evaluation.

3. Deloitte: Governance structure and readiness assessment

Deloitte’s ISO 42001 guidance emphasizes building on existing risk, security, privacy, and audit capabilities. It also addresses cross-functional ownership and evidence of operational effectiveness, including monitoring logs, data audit trails, and launch approvals.

This suggests relevance where fragmented responsibilities are a substantial obstacle to implementation.

Evaluation focus: How assessment findings become owned remediation tasks, and how advisory work connects to technical delivery.

A gap assessment becomes actionable when each finding has an accountable owner, a completion condition, and an agreed method of verification.

4. Accenture: Responsible AI governance programs

Accenture publishes responsible AI consulting services focused on establishing governance frameworks and implementing responsible AI practices. Its accompanying material discusses moving organizational principles into operational approaches.

This suggests relevance for organizations coordinating responsible AI work across multiple teams or business functions.

Evaluation focus: The exact boundary between governance design, technical implementation, and ongoing operation.

Teams should request explicit ISO 42001 deliverables where certification readiness is the objective. A general responsible AI engagement should not be assumed to include them.

5. Tata Consultancy Services: Responsible AI lifecycle services

TCS describes responsible AI services across the adoption lifecycle. Its published framework discusses security, accountability, fairness, transparency, and identity protection as guiding principles.

This makes TCS relevant to a comparison of lifecycle implementation approaches.

Evaluation focus: How those principles translate into tests and controls for the specific application.

For example, a customer-support assistant and an automated financial recommendation system require different evaluation criteria. Buyers should examine the proposed methods rather than rely on the presence of a framework alone.

What evidence could an engineering team maintain?

The following is an illustrative implementation checklist, not a prescribed ISO template or a complete certification checklist.

Engineering event	Example evidence	Practical purpose
New AI feature proposed	Intended use, system owner, dependency record	Establish what is being introduced
Model or prompt changed	Version reference, evaluation report, approval	Trace the basis for a release
Retrieval source updated	Dataset version, access review, quality checks	Investigate changes in output behavior
Production threshold breached	Alert, investigation record, response decision	Demonstrate how issues are handled
AI supplier changed	Supplier review and affected-system assessment	Revisit dependency assumptions
Feature retired	Access removal and retention decisions	Close out operational responsibilities

These records can live in existing repositories, issue trackers, registries, and monitoring systems. Their usefulness depends on traceability: a reviewer should be able to connect a release to its evaluated configuration and approval.

Sensitive prompts, customer data, and credentials should not be copied indiscriminately into evidence stores. Evidence design also needs appropriate access and retention controls.

How should teams compare proposals?

A practical comparison should examine three areas.

Delivery boundaries: Does the engagement cover assessment, implementation, tooling, or a defined combination?

Evidence quality: Can the supplier demonstrate how a control produces records during normal operation?

Maintainability: Can the internal team update the process when models, dependencies, personnel, or product requirements change?

One useful evaluation exercise is to ask each provider to walk through the same hypothetical model update—from proposed change to evaluation, approval, deployment, monitoring, and recovery.

That exercise makes differences in ownership and implementation detail easier to identify than a generic capabilities presentation.

What Should an AI MVP Actually Validate?

Arjun — Mon, 21 Sep 2026 11:31:53 +0000

An AI MVP should help a team test user demand, model quality, response times, and operating costs before expanding the product.

GeekyAnts’ AI MVP development offering covers discovery, idea validation, scope definition, AI feasibility, UI/UX design, full-stack development, testing, and pilot feedback.

The supported use cases include:

Generative AI SaaS: Test an AI feature within a subscription product.
Enterprise copilots: Help employees access approved information with permission controls.
RAG knowledge products: Search documents and generate answers with source citations.
Agentic workflows: Coordinate tasks and tools with human approval checkpoints.
Voice and conversational AI: Validate voice or chat interactions in real workflows.
Report intelligence: Extract, classify, summarize, and validate business documents.

The engineering scope includes authentication, integrations, deployment automation, monitoring, and AI evaluation. Handoff includes source code, documentation, known risks, and a roadmap for further development.

For teams planning a first release, the practical starting point is one core workflow and a measurable success criterion, such as task completion or output accuracy.

Which assumption would your team test first: user demand, AI accuracy, or cost per task?

Healthcare AI Starts Before the Model: 5 Companies to Evaluate for Engineering Support

Arjun — Mon, 21 Sep 2026 07:07:42 +0000

A healthcare AI demonstration can generate a convincing summary in seconds. A production system has a harder responsibility: showing where that summary came from, handling incomplete information, and behaving predictably when an integration fails.

For developers, these requirements turn an AI feature into a broader engineering problem. Model selection is only one decision within it.

GeekyAnts’ article on healthcare transformation in the AI era, featuring Rakshith Gowda, provides the starting point for this analysis. It emphasizes three issues: inconsistent data, clinician trust, and the need to determine whether a workflow actually requires AI.

The following discussion extends those ideas into implementation questions and a five-company shortlist. The list reflects published service capabilities, rather than an independently verified performance ranking.

What Does the Source Article Get Right?

The article challenges the assumption that years of stored healthcare records automatically indicate AI readiness. Information arriving from different organizations can contain gaps and inconsistencies.

It also connects adoption with trust: discrepancies between a digital record and a clinician’s trusted source can undermine confidence in the product.

Another useful point concerns problem selection. A workflow redesign may resolve an operational problem without introducing a model.

However, these principles leave developers with an implementation question: what should a system do when the information it receives is incomplete, contradictory, or outdated?

That behavior needs to be designed and tested explicitly.

Valid Data and Reliable Information Are Different Checks

FHIR provides mechanisms for validating resource structure, cardinality, terminology bindings, and profiles. Its documentation also distinguishes those checks from additional business rules, such as duplicate detection and authorization. Passing a validator therefore does not establish that every fact accurately represents the patient’s situation. HL7’s resource validation guidance explains these boundaries.

For an engineering team, that distinction suggests separate validation layers.

Layer	Example question
Structure	Does the resource conform to the expected profile?
Identity	Has the record been associated with the correct patient?
Meaning	Are the code and unit appropriate for the intended use?
Time	Is the information sufficiently recent for this workflow?
Application behavior	What happens when a required check fails?

A blanket rejection policy also deserves scrutiny. HL7 notes that production validation can cause important information to be lost if an entire resource is rejected because of one unexpected field.

An implementation should define how exceptions are retained, surfaced, and resolved, while controlling whether affected data can enter a particular downstream workflow.

A Practical Example: An Appointment Preparation Assistant

Consider a hypothetical tool that drafts an appointment preparation summary for staff review.

Its acceptance tests should cover more than a successful response:

Missing source material: Does the tool identify unavailable information instead of filling the gap?
Conflicting records: Does it expose the disagreement for review?
Access restrictions: Does retrieval respect the current user’s permissions?
Service failure: Can staff continue their work when the model is unavailable?
Model updates: Do previously passing examples still meet the acceptance criteria?

The evaluation should include the time required to inspect and correct the draft. A faster generation step offers limited operational value if verification takes longer than the original task.

These are proposed engineering checks for the example, not claims about a deployed product or a substitute for clinical validation.

Five Companies to Evaluate for Healthcare Engineering

1. GeekyAnts

GeekyAnts describes healthcare work involving data quality, interoperability, and EHR/EMR systems in the source article.

That makes it a candidate for teams exploring healthcare application development and integration work.

Evaluation question: Can the proposed team demonstrate how it handles inconsistent records, failed integrations, and source traceability in a comparable project?

The article establishes an approach to the problem; it does not independently establish delivery performance.

2. Thoughtworks

Thoughtworks’ life sciences and medtech practice describes work on data platforms, legacy modernization, integrated clinical platforms, and AI-enabled workflows.

Based on that scope, it may be relevant when a project requires changes to data architecture alongside application delivery.

Evaluation question: What experience does the proposed team have in the specific setting involved: hospital operations, medical devices, or pharmaceutical research?

Experience in one setting should not automatically be treated as evidence of suitability for another.

3. EPAM

EPAM’s life sciences and healthcare services span providers, payers, health technology, medtech, and pharmaceutical organizations. Its published capabilities include data standardization, cloud modernization, and AI.

That breadth suggests relevance for programs involving several systems and stakeholder groups.

Evaluation question: Who will own cross-system acceptance testing, deployment coordination, and incident investigation?

A broad service portfolio becomes useful only when responsibilities are concrete within the engagement.

4. Globant

Globant’s Healthcare & Life Sciences Studio describes patient engagement platforms, EHR-related workflows, revenue-cycle operations, and payer services.

Its offering may be relevant to organizations connecting patient-facing experiences with operational systems.

Evaluation question: How will the team measure whether a new interface reduces work across the full process?

An improved front end can still leave staff reconciling information manually in another application. Evaluation should include those downstream tasks.

5. IBM

IBM’s healthcare consulting services include healthcare platform integration, hospital modernization, and workflow transformation. Its platform offering explicitly discusses integrating clinical and nonclinical information through FHIR and other formats.

That scope suggests relevance for organizations coordinating technology changes across established enterprise environments.

Evaluation question: Which deliverables belong to consulting, software implementation, infrastructure, and ongoing operations?

Separating these responsibilities helps teams compare proposals and understand what remains with internal engineering.

What Should a Technical Evaluation Require?

A useful vendor assessment can center on a small, representative workflow using synthetic or appropriately authorized test data.

Each candidate should explain the same failure scenarios, demonstrate its proposed handling, and document the remaining limitations. The assessment should cover observability and recovery as well as normal operation.

Useful evidence includes an integration test plan, a sample incident investigation, a deployment rollback approach, and a clear ownership model. Company size and marketing

GFF 2026: What Should Developers Look for Beyond the AI Demos?

Arjun — Tue, 08 Sep 2026 10:20:37 +0000

Global Fintech Fest 2026 runs September 8–11 at Jio World Centre and Trident BKC, Mumbai. Its agenda centres on agentic AI, tokenisation, and quantum, alongside product demonstrations, startup showcases, and regulatory discussions.

The announced programme includes 700+ speakers and 5,000+ participating companies. These are announced figures, not final attendance totals or a startup count. Guests and speakers include Narendra Modi, Nirmala Sitharaman, RBI Governor Sanjay Malhotra, and Nandan Nilekani

Which participants are relevant to developers?

Sarvam AI, the AI Ecosystem Partner, brings a multilingual AI perspective.
ElevenLabs, the Voice AI Partner, makes conversational interfaces a topic to watch.
Blostem has announced SDK-based product demonstrations at Booths J18 and J20, September 9–11. Its event page also describes voice-agent and verification tools.
GeekyAnts, a Bronze Partner and exhibitor at Booth JE16, adds a product engineering perspective. Its published banking and fintech work provides context for discussions about legacy integrations, application modernization, and maintaining production systems.

Why does this matter technically?

Financial workflows put AI systems under practical constraints: actions need permissions, failures need handling, and operators need to understand what happened.

For developers attending or following the event, useful questions include:

How are tool calls authorised and validated?
What prevents a retry from repeating a payment?
When does an agent request human approval?
Can the team trace a failed action across services?
What latency and operating costs appear under realistic workloads?

The opportunity is to examine how these products behave beyond their ideal demo paths and discuss the engineering trade-offs with their builders.

Which implementation would you most want to inspect: voice agents, multilingual AI, or embedded-finance APIs?

From UX to AX: 5 Companies to Watch in Agent-Ready Application Development

Arjun — Tue, 08 Sep 2026 05:15:57 +0000

An application can be easy for a person to navigate while remaining difficult for an AI agent to operate. Buttons, menus, and dashboards communicate through visual conventions. An agent needs a reliable way to identify capabilities, supply valid inputs, and understand whether an action succeeded.

That introduces another design concern: agentic experience, or AX.

GeekyAnts’ article on designing applications for AI agents, adapted from Ashita Prasad’s thegeekconf mini session, explores this shift. It identifies three approaches: exposing website capabilities through WebMCP, embedding interactive interfaces in AI clients through MCP Apps, and generating interfaces inside applications through A2UI.

The useful engineering question is where each approach belongs, and which companies provide relevant services or tooling.

What does AX add to application design?

The source article describes applications serving two audiences: people and agents. It also highlights accessibility as a useful starting point, since meaningful labels and interface semantics can help agents interpret controls.

However, making an interface understandable does not establish permission to use it.

A hypothetical scheduling application illustrates the distinction. An agent might discover an appointment tool and identify an available slot. The backend must still establish whether the current user can make that booking and whether the slot remains available.

AX should make application capabilities explicit while preserving the application’s rules.

Three approaches that solve different problems

Approach	Where interaction happens	Main purpose
WebMCP	Within a website’s browser context	Expose page capabilities as structured tools
MCP Apps	Inside a supporting AI client	Present interactive application UI alongside a conversation
A2UI	Inside an application with a compatible renderer	Describe interfaces using structured, declarative messages

WebMCP: Make website actions discoverable

WebMCP is a proposed web standard for exposing structured tools through JavaScript and annotated HTML forms. Chrome’s documentation describes it as a progressive enhancement and notes that it remains under active development. It should therefore be evaluated against actual browser support. WebMCP documentation

A useful design exercise is to identify one existing application capability, such as searching appointments, and define its inputs and possible results.

That exercise also exposes ambiguity. Does “book appointment” reserve a slot temporarily or confirm it immediately? An agent should not have to infer the difference from a button label.

MCP Apps: Bring useful controls into the conversation

MCP Apps extends MCP with interactive interfaces rendered inside supporting hosts. It connects tool results with UI resources, allowing experiences such as forms and dashboards within an AI client. MCP Apps documentation

This matters when a conversation reaches a point where direct manipulation is easier than another prompt. Selecting a date range or inspecting chart values can be more practical through controls.

Host compatibility remains part of the implementation. Teams should test the intended client and provide a useful fallback when interactive rendering is unavailable.

A2UI: Let agents describe interfaces within boundaries

A2UI uses declarative descriptions that a client renders through supported components. Its approach separates an agent’s description of an interface from the application’s rendering implementation. A2UI documentation

The architectural value is controlled flexibility. An application can support changing combinations of approved components while retaining responsibility for their behavior.

A generated confirmation button still needs an authorized backend operation. Valid UI output is only one layer of correctness.

Five companies relevant to this shift

This is an editorial shortlist based on published capabilities, not a measured performance ranking. It includes an engineering services company alongside platform and tooling providers.

1. GeekyAnts: Custom application integration

GeekyAnts describes services covering agent interaction design, enterprise integration, grounding, validation, and lifecycle monitoring. Those capabilities are relevant when agent functionality must become part of an existing product. AI agent development services

Its AX article provides a technical introduction, but publishing about a protocol does not establish production delivery experience with it.

For an engineering evaluation, the useful questions concern comparable implementations, accessible interfaces, backend authorization, and maintenance ownership.

2. Google: Browser capabilities and declarative interfaces

Google’s Chrome work on WebMCP and the Google-led A2UI project address different parts of agent interaction: exposing website capabilities and describing interfaces for application renderers. Chrome WebMCP, A2UI

These projects merit attention from developers exploring application architecture. Teams should assess implementation maturity and supported environments before depending on them for a critical workflow.

3. Anthropic: Interactive applications inside Claude

Anthropic supports interactive connectors through MCP Apps in Claude, allowing supported applications to present interfaces within conversations. Interactive tools in Claude

This provides a concrete distribution model for application functionality inside an AI client.

The evaluation should include authentication, host restrictions, and the behavior of users who still need the standalone application. An embedded experience should have a clear relationship with the product’s existing workflows.

4. Vercel: Building agent interactions in web applications

Vercel’s AI SDK provides TypeScript tooling for model interaction, structured output, tool calls, and agents. Its UI capabilities support chat and generative interfaces. AI SDK overview

This makes Vercel relevant to teams implementing agent experiences within their own web products.

The SDK supplies building blocks. Developers still need to define loading states, approval flows, error recovery, and how tool results map to interface components.

5. Microsoft: Agent workflows in business applications

Microsoft’s Copilot Studio provides an approach to designing autonomous agents within its business technology ecosystem. Autonomous agent guidance

Its relevance is strongest when the intended experience connects to established organizational workflows.

Teams should distinguish workflow automation from interface portability. A functioning agent in one environment does not establish that its interface or tools will operate unchanged in another host.

What should developers build first?

A bounded experiment can reveal more than a broad interface redesign:

Select one task with a clear success condition.
Define inputs, outputs, permissions, and failure states.
Preserve a usable human interaction path.
Test invalid inputs, expired sessions, and repeated actions.
Measure completion, corrections, latency, and recovery.

For a scheduling prototype, success might mean that an authorized user confirms exactly one valid appointment, receives an identifiable result, and can recover from an interrupted request.

That definition is more useful than counting how many screens the agent bypassed.

AX makes another interaction path possible. The application still needs to deliver an understandable, authorized, and verifiable outcome.

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

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

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

Someone asks:

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

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

The next question starts the process again.

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

It's the controls around the generated SQL.

The workflow is roughly:

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

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

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

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

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

But I think the bigger engineering question is trust.

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

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

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

Curious how others are approaching this.

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

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

Building an application with AI has become dramatically easier.

Shipping one responsibly has not.

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

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

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

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

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

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

"AI Built It" Is Not a Risk Strategy

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

The broader engineering point is more important than the headline.

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

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

The interesting question for developers is therefore not:

Did AI write this code?

It is:

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

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

AI-Generated Code Creates a Provenance Problem

Traditional engineering already has dependency risk.

AI adds another layer.

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

AI-generated code can make provenance less obvious.

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

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

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

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

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

Boring is good when lawyers arrive.

Privacy Risk Is More Interesting Than Prompt Quality

Developers spend enormous amounts of time improving prompts.

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

Imagine an AI support application.

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

Suddenly, "the chatbot" is six systems.

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

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

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

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

There is a strange double standard emerging in software teams.

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

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

That makes no sense to me.

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

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

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

The goal should be moving governance into development.

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

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

This is where my opinion becomes even more opinionated.

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

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

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

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

GeekyAnts: My pick for focused AI product engineering

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

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

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

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

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

Thoughtworks: My pick for engineering rigor

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

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

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

EPAM: My pick for large regulated enterprises

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

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

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

Globant: My pick for AI plus digital product experience

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

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

Accenture: My pick for governance-heavy transformations

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

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

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

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

The Cheapest AI Build May Become the Most Expensive One

This is ultimately why I take the specialist side.

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

That is not the bar anymore.

The harder questions arrive later.

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

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

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

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

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

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

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

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

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

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

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

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

Companies worth considering in this space include:

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

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

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

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

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

AI vendors keep getting better.

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

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

I think the industry is looking in the wrong place.

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

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

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

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

I agree with that premise.

But I'd go further:

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

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

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

Imagine a fraud detection system.

A transaction happens at 2:03:14 PM.

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

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

The model isn't slow.

The infrastructure is.

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

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

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

That mismatch is becoming increasingly expensive.

The five legacy problems blocking enterprise AI

1. Data is everywhere

Enterprise data rarely lives in one clean system.

Customer information might be in a CRM.

Transaction data might be in a core banking platform.

Product information might sit in an ERP.

Support history might live somewhere else.

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

AI doesn't necessarily need "more data."

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

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

And bad context produces bad decisions.

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

A lot of legacy infrastructure was designed around scheduled processing.

Nightly jobs.

Hourly synchronization.

End-of-day reporting.

Periodic database updates.

That architecture made sense when the business question was:

"What happened yesterday?"

It becomes a problem when the question is:

"What should we do right now?"

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

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

3. APIs are still a surprisingly big problem

Modern AI systems need to interact with other systems.

They need to retrieve information.

They need to trigger actions.

They need to write results back.

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

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

Some have limited APIs.

Some rely on proprietary interfaces.

Some require custom middleware.

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

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

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

4. Business logic is trapped inside legacy systems

This is the more dangerous problem.

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

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

Approval rules.

Pricing logic.

Risk thresholds.

Exception handling.

Compliance rules.

Customer eligibility.

Operational workflows.

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

Replacing the system isn't just a technical migration.

It's a business-logic migration.

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

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

5. Technical debt makes every AI project slower

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

It becomes more visible.

Every new AI integration exposes another dependency.

Every missing API becomes an engineering project.

Every inconsistent database schema becomes a data problem.

Every undocumented workflow becomes a discovery exercise.

Every security restriction becomes another architectural consideration.

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

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

Stop treating AI and modernization as separate projects

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

They create an AI team.

The team builds a proof of concept.

The proof of concept works.

Then someone asks:

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

That's backwards.

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

You don't need to replace everything.

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

A phased modernization strategy is much more practical.

Modernize the systems that create the biggest AI bottlenecks.

Expose critical functionality through APIs.

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

Create shared data layers.

Improve observability.

Decouple tightly connected services.

Then connect AI to those modernized capabilities.

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

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

I think that's the more sensible approach.

The companies I'd watch in enterprise AI modernization

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

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

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

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

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

That matters.

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

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

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

2. Accenture — strongest when modernization becomes a transformation program

Accenture is a different proposition.

Its advantage is scale.

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

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

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

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

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

3. Thoughtworks — my pick for engineering-led modernization

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

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

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

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

4. EPAM — interesting for complex engineering environments

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

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

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

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

5. GeekyAnts — worth considering for product-oriented modernization

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

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

The interesting part isn't the AI marketing.

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

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

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

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

Legacy doesn't automatically mean useless.

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

The problem isn't age.

The problem is inaccessibility.

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

Modernization should answer:

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

Those are much better questions than:

"How do we replace our legacy stack?"

The architecture matters more than the model

Here's the uncomfortable reality.

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

It cannot rebuild twenty years of enterprise infrastructure overnight.

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

Stop asking only:

Which model should we use?

Start asking:

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

Can data move quickly enough?

Can systems communicate?

Can permissions be enforced?

Can decisions be audited?

Can AI trigger actions safely?

Can the infrastructure handle increased volume?

Can humans intervene when necessary?

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

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

It will simply make the bottleneck more obvious.

The enterprise AI winners will modernize selectively

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

I believe enterprises need to become selectively modern.

Modernize the systems that block important AI workflows.

Keep the systems that still provide reliable business value.

Connect what can be connected.

Replace what genuinely needs replacing.

Expose the data AI needs.

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

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

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

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

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

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

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

Are AI operators the next evolution beyond insurance chatbots?

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

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

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

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

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

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

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

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

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

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

I don't think that's true anymore.

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

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

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

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

The real opportunity is building AI-native care systems.

Telehealth Was Step One, Not the Destination

The pandemic accelerated virtual healthcare adoption faster than anyone expected.

Hospitals launched telemedicine platforms.

Clinics digitized appointments.

Patients became comfortable receiving care remotely.

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

Video calls simply moved traditional appointments online.

They didn't eliminate administrative work.

They didn't predict patient risks.

They didn't continuously monitor health.

They didn't automate care coordination.

Healthcare remained reactive.

Only the communication channel changed.

AI Changes the Entire Care Model

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

Instead of only scheduling appointments, AI can assist with:

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

This represents a shift from digital healthcare to intelligent healthcare.

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

Healthcare Needs Systems That Think Between Appointments

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

Most healthcare happens outside hospitals.

People forget medication.

Symptoms change.

Recovery slows.

New risks appear.

Traditional telehealth platforms remain largely inactive until the next consultation.

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

That's a fundamentally different operating model.

Why This Matters for Healthcare Providers

Healthcare professionals already struggle with:

Documentation overload
Staff shortages
Burnout
Administrative complexity
Rising patient expectations

Hiring more people isn't always sustainable.

Smarter systems often create a bigger impact than larger teams.

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

Healthcare becomes more human, not less.

Companies Building the Next Generation of Healthcare AI

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

Some of the notable players include:

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

Each approaches healthcare AI differently.

Some focus on cloud infrastructure.

Some build enterprise modernization platforms.

Others specialize in AI product engineering and workflow automation.

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

My Opinion: Most Hospitals Are Investing in the Wrong Problem

Here's the unpopular take.

Many healthcare organizations are still asking:

"How do we improve telehealth?"

I think they're asking the wrong question.

The better question is:

"How do we redesign healthcare around AI?"

Improving virtual appointments might increase convenience.

But intelligent care systems improve outcomes.

Those aren't the same thing.

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

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

That's where the real competitive advantage is emerging.

AI Should Become Invisible

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

It will be the one quietly working behind the scenes.

Automatically summarizing consultations.

Monitoring chronic conditions.

Flagging deteriorating patients.

Scheduling follow-ups.

Reducing paperwork.

Helping clinicians make faster, better-informed decisions.

Patients won't care whether AI generated the recommendation.

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

That's the future worth building.

Final Thoughts

Telehealth proved that healthcare could be delivered remotely.

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

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

It's the next architectural shift in digital healthcare.

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