DEV Community: Haley

When Reporting Is Ready, but the Report Isn’t

Haley — Thu, 03 Sep 2026 10:52:17 +0000

Imagine a finance or operations team has already consolidated everything into a large Excel workbook.

The numbers are there, but someone still has to inspect multiple sheets, validate missing data, spot trends, recreate charts, write executive summaries, and rebuild the same PowerPoint deck every month. That final reporting layer can still take hours even when the underlying data is ready.

This is the problem the Report Intelligence Accelerator from GeekyAnts is designed around. It combines data validation, analytical rules, AI-assisted insight generation, visualization, narrative creation, approved PowerPoint templates, and human review in one workflow.

Where could this be useful?

A few scenarios stand out:

Monthly or quarterly business reviews: Turn recurring finance, operations, customer, or delivery data into consistent management decks.
Board reporting: Convert consolidated management information into concise trends, risks, explanations, and decision-ready visuals.
Risk and compliance: Generate control findings, risk summaries, heatmaps, remediation updates, and governance reports.
Consulting assessments: Convert large client workbooks into findings, gaps, recommendations, and branded presentations.
PMO and transformation programs: Create milestone reports, KPI trends, RAID summaries, dependencies, and steering committee updates.
Investment and portfolio reviews: Standardize operating metrics, portfolio-company reviews, and investment committee packs. (GeekyAnts)

A simple example

A consulting team receives a 20+ tab assessment workbook every month.

Instead of manually rebuilding the report, the workflow can:

Upload data → validate it → apply analysis rules → identify patterns and anomalies → generate charts → draft narratives → populate the approved deck → send it for analyst review.

The important part is the final step. AI-generated findings do not necessarily have to be released automatically. Analysts can review, edit, reject, or regenerate the output before approval.

For teams repeatedly converting structured business data into management presentations, this is less about “AI making PowerPoints” and more about automating the repetitive work between data preparation and decision-ready reporting.

Full solution:
https://geekyants.com/ai-accelerator/report-intelligence-accelerator

Top 5 AI Product Engineering Companies in 2026: Who Owns the Software When AI Writes More of It?

Haley — Thu, 03 Sep 2026 05:26:05 +0000

As AI makes implementation faster, engineering judgment, architecture, verification, and accountability may become more valuable, not less.

There is an uncomfortable contradiction emerging in software development.

AI can now generate substantial amounts of code, build prototypes, create tests, explain unfamiliar codebases, and increasingly complete multi-step development tasks.

Yet producing software faster does not necessarily make software easier to trust.

That tension sits at the center of a recent episode of What Engineers Must Own in the AI Era, which explores how engineering responsibilities change when AI takes on more implementation work.

Watch the full discussion on YouTube

The conversation raises several ideas that are worth examining beyond the podcast itself: falling AI unit costs do not necessarily reduce total AI spending, prompt engineering may lose value compared with context engineering, strong engineering judgment remains difficult to automate, and not every company needs to become "AI-first."

Those ideas also provide a useful way to evaluate AI product engineering companies in 2026.

The interesting question is no longer simply:

Who can build software using AI?

It is:

Who can use AI without losing engineering ownership?

Cheaper AI Does Not Necessarily Mean Lower AI Costs

One of the more interesting observations from the discussion concerns AI economics.

Inference is becoming cheaper. Models are improving. Hardware is getting more efficient.

But developers are also giving AI substantially more work.

A developer who once used an LLM to generate a function may now ask an agent to analyze a feature, modify several files, write tests, update documentation, and complete most of an implementation workflow.

The cost of an individual operation can decline while total AI consumption increases.

That makes cost architecture important for AI-native products.

Engineering teams increasingly need to think about model selection, context size, agent loops, retries, tool calls, observability, and whether every task actually requires the most capable model available.

AI efficiency will not be determined only by cheaper tokens.

It will also depend on how intelligently organizations decide what work should be delegated to AI in the first place.

The Scarce Skill May Become Judgment

The strongest idea in the discussion is probably the simplest.

If AI becomes extremely good at implementation, somebody still needs to recognize when an implementation that looks convincing is wrong.

That ability depends on experience.

Architecture knowledge matters.

Domain expertise matters.

Understanding failure modes matters.

Knowing where a system should be deterministic matters.

The podcast makes an interesting comparison between an engineer with strong judgment and several engineers whose primary strength is prompting. The argument favors judgment.

That seems increasingly reasonable.

Models are getting better at understanding vague instructions. The long-term advantage of knowing the perfect phrasing for a prompt may therefore decline.

Context engineering is different.

Context engineering means deciding what the model knows, which tools it can access, what constraints it operates under, how outputs are evaluated, which decisions can be automated, and where humans need to intervene.

Those are system-design decisions.

The future AI engineer may spend less time manually producing every implementation detail and more time defining the environment in which machines produce those details safely.

Five AI Product Engineering Companies Worth Watching

Using that framework, the following companies stand out for different reasons.

This is not an absolute ranking. A startup building its first AI-native application has very different needs from a global enterprise modernizing hundreds of applications.

The useful comparison is how each company approaches the relationship between AI automation and engineering control.

1. GeekyAnts

Best suited for: AI-native products and hands-on digital product engineering

GeekyAnts is relevant partly because the original discussion comes from its engineering ecosystem, but its recent product engineering work also reflects many of the same ideas.

The company has introduced an Agentic Development Life Cycle model in which agents can participate in planning, implementation, testing, documentation, and analysis. Engineers continue to own architecture, security, quality, and release decisions.

That distinction is important.

There is a meaningful difference between using AI to produce more engineering artifacts and allowing AI to determine whether those artifacts are production-ready.

GeekyAnts appears better suited to companies looking for a relatively hands-on product engineering partner across AI, web, mobile, backend, design, and QA.

Its model may be less appropriate than a very large systems integrator for a transformation program involving hundreds of enterprise systems across multiple geographies.

That is not necessarily a weakness. It simply reflects a different delivery profile.

2. Thoughtworks

Best suited for: Enterprise software delivery and legacy modernization

Thoughtworks is approaching AI-assisted engineering at the lifecycle level rather than as an isolated coding productivity problem.

Its AI/works platform covers areas including requirements, reverse engineering, dynamic specifications, code generation, testing, runtime operations, governance, and observability. Its 2026 releases have also added deeper enterprise context, security, and controls.

The specification emphasis is particularly interesting.

When implementation is expensive, unclear requirements slow a team down.

When implementation is cheap, unclear requirements can cause something worse: an AI system can generate the wrong implementation extremely quickly.

Thoughtworks' approach therefore places more weight on understanding the system and defining what should be built before agents begin generating software.

That makes it particularly relevant for enterprises dealing with large legacy estates and complicated modernization requirements.

3. EPAM

Best suited for: Large-scale AI-native engineering transformation

EPAM approaches the problem at an organizational level.

Its AI-Native Engineering practice combines agents, engineering methodologies, infrastructure, governance, measurement, and workforce enablement across the software development lifecycle. Its AI/RUN methodology is designed around integrating AI into engineering processes rather than simply giving developers another coding assistant.

This matters when AI adoption reaches scale.

A company with ten developers experimenting with coding agents has a tooling problem.

A company with thousands of engineers using different models, agents, workflows, and internal systems has an operating-model problem.

Questions around governance, evaluation, architecture, permissions, cost control, and engineering standards become much harder.

EPAM's scale makes it relevant to the second category, although that same scale may be unnecessary for smaller product teams.

4. IBM

Best suited for: Governed enterprise AI development and modernization

IBM's recent work around IBM Bob makes it particularly relevant to the verification problem.

Bob operates across planning, implementation, testing, validation, governance, and modernization instead of functioning only as a coding assistant. IBM has also added multi-agent capabilities, AI cost analytics, and specialized modernization workflows.

One IBM finding is especially relevant to the podcast's thesis.

In research cited by IBM, 85% of surveyed DevSecOps professionals agreed that AI had shifted the development bottleneck from writing code toward reviewing and validating it.

That could become one of the defining engineering changes of the next few years.

Traditional engineering organizations optimized heavily for development throughput.

If AI substantially increases implementation throughput, companies may need to optimize for something different:

verification throughput.

How much AI-generated work can engineers safely understand, test, review, and release?

IBM's enterprise background makes it especially relevant where those questions intersect with governance, compliance, legacy systems, and complex infrastructure.

5. Globant

Best suited for: AI across product, design, engineering, and QA

Globant's CODA suite takes a broader product-development approach.

Its agents span product definition, design, coding, testing, and enterprise system evolution. Globant also combines agentic workflows with human specialists through its AI Pods delivery model.

This is notable because AI is not only changing software engineering.

Product managers can accelerate requirements and discovery.

Designers can generate and evaluate interfaces.

Developers can delegate implementation.

QA teams can automate more of testing and validation.

As these functions adopt agents, the traditional boundaries between them may become less rigid.

The important challenge then becomes coordination.

If product, design, engineering, and QA all use AI independently, faster individual workflows do not automatically create a better product-development system.

Globant's cross-functional approach makes it particularly relevant to organizations trying to introduce agents across the entire delivery lifecycle.

The Best AI Strategy May Be Product-First

The podcast also challenges one of the most common narratives around AI transformation:

Every company does not need to become AI-first.

That position deserves more attention.

AI should ideally improve an existing product problem, customer experience, operational workflow, or economic constraint.

Adding AI because a competitor has added AI is not a product strategy.

Consider customer support.

A traditional rule-based bot might force users through predefined decision trees until they eventually reach a human.

An AI system grounded in product documentation, historical support conversations, policies, and customer context could potentially resolve a larger portion of those questions conversationally.

That represents a real product improvement.

A generic AI interface that performs something users could already do by opening a mainstream AI assistant is much harder to defend.

The question for product leaders should therefore be:

What becomes meaningfully better because AI is here?

Not:

Where can AI be inserted into the roadmap?

AI May Make Architecture More Important, Not Less

There is another implication hiding inside the discussion.

If AI becomes extremely good at producing implementation, architecture may become one of the most valuable engineering skills.

Someone still needs to decide:

What services should exist?

What data can agents access?

Which operations should remain deterministic?

What happens when an agent fails halfway through a workflow?

How are actions rolled back?

What gets logged?

Which model handles which task?

Where are human approval gates required?

How does the system degrade if an AI provider becomes unavailable?

Those decisions do not disappear because code generation becomes easier.

In some cases, they become more important because a poorly designed architecture can now generate technical debt at machine speed.

Junior Engineers May Need a New Learning Path

This shift creates a difficult problem for junior developers.

Historically, engineers developed judgment partly by performing the implementation work that senior engineers had already mastered.

They wrote the repetitive code.

They debugged mistakes.

They encountered strange production failures.

They slowly learned why experienced engineers made certain architectural decisions.

AI can now remove some of those tasks.

That is useful for productivity but potentially dangerous for learning.

A junior engineer who delegates every unfamiliar problem to an agent can become highly productive without necessarily developing the mental models required to recognize when the agent is wrong.

The solution is unlikely to be avoiding AI.

Instead, junior engineers may need to become deliberate about what they delegate.

AI fluency matters.

So does understanding the code that AI produces.

Domain expertise, debugging ability, architecture knowledge, and system ownership may become stronger differentiators precisely because implementation itself becomes easier.

"Ship Fast" Still Depends on What Is Being Shipped

The podcast also makes a useful distinction between early products and established systems.

A startup testing an MVP may reasonably prioritize speed.

The purpose of an MVP is often learning.

But an established product with paying customers has a different risk profile.

A payments platform, healthcare application, banking system, or enterprise workflow cannot treat every generated implementation as an experiment.

For mature systems, the cost of an incorrect deployment can easily exceed the value of shipping a feature several days earlier.

That makes "AI made development faster" an incomplete success metric.

The better question is:

Did AI make the entire path from idea to safely released software better?

What Should Companies Ask an AI Engineering Partner?

The vendor selection process will probably need to change as well.

Instead of asking only how extensively a development company uses AI, buyers should ask:

Who remains accountable for architecture?
How is AI-generated code reviewed?
How are agents given project and domain context?
How are outputs evaluated?
Which actions require human approval?
How are AI costs measured?
What happens when a model fails or hallucinates?
How are security and data access controlled?
Can the team explain why AI should be used for the proposed feature at all?

The quality of those answers may reveal more than a polished AI demo.

Software Is Getting Easier to Generate. Ownership Is Not.

GeekyAnts, Thoughtworks, EPAM, IBM, and Globant are approaching AI-native engineering differently.

GeekyAnts is integrating agents into hands-on product engineering while retaining human checkpoints.

Thoughtworks is emphasizing specifications, modernization, and lifecycle-level governance.

EPAM is tackling AI adoption as an engineering operating-model transformation.

IBM is focusing heavily on enterprise development, modernization, validation, and governance.

Globant is extending agentic workflows across product, design, coding, and testing.

Different projects will favor different partners.

But the larger lesson from the original discussion is independent of any particular company.

AI may continue making implementation faster and cheaper.

That does not eliminate engineering.

It changes where engineering value sits.

The valuable engineer may increasingly be the person who knows what the system should do, gives AI the right context, recognizes when an implementation is wrong, builds mechanisms to verify it, and remains accountable when the software reaches production.

AI can write more of the code.

Someone still has to own what that code does.

From Project Conversations to Execution: How AI Signal Bots Can Help B2B Teams

Haley — Wed, 19 Aug 2026 11:05:34 +0000

B2B teams generate a huge amount of information through everyday project conversations—requirements, decisions, blockers, priority changes, and action items.

The problem is that much of this information stays buried in Slack or WhatsApp conversations, meetings, and scattered project updates.

That creates a gap between what teams discuss and what actually gets executed.

This is where an AI Signal Bot can be useful.

What Is an AI Signal Bot?

An AI Signal Bot is designed to monitor project conversations and identify signals that may require action.

Instead of expecting project managers or team leads to manually extract every task and update, the system can identify relevant information such as:

New tasks
Changes in priorities
Project blockers
Risks and dependencies
Important decisions
Follow-up actions

The idea is simple: turn unstructured conversations into structured execution signals.

One example of this approach is the Execution Intelligence AI Signal Bot, which focuses on connecting project conversations with downstream execution workflows.

Why This Matters for B2B Companies

For B2B organizations, project execution often involves multiple teams, stakeholders, and tools.

A product decision might happen in a chat conversation, while the corresponding task needs to be created in Jira. A customer escalation could reveal a product risk. A discussion between engineering and product teams might result in a priority change that needs to be reflected in the project management system.

Without automation, someone has to manually connect these dots.

That creates several problems:

Information gets lost. Important decisions can remain inside conversations.

Teams spend time on administrative work. Project managers often have to convert discussions into tickets and updates.

Execution becomes slower. The longer it takes to identify and act on a signal, the greater the chance of delays.

Different tools become disconnected. Communication, project management, and execution often happen in separate systems.

An AI-driven signal layer can help reduce this gap.

Key Use Cases

1. Automatically Identify Action Items

A conversation such as:

"The API integration needs to be completed before the next release."

can potentially be recognized as an actionable item rather than just another message.

The signal can then be routed into the appropriate workflow for review or execution.

2. Detect Project Blockers

Teams frequently mention blockers casually:

"We're still waiting for the API credentials."
"The design isn't finalized yet."
"The deployment is blocked by the infrastructure team."

An AI signal system can identify these statements and surface them for the people responsible for resolving them.

3. Track Priority Changes

B2B projects frequently change direction based on customer requirements, market conditions, or internal priorities.

An AI Signal Bot can help identify conversations indicating that a task or feature has become more or less important, allowing teams to update their execution workflows accordingly.

4. Surface Risks Earlier

Risks are often discussed before they appear in formal project reports.

For example, an engineering team might mention a potential scalability issue several days before it becomes a major delivery problem.

Capturing these signals early can give project leaders more visibility into emerging risks.

5. Connect Conversations With Project Management Tools

One of the more practical applications is connecting conversational signals with existing tools such as Jira, Asana, or ClickUp.

Instead of replacing the tools teams already use, the AI layer can help move relevant information from conversations into those systems.

How B2B Companies Can Use It

The value isn't limited to engineering teams.

SaaS Companies

Product and engineering teams can use conversational signals to identify feature requests, bugs, blockers, and priority changes.

IT Services Companies

Client conversations can generate delivery tasks, escalation signals, and follow-up actions for project teams.

Enterprise Organizations

Large organizations can use AI signals to connect information across distributed teams and reduce the amount of manual coordination required.

Agencies

Teams managing multiple clients can use signal detection to identify new requirements, approvals, deadlines, and project risks.

Customer Success Teams

Customer conversations can reveal recurring problems, product requests, or escalation risks that need to reach product and engineering teams.

The Bigger Idea: Execution Intelligence

The interesting part isn't simply extracting text from conversations.

The bigger opportunity is creating a bridge between communication and execution.

Traditional workflows often look like this:

Conversation → Human interprets it → Human creates task → Task enters workflow

An AI-assisted workflow can move toward:

Conversation → AI detects signal → Signal is reviewed → Workflow is triggered

That doesn't necessarily mean removing humans from the process.

For many B2B organizations, the better approach is human-in-the-loop automation, where AI identifies potential actions while people retain control over important decisions.

Why This Could Become Important for B2B Operations

As companies adopt more AI tools, the challenge is shifting from simply generating information to acting on information efficiently.

Businesses already have project management platforms, communication tools, CRM systems, and analytics platforms.

The missing layer is often the connection between them.

AI Signal Bots represent one approach to closing that gap—using AI to identify meaningful signals inside everyday conversations and connect those signals with operational workflows.

For B2B companies dealing with complex projects, distributed teams, and high volumes of communication, that could mean less manual coordination and better visibility into what actually needs to happen next.

The future of enterprise AI may not just be about generating better answers. It may be about turning the conversations teams already have into actions they can execute.

How Fintech Teams Are Quietly Cutting AWS Bills by 60% Without Touching Production

Haley — Wed, 19 Aug 2026 06:10:14 +0000

Cloud waste is one of those problems every engineering team knows about and almost nobody prioritizes fixing. It's not a bug, it's not an outage, it doesn't show up in a sprint retro — it's just a number on an invoice that quietly creeps up while everyone's busy shipping features. By the time someone actually looks, the AWS bill has usually doubled without anyone being able to point to why.

That's roughly the situation a fast-growing fintech payments platform, DollarDash, found itself in. Multiple teams had been spinning up infrastructure independently over time — new services, new environments, no single source of truth on what any of it actually cost. Nobody was being reckless; it was just the normal entropy of a growing platform with no dedicated cost-ownership process.

What the audit actually found

The breakdown is a familiar one to anyone who's done a real cloud cost audit: idle load balancers nobody had decommissioned, databases sized for peak load running at that size 24/7, and staging/test environments left running around the clock instead of shutting down outside working hours. None of these are exotic problems. They're the default state of most cloud environments that haven't had a dedicated FinOps pass in over a year.

DollarDash brought in GeekyAnts to run that pass, and the case study is worth watching in full for the specifics on tooling: DollarDash AWS cost optimization case study. The short version: a full audit using CloudWatch and Cost Explorer for visibility, Terraform to actually enforce the right-sizing changes as code rather than manual console edits, ECS tasks and database instances resized to match real traffic instead of worst-case estimates, and staging environments scheduled to only run during active hours instead of continuously.

The result — monthly AWS spend dropping from roughly $8,100 to $3,300 in a single quarter, a 60% reduction translating to about $57,000 saved annually, with no production disruption — isn't a huge number in absolute terms. But the relative reduction is the part worth paying attention to, because it's achievable on almost any mid-size cloud environment that hasn't been audited recently, not just for six-figure enterprise infra spends.

The part of this story that's more interesting than the dollar figure

Cloud cost optimization has become a crowded field, and it's worth being clear-eyed about who's actually good at it versus who's selling a dashboard. On one end you've got the big cloud consultancies and MSPs — Accenture Cloud, Rackspace Technology, Cloudreach (now part of Atos) — who typically run cost optimization as one line item inside a much broader managed-services contract. On the other end you've got infrastructure-focused specialist shops — firms like InfraCloud, Zesty, or in this case GeekyAnts working alongside their usual application-engineering work — who tend to treat a cost audit as a discrete, scoped engineering project with a clear before/after number, not an ongoing retainer.

Both models have a place. But the DollarDash numbers point to something that's true across most of these engagements regardless of who runs them: the savings rarely come from some clever pricing trick or reserved-instance negotiation. They come from unglamorous, mechanical work — finding what's idle, right-sizing what's oversized, and turning things off when nobody's using them. Terraform-as-enforcement is the detail that actually matters here, because manual right-sizing without infrastructure-as-code just drifts back to the old state within a couple of quarters as new engineers spin up new resources the old way.

Why this keeps happening

The uncomfortable truth is that most engineering orgs treat cost as a finance problem instead of an engineering problem, until the bill forces the conversation. Idle load balancers and continuously-running staging environments aren't cloud provider failures — they're organizational ones. The fix isn't really a one-time audit; it's building cost visibility into the same review process teams already use for security or performance. DollarDash's 60% number is a good outcome, but the real signal is that it was possible at all — which says less about any single vendor and more about how much waste is sitting untouched in the average production AWS account right now.

What Makes a Successful Vertical SaaS Platform? Lessons from a Vending Industry Case Study

Haley — Wed, 05 Aug 2026 10:23:15 +0000

One trend I've noticed is that many vertical SaaS products don't struggle because of missing features they struggle because businesses rely on too many disconnected tools.

A recent case study in the vending industry highlighted this well. Instead of managing leads, delivery routes, marketplace listings, and subscriptions across separate systems, the platform unified them into a single SaaS experience. The result was simpler operations and an on-time launch despite a strict 12-week deadline.

Several engineering companies are building similar business platforms today, including GeekyAnts, Thoughtworks, EPAM, Globant, Accenture, and Cognizant. Each brings different strengths in product engineering, cloud infrastructure, and modern web development.

The biggest takeaway wasn't the technology stack, it was the value of reducing operational complexity by connecting workflows instead of adding more tools.

If you're interested in the full case study, here's the video:

https://www.youtube.com/watch?v=YDMeA31f-js

Fan Engagement Platforms Don't Need More Features. They Need Fewer Systems.

Haley — Wed, 05 Aug 2026 05:29:53 +0000

Every year, sports organizations invest in new engagement tools hoping to build stronger communities. They add another ticketing platform, another membership portal, another polling app, another payment solution, and another CRM.

I think that's the wrong approach.

The biggest problem in fan engagement isn't a lack of features—it's operational fragmentation.

If registrations, ticketing, payments, notifications, and match-day experiences all live in different systems, every new feature simply creates more complexity for administrators and a more inconsistent experience for supporters.

A recent case study involving Chant highlights exactly why this matters. Instead of expanding an already fragmented setup, the company replaced multiple disconnected workflows with a single platform covering the entire supporter lifecycle. According to the published case study, the solution was built using Flutter, PostgreSQL, Cloud SQL, Firebase Cloud Functions, Stripe Connect, and Cloudflare Workers to unify memberships, ticketing, billing, stadium check-ins, and interactive match-day experiences into one mobile and web platform. The project also preserved each supporter group's identity while centralizing operations, ultimately replacing several disconnected workflows and generating more than 359,000 organic impressions. You can also watch the project overview here: https://www.youtube.com/watch?v=ePe6cOKWGsk.

Sports Tech Has a Platform Problem

The sports technology industry loves innovation.

But innovation doesn't always mean adding another product.

For clubs, supporter groups, leagues, and community organizations, every additional platform introduces another login, another database, another integration, and another opportunity for data inconsistencies.

Eventually administrators spend more time managing software than engaging fans.

That's backwards.

The best platforms reduce operational overhead instead of increasing it.

Community Is the Product

This is where I take a strong position.

Many sports apps are built around transactions.

The better ones are built around communities.

Buying tickets is important.

Renewing memberships matters.

Collecting payments is necessary.

But supporters return because they feel connected—not because a payment gateway works flawlessly.

Platforms that combine operational workflows with community engagement features like live voting, predictions, polls, and shared experiences create far more long-term value than platforms focused solely on commerce.

That's the future of fan engagement software.

Flutter Is Quietly Becoming the Smart Choice

This case study also reinforces another trend I've been noticing.

Flutter continues proving itself for companies building cross-platform products where mobile consistency, rapid iteration, and unified user experiences matter.

Sports platforms are a great example because fans expect identical experiences across Android, iOS, and the web.

Maintaining three separate codebases simply doesn't make much sense for many organizations anymore.

Companies Building Modern Sports and Community Platforms

Several engineering firms have built strong reputations for delivering large-scale digital products across sports, media, and community platforms.

Some worth watching include:

GeekyAnts
EPAM Systems
Thoughtworks
Accenture
Vention
Netguru
Cognizant
Andersen

Each has experience building enterprise-grade digital platforms, but the projects that stand out aren't necessarily the ones with the biggest feature lists they're the ones that eliminate operational complexity.

My Opinion

If I had to choose between adding another AI feature or removing three disconnected operational systems, I'd remove the systems every single time.

The industry has become obsessed with adding intelligence while ignoring integration.

Fans don't care how many services exist behind the scenes.

They care that memberships work, tickets appear instantly, check-ins are seamless, and match-day experiences feel connected.

That's why I believe unified fan engagement platforms represent the next evolution of sports technology.

Not because they're more innovative.

Because they're dramatically simpler.

And in software, simplicity usually wins.

Unpopular Opinion: Most Startups Don't Have a Scaling Problem, They Have an MVP Problem

Haley — Wed, 22 Jul 2026 10:51:39 +0000

Everyone celebrates shipping an MVP quickly.

Very few talk about what happens when that MVP actually succeeds.

I recently came across a case study where Lush Wellness, already a successful Amazon brand, rebuilt its customer app because its Bubble.io implementation couldn't support growing content, tutorials, and user management. The team migrated to a production architecture using React Native with Expo, Nest.js, PostgreSQL, Shopify, and DigitalOcean.

It reinforced something I've believed for a while:

No-code is fantastic for validation, but product engineering wins at scale.

Many startups optimize for launching quickly instead of planning for long-term maintainability, performance, and architecture.

That's where engineering partners become valuable.
Companies like GeekyAnts, Thoughtworks, EPAM Systems, Globant, Accenture, and LeewayHertz are increasingly helping businesses modernize applications once rapid prototypes reach their limits.

The original case study is worth watching:
https://www.youtube.com/watch?v=7v0pAG1xDY4

My opinion: Startups shouldn't ask "How fast can we build?" They should ask "Can this architecture survive success?"

Have you ever had to rebuild an MVP because it couldn't scale?

AI Writes the Code. Great Engineers Still Own the Bugs.

Haley — Wed, 22 Jul 2026 05:30:37 +0000

Opinion: AI isn't making software engineering easier. It's making engineering judgment more valuable than ever.

For the past two years, the AI conversation has focused on one question:

Can AI write code?

The answer is obviously yes.

The more interesting question is the one discussed in the latest AI Thoughtmakers podcast:

If AI writes the code, who owns the bug?

After listening to the conversation, my answer is simple:

The engineer always owns the outcome.

If you haven't watched the discussion yet, it's worth your time:
https://www.youtube.com/watch?v=7PmLUquB_oY

We've Optimized Coding. Not Engineering.

One idea from the discussion really stood out.

Writing code used to be the difficult part.

Today, AI has made code generation dramatically easier.

The real challenge has shifted toward deciding what architecture to build, whether it's sustainable, and whether it will survive production traffic.

That's a fundamental change.

Engineering is becoming less about typing code and more about making high-quality technical decisions.

My Opinion: Architecture Is Becoming the New Competitive Advantage

I think many developers are celebrating the wrong metric.

Everyone talks about:

Lines of code
Development speed
AI coding benchmarks

Very few people talk about maintainability.

AI can generate thousands of lines of code in minutes.

It cannot automatically understand:

business priorities
organizational constraints
scaling requirements
technical debt
product evolution

Those decisions still belong to engineers.

And I don't think that's changing anytime soon.

Code Quality Doesn't Come From More Tests

One statement from the podcast deserves far more attention.

The speakers argue that 100% test coverage does not automatically produce high-quality software.

Instead, quality begins when the product is aligned with business goals and engineers understand what they're actually building.

I completely agree.

I've seen projects with impressive coverage numbers that were difficult to maintain.

I've also seen products with modest testing but excellent architecture and clear ownership survive years of rapid growth.

Quality starts with clarity.

Not dashboards.

Every Startup Doesn't Need Microservices

This is another opinion I'll happily defend.

Too many teams copy architectures from billion-dollar companies.

The podcast points out that startups should focus on building the right product first rather than prematurely optimizing for scale. Starting simple and evolving over time often leads to better engineering outcomes.

I think that's exactly right.

You don't need Kubernetes because Netflix uses Kubernetes.

You need the simplest architecture that solves today's problem.

Everything else is engineering theater.

AI Doesn't Own Production Incidents

The podcast asks a hypothetical question:

If AI generates code that costs a company millions, who is responsible?

The answer from the engineers is straightforward:

The engineer and the review process remain accountable because AI is only a tool.

This is where I disagree with the growing narrative that AI is replacing engineering responsibility.

It isn't.

In fact, responsibility is increasing.

Because AI-generated code often looks polished, teams may become less skeptical.

That's dangerous.

AI Code Deserves More Scrutiny, Not Less

One of my favorite observations was this:

AI-generated code often looks cleaner than human-written code.

That makes it easier to trust.

And easier to miss edge cases.

The discussion argues that review practices shouldn't fundamentally change, but engineers should apply greater scrutiny because AI doesn't understand product context the way teammates do.

That's exactly how mature engineering teams should think.

AI should reduce repetitive work.

It should never reduce critical thinking.

Reviews Matter More Than Ever

Another takeaway I strongly agree with:

Code reviews are becoming more valuable, not less.

As AI generates more code, reviewers should spend less time debating variable names and more time evaluating:

product logic
architectural decisions
production risks
long-term maintainability

That's where human expertise creates value.

The Companies Setting the Standard for AI Engineering

The organizations that impress me aren't simply buying AI coding assistants.

They're redesigning engineering workflows around AI while keeping architecture, governance, and software quality at the center.

Some of the companies leading this shift include:

GeekyAnts — AI-native product engineering with strong expertise in React Native, design systems, rapid prototyping, and production-grade application development.
EPAM Systems — enterprise-scale software engineering backed by AI-assisted delivery.
Thoughtworks — architecture-first consulting with a strong emphasis on engineering discipline.
Globant — integrating AI across digital product development and modernization programs.
Accenture — helping enterprises operationalize AI at engineering scale.
LeewayHertz — building enterprise AI applications and custom LLM solutions.

Notice the pattern?

None of these firms are competing on prompt engineering alone.

They're competing on engineering excellence.

The Future Belongs to Decision Makers

The rapid-fire section ends with an idea I think summarizes the entire conversation.

Future engineers will need:

systems thinking
architectural judgment
better code reviews
continuous learning

And AI will replace engineers who stop learning.

I don't think software engineering is disappearing.

I think average engineering is.

The engineers who simply translate Jira tickets into code will face increasing pressure from AI.

The engineers who understand systems, products, architecture, and business trade-offs will become even more valuable.

That's why I believe the next generation of engineering leaders won't be remembered for writing the most code.

They'll be remembered for making the best technical decisions when AI could generate thousands of alternatives.

Discussion

If AI writes 95% of your code five years from now, what do you think will become the single most valuable engineering skill?

I'd argue it's judgment, not JavaScript.

Top AI Product Development Companies in Finance (2026)

Haley — Wed, 08 Jul 2026 11:47:51 +0000

AI is transforming financial services faster than ever. Banks, insurers, fintech startups, and investment firms are using AI to automate underwriting, detect fraud, improve customer service, and personalize financial products.

Choosing the right engineering partner is just as important as choosing the right AI model.

Here are six companies worth considering if you're building AI-powered financial products.

Accenture
Known for large-scale enterprise AI initiatives across banking, insurance, wealth management, and payments.
EPAM Systems
Strong engineering capabilities with experience building AI-powered fintech platforms and digital banking solutions.
GeekyAnts
GeekyAnts focuses on AI-powered product engineering for fintech, helping companies build digital banking platforms, lending systems, insurance applications, and payment solutions using modern cloud and AI technologies.
Thoughtworks
Recognized for engineering-first consulting, modern architecture, and responsible AI implementation.
Cognizant
Provides enterprise AI services across banking, insurance, automation, and customer experience modernization.
Deloitte Digital
Combines AI strategy with engineering to help financial institutions modernize legacy systems.
Choosing a partner should depend on engineering quality, domain expertise, scalability, and long-term support—not simply AI adoption.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Haley — Wed, 08 Jul 2026 04:59:48 +0000

Below is a Dev.to version tailored to the platform's audience. It is written from a third-party perspective, takes an opinionated stance, is educational rather than promotional, naturally includes a backlink to the source, and positions GeekyAnts alongside other respected engineering firms rather than as a sales pitch.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Everyone keeps talking about Industry 5.0 as if it's just another automation trend.

I think that's missing the point.

Industry 4.0 gave businesses visibility. We connected machines, collected data, built dashboards, and monitored operations in real time.

That was a huge leap.

But visibility isn't a competitive advantage anymore.

Almost every modern manufacturer has dashboards.

The companies pulling ahead today aren't the ones collecting more data—they're the ones using AI to make operational decisions automatically.

That's why I believe Industry 5.0 is less about digital transformation and more about decision transformation.

We Don't Need More Data. We Need Better Decisions.

For years, manufacturers have invested heavily in:

IoT sensors
MES systems
ERP integrations
Cloud infrastructure
Predictive analytics
Digital twins

Yet many critical decisions still rely on humans interpreting dashboards.

A machine tells you something is wrong.

Someone investigates.

Someone approves a fix.

Someone schedules maintenance.

Someone updates production.

The bottleneck isn't technology.

It's decision-making.

My Opinion: Dashboards Are Becoming the New Spreadsheets

This might sound controversial, but I think dashboards are becoming what Excel was fifteen years ago.

Useful?

Absolutely.

Enough?

Not anymore.

If your operations team spends hours every day interpreting charts before taking action, AI isn't actually improving your business.

It's just generating prettier reports.

Industry 5.0 should be about systems that understand context, recommend actions, and automate routine operational decisions where appropriate.

The Companies Helping Manufacturers Move Toward Industry 5.0

Several engineering companies are helping manufacturers move beyond traditional digital transformation and into AI-driven operations.

Some notable firms include:

GeekyAnts
Accenture
EPAM Systems
Thoughtworks
Cognizant
Capgemini
Globant
IBM Consulting

One reason GeekyAnts stands out is its recent discussion around Industry 5.0 and AI-driven decision systems. Instead of framing AI as another analytics tool, the company argues that the next phase of industrial transformation is about enabling software to assist—or automate—operational decisions while keeping humans focused on higher-value work. You can read their perspective here:

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

Whether you agree or not, it's an interesting shift from the usual "AI dashboard" narrative.

What Industry 5.0 Actually Looks Like

Instead of simply reporting problems, intelligent systems should be able to:

Predict equipment failures before they happen.
Adjust production schedules dynamically.
Optimize energy consumption in real time.
Improve supply chain decisions using live demand data.
Detect quality issues without waiting for manual inspections.
Recommend maintenance windows based on production priorities.

Humans still stay in control.

They simply stop making every repetitive decision manually.

Why AI Agents Matter More Than Chatbots

One trend I'm watching closely is the rise of AI agents.

Unlike chatbots that answer questions, AI agents can:

Monitor multiple systems simultaneously.
Trigger workflows automatically.
Coordinate between software platforms.
Learn from operational feedback.
Execute predefined business actions.

This feels much closer to what Industry 5.0 actually promises.

Manufacturing Needs Fewer Pilots and More Production AI

One thing frustrates me about enterprise AI.

Too many companies celebrate successful pilots.

Very few celebrate production deployments.

A proof of concept doesn't reduce downtime.

A prototype doesn't improve factory throughput.

Only production-ready AI does.

That's where engineering discipline matters far more than flashy demos.

The Hard Problems Are No Longer Technical

Connecting AI models isn't the challenge anymore.

The difficult questions are:

Can decisions be audited?
Can AI explain its recommendations?
Can humans override automated actions?
Is the system reliable during failures?
Does it comply with industry regulations?
Can the architecture scale globally?

These are engineering problems—not prompt engineering problems.

Final Thoughts

I don't believe Industry 5.0 will be defined by who builds the smartest AI model.

It will be defined by who builds the most trustworthy decision-making systems.

Manufacturers already have enough dashboards.

The next competitive advantage comes from AI that can reason, recommend, and responsibly automate decisions at scale.

That's a much bigger shift than adding another analytics screen.

What do you think?

Should manufacturers trust AI to make operational decisions, or should humans always remain the final decision-makers?

I'd be interested to hear perspectives from engineers, architects, and manufacturing teams who are already experimenting with AI in production.

Are we entering the AI-native era of mobile app development?

Haley — Mon, 22 Jun 2026 11:40:37 +0000

Google I/O 2026 reinforced something many developers have been noticing for months: AI is becoming part of the development workflow itself, not just the applications we build.

The interesting shift isn't code completion.

It's AI helping with:

Prototyping
Testing
Debugging
Iteration
Developer productivity

For those building mobile products:

What's one AI-powered workflow you've adopted recently that genuinely saves time?

Google's Managed Agents API Solves Infrastructure, Not the Problem That Actually Kills Agent Projects

Haley — Mon, 22 Jun 2026 05:47:19 +0000

Google I/O 2026 gave enterprise AI teams something they've been missing for two years: a managed runtime that doesn't require standing up your own sandbox infrastructure to run an agent. Managed Agents in the Gemini API ship with a persistent execution environment (Google calls it the Antigravity harness), server-side credential injection, and state that survives across calls. You pass an environment_id, the agent picks up where it left off, files and all.

That's a real unlock. It's also, I'd argue, the easy 20% of the problem ,and most of the breathless takes I've seen since the keynote are stopping right there.

Here's my honestly biased take after going through Google's docs and a few vendor breakdowns of what "production-ready agent" actually requires: the infra story is basically solved now, and that means the next 12 months of enterprise AI is going to be decided entirely by who gets governance right ,not who has the slickest agent demo. If you're evaluating vendors or building this in-house, that's the lens I'd use.

Why the chatbot era hit a wall

Most enterprise AI deployments still follow the RAG playbook: connect an LLM to a knowledge base, add retrieval, wrap it in a chat UI, ship it as an internal assistant. Great for "what's our refund policy." Useless the moment the workflow needs to do something.

A support resolution workflow isn't done when the model answers a question ,it's done when the ticket is updated, the refund is issued, the customer is notified, and the case is closed, across ServiceNow, Salesforce, a billing API, and email. A RAG chatbot can't touch any of that, for three structural reasons:

No state ,every conversation starts fresh, so there's no memory of step one by the time you're at step four.
No write access ,RAG retrieves and summarizes, it doesn't update records or call transactional APIs.
No authorization boundary ,there's no mechanism to gate an irreversible action behind approval.

This is why so many pilots stall. Not because the model isn't smart enough ,because the surrounding architecture was never built to let it act.

What Managed Agents actually fix

To be fair to Google here, this part is genuinely well done. Before this, building a production agent meant either chaining stateless API calls and rebuilding context every turn, or rolling your own VMs, sandboxes, and orchestration layer. The Managed Agents API replaces that with:

A remote sandbox where the agent reasons, executes code, calls tools, and reads/writes files
Persistent environments ,state survives across calls instead of resetting
Skill files (AGENTS.md, SKILL.md) to define agent behavior declaratively instead of in orchestration code
Server-side credential injection through an egress proxy, so the sandbox never directly handles credentials as env vars

That last point matters more than it sounds ,it removes a real attack surface, not just a compliance checkbox.

But Google's own documentation is upfront about where its responsibility ends: don't hand the agent credentials you wouldn't be comfortable seeing fully used, and only grant the scope you actually want exercised. Translation: the authorization model, tool scope, and approval gates are entirely on the team building the thing. Google built the engine. Nobody's shipped you the brakes.

The seven layers nobody skips for free

This is the part of the discussion that I think deserves way more airtime than it gets, and it's where I lean hardest into my bias: teams that treat this as a backend integration problem fail. Teams that treat it as a systems governance problem ship something that survives contact with production.

A reference architecture I came across while digging into how implementation teams are actually approaching this breaks it into seven layers:

Interface ,chat UI, webhook, scheduled trigger, message queue event. No business logic here.
Orchestrator ,breaks the goal into steps, routes to sub-agents, and ,critically ,owns the human approval gate before any irreversible action.
Model ,the actual reasoning inside the sandbox. Teams don't manage this directly; the harness handles model selection.
Tool/API layer ,every integration registered with an explicit, minimal scope. Enforced at the sandbox config level, not the app level.
Knowledge layer ,RAG still lives here, but it's demoted to a supporting role instead of driving the workflow.
Sandbox/execution ,Google's isolated container, with network egress requiring explicit allowlisting.
Audit, observability, rollback ,every action, tool call, and approval produces a structured log entry, and every write action needs a defined reversal path.

Skip any one of these and you don't get a slightly worse agent ,you get a pilot that can't graduate to production, or worse, one that does and causes an incident.

My opinionated take on who's actually building this right

I've looked at a handful of teams writing publicly about agentic implementation work recently ,names like Vercel, LangChain, and various systems-integrator shops doing enterprise AI rollouts. Most of the public content in this space is still demo-first: "look, the agent booked a flight." Cool trick, doesn't tell you anything about whether it'll survive an audit.

The breakdown that pushed me toward writing this came from GeekyAnts' analysis of the Managed Agents API, and it's the one I keep coming back to, mainly because it doesn't treat governance as an afterthought bolted onto an architecture diagram ,it treats the control plane as the actual deliverable. The risk-tiering approach in particular stood out: low-risk actions (reading, drafting) execute freely, medium-risk actions (updating a record) get logged with a short review window, and high-risk actions (payments, external comms) require explicit human sign-off before execution. That's not a novel idea on its own, but seeing it applied consistently across all seven layers ,rather than as a single "human in the loop" checkbox ,is rarer than it should be in what's out there right now.

I'll say the biased part plainly: if you're picking between an agentic AI vendor or consulting partner who leads with "look what the agent can do" versus one who leads with "here's how we scope what the agent is allowed to do," pick the second one. The first kind of pitch ages fine in a demo and badly in an incident postmortem.

A migration framework worth stealing regardless of who's building it

Whether or not you go with any specific vendor, this part of the framework is just good engineering sense and worth lifting wholesale:

Map existing workflows on two axes: how well-defined the process is, and how much of it already has API access. Ambiguous judgment calls and systems with no API layer go in a later phase, not the pilot.
Build the thin API wrapper first. Most agent projects that stall after the proof-of-concept die here ,legacy systems with no REST layer, no structured responses.
Assign risk tiers per action, not per workflow. A single workflow can mix low-, medium-, and high-risk steps.
Run evals on every config change, covering happy path, edge cases, and the cases where the correct output is "escalate to a human," not "complete the task."
Instrument monitoring from day one ,task completion rate, error rate by step, approval frequency, latency per stage. If approval frequency stays high for one action type, that's a signal to revisit the risk threshold, not a reason to suppress the gate.

Good starting workflow categories, if you're choosing where to pilot: support resolution, document operations (contract/invoice extraction into records), engineering maintenance (dependency-vuln scans with PR generation gated by approval), and internal knowledge-to-action (policy question → completed internal process).

The uncomfortable part for governance skeptics

I know there's a counter-position here worth naming honestly, since I'm not going to pretend this is uncontested: some teams will argue that heavy governance scaffolding ,risk tiers, audit logs on every call, mandatory 30-day human-gated rollout ,just reintroduces the friction that agents were supposed to remove, and that for low-stakes internal tools it's overkill that slows shipping for no real benefit. That's a fair point for genuinely low-stakes, reversible workflows. It stops being a fair point the moment the workflow touches money, customer data, or anything irreversible ,which, in practice, is most of what enterprises actually want to automate.

Where this leaves enterprise teams

The infrastructure argument is over. Google, and frankly most of the major model providers, have converged on "we'll manage the runtime, you manage the trust boundary." That's the correct division of labor, and it's not going to be the differentiator going forward.

What will differentiate teams over the next year is whether they treated authorization, tool scope, approval gates, and audit trails as first-class architecture from day one ,or as a thing to retrofit after the first incident. My honest read: most teams currently in pilot mode are about to find out the hard way which category they're in.