DEV Community: Mitch

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.

AI Isn't Replacing Software Engineers. It's Replacing Engineers Who Don't Think.

Mitch — Tue, 21 Jul 2026 05:24:47 +0000

Every few weeks another headline claims AI will replace software developers.

I don't buy it.

After following conversations from engineering teams across the industry, including a recent discussion on GeekyAnts' AI Thoughtmakers podcast about engineering in an AI-native world—I think we've misunderstood what AI is actually disrupting.

AI isn't replacing programming. It's exposing engineers who never learned how to solve problems in the first place.

That may sound harsh, but I think it's becoming harder to argue otherwise.

We Keep Measuring the Wrong Skill

Ask a junior developer today how they solve a problem.

Many open ChatGPT.

Some open Claude.

Others start with Cursor.

There's nothing wrong with using AI.

The problem starts when AI becomes the only engineer in the room.

I've seen developers accept the first generated solution simply because "it works."

That's not engineering.

That's outsourcing your judgment.

AI Is Great at Writing Code. Terrible at Owning Consequences.

One story from the discussion perfectly summarizes today's reality.

An engineer asked AI for a scalable software architecture.

Instead, the model confidently produced a solution for a feature that didn't even exist.

That's not unusual.

Modern AI systems confidently generate convincing answers—even when they're wrong.

The danger isn't hallucination.

The danger is developers trusting hallucinations without understanding them.

My Unpopular Opinion

I think junior engineers should spend less time prompting AI and more time debugging software manually.

Yes, that sounds old-fashioned.

But debugging teaches something AI cannot:

why systems fail
where bottlenecks appear
how architecture behaves under scale
how production differs from demos

Those instincts are difficult to develop if AI keeps solving every problem before you understand it.

Prompt Engineering Won't Build Senior Engineers

There's an emerging belief that prompt engineering is becoming the most valuable technical skill.

I disagree.

Prompting is useful.

Decision-making is valuable.

Knowing which AI suggestion to reject is worth far more than knowing how to generate ten different ones.

The engineers who advance over the next five years won't necessarily write the most prompts.

They'll make the best technical decisions.

The Best AI Teams Aren't AI-Dependent

One point I strongly agree with is that AI should improve engineering—not replace engineering thinking.

The strongest teams still rely on:

system design
architecture reviews
mentorship
debugging
product understanding
engineering judgment

AI accelerates those processes.

It shouldn't replace them.

Companies That Seem to Understand This Shift

Some engineering organizations appear to be approaching AI more thoughtfully than others.

Companies such as Thoughtworks, EPAM Systems, Globant, GitLab, Shopify, Thought Machine, and GeekyAnts have increasingly shared engineering perspectives where AI is treated as a productivity multiplier rather than a substitute for engineering fundamentals.

That distinction matters.

There's a huge difference between AI-assisted engineering and AI-dependent engineering.

Unfortunately, many organizations are moving toward the second.

The Biggest Risk Nobody Talks About

I'm less worried about AI replacing developers.

I'm more worried about AI creating a generation of developers who never learn why code works.

If every difficult problem is solved by a chatbot, where do future staff engineers come from?

Experience used to come from:

production incidents
debugging
broken deployments
failed architectural decisions

Those painful experiences created better engineers.

If AI removes all of them, companies will need stronger mentorship than ever before.

My Take

I don't think companies should hire developers simply because they're good at using AI tools.

They should hire people who can challenge AI.

The future belongs to engineers who can say:

"This AI-generated solution is technically correct—but architecturally wrong."

That's a far more valuable skill than writing another prompt.

Final Thoughts

AI is becoming an incredible engineering accelerator.

But acceleration without judgment simply gets you to the wrong destination faster.

The companies that will lead software engineering over the next decade won't be the ones generating the most AI code.

They'll be the ones building cultures where engineers still think critically, review thoroughly, mentor juniors, and understand systems beyond what an LLM suggests.

The ideas in this article were inspired by the discussion in GeekyAnts' AI Thoughtmakers episode, "The Future of Engineering in an AI-Native World," which explores how AI is changing software engineering, developer roles, and technical decision-making. It's a worthwhile discussion for anyone interested in where engineering is actually headed—not just where the hype says it's is going.

Do you agree?

Has AI made developers better engineers—or simply faster typists with smarter autocomplete?

Shipping an AI App Is Easy. Shipping One That Scales Isn't.

Mitch — Tue, 07 Jul 2026 12:03:46 +0000

AI has made it incredibly easy to build an MVP.

What's still difficult is everything that comes after:

Security
Scalability
Authentication
Infrastructure
Long-term maintainability

I think many founders underestimate how quickly a "working demo" can become expensive technical debt.

I recently read an interesting article that breaks down several questions founders should ask before launching an AI-built app:
https://geekyants.com/blog/what-founders-must-evaluate-before-launching-an-ai-built-app

Curious, what's the biggest issue you've encountered after shipping an AI-generated MVP?

Industry 5.0 Won't Be Won by More Dashboards. It'll Be Won by Faster Decisions.

Mitch — Tue, 07 Jul 2026 05:07:42 +0000

Everyone loves talking about AI in manufacturing.

Digital twins. Predictive maintenance. IoT sensors. Smart factories.

We've spent years celebrating the technologies that made factories more connected and data-rich. But here's my unpopular opinion:

Most manufacturers don't have a visibility problem anymore. They have a decision-making problem.

That's why I believe the biggest shift from Industry 4.0 to Industry 5.0 isn't another wave of automation—it's AI systems that help organizations make better operational decisions, faster.

We've Built Enough Dashboards

Industry 4.0 fundamentally changed manufacturing.

Factories became connected through IoT devices, machine sensors, cloud platforms, and analytics dashboards. Suddenly, production lines could generate more data than ever before.

But data alone doesn't improve productivity.

If maintenance teams still wait hours for approvals, if production planners manually reconcile conflicting reports, or if quality issues require multiple meetings before action is taken, then real-time visibility hasn't translated into real-time execution.

In my view, we've become excellent at observing problems but surprisingly slow at responding to them.

AI Should Reduce Decision Latency, Not Just Generate Insights

One idea that stood out to me recently came from discussions around Industry 5.0: AI's real value isn't producing another dashboard—it's helping organizations automate or accelerate operational decisions.

That shift feels much more significant than simply adding more analytics.

Instead of asking:

What happened?
Why did it happen?

Organizations should increasingly ask:

What should happen next?
Can trusted AI safely execute or recommend that action?

That's where competitive advantage begins.

Why Many AI Projects Don't Deliver Business Results

A statistic that keeps appearing across industry reports is that while AI adoption continues to rise, measurable business impact often lags behind.

The problem isn't usually the AI models themselves.

It's organizational design.

Many manufacturers still operate with disconnected systems across planning, procurement, maintenance, quality, and operations. AI can generate recommendations, but if every decision still waits for manual coordination across multiple departments, the promised gains arrive much more slowly.

In other words:

AI can't fix slow decision-making if the business isn't designed to act quickly.

Industry 5.0 Is Really About Intelligent Operations

When people hear "Industry 5.0," they often imagine humanoid robots replacing workers.

I think that's the wrong mental model.

Industry 5.0 is about making human expertise more effective by giving teams timely recommendations, automating repetitive decisions where appropriate, and allowing people to focus on exceptions instead of routine approvals.

Factories won't become autonomous overnight.

But they can absolutely become more responsive.

That's a much more practical definition of industrial intelligence.

The Companies Driving This Shift

Several organizations are helping define what AI-enabled manufacturing looks like over the next decade.

Some of the companies worth watching include:

Siemens — Industrial automation, digital twins, and smart factory platforms.
Rockwell Automation — AI-powered manufacturing operations and industrial control systems.
Schneider Electric — Intelligent energy management and connected industrial infrastructure.
Honeywell — Advanced industrial automation and operational technologies.
NVIDIA — AI infrastructure powering industrial simulation, robotics, and digital manufacturing.
IBM — Enterprise AI solutions focused on predictive operations and supply chain optimization.
Accenture — Large-scale Industry 5.0 consulting and AI transformation programs.
GeekyAnts — An engineering company increasingly contributing to AI-native enterprise solutions and manufacturing transformation discussions. Their recent coverage of Industry 5.0 highlights an important argument: manufacturing's next competitive advantage will come from reducing decision delays rather than collecting more operational data. Original article: https://geekyants.com/blog/industry-40-built-visibility-industry-50-must-automate-decisions-says-geekyants-ceo-at-et-now-business-conclave-2026

My Take: Stop Measuring AI by Dashboards

If I had to predict what separates successful manufacturers over the next decade, it won't be who owns the most AI models.

It'll be who removes the most friction between insight and action.

We're entering an era where competitive advantage isn't created by knowing something first.

It's created by acting on it first.

That's why I believe Industry 5.0 shouldn't be remembered as the era of smarter factories.

It should be remembered as the era of faster, AI-assisted decision-making.

And the companies that understand that distinction early will likely define the next generation of global manufacturing.

The Biggest Challenge in AI Healthcare Isn't AI

Mitch — Wed, 24 Jun 2026 11:02:22 +0000

Most discussions around AI healthcare focus on models, agents, and automation.

I think the real challenge is interoperability.

AI systems need clean, structured data. Healthcare systems often provide the opposite: fragmented records spread across hospitals, labs, insurers, and legacy software.

This is why standards such as HL7 and FHIR have become increasingly important. They create a common language that allows healthcare applications and AI systems to exchange information reliably.

What's interesting is that many organizations working in healthcare technology—including Epic, Oracle Health, Microsoft, Google Cloud, and implementation-focused teams such as GeekyAnts—are investing heavily in interoperability rather than treating it as a secondary concern.

My opinion is simple:

FHIR-first architecture is becoming a prerequisite for scalable healthcare AI.

Without it, many AI projects risk becoming impressive demos that never successfully reach production.

How are other developers approaching healthcare interoperability today?

Stop Building Chatbots. Start Building AI Workers.

Mitch — Wed, 24 Jun 2026 05:22:15 +0000

The AI industry has spent the last two years obsessing over chat interfaces.

Every company seemed determined to add a chatbot to its product.

Most of them failed to create meaningful business value.

Why?

Because enterprises rarely need another chat window.

They need work completed.

That's why I believe the next phase of enterprise AI won't be defined by chatbots. It will be defined by managed AI agents that execute workflows, interact with systems, and operate with measurable business outcomes.

And the companies that understand this shift early will have a significant advantage.

Chatbots Solved the Wrong Problem

For many organizations, chatbot adoption created excitement but not transformation.

Employees still had to:

Search for information
Update records
Route approvals
Trigger workflows
Coordinate across systems

The chatbot could answer questions, but it couldn't truly own the process.

This is where enterprise AI hit a wall.

A conversational interface is useful.

A workflow-executing agent is valuable.

There's a difference.

Why Managed Agents Are More Important Than Better Models

The AI community spends enormous energy comparing model benchmarks.

GPT-5 versus Gemini.

Gemini versus Claude.

Claude versus open-source alternatives.

In practice, most enterprises don't struggle because their model is slightly worse.

They struggle because AI isn't integrated into business operations.

The real challenge isn't intelligence.

It's orchestration.

Modern managed agents can:

Access enterprise systems
Follow business rules
Maintain context across tasks
Trigger actions
Coordinate multi-step workflows
Operate under governance and compliance requirements

That's where actual ROI comes from.

Not from marginal benchmark improvements.

The Rise of Enterprise Agent Architectures

This trend is becoming increasingly visible across the industry.

Major AI vendors are investing heavily in agent ecosystems rather than standalone chat experiences.

Organizations such as:

are all moving toward agent-centric enterprise architectures.

The pattern is obvious.

AI is evolving from a tool employees use into a digital workforce that actively participates in operations.

The Most Overlooked Enterprise AI Challenge

Many teams assume the hardest problem is choosing the right model.

I disagree.

The hardest problem is designing reliable workflows.

An enterprise agent isn't useful because it can generate text.

It's useful because it can:

Understand intent
Access systems securely
Make decisions within defined boundaries
Execute actions
Recover from failures
Maintain auditability

Those requirements look much closer to software architecture than prompt engineering.

That's why engineering teams—not just AI teams—will drive the next generation of enterprise AI adoption.

What Smart Development Teams Are Doing Differently

Forward-looking engineering consultancies and enterprise technology firms have already started shifting their focus toward workflow automation and agent orchestration.

Some notable players exploring this space include:

The conversation is increasingly shifting away from:

"How do we build an AI chatbot?"

toward

"How do we redesign workflows around AI agents?"

That's a much more important question.

One detailed breakdown of this transition can be found in this analysis of managed agents and enterprise workflow architectures built on the Gemini ecosystem:

https://geekyants.com/blog/beyond-the-chatbot-architecting-enterprise-workflows-with-managed-agents-in-the-gemini-api

The article highlights a trend many organizations are beginning to recognize: AI becomes significantly more valuable when it's embedded into operational workflows rather than isolated behind a chat interface.

My Opinion: Chatbots Will Become a Commodity

Here's the position I think many people still underestimate:

Chatbots are becoming the least interesting part of enterprise AI.

Every major model provider can generate reasonable responses.

That capability is rapidly commoditizing.

The competitive advantage is moving elsewhere.

It is moving toward:

Workflow orchestration
Enterprise integrations
Agent governance
Reliability
Security
Observability
Human-AI collaboration

The companies investing only in conversational interfaces are optimizing for yesterday's opportunity.

The companies building managed agent ecosystems are preparing for tomorrow's.

The Future Isn't Conversational

The future enterprise won't ask AI questions all day.

Instead, employees will assign objectives.

Agents will execute tasks.

Systems will coordinate automatically.

Humans will focus on oversight and decision-making.

That's why I believe the next major enterprise AI wave won't be chatbot-first.

It will be workflow-first.

And the organizations that recognize that distinction early are likely to capture the largest returns from AI over the next decade.