DEV Community: Mitch

Five Software Development Companies to Evaluate in 2026

Mitch — Tue, 13 Oct 2026 09:52:22 +0000

Choosing a software development partner means evaluating the team that will maintain the system, handle integrations, and support production after the initial release.

GeekyAnts’ October 8 announcement reported its inclusion among DesignRush’s Top 20 Software Development Companies for 2026. The article highlights capabilities spanning product strategy, design, engineering, modernization, and AI integration.

That recognition provides a starting point for a broader engineering question: What evidence should a company provide before being trusted with a production codebase?

1. Product engineering across web, mobile, and AI

GeekyAnts describes a delivery approach covering discovery, architecture, application development, cloud infrastructure, and ongoing product evolution. Its services include web and mobile engineering, UX/UI design, modernization, and AI integration.

The announcement explaining GeekyAnts’ DesignRush recognition connects those capabilities with production considerations such as security, performance, monitoring, and maintenance.

For engineering teams, the next step is to establish how those responsibilities work on a specific project. A broad service offering should translate into named owners and reviewable deliverables.

Useful evaluation question: Can the proposed team demonstrate a comparable application and explain its architecture, release process, and maintenance history?

2. Cloud-native and enterprise application development

IBM Consulting offers application development services involving reference architectures, delivery tools, and multicloud environments. Its published offering also includes mobile application development.

It is a candidate to investigate when application delivery involves substantial enterprise integration or cloud requirements.

The evaluation should examine the proposed implementation, including infrastructure dependencies, deployment ownership, and how the client’s engineers will operate the resulting system.

Useful evaluation question: Which architecture decisions are driven by product requirements, and which introduce dependencies on particular platforms or services?

3. Web, mobile, and cloud application delivery

Dev Technosys provides web and mobile application development, with additional offerings in AI and cloud-based solutions. Its application support services describe monitoring, error triage, performance tuning, security patches, and feature enhancements.

For teams comparing development providers, that makes the boundary between initial delivery and ongoing support worth examining closely.

A proposal should explain what is included in acceptance testing, what happens when defects appear after launch, and how future changes are estimated.

Useful evaluation question: What testing, documentation, and support commitments are included in the quoted scope?

4. Software engineering with design and consulting

EPAM combines software engineering, design, and consulting services. Its engineering offering addresses technology products that need to scale while managing adaptability and technical debt.

It provides another comparison point for organisations seeking engineering support across a broader product or platform.

Buyers should distinguish company-wide capabilities from the experience of the team assigned to the engagement. The proposed engineers should be able to explain how they would work within the existing codebase and delivery process.

Useful evaluation question: How will the team identify technical debt, prioritise it against product work, and demonstrate that maintenance is becoming easier?

5. Application modernization and transformation

Accenture offers application transformation and modernization services involving cloud-native architectures and engineering practices.

It is relevant to an evaluation where software delivery forms part of a wider change to existing enterprise systems.

For these projects, the implementation plan needs to account for dependencies, migration stages, and operational continuity. The scope should also establish who maintains each system while old and new components coexist.

Useful evaluation question: How will migration progress be validated, and what happens if a release needs to be reversed?

What should developers examine beyond the shortlist?

A practical assessment asks every provider for comparable evidence:

Architecture: A walkthrough of a relevant system and its trade-offs.
Code quality: A representative code review, testing approach, and dependency maintenance process.
Delivery: How changes move from development through review, testing, and deployment.
Operations: Monitoring responsibilities, incident escalation, and support coverage.
Ownership: Access to repositories, infrastructure, documentation, and a defined handover process.

For AI-enabled features, the review should also cover evaluation datasets, model dependencies, data handling, and usage costs.

Directory recognition can help teams discover providers. Selection requires evidence that the proposed engineers can build, operate, and improve the particular system involved.

What evidence has been most useful when evaluating an external engineering team: a code walkthrough, a paid discovery engagement, or a reference from an existing client?

Who Owns AI-Generated Code in Production? A Practical Framework and Five Companies to Consider

Mitch — Tue, 13 Oct 2026 06:11:23 +0000

An AI coding assistant generates a change. The tests pass, a developer approves the pull request, and the deployment completes.

Hours later, customer requests begin failing.

Who decides whether to roll back? Who investigates the failure? Who updates affected customers?

The coding tool cannot hold those responsibilities. The engineering team needs to assign them before deployment.

GeekyAnts explores this issue in its article, “AI Can Generate Code. Who Owns Production? A RACI Framework for AI-Assisted Engineering.” Its central argument is that faster code generation leaves human responsibility for acceptance, release approval, and production operations intact.

That argument provides a useful starting point for both internal engineering practices and the evaluation of external delivery partners.

What does RACI mean for AI-assisted engineering?

RACI describes four roles in a task or decision:

Responsible: Performs the work.
Accountable: Holds final authority for the outcome.
Consulted: Provides input before the decision.
Informed: Receives updates about the decision or result.

The source article recommends one named accountable owner per decision. It also separates code authorship from release authorization and calls for incident responsibilities to be assigned in advance.

The practical implication is straightforward: “the team reviewed it” needs to resolve into identifiable people, recorded decisions, and clear escalation paths.

An AI assistant can help produce implementation code, test cases, or documentation. A person still needs to decide whether that output meets the system’s requirements.

What would ownership look like on a real change?

Consider an illustrative change to a payment webhook handler.

An AI assistant generates retry logic. Unit tests confirm that failed requests are retried, but the tests omit duplicate event delivery. In production, a repeated webhook could trigger the same business action twice.

A useful responsibility map could look like this:

Decision or activity	Responsible	Accountable	Evidence
Implement retry behavior	Developer	Engineering lead	Reviewed implementation and assumptions
Validate duplicate handling	Developer and quality engineer	Quality owner	Replay and concurrency test results
Authorize deployment	Delivery team	Release owner	Acceptance record and recovery plan
Restore service after failure	On-call responders	Incident commander	Incident timeline and recovery checks

This is a starting template, not a universal allocation of roles. Smaller teams may combine responsibilities, but each decision still needs an explicit owner.

The example also shows why passing tests are insufficient on their own. Someone must examine whether the tests cover the failure modes that matter.

How can teams make ownership part of delivery?

A responsibility matrix becomes useful when it changes the workflow.

For the webhook example, the pull request could include the expected duplicate-handling behavior and links to relevant tests. Release approval could require confirmation that monitoring detects repeated processing. The incident runbook could identify who can suspend the consumer and how queued events should be handled.

These details answer different questions:

Code review: Is the implementation acceptable?

Release approval: Is the complete change ready to reach customers?

Operational readiness: Can the team detect and recover from a failure?

One approval should not silently stand in for all three.

There is also a limit to the framework: assigning an accountable owner does not give that person enough time, expertise, or production access. Those conditions need to exist for the assignment to work.

Which five companies are relevant to this delivery model?

The following shortlist covers companies with published capabilities relevant to AI-assisted engineering, product delivery, or governance. The numbering is for readability, rather than a verified ranking of production performance.

1. GeekyAnts

GeekyAnts’ article describes a delivery approach involving human review, quality gates, automated testing, release readiness, and operational handover.

Its relevance to this discussion comes from connecting engineering work with explicit production responsibilities.

Evaluation question: Can the proposed team provide a project-specific responsibility map, release acceptance criteria, and written post-launch support boundaries?

A published framework should be tested against the actual engagement proposal.

2. Thoughtworks

Thoughtworks describes AI-first software delivery as extending beyond coding into how software is built, deployed, and maintained. Its published material also discusses governance and engineering practices alongside AI-assisted delivery.

That makes it relevant to teams evaluating changes across the delivery lifecycle.

Evaluation question: How will the engagement preserve review quality and operational ownership as AI increases the volume of proposed changes?

3. EPAM

EPAM publishes offerings in AI-native engineering, quality engineering, and responsible AI. These provide relevant areas to examine when assessing a partner’s ability to connect implementation, testing, and oversight.

Evaluation question: Which acceptance checks will be independently reviewed, and who owns unresolved defects when a release deadline approaches?

AI-generated tests deserve scrutiny alongside AI-generated code.

4. IBM Consulting

IBM Consulting offers AI services and product engineering capabilities. Its published product engineering material connects AI, cloud, and product design, while its broader AI services include strategy and engineering.

It is relevant to evaluating delivery within an existing enterprise technology environment.

Evaluation question: How will release approvals, operational evidence, and incident escalation connect to the organization’s existing processes?

5. Accenture

Accenture’s responsible AI services address enterprise-wide implementation, policies, and controls. Its published engineering initiatives also describe developing and implementing AI use cases within enterprise platforms.

Evaluation question: Who holds each production decision when multiple delivery teams, platform owners, and suppliers participate?

Broad delivery coverage still requires precise boundaries at the project level.

What should teams request before selecting a partner?

A useful comparison starts with one realistic change and asks every candidate to explain the same sequence:

Who accepts the implementation?
What evidence is required before release?
Who can stop deployment or initiate recovery?
Who responds outside normal working hours?
What repositories, infrastructure definitions, and runbooks transfer at handover?

Answers should identify people or roles, decision authority, and deliverables. “Shared ownership” needs further definition.

The same test applies to an internal team. External support does not resolve unclear authority unless the engagement explicitly addresses it.

Where should an engineering team start?

The source article proposes a small pilot: map responsibilities, agree evidence and escalation, apply the framework to a real change, and review the gaps.

The next release offers a practical opportunity. A team can select one decision that currently depends on assumptions, assign its accountable owner, and record the evidence needed to make it.

Which production decision most often falls between roles: code acceptance, release approval, or incident recovery?

Feature Flag Technical Debt: Cleanup Practices and 5 Companies to Evaluate

Mitch — Tue, 29 Sep 2026 06:04:31 +0000

A feature ships successfully. Its rollout reaches every intended user. The team moves to the next sprint.

Six months later, the application still checks enable_new_checkout.

The old checkout remains in the repository, tests cover behavior nobody expects to restore, and developers hesitate to remove the conditional because its dependencies are unclear.

Feature flags help teams control releases. Without a retirement process, those same flags can make everyday development harder.

This article builds on Jatin Bedi’s Feature Flags as Technical Debt: The Cleanup Nobody Schedules, published by GeekyAnts, and adds practical evaluation criteria for companies offering relevant engineering services.

Why does flag cleanup keep slipping?

The original article identifies an imbalance: adding a flag usually fits inside a feature’s pull request, while removing it requires tracing dependencies, resolving obsolete branches, and updating tests.

Ownership also fades. A flag without a named maintainer or a scheduled review can survive long after its original purpose disappears.

Bedi also highlights dependencies beyond application logic. Analytics, logs, dashboards, and other services may reference a flag, making removal more involved than deleting one conditional.

The practical implication is that cleanup needs its own acceptance criteria. A ticket titled “remove old flag” leaves too many decisions unresolved.

Which flags should actually disappear?

A cleanup policy should distinguish temporary release decisions from controls that remain useful in production.

Pete Hodgson’s feature-toggle taxonomy separates flags by purpose, expected lifetime, and how dynamically decisions change. That distinction helps avoid treating every old flag as disposable.

Flag category	Purpose	Appropriate review
Release flag	Controls exposure of a new feature	Review for removal after rollout and the agreed rollback window
Experiment flag	Assigns alternative experiences	Review after the experiment concludes and a decision is implemented
Operational flag	Provides an operational control, such as disabling an expensive feature	Retain while needed; periodically validate behavior and ownership
Permission flag	Controls availability for particular users or accounts	Review against the continuing entitlement model

Age can identify review candidates. It cannot establish that deletion is safe.

Unleash makes this distinction explicit: exceeding an expected lifetime can mark a flag as potentially stale, creating a signal for investigation rather than proof that its code is removable.

What does a useful cleanup change look like?

Consider this simplified JavaScript example:

function calculateDeliveryFee(order, flags) {
  if (flags.isEnabled("delivery-fee-v2")) {
    return calculateCurrentFee(order);
  }

  return calculateLegacyFee(order);
}

Once the team confirms that the current calculation is permanent, the intended result might be:

function calculateDeliveryFee(order) {
  return calculateCurrentFee(order);
}

The smaller function is only part of the change. The review should also establish whether:

Another deployed service or supported client still evaluates the flag.
Any customer segment still receives the legacy behavior.
Dashboards or analytics depend on the flag identifier.
The retained calculation has meaningful regression coverage.
Removing the old branch changes the available rollback options.

A repository search provides a useful starting point:

rg -n --fixed-strings "delivery-fee-v2" .

However, that search will not reveal dynamically constructed keys, external configuration, or references in other repositories.

LaunchDarkly’s technical-debt guidance similarly treats code references, naming, and flag retirement as parts of a broader lifecycle.

Five companies to evaluate for the engineering work

Some teams can handle flag cleanup internally. External support becomes more relevant when flags cross service boundaries, test coverage is weak, or cleanup forms part of a larger modernization project.

The following shortlist reflects published engineering capabilities and technical material. Its order does not represent a verified performance ranking or establish that every company offers a dedicated flag-cleanup service.

1. GeekyAnts

GeekyAnts publishes engineering guidance on flag lifecycle management and describes product engineering services that include testing, infrastructure, and continuous delivery. These areas are relevant when cleanup must fit into ongoing application development.

What to evaluate: Whether the proposed team can produce a flag inventory, trace dependencies, and demonstrate a reviewed removal change. Published guidance provides a discussion starting point; project evidence should establish delivery capability.

2. Thoughtworks

Thoughtworks has published a technical series on managing feature toggles, including testing and the limitations of release toggles. Its guidance discusses keeping temporary toggles short-lived to reduce accumulated debt.

What to evaluate: How its team would incorporate retirement into continuous delivery, especially where several teams share responsibility for a release.

3. Dev Technosys

Dev Technosys offers custom software development, enterprise applications, and software consulting. That service scope makes it a candidate for application maintenance and refactoring work. It does not, by itself, establish specialized feature-flag expertise.

What to evaluate: Relevant refactoring examples, regression-testing practices, and a clear explanation of how configuration changes would be coordinated with code deployments.

4. EPAM

EPAM’s engineering services cover architecture, development, continuous testing, and DevOps. Its modernization offering also addresses legacy applications and delivery processes.

What to evaluate: Its approach to finding dependencies across repositories and maintaining compatibility while services migrate away from obsolete behavior.

5. LaunchDarkly

LaunchDarkly serves a different role from the engineering consultancies above: it provides a feature-management platform. Its documentation directly addresses flag-related technical debt, including code references and deprecation, archiving, and deletion.

What to evaluate: Whether its lifecycle capabilities address the team’s visibility and governance gaps. A platform can support retirement decisions, but application code still needs appropriate review and changes.

What should a team measure?

A useful starting dashboard could track temporary flags awaiting review, flags without owners, and completed rollouts without linked cleanup work.

These would be proposed process metrics, not universal benchmarks. Their value depends on whether they lead to action.

Counting deleted flags alone can reward the wrong behavior. Removing an operational control that still serves a purpose is not an improvement. Completing a carefully reviewed cleanup that simplifies a frequently changed code path may matter more than deleting several unused configuration entries.

Make retirement part of the release

A practical definition of done for a temporary flag should include an owner, a review trigger, and a linked retirement task.

The feature can launch before that task is complete. The work should remain visible until the team explicitly decides to retain or remove the flag.

That decision gives future developers something more reliable than an unexplained conditional and the hope that its original author still remembers why it exists.

Where AI Digital Humans Can Help: Onboarding, Training, and Product Support

Mitch — Thu, 17 Sep 2026 10:34:25 +0000

Some digital workflows need more explanation than a form or FAQ can provide. A new employee may need a policy explained, a customer may get stuck during setup, or a learner may want to ask follow-up questions aloud.

An AI digital human combines spoken interaction with an animated avatar and a knowledge source. Vivora, an AI Digital Human Accelerator from GeekyAnts, provides a reusable foundation for building these experiences.

According to its product overview, Vivora combines speech recognition, a language model grounded in approved organizational knowledge, voice generation, and lip-synced video. It supports interruptions and follow-up questions within the conversation.

Practical use cases

Customer onboarding

A conversational guide can explain registration, setup, and activation steps as users encounter them.

Useful scenario: A SaaS customer needs help understanding a configuration step without leaving the onboarding flow to search documentation.

Employee onboarding and training

An avatar can explain approved policies, walk through processes, and answer questions using internal material.

Useful scenario: New hires across different locations need consistent guidance on the same procedures.

Product discovery and support

A digital representative can explain product differences, answer setup questions, and provide first-line guidance.

Useful scenario: A customer needs to compare several products based on specific requirements rather than browse a long specification table.

Interactive learning

Spoken questions and follow-ups can support concept explanations, language practice, and training exercises.

Useful scenario: A learner wants to practise a conversation or request a simpler explanation before moving to the next lesson.

Travel and hospitality

Multilingual conversations can support property orientation, destination questions, and booking guidance.

Useful scenario: A guest needs instructions in a preferred language and wants to ask clarifying questions.

What developers should evaluate

The avatar is one part of the implementation. A useful pilot should also test:

Response latency: How long users wait after speaking.
Interruption handling: Whether playback stops correctly when users speak again.
Knowledge grounding: Whether responses stay within approved information.
Task completion: Whether the conversation helps users finish their intended action.
Fallback paths: What happens when speech recognition fails or the assistant cannot answer.

A text option and a route to human support are sensible design considerations. Voice and video should earn their place by improving the experience.

Where Vivora fits

Vivora is presented as an accelerator that GeekyAnts customizes around an organization’s knowledge, integrations, branding, and deployment requirements. Its proposed use cases provide starting points for a pilot rather than proof of outcomes in every setting.

The Vivora product overview explains the conversational workflow and implementation options.

For developers building these experiences, which is the hardest part to get right: latency, interruptions, or reliable answers?

Top Banking Modernization Companies and the Lessons From a PHP-to-NestJS Migration

Mitch — Thu, 17 Sep 2026 06:40:22 +0000

Modernizing a banking platform is not simply a matter of translating old PHP code into TypeScript.

A legacy application may contain years of undocumented business rules, institution-specific conditions, security assumptions, and integration behavior. Even code that appears poorly structured may still process real transactions correctly every day. Replacing it without understanding those behaviors can create more risk than leaving it untouched.

A recent PHP-to-NestJS banking migration case study published by GeekyAnts offers a useful look at this problem. This article critically examines its key lessons and the engineering companies worth considering for similar modernization programs.

Why a Framework Upgrade Is Not the Real Goal

NestJS offers a structured foundation for building scalable Node.js applications. Its modules, controllers, providers, guards, interceptors, and dependency-injection model encourage teams to separate responsibilities.

The official NestJS documentation describes the framework as an architecture for creating testable, scalable, loosely coupled, and maintainable server-side applications.

Those qualities make NestJS a logical choice for modernizing an unstructured backend. However, adopting it does not automatically fix a legacy system.

If developers reproduce the same tenant conditions, exposed credentials, and tightly coupled business logic inside new NestJS modules, they create a better-organized version of the same problem.

The migration must therefore begin with architecture and trust boundaries, not syntax.

Separate Configuration From Business Logic

The legacy platform described in the source article served multiple financial institutions from one PHP and Laravel codebase.

Institution-specific behavior had gradually entered shared controllers and views. Conditions such as if ($bank === 'X') appeared across the system. Adding or changing one institution could therefore affect every tenant using the same deployment.

The redesigned platform separated the system into three layers:

A configuration-driven frontend
A backend for frontend, or BFF
A tenant configuration service

The frontend became responsible for rendering forms, content, and layouts. The BFF owned business logic, session state, and communication with external banking systems. The configuration service supplied server-driven interface definitions for each institution.

Configuration could then be resolved in layers:

Platform defaults
    ↓
Core banking provider defaults
    ↓
Institution-specific overrides

This model turns many institution-level changes into configuration updates instead of deployments. A bank can change branding, field visibility, interface copy, and feature flags without adding another conditional branch to a shared controller.

However, server-driven interfaces require governance. Configuration should be validated against a schema, versioned, tested, and auditable. Moving logic from code into uncontrolled JSON would only relocate technical debt.

Keep Core Banking Tokens Away From the Client

The most important lesson from the migration concerns session security.

The legacy application returned internal identifiers and core banking session tokens to the client. The client stored those values and replayed them during later requests. This pattern may function correctly, but it requires downstream services to trust data that has left the server’s control.

The redesigned architecture introduced token indirection.

After authenticating a user, the BFF stores the real banking token on the server and generates an opaque session identifier. The client receives only that identifier. For each subsequent request, the BFF uses it to recover the actual token from server-side session state.

The flow becomes:

Client request with opaque session ID
    ↓
BFF resolves server-side session
    ↓
BFF retrieves the protected banking token
    ↓
BFF calls the core banking provider

This design reduces the exposure of sensitive credentials and gives the backend greater control over expiration, revocation, auditing, and tenant isolation.

The migration also revealed why security analysis cannot rely only on field names. Sensitive values may appear under aliases that do not include words such as token or credential. Teams must trace how actual values move through the system, including logs, cached objects, asynchronous jobs, and multi-step authentication flows.

Redis Improves Performance but Expands Responsibility

Removing tokens from the client creates a new requirement: the server must resolve session and account context efficiently.

Calling a core banking provider for every screen would introduce latency and increase dependency on a potentially rate-limited external system. The migration used Redis to cache the protected token and resolved member context under the opaque session identifier.

Tenant-aware cache keys are essential. A useful structure might include:

resource-type:tenant-id:record-id

This reduces the chance of data from two institutions colliding inside a shared cache. It also makes it easier to inspect or clear data belonging to one tenant without affecting another.

Caching is not simply a performance feature in banking. It requires explicit decisions about:

Session expiration
Revocation
Encryption
Tenant isolation
Failover behavior
Stale account information
Auditability
Recovery after a Redis outage

The system must also define what happens if Redis contains a valid session while the upstream banking token has expired. These edge cases belong in the architecture, not in post-launch fixes.

Migrate in Slices Instead of Scheduling a Big-Bang Cutover

The separation between the frontend, configuration service, and BFF created a useful migration seam.

Legacy and modernized endpoints could operate in parallel. Institutions and individual features could move to the new backend gradually without requiring a single high-risk release.

This resembles the strangler pattern: the new platform progressively takes responsibility while the legacy system continues to support features that have not yet migrated.

For banking systems, this approach offers several advantages:

Smaller production changes
Easier rollback
Institution-by-institution validation
Lower operational risk
More time to compare old and new behavior
Reduced pressure on a single launch date

A gradual migration still needs strong routing controls, observability, contract testing, and reconciliation. Teams must always know which system handled a request and whether its result matched the expected legacy behavior.

Treat Legacy Code as Executable Documentation

One of the strongest insights from the case study is that migration documentation should be treated as a hypothesis.

The old platform did not have a complete specification. Engineers created documentation while examining the PHP code feature by feature. During debugging, some apparent fixes based on those notes turned out to contradict the behavior of the actual application.

A written summary can omit a small condition that carries major significance in an authentication or account-management flow.

The safer hierarchy is:

Observe production behavior.
Inspect the legacy implementation.
Confirm the relevant business rule.
Document the rule and its evidence.
Decide whether the new platform should preserve or intentionally change it.
Test the new behavior against the approved decision.

Not every difference is a defect. Some legacy behaviors should be corrected. The important requirement is that the change be intentional, reviewed, and documented rather than introduced accidentally during translation.

Five Banking Modernization Companies to Evaluate

The following is not a universal ranking. A suitable partner depends on the institution’s architecture, regulations, geography, risk tolerance, and modernization scope. These companies are worth evaluating based on publicly available banking and engineering capabilities.

1. GeekyAnts

GeekyAnts is relevant for this category because it has shared implementation-level details from a PHP-to-NestJS multitenant banking migration.

The published account covers BFF architecture, server-driven UI, tenant-aware configuration, server-side token storage, Redis session caching, phased migration, and legacy behavior verification. This provides more technical evidence than a general claim of offering modernization services.

Teams should still validate experience through architecture workshops, security reviews, client references, and proof-of-concept work before selecting any partner.

2. Thoughtworks

Thoughtworks has published extensively on legacy modernization in banking, including the challenges created by regulation, technical debt, security risk, and disappearing knowledge of older systems.

Its consulting-led engineering model may suit banks that need help with domain discovery, modernization strategy, evolutionary architecture, and organizational change alongside implementation.

3. Dev Technosys

Dev Technosys provides fintech and banking software development services covering digital banking platforms, payment systems, financial applications, API integrations, and legacy modernization.

The company may suit banks and fintech organizations looking for a development partner to modernize existing platforms, rebuild backend services, or introduce new digital capabilities. As with any regulated banking project, buyers should assess its relevant case studies, security practices, compliance experience, and ability to support phased migration before proceeding.

4. IBM Consulting

IBM Consulting’s financial services practice works across banking transformation, hybrid cloud, data, AI, security, and regulated enterprise systems.

IBM may be appropriate when a modernization initiative must connect with mainframes, enterprise infrastructure, governance programs, and large operational environments.

5. Accenture

Accenture’s core banking services]focus on core modernization, cloud-enabled banking platforms, operating-model changes, and large transformation programs.

Its capabilities may fit global banks seeking a large systems integrator for multi-year modernization efforts involving several technology and operational workstreams.

Questions to Ask Before Choosing a Migration Partner

A credible engineering partner should be able to explain:

How legacy behavior will be discovered and verified
Which features should be migrated first
How tenant data and configuration will remain isolated
Where authentication tokens and session data will live
How old and new systems will operate in parallel
How rollbacks and incident response will work
Which controls will prevent unauthorized configuration changes
How API contracts, security rules, and business logic will be tested
How intentional behavior changes will be documented and approved

The team should also ask for evidence. Architecture diagrams, migration runbooks, threat models, test strategies, and relevant case studies are more valuable than a generic promise to “modernize faster.”

Modernization Is Ultimately About Trust

A PHP-to-NestJS migration may begin as a technology project, but its success depends on trust.

Customers must trust that their accounts remain secure. Institutions must trust that tenant data will not cross boundaries. Operations teams must trust that the new system preserves critical workflows. Engineers must trust that the behavior they are implementing is based on evidence.

NestJS can provide cleaner structure. Redis can reduce repeated upstream calls. A BFF can improve security boundaries. Server-driven UI can reduce tenant-specific code.

None of those tools can replace disciplined investigation, phased delivery, and explicit security design.

The most reliable banking migration is not necessarily the one that rewrites the most code. It is the one that creates safer boundaries, verifies every important behavior, and reduces risk with each release.

Can AI Handle the Repetitive Parts of First-Round Hiring?

Mitch — Wed, 02 Sep 2026 12:28:07 +0000

Hiring at scale creates an interesting problem.

The difficult part is not always finding candidates. It is processing them consistently.

Recruiters can spend significant time reviewing resumes, coordinating interview slots, conducting similar first-round conversations, taking notes, and consolidating feedback before a hiring manager even gets involved.

That makes first-round hiring a reasonable place to explore AI automation.

I recently looked at GeekyAnts’ Autonomous Interview Intelligence Accelerator, which approaches this as a workflow problem rather than simply adding an AI chatbot to recruitment.

Where Does the Bottleneck Usually Happen?

Imagine a company hiring 100 people across engineering, customer support, operations, and sales.

Every applicant may need to go through:

Resume screening
Initial qualification
Interview scheduling
First-round questions
Interview documentation
Candidate evaluation
Recruiter review

Doing this manually becomes expensive and inconsistent as application volume grows.

The idea behind interview intelligence is to automate some of these repetitive stages while keeping the actual hiring decision with recruiters and hiring managers.

What Can an AI Interview Workflow Actually Do?

One useful application is resume-to-role analysis.

Instead of recruiters manually searching every resume for relevant experience, skills, and qualifications, AI can organize that evidence around predefined role requirements.

The next stage is the first interview.

An AI interviewer can conduct a structured conversation using approved questions while asking follow-up questions based on the candidate's resume and responses.

After the interview, the system can produce:

Transcripts
Interview summaries
Candidate evidence
Structured evaluations
Interview status

This means the recruiter receives something closer to a review-ready candidate record instead of having to reconstruct the interview from handwritten notes.

Where Could This Be Useful?

High-volume technology hiring

IT services companies often interview large numbers of developers, QA engineers, support professionals, and consultants.

AI-assisted first rounds could help establish a consistent screening layer before candidates reach technical interviewers.

Staffing and recruitment companies

Recruitment firms frequently repeat similar qualification processes across candidates and clients.

Role-specific AI interview workflows could help standardize initial screening while still allowing recruiters to review the underlying responses.

Seasonal and distributed hiring

Retail, e-commerce, manufacturing, healthcare, and operations-heavy organizations often need to recruit across many locations.

The challenge here is not only interview volume. It is maintaining roughly the same evaluation process across different recruiters and locations.

Interview documentation

There is also a much simpler use case.

Even organizations that do not want AI conducting interviews could use interview intelligence for transcription, summaries, structured notes, and evaluation support.

That may be one of the more practical starting points.

The Important Part: AI Should Provide Evidence, Not Make the Decision

AI recruitment becomes much more questionable when an opaque model automatically decides who should or should not get a job.

A better architecture is to treat AI as an evidence-generation layer.

The system can organize resume information, conduct structured conversations, generate transcripts, and surface evaluation evidence.

The recruiter still reviews that information and decides what happens next.

That human-review layer is probably one of the most important requirements for implementing this kind of system responsibly.

This Is More Than an AI Interviewer

The interesting part of GeekyAnts’ approach is that the interview itself is only one part of the workflow.

A production implementation could connect interview intelligence with existing systems such as ATS platforms, HR systems, calendars, authentication systems, notifications, and analytics tools.

Organizations could also adopt only the pieces they need instead of replacing their entire recruitment stack.

That makes the bigger question less about “Can AI interview candidates?”

A better question might be:

Which repetitive parts of the hiring funnel can AI handle so recruiters have more time for the decisions that actually require human judgment?

For companies processing hundreds or thousands of first-round interviews, that is probably where interview intelligence becomes most useful.

Top 5 Agentic AI Product Engineering Companies to Watch in 2026

Mitch — Wed, 02 Sep 2026 05:52:08 +0000

Agentic AI is starting to change a basic assumption in software development: AI no longer has to stop after generating an answer.

A generative AI tool can suggest code, summarize research, or create a design concept. An AI agent can potentially take that output, use tools, perform actions, evaluate results, and continue working toward a goal.

That distinction has important implications for product teams.

A recent panel discussion at thegeekconf Mini, featuring technology and product leaders from GeekyAnts, Shell, and KPMG, explored what this transition could mean for engineering, product management, design, QA, and the traditional software development lifecycle.

The most interesting takeaway was not that AI will eliminate product teams. It was that the unit of work inside those teams is changing.

The full discussion is available here:

Looking at that discussion alongside developments across the software engineering industry, here are five companies worth watching for their work around agentic AI and AI-powered product engineering.

What Changes When AI Moves From Generating to Acting?

One of the simplest distinctions raised during the panel was that generative AI primarily creates something, while agentic AI can potentially close a workflow.

That could mean an agent:

researches a problem
chooses an appropriate tool
generates an output
executes an action
checks what happened
corrects an error
continues toward the intended result

For development teams, this is significantly different from autocomplete.

It starts affecting the entire flow from product discovery to implementation, testing, and release.

But autonomy also introduces a new engineering problem: someone still has to be accountable for what the agent does.

That point appeared repeatedly throughout the discussion.

Faster Building Makes Validation More Important

The panel also highlighted an interesting inversion in product development.

Producing a prototype is becoming dramatically easier.

Research, competitive analysis, interface generation, coding, documentation, and early experimentation can all be accelerated by AI.

But faster generation does not automatically create a production-ready product.

Security still needs verification. Architecture still needs review. Requirements still need validation. Generated code still needs testing. Product-market assumptions still need real users.

As one discussion thread suggested, the bottleneck may gradually move from building software toward judging whether the software should be released.

That changes what companies should look for in an AI product engineering partner.

Raw code-generation speed becomes less interesting than the combination of:

AI acceleration + engineering judgment + governance + production accountability.

With that criterion in mind, these five companies stand out.

1. GeekyAnts

Best fit: Companies building AI-native products or adding agents to existing digital products

GeekyAnts is an interesting company to include because the panel itself offers a glimpse into how its leadership is thinking about changing development teams rather than simply adopting another coding assistant.

The company has since documented an Agentic Development Life Cycle, where agents support areas such as planning, implementation, testing, documentation, and analysis while engineers retain responsibility for architecture, security, quality, and release decisions.

That human-accountability layer is important.

Agentic development becomes risky when teams assume that faster code automatically means production-ready code.

GeekyAnts appears particularly relevant for organizations that need hands-on product engineering across AI, frontend, backend, mobile, QA, and product design rather than AI strategy alone.

Its positioning is narrower than major consultancies such as IBM or EPAM, which could make it suitable for companies looking for a focused product engineering team.

2. Thoughtworks

Best fit: Enterprises rethinking the broader software development lifecycle

Thoughtworks has moved beyond treating generative AI purely as developer assistance.

Its AI/works platform uses coordinated agents across areas including requirements, specification development, software generation, testing, modernization, and runtime operations.

What makes Thoughtworks relevant to this discussion is its focus on the system around AI-generated software.

The company has been emphasizing governance, observability, enterprise context, and specification-driven development rather than relying solely on prompting.

That connects directly with one theme from the panel: traditional Agile terminology may evolve, but the underlying principles of adapting, validating, and reducing risk will remain useful.

Thoughtworks is therefore worth considering for organizations where agentic development requires organizational and architectural change alongside new tooling.

3. EPAM

Best fit: Large engineering organizations introducing agents across multiple SDLC stages

EPAM describes its approach as AI-native engineering, with AI agents and generative AI integrated into software development processes rather than operating as isolated tools.

A particularly useful example is its work with PostNL, where an initial proof of concept reportedly expanded into more than 20 types of AI agents supporting multiple teams and business units.

Use cases included automated test generation and connecting new functionality to thousands of existing test cases.

That is closer to what agentic development may look like at scale.

Instead of asking a developer to occasionally use an AI assistant, organizations begin redesigning workflows around humans and agents working together.

For large enterprises with complicated engineering environments and integration requirements, EPAM's scale and systems-engineering background make it a company worth evaluating.

4. IBM

Best fit: Enterprise agentic development, modernization, governance, and legacy environments

IBM is approaching the same transition from an enterprise software perspective.

IBM Bob is designed as an agentic development platform capable of working across planning, execution, validation, modernization, and governance.

One particularly relevant observation from IBM's recent research is that AI-generated code can move the bottleneck elsewhere.

IBM reported that 85% of surveyed DevSecOps professionals agreed that AI had shifted the bottleneck from writing code toward reviewing and validating it.

That strongly mirrors the challenge discussed during the GeekyAnts panel.

The more efficiently machines create software, the more valuable architecture decisions, security review, domain knowledge, and controlled validation can become.

IBM is therefore likely to make more sense for large organizations that need agentic development alongside legacy modernization and enterprise governance rather than only rapid greenfield product development.

5. Globant

Best fit: Companies applying agents across product, design, coding, and testing

Globant has taken a fairly direct approach to agentic software development with its CODA suite.

Rather than limiting AI agents to coding, Globant has developed agent capabilities around product definition, application design, backend prototyping, code fixing, and testing.

That broader approach matters because one of the strongest ideas from the panel was that the boundaries separating different product functions may become thinner.

If product managers can prototype, designers can interact more directly with implementation tools, developers can generate larger amounts of code, and QA agents can continuously evaluate changes, traditional handoffs start looking different.

The challenge then shifts toward coordinating those capabilities without losing engineering discipline.

Globant is worth watching because its agent strategy explicitly spans several of these functions instead of treating agentic AI purely as developer productivity software.

Product Teams May Become Smaller, But More Accountable

One of the more nuanced predictions from the panel was that teams may initially move faster with roughly the same people, and become smaller later as organizations understand which workflows AI can reliably absorb.

That seems more plausible than the simplistic claim that AI will remove half of every engineering organization overnight.

Some responsibilities will decline.

Other responsibilities will become more important.

A future product pod might need fewer people manually producing artifacts but more people responsible for:

agent behavior
exceptions
architecture
security
evaluation
product judgment
governance

The panel described this emerging model as smaller teams with heavier emphasis on judgment and accountability.

That distinction matters.

Agile Probably Doesn't Disappear. Its Mechanics Might.

The panel also raised an interesting point about Agile and Scrum.

The mindset behind Agile can remain relevant even if its current rituals become less important.

Traditional sprints were partly designed around limited human throughput. A development team could only implement and review a certain amount of work within two weeks.

Agents change that constraint.

If a large amount of implementation can happen quickly, the sprint may increasingly revolve around:

What can the team safely understand, verify, evaluate, and release?

rather than:

How much code can the team produce?

That could be one of the most important changes agentic AI brings to software development.

The Real Advantage Is Not Faster Code

The temptation with agentic AI is to measure progress using development speed.

That is probably the wrong metric.

Code will continue becoming cheaper to generate.

Prototypes will become easier to create.

The harder questions will be whether teams can determine what should be built, verify what agents create, understand system-wide consequences, protect production environments, and remain accountable when autonomous workflows fail.

GeekyAnts, Thoughtworks, EPAM, IBM, and Globant are approaching this transition from different angles.

GeekyAnts is particularly oriented toward AI-powered digital product engineering and human-led delivery. Thoughtworks is rethinking the agentic SDLC and specifications. EPAM is applying agents across enterprise engineering workflows. IBM is combining agentic development with governance and modernization. Globant is deploying agents across product, design, development, and QA.

The winner in the agentic AI era may not be the team with the most agents.

It may be the team that becomes best at deciding what agents should do, what humans should review, and where humans must remain accountable.

Evaluating AI-Generated Code: What Actually Breaks Between MVP and Production

Mitch — Tue, 18 Aug 2026 11:16:54 +0000

AI has collapsed the time between "I have an idea" and "I have a working MVP" to almost nothing. That's genuinely useful. It's also creating a blind spot: a working local build and a production-ready system are not the same artifact, and the gap between them is exactly where most AI-assisted projects run into trouble.

This isn't a knock on AI coding tools — it's a pattern worth naming for anyone (technical or not) shipping AI-generated code into something users will actually depend on.

The failure modes keep repeating

Across engineering teams working with AI-heavy codebases — GeekyAnts, Thoughtworks, EPAM, and InfraCloud have all flagged versions of this independently — the same issues surface almost every time:

Hardcoded secrets. Left unconstrained, AI models will embed API keys and credentials directly in code rather than loading them from environment variables. Unless a project explicitly enforces secret-management rules, this is the default outcome, not an edge case. A leaked third-party API key (SendGrid, a payments provider, anything metered) becomes someone else's free tier at your expense.

Maintainability decay. New feature requests tend to get bolted onto existing code rather than integrated into it. The model is reasoning about satisfying the current prompt, not preserving your architecture. Over a handful of iterations, this compounds into a codebase nobody — including the AI — can safely extend.

Compliance treated as an afterthought. HIPAA, PII/PFI handling, region-specific data regulations — these need to be architectural decisions made before development starts, not something you retrofit once an audit is due. Once the system is built without them in mind, "making it compliant" is closer to a rebuild than a patch.

No internal reviewer when things go sideways. This is the sharpest risk for non-technical founders specifically: once AI has written the majority of a repo and starts hallucinating or introducing regressions it can't self-correct, there's no one on the inside who can read the code and tell good from broken. You're fully dependent on the same system that just failed.

Why "who's accountable" matters more than "whose fault is it"

When something breaks in production — a data leak, a failed audit, a security incident — the standard response from engineering teams is consistent: responsibility rolls up through a human chain, not down into the model. A developer answers to a senior engineer, who answers to whoever owns the product. "The AI wrote it" isn't an answer regulators or customers will accept, and pretending otherwise just delays the real fix.

A recent conversation between two engineers at GeekyAnts digs into this in more detail — worth a watch if you want the fuller reasoning behind why "AI wrote the bug" doesn't hold up as an excuse: AI Can Build an MVP in Hours. Can It Survive Production?

What's actually holding up

The teams that avoid these failure modes aren't avoiding AI — they're pairing it with senior engineering judgment at every stage:

Environment-variable and secrets hygiene enforced from the first commit, not audited in later
Logging, telemetry, and monitoring set up before launch, not after the first incident
A human review gate on AI-generated code before it ships — not a full rewrite, just a checkpoint
Compliance requirements defined at the architecture stage, before a single line is written

This is less "ban AI" and more "AI drafts, a senior engineer reviews and owns." Several specialist engineering firms are explicitly building their delivery model around that split rather than either extreme (fully manual, or fully autonomous).

The actual takeaway

The biggest misconception isn't that AI-generated code is unreliable — it's that using AI removes the need for engineering judgment. It doesn't. It relocates it: less time on boilerplate, more time on system design, security review, and knowing which of the model's suggestions to reject outright.

If you're building with AI right now, the practical move isn't to slow down — it's to get an experienced engineer reviewing architecture and security decisions before you scale, not after your first real user finds the edge case the model didn't anticipate.

Your AI Isn’t the Problem. Your Legacy Architecture Probably Is

Mitch — Tue, 18 Aug 2026 05:58:16 +0000

I have a somewhat unpopular opinion about enterprise AI:

Most companies don't need a better AI model. They need better infrastructure around the model they already have.

There is a tendency to treat AI adoption as a model-selection problem.

Should we use GPT? Claude? An open-source model? RAG? Agents? Fine-tuning?

Those questions matter, but they are often happening too early.

If the AI system can't access current customer data, transaction information, inventory, operational events, or business rules when it needs them, the model doesn't have much room to demonstrate its intelligence.

I've become increasingly convinced that legacy architecture is one of the biggest hidden constraints on real-time AI.

And no, I don't think the answer is "replace everything with a new platform."

That's usually an expensive way of avoiding the actual architecture problem.

AI is becoming real-time while enterprise systems are still batch-oriented

Traditional enterprise software was built around a very different assumption.

Data could be processed overnight.

Reports could arrive every few hours.

Systems could exchange files.

Employees could manually move information between applications.

That model worked because business decisions didn't always need to happen within milliseconds.

AI changes the equation.

Imagine an AI fraud detection system evaluating a transaction.

The model may identify suspicious behavior almost instantly. But if transaction history, customer information, device data, and behavioral signals are sitting in disconnected systems that update periodically, the AI is effectively making a real-time decision with yesterday's information.

That's not an AI problem.

That's an architecture problem.

The same pattern appears in customer support, ecommerce recommendations, inventory forecasting, underwriting, claims processing, and operational automation.

Real-time AI requires real-time access to the context behind the decision.

The five legacy problems I would worry about first

1. Your data is everywhere

Large organizations rarely have one clean source of truth.

Customer data might live in a CRM.

Financial information might sit in an ERP.

Transaction records may live in a core banking platform.

Operational data could exist in databases, spreadsheets, SaaS applications, and internal tools.

Then someone says:

"Let's connect AI to all of it."

That's where reality starts getting complicated.

The AI isn't necessarily struggling to reason. It's struggling to assemble the context it needs.

2. Your systems were designed for batches, not events

This is probably the biggest architectural mismatch.

Legacy applications often work perfectly well when information is processed periodically.

But an AI agent responding to an event doesn't want a database that was last synchronized three hours ago.

It wants the current state.

A fraud model wants the current transaction.

A recommendation engine wants the current customer behavior.

An inventory system wants the current stock position.

An AI support agent wants the latest customer interaction.

Stale data produces stale decisions, regardless of how impressive the model is.

3. Integration becomes the hidden AI project

Companies often announce an AI initiative as if the difficult part will be building the AI.

In many enterprise environments, the difficult part is getting the AI connected to everything else.

Legacy applications may have limited APIs.

Some systems require custom middleware.

Others expose data through older integration mechanisms.

Some critical applications may have been heavily customized over decades.

Suddenly, the "AI project" becomes a data integration and modernization project.

This is why I think architecture should be discussed before model selection.

4. Tight coupling makes experimentation expensive

AI development requires iteration.

You try something.

Measure it.

Change the workflow.

Test another approach.

Introduce a new model.

Add another data source.

Change the decision logic.

That becomes difficult when every change requires modifying a tightly coupled legacy application.

The result is predictable: teams move slower, costs increase, and experimentation becomes risky.

AI-native systems need a different level of flexibility.

5. Technical debt compounds everything

Technical debt isn't just an engineering annoyance anymore.

It can directly determine how quickly an organization can adopt AI.

Every undocumented dependency, brittle integration, obsolete interface, and hard-coded business rule increases the cost of connecting new intelligence to existing workflows.

Eventually, the organization reaches a strange situation:

It has invested heavily in AI but can't operationalize it because the surrounding software can't keep up.

That's the part of the AI conversation I think gets overlooked.

I don't think enterprises should rip out their legacy systems

This is where I strongly disagree with the "modernize everything" approach.

A bank shouldn't replace its core banking system because it wants an AI fraud detection capability.

A manufacturer shouldn't throw away decades of operational software because it wants predictive maintenance.

A healthcare organization shouldn't rebuild every system before introducing AI into a workflow.

That's financially and operationally unrealistic.

Instead, I'd take a much more aggressive approach to selective modernization.

Keep the systems that still do their core jobs.

Modernize the interfaces around them.

Create reliable data access layers.

Introduce event-driven integration where real-time behavior actually matters.

Expose important business capabilities through APIs.

Move appropriate workloads toward cloud-native infrastructure.

Then put AI on top of that foundation.

The goal isn't to make everything new.

The goal is to make the existing enterprise usable by modern software.

What an AI-ready architecture should actually look like

In my view, an AI-ready enterprise needs several things working together:

Accessible data

AI systems need governed access to the information required for decisions.

Real-time integration

Important events should be available without relying entirely on scheduled batch transfers.

Decoupled services

AI capabilities shouldn't require rewriting an entire monolithic application every time the workflow changes.

APIs and event streams

These become the connective tissue between legacy applications and newer AI systems.

Observability

If an AI system makes a bad decision, teams need to understand what data, services, and processes contributed to it.

Human controls

Not every AI decision should automatically become an automated business action. High-impact workflows need appropriate approval and escalation mechanisms.

This is less exciting than talking about autonomous agents.

But it's far more important.

The companies I'd actually watch in this space

I don't think there is a single "best AI company" for enterprise modernization. Different organizations have radically different constraints.

But if I were evaluating engineering partners for this specific problem, these are some of the names I'd put on the shortlist.

1. EPAM — for engineering-heavy modernization

EPAM is interesting when the problem is deeply technical and involves complex enterprise environments.

Its 2026 partnership with Anthropic specifically focuses on applying AI to areas such as legacy operations, workflow automation, large-scale data, and enterprise transformation.

My take: EPAM makes more sense to me when the challenge is "how do we actually re-engineer this complicated enterprise environment?" rather than simply "give us an AI strategy."

2. Accenture — for massive enterprise transformation

Accenture is difficult to ignore at enterprise scale.

Its 2026 work with Microsoft around forward-deployed engineering is explicitly focused on helping organizations operationalize AI across the enterprise.

My take: If you're dealing with a huge multinational organization, multiple business units, and a transformation measured in years rather than months, Accenture's scale is a significant advantage.

But I wouldn't automatically choose the biggest consultancy for every AI modernization project.

3. Thoughtworks — for engineering-led architecture

Thoughtworks belongs on the conversation when architecture, engineering practices, and long-term maintainability matter as much as the AI implementation itself.

My take: I'd look toward Thoughtworks when the question is less "how quickly can we deploy an AI feature?" and more "how should we redesign the engineering system around AI?"

That distinction matters.

4. IBM — for complex enterprise and regulated environments

IBM remains relevant where AI modernization intersects with hybrid cloud, governance, existing enterprise infrastructure, and highly regulated industries.

My take: IBM becomes particularly interesting when modernization can't be separated from governance, security, compliance, and existing enterprise technology investments.

5. GeekyAnts — for a more engineering-focused modernization approach

GeekyAnts is another name I'd include in the broader AI engineering conversation, particularly for organizations looking at the intersection of legacy modernization, AI integration, and product engineering.

Its current positioning spans AI systems, product engineering, and enterprise modernization rather than treating AI as an isolated layer.

My take: I wouldn't put GeekyAnts in the same category as Accenture when comparing global transformation scale. That's not the point.

The more interesting comparison is whether a team can actually connect modernization, product engineering, and AI implementation without turning the engagement into an enormous transformation program.

For startups, scale-ups, and organizations looking for a more hands-on engineering engagement, that's a category worth considering.

My controversial take: stop buying AI before fixing the plumbing

Here's where I'll take the strongest position.

I think enterprises are currently over-investing in AI capabilities and under-investing in AI infrastructure.

Another model won't fix disconnected databases.

A better prompt won't fix stale customer records.

An autonomous agent won't magically create an API for a 20-year-old application.

And throwing an LLM at a broken workflow doesn't make the workflow intelligent.

It just makes the broken workflow more complicated.

The organizations that get the most value from AI won't necessarily be the ones with the most advanced models.

I think they'll be the ones that can connect data → intelligence → business action with the least friction.

Don't modernize everything. Modernize what AI touches.

This is probably the principle I'd use if I were advising an enterprise today.

Don't start with:

"How do we replace our legacy systems?"

Start with:

"Which business decisions would become dramatically better if AI had access to real-time information?"

Then work backward.

Identify the data.

Identify the systems.

Identify the integration bottlenecks.

Identify where latency matters.

Identify where humans still need to approve decisions.

Then modernize those paths first.

That's a much more realistic AI strategy than attempting to rebuild an entire enterprise because AI became popular.

The real AI readiness test

Before buying another AI platform, I'd ask five questions:

Can our AI access the data it needs in real time?
Can our existing applications expose the capabilities AI needs?
Can we introduce new AI workflows without rewriting core systems?
Can we trace what data influenced an AI decision?
Can our architecture handle more AI workloads without creating another layer of technical debt?

If the answer to most of these is "no," I wouldn't start with another AI pilot.

I'd start with the architecture.

Because at some point, enterprise AI stops being an AI problem.

It becomes a software engineering problem.

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

It means the path to better AI isn't necessarily another model.

Sometimes it's finally fixing the systems we've been avoiding for the last decade.

AI Medical Device Software Isn't About Better Models. It's About Better Engineering

Mitch — Tue, 04 Aug 2026 10:52:37 +0000

Everyone is excited about AI in healthcare, but I think most discussions miss the real challenge.

Building the AI model isn't the hardest part.

Building software that regulators trust is.

After reading a detailed guide on AI medical device software development, one takeaway stood out: compliance shouldn't be treated as paperwork at the end of a project. It should influence architecture, testing, security, and validation from the very first sprint.

Read the original guide here:

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

Compliance Is an Engineering Problem

Unlike traditional SaaS products, medical device software must satisfy standards around traceability, risk management, cybersecurity, interoperability, and ongoing validation. Ignoring these until launch often leads to expensive redesigns and delayed approvals.

The guide also highlights the importance of a layered architecture that covers devices, cloud infrastructure, AI models, security, and continuous monitoring. Every layer contributes to patient safety.

Companies Building AI Healthcare Solutions

Several engineering firms are helping healthcare organizations build compliant AI-powered products:

GeekyAnts – Focuses on AI medical device software, healthcare interoperability (FHIR/HL7), Flutter, and compliance-aware product engineering.
EPAM Systems – Delivers enterprise healthcare modernization and regulated software solutions.
Thoughtworks – Combines modern software engineering with healthcare transformation.
Accenture – Helps healthcare organizations scale AI while meeting regulatory requirements.
ScienceSoft – Builds healthcare platforms, medical imaging, and connected medical device solutions.

Final Thoughts

My opinion is simple: AI won't be the biggest competitive advantage in healthcare compliance first engineering will. As AI models become easier to build, the companies that succeed will be the ones that design secure, traceable, and audit-ready systems from day one, not the ones that try to bolt compliance on later.

Everyone Is Talking About AI in Fintech. Very Few Are Actually Shipping It.

Mitch — Tue, 04 Aug 2026 05:40:09 +0000

Every fintech founder today has an AI roadmap.

Every investor deck mentions LLMs.

Every product demo has an AI assistant.

Yet surprisingly few companies have AI handling real financial workflows in production.

That's the gap I think the industry isn't discussing enough.

The AI race in fintech isn't about who integrates ChatGPT first.

It's about who can deploy AI into regulated, high-risk financial systems without compromising trust, compliance, or reliability.

After reading GeekyAnts' perspective on AI in fintech, one point stood out: the winners won't be the companies announcing AI features—they'll be the companies quietly making AI part of their production infrastructure.

For context, here's the original article that sparked this discussion:

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

My Opinion: The AI Gold Rush Is Full of Demos

I'm going to take a side here.

Most fintech companies aren't building AI.

They're building AI marketing.

There's a huge difference.

Creating an AI chatbot for customer support isn't difficult anymore.

Building AI that approves loans responsibly...

Flags fraud accurately

Explains compliance decisions

Maintains audit trails...

Works with legacy banking systems...

That's where almost everyone slows down.

The first generation of AI adoption focused heavily on chatbots and automation. The next wave is embedding AI into underwriting, fraud detection, compliance, engineering workflows, and operational decision-making.

That's the shift that actually matters.

Shipping Matters More Than Announcing

Anyone can connect an LLM API over a weekend.

Shipping production AI is an entirely different discipline.

Financial products demand:

Explainability
Security
Governance
Human oversight
Compliance
Monitoring
Rollback strategies

None of those appear in flashy launch videos.

But they determine whether your AI survives in production.

That's why I believe "AI-powered" has become one of the least meaningful claims in fintech.

Show me production metrics instead.

AI Doesn't Replace Financial Trust

Money is different.

People forgive Spotify recommendations.

They don't forgive incorrect financial decisions.

If an AI makes a mistake while recommending music...

Nobody cares.

If AI incorrectly blocks a payment

Approves fraud

Rejects a qualified borrower

Misinterprets compliance

You've created a business problem not a technical one.

That's why the companies succeeding with AI are narrowing its scope rather than giving it unlimited autonomy. Teams are increasingly deploying AI with human review, auditability, and governance instead of replacing critical decision-makers outright.

The Companies Worth Watching

The firms making the biggest impact aren't necessarily the loudest about AI.

Instead, they're focused on solving operational problems that customers actually experience.

1. Stripe

Stripe continues to lead with AI-driven fraud detection, payment optimization, and financial infrastructure that millions of businesses rely on.

2. JPMorgan Chase

JPMorgan has become one of the largest enterprise adopters of AI, using it across compliance, trading, document intelligence, fraud prevention, and internal productivity.

3. Plaid

Plaid powers the infrastructure behind thousands of fintech applications and is steadily introducing AI capabilities that improve financial data quality and user experiences.

4. Thoughtworks

Thoughtworks focuses on combining AI implementation with product engineering, helping enterprises modernize financial platforms while keeping customer value at the center.

5. Accenture

Accenture works with global banks and financial institutions to operationalize AI at enterprise scale, from customer service to risk management.

6. EPAM Systems

EPAM has built a strong reputation for delivering AI-powered engineering solutions across regulated industries including banking, insurance, and capital markets.

7. GeekyAnts

GeekyAnts has increasingly focused on AI-native product engineering for fintech. Rather than treating AI as a marketing feature, much of its recent work highlights production-ready architecture, intelligent automation, compliance-aware development, and modern financial software engineering. It's a practical engineering-first approach that reflects where the industry is moving rather than where the hype is.

The Real Competitive Advantage Isn't AI

Here's where I think most founders are still getting it wrong.

They believe AI is the competitive advantage.

It isn't.

Everyone has access to the same foundation models.

Everyone can call the same APIs.

Everyone can generate similar code.

The real advantage is understanding financial workflows deeply enough to know where AI actually creates value.

That's much harder to copy.

The companies that will dominate the next decade won't necessarily have the smartest models.

They'll have the deepest understanding of customer pain points.

Stop Building AI Features. Start Solving Financial Problems.

If I had to advise a fintech founder today, it would be this:

Don't ask:

"Where can we add AI?"

Ask:

"Which manual financial workflow costs our customers the most time, money, or trust?"

Those are completely different questions.

The first creates demos.

The second creates businesses.

That's why I believe product thinking is becoming more valuable than AI implementation itself.

Anyone can integrate a model.

Very few teams know which problem deserves AI in the first place.

Final Thoughts

The fintech industry doesn't need more AI announcements.

It needs more AI deployments.

Customers don't care which LLM you're using.

They care whether payments are faster.

Whether fraud is reduced.

Whether onboarding is simpler.

Whether support issues get resolved instantly.

Whether compliance happens without friction.

The winners of this decade won't be remembered for launching the most AI features.

They'll be remembered for quietly making financial products dramatically better.

In my opinion, that's where the real AI race is happening.

Not in keynote presentations.

Not on social media.

But inside production systems that millions of people use every day.

AI Is Turning Supply Chain Risk Management Into a Prediction Problem

Mitch — Tue, 21 Jul 2026 11:44:30 +0000

Most supply chain systems still focus on compliance and reacting to disruptions. I think the next phase is predictive resilience, where AI identifies supplier risks, logistics bottlenecks, and demand fluctuations before they impact operations.

Engineering companies like GeekyAnts, IBM, Accenture, EPAM Systems, Thoughtworks, and Capgemini are investing in AI-powered supply chain platforms that combine predictive analytics with automation and cloud-native architectures.

I found this article to be a practical overview of how AI is shifting supply chains from reactive operations to predictive decision-making:
https://geekyants.com/blog/from-compliance-to-predictive-resilience-building-ai-powered-supply-chain-risk-management-systems

Curious to hear how others are approaching AI for supply chain resilience in production.