In the sprawling architecture of modern enterprise software, APIs are the silent connective tissue — and when they fail, the damage rarely stays contained. Abhishek Saikia, Co-Founder and CEO of KushoAI, has built his company around one uncomfortable truth: most production failures were testable before they happened. They were too complex to script manually.
Co-Founder and CEO
KushoAI
In this conversation, Saikia breaks down why traditional QA tooling collapses at the integration layer, how KushoAI compresses testing cycles by up to 100x, and why the real crisis isn’t running tests — it’s knowing which ones to write. For engineering leaders navigating high-velocity releases and regulatory scrutiny, his answers are worth sitting with.
CIO&Leader: Kusho AI claims testing cycles up to 100x faster. What’s the core architectural decision that makes that number possible?
Abhishek Saikia: The biggest architectural decision was to collapse test design, test coding, execution, and maintenance into one automated workflow.
In most QA teams, the slow part is not actually running tests. It is figuring out what to test, writing scripts, adding assertions, debugging broken tests, and then doing it all again when the API changes.
KushoAI ingests API specifications, collections, or live traffic and generates executable test suites directly in the frameworks teams already use, such as Pytest, Postman, Rest Assured, Playwright, Selenium, and Cypress. The output is not a test plan that still needs to be coded. It is runnable test code with assertions, dependencies, validations, and CI/CD compatibility.
That is where the 100x number comes from. A complex API flow that can take a QA team days to cover manually can be converted into a working test suite in minutes.
CIO&Leader: Traditional QA tools have been around for decades. At what exact point does an API-first, high-scale system break them, and why hasn’t the industry fixed this sooner?
Abhishek Saikia: Traditional QA tools start breaking at the integration layer.
They work reasonably well when teams are testing a fixed set of workflows or individual endpoints. The problem starts when a single user action triggers 10, 20, or 50 API calls across authentication, payments, risk checks, notifications, reconciliation, and internal logging.
At that point, the test surface area grows much faster than a human team can keep up with. Every service has its own schema, permissions, state rules, failure modes, and downstream dependencies. Most teams end up testing the happy paths well and missing the edge cases that actually cause production issues.
The industry did not fix this earlier because QA automation mostly focused on executing tests faster. The harder problem was deciding what to test and keeping that coverage up to date as systems changed. That reasoning layer was still manual.
That is the part KushoAI automates.
CIO&Leader: You’re simulating thousands of real-world scenarios in pre-production. How do your AI models know which edge cases actually matter versus which ones are just noise?
Abhishek Saikia: We do not optimize for the largest number of tests. We optimize for the scenarios most likely to create production risk.
A null value in a search filter is not the same as a null value in a payment authorization request. A malformed optional field is not the same as a broken retry path, an authorization bypass, a duplicate transaction, or a reconciliation mismatch.
KushoAI looks at the API contract, request and response schemas, authentication rules, required and optional fields, state transitions, and workflow dependencies. It also learns from execution feedback and failure patterns across real test runs.
That helps the system separate theoretical edge cases from operationally important ones.
In practice, the goal is a smaller but stronger test suite. Enterprise teams do not need thousands of random tests that create maintenance load. They need coverage around security, data integrity, workflow completion, and business-critical failure paths.
CIO&Leader: Generic LLMs like GPT or Gemini can write test cases too. What does Kusho’s proprietary model do that a well-prompted foundation model simply cannot?
Abhishek Saikia: Generic LLMs can write test code. That part is no longer special. The problem is what happens before and after the code is written.
KushoAI understands API contracts, schemas, dependencies, auth rules, and multi-step workflows as testing objects. For example, testing a checkout flow is not just about writing five separate tests. The system needs to know that authentication creates a token, cart creation returns an ID, coupon logic changes the payable amount, payment creates a transaction state, and order confirmation depends on all of it.
A generic model usually needs a human to provide that context, spot missing cases, run the tests, debug failures, and maintain the suite.
KushoAI closes that loop. It generates tests, executes them, reads failures, fixes broken assumptions, and updates the suite as APIs evolve. That is the part that a well-prompted foundation model still does not own reliably.
CIO&Leader: In banking specifically, a failure isn’t just a bug. It’s a regulatory event. How does Kusho’s output map to compliance and audit requirements, not just uptime metrics?
Abhishek Saikia: In banking, a passing test is not enough. Teams need evidence they can defend later.
KushoAI creates structured test artifacts that can be traced back to APIs, workflows, scenarios, and failure categories. This gives engineering, security, and compliance teams a record of what was tested, why it was tested, what passed, what failed, and when coverage last changed.
That matters because audit teams do not only care whether a system is currently healthy. They care whether critical flows were tested consistently before release.
For banking customers, the important areas usually include authentication, authorization, input validation, transaction integrity, schema changes, negative paths, and workflow-level failures. These connect directly to operational risk, customer impact, and compliance readiness.
KushoAI’s outputs can be exported and reviewed as evidence packages, traceability matrices, test reports, and CI/CD records, so the testing process fits within enterprise governance rather than sitting outside it.
CIO&Leader: You’re positioning AI as an engineering force multiplier. But at what scale does a team actually need Kusho? Is this a 10-engineer problem or a 500-engineer problem?
Abhishek Saikia: It depends less on engineering headcount and more on platform surface area and release velocity.
A 50-person fintech team can feel this problem very early if they are managing payments, KYC, fraud checks, customer onboarding, and third-party integrations. They may not have a large QA team, but they still carry enterprise-grade risk.
At 500 engineers, the problem looks different. Different teams own different services. APIs change independently. Documentation drifts. Test suites become uneven. Cross-service workflows fall through the cracks because each team assumes the other team is covering the integration risk.
A useful threshold is when a company has dozens of important APIs, frequent releases, and a high cost of failure. At that point, manual test creation and maintenance start turning into technical debt.
So this is not only a 500-engineer problem. It is a complex problem, and high-scale API teams hit it much earlier than people expect.
CIO&Leader: When you do a post-mortem on a major enterprise system failure, what’s the single most common crack in the infrastructure that nobody wants to talk about?
Abhishek Saikia: The most common cause of cracks is untested failure behavior between services.
Teams usually test the happy path. Many also test for obvious failures, such as 400 or 500 responses. What gets missed is partial failure: a service is not down, but slow; a dependency returns delayed or inconsistent data; a retry creates a duplicate state; an authorization rule behaves differently under a specific condition.
These are the failures that cause cascades.
For example, Service A calls Service B. Service B is slow but technically available. Service A has weak timeout handling. Requests pile up. Thread pools exhaust. A third service, depending on Service A, starts failing. Suddenly, the issue is no longer local.
The uncomfortable truth is that many outages were testable before production. They were just too hard to script manually.
That is why workflow-level testing matters. Modern systems rarely fail in clean, isolated ways. They fail through interactions.