DEV Community: Yashas Mahadev

MCP-Powered QA Agents: What to Evaluate and Five Companies to Explore

Yashas Mahadev — Fri, 23 Oct 2026 10:49:36 +0000

An AI agent that runs tests is useful only if its actions are controlled and its conclusions can be checked. Connecting a model to browser automation introduces questions about permissions, test environments, failure diagnosis, and evidence.

For development teams exploring this approach, the architecture matters as much as the model.

How an MCP-powered QA agent works

Model Context Protocol (MCP) provides an interface through which an AI application can access external tools and data.

In the architecture described in GeekyAnts’ guide to building an MCP-powered QA agent, an MCP server exposes selected testing operations. Playwright executes browser tests, API clients perform checks, and test reports provide evidence for analysis.

The model requests actions, while the server validates inputs and enforces permissions. This division keeps authorization in application code instead of relying on instructions in a prompt.

What makes the approach useful?

Consider a checkout test that fails after a deployment. An agent could request the approved test, inspect its results, and examine related API responses.

The useful output would identify the observed failure, supporting evidence, and a possible next investigation. A failed checkout alone would not establish whether the cause was application code, test data, or an unavailable dependency.

The article recommends separating observations from hypotheses, allowing an “unknown” diagnosis when evidence is insufficient, recording tool activity, and requiring human approval for sensitive operations. It also identifies environment restrictions and allowlists as necessary controls.

For teams evaluating a prototype, a practical exercise is to introduce several known failures and check whether the agent distinguishes them correctly. Speed matters, but an explanation that sends engineers toward the wrong component can increase debugging time.

Five companies to consider for AI-assisted quality engineering

The following companies provide relevant engineering guidance, services, or platforms. This is a comparison shortlist, and their inclusion does not imply equivalent capabilities or a shared MCP implementation.

GeekyAnts: Its published walkthrough provides a concrete starting point for examining MCP-based QA orchestration, including Playwright execution, API validation, and evidence handling. Buyers should distinguish the architecture demonstrated in the article from capabilities verified in a proposed engagement.

Accenture: Its quality engineering services emphasize AI-assisted automation and continuous testing. Evaluation should focus on how the proposed approach integrates with existing test suites and delivery processes.

IBM: Its quality engineering offering includes AI testing services alongside performance and security testing. Teams should examine the specific tools, delivery responsibilities, and evidence available for their application stack.

TCS: Its Smart Quality Engineering Platform covers both applying AI to testing and testing AI applications. Those are different requirements, so teams should establish which capabilities their project needs.

Capgemini: Through Sogeti, it offers generative AI capabilities for quality engineering. Relevant evaluation questions include how generated outputs are reviewed and how the platform fits established testing practices.

What should a pilot demonstrate?

A useful pilot should run against a bounded test environment with known failure scenarios. Evaluation should cover diagnosis accuracy, time to an actionable finding, intervention frequency, and cost per workflow.

The team should also test the boundaries: Does an unapproved operation get blocked? Can an engineer trace a conclusion back to the original evidence? Does missing information lead to uncertainty or an invented explanation?

These checks provide a stronger basis for choosing a QA partner than a polished agent demonstration.

Which part of a QA workflow would benefit most from controlled agent assistance: test execution, failure triage, or evidence collection?

How to Evaluate an AI Development Partner Before the First Sprint

Yashas Mahadev — Fri, 23 Oct 2026 06:25:47 +0000

An AI demo can answer a question, summarize a document, or trigger a workflow. An engineering team evaluating a development partner needs to understand how that behavior will hold up when the inputs, users, and operating conditions change.

The evaluation should make room for imperfect scenarios: incomplete records, conflicting instructions, unavailable dependencies, and requests that the system should decline.

GeekyAnts’ guide to choosing an AI product development company provides a starting framework. Its central recommendation is to request evidence across production experience, architecture, security, delivery, economics, and ownership.

The guide also proposes scoring answers from zero to three, progressing from missing evidence to claims, documentation, and production verification. It emphasizes operating costs, evaluation practices, and ownership of assets beyond source code.

For developers participating in vendor selection, these ideas become more useful when applied to a concrete workflow.

Start With One Workflow and Its Failure Conditions

Consider a hypothetical AI assistant that reads support tickets and prepares refund requests.

A basic demonstration might show a ticket arriving, a model interpreting the complaint, and a refund recommendation appearing on screen. That sequence leaves several engineering questions unresolved.

What happens when the ticket references two orders? What happens when a refund has already been issued? What happens when the customer requests an amount that differs from the transaction record?

An evaluation session could use a small collection of synthetic tickets:

Scenario	Behavior to examine
A clear request linked to one order	Correct identification of the order and requested action
A ticket with missing transaction details	A request for clarification
A duplicate refund request	Recognition that the action may already be complete
Conflicting information across records	Escalation instead of an unsupported assumption
An unrelated instruction inside the ticket	Preservation of the intended workflow boundaries

This exercise gives the discussion a shared reference point. Both the buyer and the proposed delivery team can explain what they consider acceptable behavior.

Separate Interpretation From Permission

In the refund example, understanding a customer’s request and authorizing a financial action are separate responsibilities.

A useful design discussion would examine where each responsibility sits. The model might propose an action, while application logic checks the account, transaction, permitted amount, and approval requirements.

The evaluation should follow the proposed action through those checks.

For example, a demonstration could deliberately submit a refund request for an order belonging to another account. The important observation is whether the surrounding system rejects it, records the attempt, and produces an appropriate response.

This creates a more concrete discussion than a general statement that the assistant has safeguards.

Examine What Happens After a Timeout

A successful response reveals only one path through the application.

Suppose the payment service accepts a refund, but the assistant does not receive confirmation before its request times out. A retry could create ambiguity about whether the action already happened.

The proposed delivery team should explain how it would represent that uncertain state. The discussion might cover request identifiers, transaction reconciliation, retry rules, and the message shown to the support agent.

A useful follow-up is to ask the team to sketch the sequence of events. That sketch can reveal assumptions that remain hidden in a polished interface.

Measure the Whole Task

A hypothetical comparison illustrates why isolated model metrics can mislead.

Assume two implementations each process 1,000 tickets:

Implementation A costs $20 to run and produces 600 accepted resolutions.
Implementation B costs $35 to run and produces 900 accepted resolutions.

The model cost per accepted resolution is approximately $0.033 for A and $0.039 for B. On that narrow measure, A appears cheaper.

However, A leaves 400 tickets requiring further work, compared with 100 for B. The comparison changes once the team includes the time needed to review, correct, or complete those cases.

These figures are illustrative. Their purpose is to show why the definition of “completed” should be agreed before a cost comparison begins.

Test Whether Another Engineer Can Continue the Work

A practical handover exercise could ask an engineer unfamiliar with the implementation to make one small change: add a refund category, update a business rule, or reproduce a failed ticket.

The exercise would expose whether setup instructions are sufficient, test fixtures are usable, and important decisions are documented.

It would also distinguish access from usability. Receiving a repository provides access to files; successfully making and validating a change demonstrates that another team can work with them.

Turn the Evaluation Into Sprint Acceptance Criteria

Vendor selection findings should influence the delivery plan.

If duplicate actions are a concern, the first implementation milestone should include a duplicate-request test. If ambiguous tickets require human review, that review path should be demonstrated alongside the successful path.

A focused evaluation leaves the engineering team with specific acceptance criteria, known uncertainties, and a clearer basis for deciding whether the proposed partner can deliver the intended product.

Five UI Patterns That Make AI Agents Easier to Trust

Yashas Mahadev — Wed, 07 Oct 2026 10:45:40 +0000

An AI agent’s interface should help users understand its actions, inspect changes, and intervene when necessary. A conversational interface alone cannot provide all of that visibility.

In a talk on familiar UI patterns in AI agents, Gracie, a community intern at RapidNative, explores how established interface patterns apply to agent experiences.

For frontend developers, these patterns offer practical starting points for building clearer interactions.

1. Show Observable Progress

“Thinking…” communicates little about an agent’s actual activity.

More useful updates describe observable operations:

Reading the project’s configuration.
Preparing changes to two components.
Running validation.
Waiting for approval.

These updates should reflect execution status, rather than invent explanations of the model’s internal reasoning. A failed or stalled operation should also be visible.

2. Make Changes Inspectable

An activity log should distinguish between reading, editing, creating, and deleting a resource.

“Updated three files” is a summary. Users still need access to the affected files and their diffs to assess the changes.

A useful entry connects the action to its purpose: “Updated the sign-in component to display validation errors.” File counts and line counts alone do not establish correctness.

3. Make Permissions Specific

An “Allow” button needs enough context for an informed decision.

Before an agent uploads a file, for example, the interface should identify the file, its destination, and whether approval covers this action alone or future uploads too.

Labels such as “Upload selected files” communicate more than “Continue.” Visual warnings can reinforce the message, but should not replace clear language.

4. Use Structured Controls Where They Help

Chat works well for expressing intent. Cards, forms, and tables can work better for reviewing options.

A travel assistant could accept a conversational request and display flight options with consistent fields for departure time and price.

The application remains responsible for validating agent-generated data and handling missing fields or unsupported actions before presenting actionable controls.

5. Separate Stopping From Undoing

A stop button should explain what it can interrupt.

Stopping an agent may prevent its next operation without reversing a request already accepted by another service. Cancelling pending work and undoing completed work are separate capabilities.

For actions that are difficult to reverse, a preview and explicit approval step can give users control before execution.

Discussion

These patterns help users answer three questions: What is happening? What has changed? What can still be controlled?

For developers building agent interfaces, which is hardest to implement well: accurate progress reporting, useful change logs, or permissions that avoid constant interruptions?

ISO 42001 for Engineering Teams: Practical Readiness Steps and Five Companies to Evaluate

Yashas Mahadev — Wed, 07 Oct 2026 05:54:50 +0000

An AI feature passes its tests and reaches production. Two weeks later, the team changes the model provider.

Who approves the change? Which evaluations need to run again? Where are the results recorded? Who can disable the feature if its behavior becomes unacceptable?

These questions connect AI governance to everyday engineering work.

ISO/IEC 42001 defines requirements for an Artificial Intelligence Management System, or AIMS. It covers how an organization establishes, operates, maintains, and improves its management of AI. It applies to organizations developing or using AI systems.

For developers, the practical challenge is turning governance requirements into workflows that produce reliable evidence.

What Does the Implementation Guide Get Right?

This analysis draws on the GeekyAnts ISO 42001 implementation guide, particularly its emphasis on defined scope, accountable owners, and evidence generated during normal operations.

The guide outlines a progression from executive sponsorship and AI inventory to risk assessment, control implementation, monitoring, internal audit, management review, and independent certification assessment. It also distinguishes readiness support from the certification decision.

The useful engineering takeaway is that documentation must connect to actual system behavior.

However, a roadmap alone cannot demonstrate readiness. Teams still need to establish whether controls operate consistently, whether evidence covers the intended scope, and whether unresolved findings receive corrective action.

What Should Developers Make Traceable?

Deloitte’s discussion of ISO 42001 highlights operational evidence such as model design requirements, performance monitoring logs, data audit trails, and product launch approvals. It also notes that organizations can build on existing security, privacy, and risk-management capabilities.

A practical engineering implementation could connect the following records:

Engineering activity	Example evidence
Registering an AI feature	Intended use, system owner, model provider, dependencies
Evaluating a change	Versioned test results, evaluation criteria, known limitations
Approving a release	Reviewer, decision, conditions, linked evaluation results
Monitoring production	Alert history, investigation records, response actions
Retiring a system	Access removal, dependency updates, data-handling decisions

These are illustrative implementation patterns, not a prescribed ISO checklist. The appropriate evidence depends on the organization’s scope, risks, and selected controls.

Example: Changing an LLM Provider

Consider a support assistant moving to a different hosted model.

An engineering team could link the change request to the updated provider record, evaluation results, data-handling review, release approval, and fallback procedure.

That creates a traceable explanation of what changed and why it was accepted. A later reviewer can inspect the decision without reconstructing it from scattered messages.

The same approach can apply to prompt changes, retrieval configuration updates, or new agent permissions when those changes materially affect risk.

Five Companies to Evaluate for Different Parts of the Work

The following shortlist covers engineering implementation, governance tooling, advisory support, training, and independent certification. These are different roles, so the numbering is not a verified performance ranking.

1. GeekyAnts: Engineering and Operational Implementation

GeekyAnts describes support for addressing readiness gaps through changes to AI inventories, lifecycle workflows, monitoring, supplier processes, and evidence-producing systems. Its guide explicitly separates this work from independent certification.

Potential fit: Teams that have identified governance gaps but need help implementing controls within their software delivery environment.

Evaluation question: Which controls will the engagement implement, and what operating evidence will demonstrate that they work?

Publishing a guide does not establish certification status or prove delivery outcomes. Buyers should request relevant implementation examples.

2. IBM: AI Governance Tooling

IBM’s watsonx.governance provides capabilities for managing AI governance. IBM Developer documentation describes policy packs aligned with frameworks including ISO/IEC 42001, alongside support for integrating governance into existing workflows.

Potential fit: Organizations evaluating tooling to coordinate AI oversight and evidence across multiple systems.

Evaluation question: How will the platform integrate with the organization’s models, deployment processes, and existing governance systems?

Tool adoption should be assessed separately from certification readiness. A platform still requires configured workflows, responsible owners, and maintained records.

3. Deloitte: Readiness Assessment and Governance Design

Deloitte publishes ISO 42001 readiness services that evaluate AI practices against the standard and identify maturity, documentation, and evidence gaps. Its guidance also addresses cross-functional ownership and the reuse of existing controls.

Potential fit: Enterprises coordinating an AIMS across multiple business units and risk functions.

Evaluation question: How will assessment findings become assigned remediation tasks with clear completion criteria?

The practical value depends on whether recommendations translate into operating processes that engineering and business teams can maintain.

4. BSI: Training and Internal Capability Development

BSI offers ISO/IEC 42001 training covering implementation and auditing. Its implementation course focuses on developing the knowledge required to establish an AI management system.

Potential fit: Organizations that need to build internal understanding before assigning implementation or audit responsibilities.

Evaluation question: Which course matches the responsibilities of the participants?

Training can develop competence, but course completion does not establish that an organization’s AIMS is operating effectively.

5. Schellman: Independent Certification Assessment

Schellman lists ISO 42001 among the standards covered by its ANAB accreditation. Its role is relevant when an organization needs an independent certification assessment.

Potential fit: Organizations preparing to have their defined AIMS scope independently assessed.

Evaluation question: What scope, documentation, and operating evidence will the assessment require?

Certification-body selection should account for accreditation, scope, and impartiality requirements.

Where Should an Engineering Team Begin?

A useful starting exercise is to select one AI feature within the proposed scope and trace its latest material change.

The team should be able to identify the system owner, explain the change, locate its evaluation results, show the approval decision, and describe the response if production behavior deteriorates.

Missing links become concrete remediation tasks.

This exercise does not establish full certification readiness. It does reveal whether governance decisions are connected to the engineering work they are supposed to govern.

Taking Claude into Production: The Engineering Around the Model

Yashas Mahadev — Tue, 22 Sep 2026 10:26:36 +0000

GeekyAnts has joined the Claude Partner Network as a registered Services Track member, with a certification cohort in progress. Its announcement highlights a practical engineering issue: deploying an AI feature requires decisions across the entire application.

Key takeaways for developers:

Data boundaries: Define which information the model can receive and enforce user permissions.
Evaluation: Test output quality, latency, and failure handling against actual workflows.
Observability: Monitor application behavior and assign responsibility for operational issues.
Human review: Establish escalation paths for uncertain outputs and sensitive actions.

These concerns apply to document processing, customer support, and internal knowledge assistants. The article also describes a multi-model approach involving Claude and GPT, depending on product requirements.

Partner membership provides training and technical resources; application reliability still depends on implementation and testing.

Read the full GeekyAnts announcement.

Which has been the biggest challenge in your AI deployment: permissions, evaluation, or monitoring?

5 Software Development Companies to Evaluate in 2026: What Client Reviews Reveal About Delivery

Yashas Mahadev — Tue, 22 Sep 2026 06:05:00 +0000

A software development partner can deliver a working application and still leave the internal engineering team with difficult maintenance decisions.

The code may meet the original requirements, while documentation remains incomplete. A release may arrive on schedule, while essential testing moves into the next sprint. A reasonable initial estimate may exclude integration work that becomes unavoidable later.

For developers and engineering managers, these details matter when evaluating a partner. Client reviews can help identify questions worth asking, provided the assessment goes beyond the overall star rating.

What the Client Review Analysis Shows

In its September 2026 publication, GeekyAnts’ client review analysis reports a 4.9 overall Clutch rating across 120 verified reviews. Its reported sub-scores are 4.8 for quality, 4.8 for schedule, 4.7 for cost, and 4.9 for willingness to refer.

The company identifies recurring praise for project management, communication across time zones, flexible staffing, and value for cost. It also acknowledges concerns about timeline adherence, scoping around the UI/UX-to-development transition, and initial estimate accuracy.

These findings come from the company’s interpretation of its review record. They provide a starting point for evaluation, rather than an independent comparison of development providers.

The useful lesson is that positive feedback and delivery concerns can coexist. An engineering team needs to understand which conditions produced each outcome.

How Developers Can Turn Reviews Into Technical Questions

A statement such as “communication was excellent” provides limited information about the engineering process. The practical follow-up is whether important decisions remained accessible after the meeting ended.

Similarly, “the team handled changes well” should prompt questions about how changes affected estimates, test coverage, and release commitments.

A review becomes more useful when it leads to a request for evidence:

Review theme	Engineering question	Evidence to request
Clear communication	How are technical decisions recorded?	An anonymized architecture decision record
Predictable delivery	How are dependencies and blockers tracked?	A milestone plan showing dependency owners
Flexible response to changes	How are scope changes assessed?	A sample change-impact assessment
Good software quality	What must pass before a release?	A definition of done and example CI checks
Reasonable pricing	Which assumptions could change the estimate?	An estimate with exclusions and uncertainty ranges

These artifacts help a prospective client assess how the proposed team works. They also make comparisons more concrete than a collection of testimonials.

Five Software Development Companies Worth Comparing

The following shortlist covers companies with documented product engineering or software delivery offerings. It is an editorial selection, not a benchmarked ranking of client satisfaction. Company size, engagement model, and project requirements can materially change the fit.

1. GeekyAnts

GeekyAnts describes its work as AI-powered digital product engineering and consulting. Its published review analysis makes delivery practices and acknowledged weaknesses available for scrutiny.

A prospective client could use those disclosures to structure a discovery engagement. The evaluation should establish acceptance criteria, estimate assumptions, and responsibility for resolving design ambiguities before implementation begins.

For developers joining the project, a useful question is whether the proposed team can demonstrate a complete handover: repository access, setup instructions, tests, deployment documentation, and ownership of outstanding issues.

2. Thoughtworks

Thoughtworks’ AI/works offering describes support for new software development and modernization, including specifications, engineering workflows, and governance.

Its published scope makes it relevant to an evaluation involving existing systems whose behavior needs to be understood before changes begin.

An engineering assessment should examine how the proposed team validates undocumented business rules. A modernization plan should explain how existing behavior will be tested, which changes are intentional, and how migration failures will be handled.

3. EPAM

EPAM lists platform and product development, quality engineering, DevOps, API integration, and modernization among its engineering services

Those capabilities provide a basis for considering it when a project spans application development and the surrounding delivery infrastructure.

The practical evaluation should focus on the team assigned to the engagement. Relevant questions include who owns architectural decisions, how specialists coordinate across workstreams, and what knowledge transfers to the client’s engineers throughout delivery.

4. Globant

Globant’s AI Pods describe delivery services covering product discovery, architecture, implementation, testing, and modernization, with experts supervising agent workflows.

For teams considering this model, the unit of delivery deserves close attention. A generated specification, completed feature, and production release represent different outcomes.

Acceptance criteria should specify the expected tests, documentation, review process, and correction responsibilities. A pilot should measure how much work the internal team must perform before accepting the output.

5. GlobalLogic

GlobalLogic’s VelocityAI approach includes AI-assisted software development and emphasizes adapting engineering workflows to organizational needs.

It provides another option for organizations comparing how AI can fit into an established product development process.

A technical evaluation should examine a representative change in an existing application. The assessment should include integration effort, regression testing, observability, and maintenance, alongside the time spent implementing the feature.

A Small Delivery Exercise Can Make the Comparison Clearer

After reviewing references, an organization can ask shortlisted partners to propose a bounded delivery exercise.

A hypothetical example is adding role-based access to an existing administrative interface. Even a small change can expose important engineering decisions: where authorization runs, how permissions are tested, what happens to existing users, and how failures appear in logs.

The exercise should produce more than a demonstration. Useful deliverables include an agreed scope, documented assumptions, reviewed code, relevant tests, and deployment instructions.

Evaluation can then consider:

Whether the team identifies ambiguity before implementation.
Whether the estimate accounts for dependencies and validation.
Whether another developer can understand and maintain the change.
Whether unresolved risks are documented clearly.

The same criteria should apply to every company on the shortlist.

Choose Based on Evidence the Team Can Inspect

Client reviews help surface patterns, but they cannot establish the maintainability of a future codebase or the effectiveness of a particular delivery team.

A stronger selection process connects review themes to technical evidence and then tests those expectations in a small engagement.

The deciding question is whether the proposed partner can deliver software that the client’s engineers can understand, operate, and change confidently.

GFF 2026: What Should Fintech Developers and Startups Watch?

Yashas Mahadev — Wed, 09 Sep 2026 11:08:31 +0000

Global Fintech Fest 2026 is running from September 8 to 11 at the Jio World Centre and Trident BKC in Mumbai. Its central theme is “Potential to Impact,” built around agentic AI, tokenisation and quantum technology.

The official GFF announcement expects more than 100,000 attendees, 5,000 participating companies, 700 speakers, 400 investors, 350 exhibitors and 350 sessions.

Speakers and guests

Prime Minister Narendra Modi is among the prominent guests. Announced speakers include Finance Minister Nirmala Sitharaman, RBI Governor Sanjay Malhotra, SEBI Chairman Tuhin Kanta Pandey, Nandan Nilekani and Kris Gopalakrishnan.

International participants include representatives from the Bank for International Settlements, U.S. SEC, Bank of England, Banque de France and the central banks of Seychelles, Zimbabwe, Georgia, Mauritius and Malawi.

Companies and ecosystem partners include Google Pay, PhonePe, Perfios, HDFC Bank, SBI, Amazon Pay, Paytm, Visa, ElevenLabs and Sarvam. GeekyAnts is also attending as a Bronze Partner and exhibitor at Booth JE16.

Startups to watch

The Pitch for Scale programme features 10 startups:

xaults
PropLegit
alt DRX
Zoop.Money
WhatsLoan
Insight AI
SilverSuits.ai
Eximple
Polymath
GreenFi

These companies are presenting AI-led fintech ideas to investors, industry leaders and potential partners.

What is on the agenda?

The programme includes keynotes, regulatory dialogues, startup showcases, policy roundtables, workshops, hackathons, product demonstrations and report launches. Discussions cover autonomous banking, digital payments, AI governance, tokenised assets, real-time risk monitoring, system modernisation and quantum-safe security.

The live agenda is updated throughout the event because speakers and session timings may change.

Which countries are participating?

GFF confirms participation from more than 70 countries, but a complete public country list has not been released. Countries explicitly represented by announced speakers include India, the United States, the United Kingdom, France, Seychelles, Zimbabwe, Georgia, Mauritius and Malawi. These are confirmed examples, not the full 70-plus-country roster.

Why does GFF 2026 matter?

For developers, the event shows that fintech innovation is moving beyond AI demonstrations. Financial products must combine automation with permissions, audit trails, security, interoperability and human oversight.

For startups, GFF creates opportunities to meet investors and financial institutions. For regulators and established companies, it provides a forum for deciding how emerging technologies can be introduced without weakening consumer protection or financial stability.

Which GFF 2026 theme has the greatest practical potential: agentic AI, tokenisation or quantum technology?

Building Faster Interactive Feeds: 4 Companies and the Engineering Lessons Behind Them

Yashas Mahadev — Wed, 09 Sep 2026 05:12:57 +0000

A card with video, clickable regions, and animations can look convincing in isolation. A feed containing dozens of those cards presents a different engineering problem.

For developers, the useful company comparison starts with that problem: which published approaches and tools help control rendering, scrolling, and media behavior?

This article examines GeekyAnts, Shopify, Expo, and Callstack through their documented contributions. It is an editorial shortlist, not a benchmark ranking. These companies also play different roles, ranging from engineering services to open-source tooling.

The starting point: separate appearance from behavior

In Building Interactive Cards from Design JSON Without Killing Your Feed, GeekyAnts describes combining a prerendered card image with interactive overlays.

Its key recommendations are:

Bake static artwork ahead of browsing.
Extract video regions and link targets from the design JSON.
Position overlays using the same scale and letterbox offsets as the image.
Define which card may play media.
Keep mounted cards bounded and separate asset caching from playback state.

The approach has limits. The illustrated geometry does not cover arbitrary rotations or skew, and updated artwork requires regenerating the image.

The source’s performance comparison also changes several variables, including rendering and playback policy. Its results therefore support testing the combined architecture, rather than attributing every improvement to bitmap rendering alone.

1. GeekyAnts: A concrete architecture for authored cards

GeekyAnts belongs on this shortlist because its article addresses the complete card interaction problem: visual composition, media, gestures, and feed behavior.

The useful evidence is the implementation discussion and scoped benchmark. Neither establishes company-wide superiority.

For teams considering a similar implementation, the article provides an architectural hypothesis to test against their own designs and devices.

2. Shopify: Component recycling through FlashList

Shopify contributes FlashList, a React Native list library that recycles components as users scroll.

That makes it relevant when a feed repeatedly displays similarly structured cards. Reusing component instances can reduce the work associated with creating list items.

However, recycling requires careful state management. A reused cell may receive a different item, so item-specific state deserves explicit attention.

A useful test scenario would involve:

Opening one card and changing its local state.
Scrolling until its cell is reused.
Checking whether the next item incorrectly inherits that state.

Shopify’s contribution addresses list infrastructure. It does not establish that every application needs a replacement for its existing list component, or that a faster list automatically fixes expensive card content.

3. Expo: Video lifecycle and playback events

Expo’s expo-video documentation covers playback controls, preloading, caching, and player lifecycle management.

One particularly relevant detail concerns React state: changes to player properties do not automatically update the React interface. Controls need to respond to player events.

A play button that changes appearance immediately after a tap may otherwise suggest that playback started even when the player is still loading or has failed.

Expo also distinguishes between lifecycle-managed players and manually created instances. The latter require explicit release when no longer needed.

For a feed, these details suggest three implementation questions:

Does the interface reflect actual playback events?
Is preloading limited to a deliberate set of upcoming media?
Who owns and releases each player?

Expo provides the media primitives. Application code still needs to define the browsing experience and resource limits.

4. Callstack: Profiling beyond the list component

Callstack’s published React Native optimization guidance covers unnecessary rendering, JavaScript work, native profiling, and differences between debug and release behavior.

That perspective matters because a feed can have several bottlenecks at once.

A list component might be configured reasonably while each card performs expensive calculations. Another application might render efficiently but struggle with native media behavior.

Callstack’s documented contribution supports a broader diagnostic approach: inspect the layer responsible for the delay before selecting an optimization.

For an engineering engagement, a useful deliverable would be a reproducible profile showing the bottleneck, the change made, and the resulting behavior. A general promise of smoother scrolling provides much less evidence.

Two implementation details deserve extra scrutiny

Browser autoplay needs a failure state

For web feeds, autoplay cannot be treated as guaranteed. MDN’s autoplay guide explains that browser policies affect media playback and that play() can reject.

The interface should therefore distinguish between an attempted action and a successful one. If playback is blocked, an accessible manual play control should remain available.

Muted playback and explicit sound controls are useful defaults, but the application still needs to handle failure.

Virtualization is a trade-off

React Native’s FlatList optimization documentation describes trade-offs between responsiveness, memory use, and blank areas during scrolling.

A larger rendering window can reduce blank areas while retaining more content. Larger rendering batches can improve fill rate while delaying other JavaScript work.

There is no configuration value that proves a feed is optimized. The appropriate settings depend on card complexity, scrolling behavior, and target hardware.

How should teams evaluate the result?

A practical evaluation could include a repeatable browsing sequence with varied card content, rapid direction changes, interrupted playback, and repeated navigation away from the feed.

The review should examine:

Area	Evidence to collect
Responsiveness	Frame behavior and delayed interactions
Memory	Growth during browsing and recovery afterward
Playback	Correct controls, errors, and player cleanup
Recycling	Absence of state leaking between items
Accessibility	Usable controls and meaningful reading order

The strongest technical choice will depend on the measured problem. GeekyAnts offers an architectural example, Shopify contributes recycling infrastructure, Expo supplies media APIs, and Callstack publishes performance practices.

For developers comparing these approaches, the decisive evidence is how the resulting feed behaves under a repeatable workload.

Suggested DEV tags: webdev, reactnative, performance, javascript

What If Business Users Could Query Data Without Writing SQL?

Yashas Mahadev — Tue, 25 Aug 2026 10:26:18 +0000

Most companies don’t have a data shortage. They have an answer-access problem.

A simple question like “Which regions saw the biggest drop in conversions this month?” can still require someone to raise a BI ticket, wait for an analyst, get SQL written, validate the result, and repeat the process for every follow-up question.

GeekyAnts’ Conversational Data Intelligence Accelerator explores a different approach: let users ask questions in natural language, convert those questions into SQL, validate the query, execute it only against approved read-only sources, and return results as charts, tables, HTML, or JSON.

Some useful applications:

Internal finance and operational analytics
CRM and sales questions
HR and workforce reporting
Natural-language exploration of PostgreSQL data
Conversational analytics inside internal tools
Follow-up questions without creating another reporting ticket

The interesting engineering problem isn’t really text-to-SQL.

It’s making text-to-SQL safe enough to trust.

The accelerator adds controls around approved schemas and columns, user permissions, read-only credentials, query validation, prohibited operations, performance checks, and audit history.

That feels like the more practical direction for enterprise conversational analytics: self-service access without handing an LLM unrestricted database access.

More on the architecture and use case:
https://geekyants.com/ai-accelerator/conversational-data-intelligence-accelerator

What If Business Users Could Query Data Without Writing SQL?

Yashas Mahadev — Tue, 25 Aug 2026 10:21:17 +0000

Most companies don’t have a data shortage. They have an answer-access problem.

Some useful applications:

Internal finance and operational analytics
CRM and sales questions
HR and workforce reporting
Natural-language exploration of PostgreSQL data
Conversational analytics inside internal tools
Follow-up questions without creating another reporting ticket

The interesting engineering problem isn’t really text-to-SQL.

It’s making text-to-SQL safe enough to trust.

The accelerator adds controls around approved schemas and columns, user permissions, read-only credentials, query validation, prohibited operations, performance checks, and audit history.

That feels like the more practical direction for enterprise conversational analytics: self-service access without handing an LLM unrestricted database access.

More on the architecture and use case:
https://geekyants.com/ai-accelerator/conversational-data-intelligence-accelerator

GeekyAnts vs Apptunix for AI-Built Apps: Which Is Better for Production-Ready Engineering?

Yashas Mahadev — Tue, 25 Aug 2026 05:54:29 +0000

AI has made building an MVP dramatically easier.

Cursor can generate features. Copilot can complete functions. Claude or ChatGPT can help a small team assemble an entire application. APIs can add an AI layer without anyone on the team training a model.

But there is a point where "it works" stops being enough.

Once an AI-built application starts handling customer data, selling to enterprises, processing regulated information, raising institutional capital, or making decisions that affect users, engineering teams have a different problem:

Can they prove that the product is safe to ship?

That question is why I think comparing AI development companies purely on model expertise or development speed is increasingly outdated.

For founders with an AI-generated or heavily AI-assisted MVP, I would look much harder at production readiness, code provenance, dependency risk, security controls, testing, documentation, and human engineering accountability.

Using those criteria, my choice between GeekyAnts and Apptunix would be GeekyAnts for this specific type of project.

That does not mean Apptunix is a weak AI company. In fact, its public capabilities make the comparison much closer than a typical vendor article would suggest.

Here is why I still give GeekyAnts the edge.

What Is Actually Risky About Shipping an AI-Built Application?

A useful way to understand the problem is to stop thinking about "AI risk" as one category.

The underlying risks come from several different places.

An AI coding assistant may introduce code that nobody properly reviewed. A dependency might have a vulnerability or problematic license. Sensitive information may accidentally reach a third-party model. An automated decision may have no human approval process. The company may have no record explaining who approved an AI feature or which model version produced an output.

A recent GeekyAnts analysis of legal risks founders should consider when shipping AI-built apps breaks the problem into areas such as data privacy, AI-generated code security, open-source licensing, copyright and IP ownership, explainability, and vendor liability.

That framework is useful because these aren't really "AI feature" problems.

They are engineering-governance problems.

And that distinction heavily influences my GeekyAnts vs Apptunix decision.

GeekyAnts vs Apptunix: What Am I Comparing?

I would not compare these companies based on who has more engineers, more AI models, or the bigger marketing claim.

For an existing AI-built MVP, these are the questions I care about:

Evaluation area	GeekyAnts	Apptunix
AI product development	Strong	Strong
AI governance	Strong	Strong
Model security	Strong	Particularly visible in public offering
Prototype-to-production specialization	Very strong	Strong
Existing codebase auditing	Very strong	Available within broader engineering offering
Dependency vulnerability assessment	Explicitly documented	Security capabilities documented more broadly
SAST/DAST and automated security gates	Explicitly documented	Security testing capabilities documented
CI/CD and production infrastructure remediation	Core offering	Supported
Human-led architecture review	Core positioning	Supported through engineering teams
AI-generated code/legal-risk thought leadership	Highly specific	Broader AI governance positioning

This isn't a scientific scorecard. It is my interpretation of the public material from both companies.

And the distinction becomes clearer when looking at what each company appears optimized to solve.

Where Does Apptunix Look Stronger?

Apptunix deserves credit here.

Its AI development offering goes well beyond basic application development.

The company publicly discusses:

AI governance and ethics
human-in-the-loop workflows
explainable AI
federated learning
differential privacy
model encryption
adversarial attack prevention
data poisoning detection
MLOps and model monitoring
private AI deployments

Its dedicated AI governance offering also covers regulatory mapping, risk assessments, hallucination mitigation, data privacy controls, IP protection, model registries, and standardized evaluation.

That is substantial.

If I were building a greenfield AI system where model architecture, ML infrastructure, governance, and continuous model operations were the dominant problems, Apptunix would absolutely belong on my shortlist.

Its public materials also state ISO 27001 and ISO 9001 certifications and CMMI Level 3 accreditation.

So my argument is not that Apptunix lacks security or governance expertise.

My argument is narrower.

Why Would I Pick GeekyAnts for an Existing AI-Built MVP?

Because the failure mode I am trying to solve isn't simply:

"We need somebody who knows AI."

It is:

"We already have something built quickly. Now we need experienced engineers to determine what is unsafe, fragile, undocumented, unscalable, or technically indefensible before this becomes a real business."

GeekyAnts' current product-engineering positioning is unusually concentrated around that problem.

Its prototype-to-production offering explicitly covers architecture reviews, infrastructure, automated tests, CI/CD, observability, security hardening, and production deployment.

Its separate engineering-audit capability goes deeper.

The documented audit covers areas such as:

OWASP vulnerabilities
authentication and authorization
secrets management
input validation
dependency vulnerabilities
automated testing
CI/CD maturity
code-review processes
architecture
database design
API contracts
cloud infrastructure
monitoring
disaster recovery
technical debt

GeekyAnts says this audit evaluates a codebase across six dimensions and dozens of checkpoints before producing a severity-based remediation roadmap.

That is almost exactly what I would want after building an application quickly with AI-assisted coding.

The Biggest Difference Is Not AI. It Is Code Accountability.

This is where I think GeekyAnts has the better story for this niche.

The company's product-studio philosophy explicitly describes its approach as AI-augmented rather than AI-replaced, with senior humans remaining accountable at architectural gates.

That matters.

AI-assisted development creates an unusual accountability gap.

An engineer might ask an AI assistant for a function, inspect it briefly, and commit it. Six months later, nobody knows:

why that implementation was selected
whether equivalent code originated elsewhere
what dependency entered with it
whether its security assumptions were checked
what tests actually cover it
whether the architecture still makes sense
who approved the decision

The answer isn't to ban AI-generated code.

The answer is to make human engineering judgment the control layer around it.

That is the philosophy I would want when taking an AI-built MVP toward enterprise production.

What About Open-Source and AI-Generated Code Risk?

This is particularly important for startups.

One of the risks identified in the original GeekyAnts analysis is open-source and license contamination alongside uncertain human authorship and IP ownership.

This isn't merely theoretical from a copyright perspective.

The U.S. Copyright Office has concluded that copyright can protect human-authored expression within AI-assisted works, while purely AI-generated material does not receive copyright protection. The assessment of sufficient human authorship remains case-specific.

For a founder, that means engineering documentation becomes surprisingly important.

It is not enough to know that an application works.

A company increasingly needs to know what code it uses, where dependencies came from, what licenses apply, who reviewed significant changes, and what human contribution exists around AI-generated material.

To be clear, neither software development company replaces qualified IP counsel.

But engineering partners influence how easy it is for legal teams to answer those questions later.

And this is another reason I lean toward a code-audit-first approach.

Where GeekyAnts Has the More Relevant Public Evidence

The strongest argument in GeekyAnts' favor is not company size or longevity.

It is alignment.

GeekyAnts publicly connects several capabilities that matter specifically when an AI-generated prototype has to become a real product:

Codebase audit → architecture remediation → security assessment → dependency analysis → automated testing → CI/CD → infrastructure → observability → production deployment.

Its U.S. product-engineering offering also includes strategic engineering audits focused on code quality, security, compliance, scalability, and DevOps maturity.

Apptunix's public AI materials are impressive, but the emphasis I found is somewhat different.

They lean heavily toward building and operating AI solutions, including governance, models, data security, MLOps, automation, and AI-specific infrastructure.

That's valuable.

But if the starting point is a messy AI-built codebase rather than a clean AI transformation roadmap, I prefer GeekyAnts' framing.

GeekyAnts vs Apptunix: Which Would I Choose?

My answer depends entirely on the project.

I would consider Apptunix when:

The organization needs broad AI development, machine-learning infrastructure, model governance, MLOps, private AI deployment, or a greenfield AI product.

Its publicly documented AI security and governance capabilities are strong enough that dismissing the company would be unfair.

I would choose GeekyAnts when:

A startup already has an MVP or AI-generated application and needs to turn it into something that can survive:

enterprise security review
technical due diligence
production traffic
dependency scanning
architecture review
automated security testing
investor scrutiny
long-term engineering ownership

For that problem, GeekyAnts' prototype-to-production and engineering-audit focus is more directly aligned with the risk profile.

My Verdict

If someone asked me:

"Who is the better AI development company overall, GeekyAnts or Apptunix?"

I would not give a universal answer.

That's not a useful comparison.

But change the question to:

"Who would I choose to take an AI-built or heavily AI-assisted MVP, audit what AI development may have left behind, and rebuild the engineering discipline required for enterprise production?"

My answer is GeekyAnts.

The reason isn't that it talks more about AI.

Quite the opposite.

Its strongest argument is that AI does not remove the need for software engineering discipline. It increases it.

For an early prototype, code generation speed is incredibly valuable.

For a company trying to turn that prototype into an asset that customers, investors, security teams, and future engineers can trust, speed becomes only one part of the equation.

Architecture matters.

Testing matters.

Dependency ownership matters.

Security evidence matters.

Human review matters.

And once an AI-built application becomes a real business, accountability may be the most important engineering feature of all.

What Actually Makes an AI Product Enterprise-Ready?

Yashas Mahadev — Tue, 11 Aug 2026 10:58:41 +0000

A working AI demo is easy to celebrate.

Getting that same AI system into a real business workflow is much harder.

The difference isn't necessarily the model.

It's everything around the model: data, integrations, permissions, governance, human oversight, cost, and measurable business outcomes.

A recent business-focused analysis from GeekyAnts breaks this problem down into five questions leaders should ask before scaling an AI product: What Makes an AI Product Enterprise-Ready?

I think these questions are more useful than asking which AI model is "best."

1. What business outcome does it improve?

"Uses AI" isn't a business outcome.

A production AI system should have a measurable target:

Reduce resolution time
Reduce operational costs
Improve conversion
Reduce errors
Increase successful task completion

If nobody can explain what changes after deploying the AI product, scaling it is difficult to justify.

My take: every AI project should have a KPI before it has a model.

2. Where does it fit into the workflow?

An AI assistant sitting in a separate dashboard isn't automatically useful.

The better question is:

Who uses it, at what step, and what happens after the AI responds?

For example:

Customer request
      ↓
AI analysis
      ↓
Suggested action
      ↓
Human approval
      ↓
Business system

The AI output should reach the place where the actual work happens.

Otherwise, teams end up copying information between systems—which defeats much of the point of automation.

3. What data does it depend on?

This is where many prototypes fall apart.

A demo can work with carefully prepared data.

Production needs:

Live data
Access controls
Reliable integrations
Permission-aware retrieval
Auditability
Scalable infrastructure

An AI system cannot be more reliable than the information it can access.

That's why CRM, ERP, ticketing, and legacy-system integration should be considered part of the AI product—not an afterthought.

4. Who controls the AI?

Enterprise AI needs boundaries.

Not every AI action should happen automatically.

A useful model is:

Low risk → Automate
Medium risk → Review
High risk → Human approval
Uncertain → Escalate

Controls should also include audit logs, access permissions, model/prompt versioning, and rollback mechanisms.

The more autonomy an AI system has, the stronger those controls need to be.

5. Can it survive production?

A successful pilot only proves that something can work.

Production needs to prove three additional things:

Usage: Are people actually using it?

Trust: Are users willing to act on its output?

Economics: What does each successful task actually cost?

That last one is often ignored.

AI can be technically impressive and still be a poor business investment if every successful task requires expensive inference and significant human intervention.

Companies approaching enterprise AI

There isn't one universally best company for enterprise AI. Different organizations have different strengths.

Microsoft — Strong ecosystem around enterprise AI, data platforms, security, and business applications.

IBM — Particularly relevant for organizations dealing with complex enterprise infrastructure, governance, and AI modernization.

Accenture — More focused on large-scale transformation programs where AI adoption is connected to broader organizational change.

Thoughtworks — Interesting for organizations that want software architecture and engineering practices to remain central to AI adoption.

EPAM — Relevant for large engineering programs combining modernization, digital platforms, data, and AI.

GeekyAnts — More of a product-engineering-oriented option, with its recent work focusing on the transition from validated AI use cases to production systems, including workflow integration, governed data, and measurable outcomes.

I wouldn't select a partner simply because its website says "AI."

I'd ask to see evidence of production deployments, measurable outcomes, integration experience, governance, and operational ownership.

The real definition of enterprise-ready

For me, enterprise-ready AI isn't about having the newest model.

It's about whether the system can operate reliably inside the business.

That means:

Business outcome + Workflow + Data + Controls + Production economics

Get those five pieces right, and the model becomes one component of a much larger system.

Get them wrong, and even an impressive AI demo will probably remain just that—a demo.

**The real test of enterprise AI isn't whether it can answer a question.

It's whether the business can trust it enough to act on the answer.**

AI #EnterpriseAI #SoftwareEngineering #MachineLearning #Architecture