Role

Hire an AI QA engineer

Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.

What this worker is

An AI QA engineer in Polaris is a worker you hire to turn raw bug reports into engineering-ready tickets and to write test plans. It rewrites reports with reproduction steps, expected and actual behaviour and a severity, groups duplicates, drafts regression checklists, and posts the batch as a comment. It reasons about software from what it is given and does not execute code.

Typical output: Rewritten tickets with severity and steps
Core connections: GitHub, Linear, Slack
Illustrative task: 2.4 human-hours, $4.80

What this worker is great at

The gap between what a user reports and what an engineer can act on.

Making a report reproducible
It rewrites the customer's story into numbered steps, expected behaviour, actual behaviour, environment and severity, and it marks the fields it could not fill rather than inventing them.
Killing duplicates
Fourteen reports are often nine bugs. It groups them and names the one ticket the engineer should read.
Writing the test plan
For a feature about to ship: the happy path, the edge cases that actually break things, and the regression list of what this change is most likely to have damaged.
Severity with a reason
A severity nobody can argue with is a severity nobody trusts. Each one comes with the impact sentence behind it.
Release checklists
Acceptance criteria as checklist items on the task, ticked as each one is genuinely verified by whoever verifies it.

Before and after, on one report

The value of this role is visible in a single row.

Field	What arrived	What the worker delivers
Title	Export is broken	CSV export returns an empty file for orgs with more than 1,000 rows
Steps	None	Numbered, from a clean session, with the data condition stated
Expected vs actual	Missing	Both written explicitly, in the user's terms
Severity	Unset	Set, with the impact sentence that justifies it
Duplicates	Unknown	Three earlier reports linked, one canonical ticket named

A realistic first week

1
Day one: the untriaged backlog
Assign everything nobody has looked at. Acceptance criteria: every report rewritten, every duplicate grouped, every severity justified.
2
Day two: the definition of severity
Write your severity ladder into the skill file so the next batch uses your scale rather than a generic one.
3
Day three: a test plan for the next release
Feature description in, happy path plus edge cases plus regression list out.
4
Friday: the pattern report
One page on what this week's bugs have in common, which is the artefact that changes engineering priorities.

Where the human stays in charge

The QA engineer prepares

Reproducible, severity-rated tickets
Duplicate groupings with a canonical ticket
Test plans and regression checklists
A weekly pattern summary

Engineers decide

Whether a bug is real after reproducing it
What gets fixed and in what order
Whether the release is safe to ship
Closing the task and rating the batch

What an AI QA engineer is not good at

It does not run your software. There is no browser, no test runner and no shell in the machine session, so it cannot reproduce a bug, take a screenshot or watch a suite go red. It writes the plan and the ticket; a person or your CI runs the test.

That limit is worth stating plainly because the role name invites the opposite assumption. Everything it produces is derived from the reports, the descriptions and the code context you put in front of it, plus live web search for library behaviour and error messages.

It also cannot tell you whether an intermittent failure is a race condition or a flaky test environment. It will list both hypotheses and the evidence that would separate them, which is genuinely useful, and then an engineer has to go and look.

Questions people ask

+Can an AI QA engineer run automated tests?

No. The machine session has web search, documents and file production, not a test runner or a browser. It writes test plans, cases and checklists that your engineers or your CI execute.

+How does it decide severity?

By the ladder you write into its SKILL.md. Without one it uses a generic scale, which is why the first week should include ten minutes writing down what critical actually means at your company. Every severity is delivered with the impact sentence behind it.

+Does it work with our issue tracker?

Linear and GitHub are both in the connection catalog, and the tickets it prepares are written to be pasted or moved into whichever tracker you use. Polaris tasks themselves can hold the work if you would rather not keep two systems.

+What does a triage batch cost?

As an illustrative example from the published formula, fourteen reports rewritten in one session comes to about 2.4 human-equivalent hours, or $4.80 at $2 per human-hour. The effort behind that number is itemised on the work log and can be challenged there.

Hire an AI technical writer

The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.

Forty new issues on Monday, half of them the same bug

Every new issue checked for duplicates, version and repro before an engineer opens it.

Six open pull requests and nobody knows whose turn it is

The review queue, ordered by age and named by who is blocking it, posted every morning.

The incident ended and the writeup never started

The timeline assembled from the channel and the deploy history, with the gaps left honest.

Connect GitHub to Polaris

Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.

Connect Linear to Polaris

A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.

Acceptance criteria

Written before the work, checkable after it, and binary either way.

Agents deliver, humans close

One rule holds the whole product together, and it is a rule about who is allowed to say finished.