AI quality engineering for teams shipping AI-written code

A green build is a claim. We check it.

Sahasa.AI checks the code your engineers and their AI assistants write. It writes tests in the frameworks you already use, finds bugs and security issues in each change, and tells you plainly which results actually ran.

Book a demo How it works

Built for engineering organisations of 200 to 5,000 engineers, including regulated ones.
Nothing to migrate. Your current suite stays, and the tests are plain code in your repository.
Runs in your cloud, on your own AI provider account.

SAHASA.AI · VERIFICATION

RUN #1042 · payments-service

PAY-114 · refund over limit, second approver

22 SEP 2026 · 09:14 · 3 files changed

pytest, 14 testsran in the sandboxMEASURED
JUnit, 6 testsno JVM in this stageGENERATED ONLY
refund_handler.py:212null merchant_id on split chargesBUG · FIX
POST /refundno rate limit, backed by route tableTHREAT
Load test against SLOno k6 report attachedN/A

Measured14
Generated only6
Not measured (N/A)1

NOT READY TO SHIP · 1 BUG OPEN

Sample run · illustrative data

The problem

Writing code got cheap. Trusting it didn't.

Sources · Stack Overflow Developer Survey 2025 · Forrester, Dec 2025

84%

of developers use or plan to use AI coding tools.

say they highly trust what those tools produce.

~25%

is where test automation stalls in most organisations.

Our view

More generated code means more to verify, and in most teams nobody owns that step. It gets done late, by hand, or not at all. We built Sahasa.AI to own it.

Live

Every finding points at a real line of code.

Point Sahasa.AI at a repository or a set of changes. One run brings back the tests it wrote, the bugs it found with a proposed fix, and only the threats it could back with a real finding. Every cited file and line is checked against your repository first.

Bugs cited to file and lineThe real code is attached, and a citation that doesn't resolve in your repository is shown as unverified.
Threats checked against findingsA threat is marked corroborated only when a scan result shares its CWE. Otherwise it stays a hypothesis.
Blast radius from resolved importsWhich callers and tests a change can reach, so reviewers know where else to look.
Tests in your frameworkPlaywright, Cypress, Selenium, pytest, Jest, JUnit or Cucumber, reviewed like any other change.

Run #1042· payments-servicecompleted

Refund over limit requires a second approver PAY-114

3 changed files in src/payments/ · code written with Copilot · started on demand

Resultsfinished in 4 minutes · strong model tier

14 measured6 generated only1 bug1 threat1 N/A

BUG · NULL HANDLINGline verified

Partial refund passes a null merchant ID on split charges

src/payments/refund_handler.py:212 · in this change

212- merchant_id = charge.splits[0].merchant_id
212+ merchant_id = charge.primary_merchant_id or charge.splits[0].merchant_id

THREAT · STRIDE · DENIAL OF SERVICEcorroborated · CWE-770

No rate limit on POST /refund

Open to any signed-in user and calls the payment provider synchronously. Backed by the route table and by the missing limiter in the dependency graph.

TESTS WRITTENrun in the sandbox

test_approval.py · refund above limit needs second approverpassed
test_approval.py · approver cannot approve own requestpassed
test_limits.py · 12 boundary cases around 10,00012 passed
RefundServiceTest.java · 6 testsnot run · no JVM

BLAST RADIUSimports resolved

refund_handler.py is called by 3 modules and covered by 4 test files. Run refunds/ and ledger/ first.

Illustration · sample data

About thirty modules

From the requirement to the release.

Each module does one job and can be switched off or pointed at a different AI model. We suggest starting with Build and Verify, because that's where AI-written code piles up fastest.

BRD_Refunds_v3.docx· 14 pages42 requirements · 3 too vague to test

§ 3.1 Refund approvalsRefunds are raised by operations staff. A refund above 10,000 must be approved by a second approver. An approver cannot approve their own request. The refund screen should be fast and easy to use. Refund decisions are logged for audit and retained for seven years.

REQ-12 · § 3.1testable

Refunds over 10,000 need a second approver.

REQ-13 · § 3.1testable

An approver cannot approve their own request.

REQ-14 · § 3.1needs work

The refund screen should be fast and easy to use.

Suggested: the refund screen loads in under 2 s at p95 on staging.

The problem

Requirements arrive as prose. Nobody knows which are testable, or which the code actually implements.

What it does

Splits documents into atomic requirements with a source reference
Scores testability and suggests rewrites
Checks each requirement against the code

Used by analysts, product and QA · no code needed

Scenario coverage· Refunds1 requirement has only a happy path

Requirement	Happy	Alt	Negative	Boundary	Error
REQ-12Second approver over 10,000
REQ-13No self-approval
REQ-15Partial refunds on split charges

P1TC-031 · exactly 10,000 needs no second approverboundary

P1TC-032 · 10,000.01 needs a second approverboundary

P2TC-040 · approver tries to approve own refundnegative

The problem

Cases are written by hand from memory, and "covered" means a test mentions the requirement.

What it does

Maps scenarios per requirement and flags one-sided ones
Writes P1 to P4 cases using boundary, equivalence and state techniques
Measures coverage itself and fills the gaps

Used by QA and analysts · exports to Excel, CSV and JSON · Xray, Zephyr and Azure Test Plans in build

tests/refunds/approval.spec.ts· new file+142 −0

tests/refundsapproval.spec.tsAlimits.spec.tsApagesRefundPage.tsAApprovalPage.tsMfixturescharges.jsonARUN.mdA

// PAY-114 · selectors checked on staging at 09:41
test('refund above limit needs a second approver', async ({ page }) => {
  await loginAs(page, 'ops.manager');
  await refunds.open('ch_7f21');
  await page.getByLabel('Amount').fill('12500');
  await page.getByRole('button', { name: 'Submit refund' }).click();
  await expect(page.getByTestId('approval-banner'))
    .toContainText('Second approver required');
});

selectors verifiedextends existing suite2 selectors repaired

The problem

Assistant-written tests reference selectors that don't exist, and the existing suite decays as the UI changes.

What it does

Unit, integration, end-to-end and contract tests from code, OpenAPI and a live inspection
Extends your suite in place and repairs broken selectors
Playwright, Cypress, Selenium, pytest, Jest, JUnit 5, Go, Cucumber

Used by developers and automation engineers

Findings· payments-service · run #1042SAST · CVE · secrets · DAST

SAST · CWE-89 · SQL INJECTIONline verified

Refund search builds SQL from the query string

src/payments/search.py:48 · Semgrep rule python.lang.security.sqli

DEPENDENCY · CVE-2024-6345high

setuptools < 70.0 in services/ledger

requirements.txt:14 · fix: upgrade to 70.0

THREAT MODEL · STRIDE6 corroborated · 9 hypotheses

Built from your routes, call graph and dependencies. A threat is corroborated only when a real finding shares its CWE. We never issue a "secure" verdict.

The problem

A UI test only finds the bug it happens to hit, and security sits in a separate tool with a separate budget.

What it does

Twelve categories of bug detection, each with a fix
Semgrep and Bandit, dependency CVEs, secrets, DAST
STRIDE, LINDDUN or PASTA, checked against findings

Used by developers and security engineers · shortens the pen-test, doesn't replace it

Nightly #311· checkout-web · JUnit reportfailed

23failures, grouped into3causes

Payment sandbox returned 503environment · 14All 14 hit /v1/charges between 02:10 and 02:14. Not a product bug.

Approval banner test id renamedtest · 6Changed in PR #479. Repair proposed for 6 tests.

Rounding on split refundsproduct · 3A real defect, traced to refund_handler.py:230.

Search results orderflaky suspectedPassed 9 of the last 10 runs. Kept out of the count.

The problem

A red nightly build costs someone a morning of reading logs, and flaky tests hide real defects.

What it does

Generated suites run in your CI
Failures grouped by cause from JUnit, pytest or Jest reports
Running suites inside the platform is next on the roadmap

Used by automation engineers and QA

payments-platform· 4 repositories · 212 requirementslast run 9 min ago

Requirements verified

78%measured

Open security findings

31 high

Load test vs SLO

N/Ano report

PAY-114	Refund over limit needs a second approver	verified
PAY-115	Approver cannot approve own request	verified
PAY-118	Audit log retained seven years	shallow
PAY-121	Partial refunds across split charges	uncovered

The problem

The traceability matrix is a spreadsheet, and leadership sees a green build and has to take it on trust.

What it does

Requirement to scenario to case to test to code, each link resolved
Performance verdicts from k6, JMeter or Gatling results
A project dashboard with coverage history and analytics, and N/A where nothing was measured

Used by leadership, QA and auditors · see the project dashboard

Illustrations · sample data

What changes

What a pilot measures.

We record your current numbers in week one and compare them in week four. These are the measures we track, not results we're claiming.

Pilot measures

Test authoring
Engineers review generated tests instead of scripting them by hand.
Authoring time per feature
Regression coverage
Each change gets tests in the team's own framework, alongside the suite that already exists.
Requirements with verified tests
Failed builds
Failures are grouped by cause from the CI report, with flaky tests set aside.
Time to root cause
Security
Scanning and a threat model on every change, before the pen-test starts.
Issues found before the pen-test
Audit evidence
A traceability matrix computed from requirements, code and tests, each line traced to a commit.
Audit preparation time

Where we sit

Between code being written and code being released.

Yours

Requirements

Jira, BRDs, specs

Yours

Code is written

Engineers with Copilot, Cursor, Claude Code

Sahasa.AI

Verification

Tests designed and written
UI checked in a real browser
Bugs, security and threats
Traceability, with a label on every result

Yours

CI/CD and execution

Your pipeline, runners and device farms

Yours

Release and operate

Deployment, monitoring, incidents

We read from

Your repositories
Jira, BRDs, Word, Excel, PDF
OpenAPI specs, CI reports, load-test results
A running URL, behind login and SSO

We write to

Plain test files, ready to commit
Findings and fixes, cited to file and line
An Excel traceability matrix, plus CSV, JSON and Markdown
Xray, Zephyr and Azure Test Plans In build
A dashboard per product

You keep

Your CI/CD and test management
Your device farm or cloud grid
Your AI provider account and keys
Every test, if you stop using us

Our position

What we won't do.

Most tools in this market claim the whole lifecycle. We'd rather be exact about where we stop.

We won't run a device farm.
Tests run in your CI, on your grid, or in a browser we control for live checks. Mobile through Appium, on devices or a cloud grid you already pay for, is next on the roadmap.
We won't move your suite into our format.
We extend it in place, in the framework it's written in, and repair tests that break when the UI changes. There's no proprietary step language to leave later.
We won't replace your CI, tracker or test management.
Every result exports cleanly to the tools you already run. CI steps and two-way Jira are next on the roadmap.
We won't sign off in place of a pen-test.
We clear code-level findings and the threat model first. Your security team and your pen-testers still make the call.

Track record

Three engagements behind the platform.

Low-code platform vendor

Test automation for a whole partner ecosystem

Before Sahasa.AI was a product, our team built and ran the test automation platform for a low-code vendor's partner ecosystem.

Test authoring moved from specialists to the wider delivery team
Regression became a routine gate on every release

Low-code product company

Faster releases and a shorter security assessment

A fast-moving product team uses Sahasa.AI day to day, from requirements to runnable suites, with bug and security analysis on every change.

Code-level security and the threat model are done before the pen-test starts
One standard across engineers using different AI assistants

Large Canadian retailer

A platform shaped to their own quality model

We learned their standards and existing modules first, then fitted the platform to them across requirements, generation, security and traceability.

Their taxonomy, gates and dashboards, shipped as configuration
Traceability across many teams and repositories

Read the three engagements

Next step

Bring one repository.

We'll walk you through Sahasa.AI on a sample project and talk through how it would fit your stack. If it looks useful, we can scope a pilot together.

01
A short call. Your stack, your frameworks, and where quality hurts today.
02
A demo. The platform on a sample project, and how it would connect to your tools.
03
A pilot, if it fits. Scoped with you around one service.