Engineering
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.
What the worker does
Bug triage with an AI worker means every new issue arrives pre-checked. The worker searches existing issues for near-duplicates, verifies whether the reported version is current, extracts repro steps into a consistent shape, and proposes a severity label using the rubric written in its skill file. Each proposal is posted as a comment. Closing, merging duplicates and setting real severity stay with an engineer.
- Runs
- Daily, or on arrival
- Connections
- GitHub, Linear, Slack
- Never automated
- Closing an issue
Triage is expensive because of who has to do it
Deciding whether a report is a duplicate requires knowing the codebase. So the person doing triage is an engineer, and the forty minutes they spend before lunch reading reports is forty minutes of the most expensive time available, spent on matching text against text.
Worse, it is interrupt-shaped. Reports arrive all day, triage happens in batches, and the reports that arrive after the batch sit untouched until the next one.
What the worker does with each new report
In this order, because each step can make the next unnecessary.
- 1
Search for near-duplicates
Against open and recently closed issues, matching on symptom rather than wording. Candidates are listed with links and a note on why they look similar, so the engineer confirms in seconds instead of searching.
- 2
Check the reported version
If the reporter is three releases behind and the symptom matches something already fixed, that fact belongs at the top of the comment. This one check resolves a meaningful share of reports on its own.
- 3
Normalise the repro
Steps, expected, actual, environment. Reports arrive as paragraphs; engineers need a shape. What is missing is listed as missing rather than filled in with a guess.
- 4
Propose severity
Using the rubric in the worker's SKILL.md, which you wrote. Data loss is severity one, cosmetic on a settings page is severity three, and the worker cites which rule it applied.
- 5
Post, and stop
The proposal lands as a comment on the task. The machine does not label, close, merge or assign in your tracker. An engineer spends ten seconds accepting or overriding.
Signal in the report, and what the worker does with it
| What the report contains | What the worker does |
|---|---|
| A stack trace | Searches issues for the same top frames and links matches |
| A version number | Compares against the current release and flags staleness |
| A screenshot only | Records that there are no written repro steps and says so |
| Wording close to an existing issue | Proposes a duplicate link with both issue references |
| No environment details | Lists the missing fields for the reporter to fill in |
What changes for the engineer
Triage becomes review
Instead of investigating forty reports, an engineer reads forty proposals and disagrees with a handful. The expensive part of the hour disappears.
Reports stop aging
A cloud machine claims triage jobs from a queue, so a report filed at 11pm is checked before anyone reads it, rather than waiting for the next batch.
The rubric gets written down
Briefing the worker forces the team to state what severity one means. Most teams discover during this exercise that they did not agree.
Questions people ask
+Can the worker close duplicates automatically?
No. It proposes a duplicate link with both issue references and the reason it thinks they match. A wrong duplicate closure costs a user's report, which is more expensive than the ten seconds an engineer spends confirming.
+Does it need write access to GitHub?
Not for triage as described here. It reads issues through the GitHub connection and delivers proposals as comments on Polaris tasks. Connections are authorised once for the organisation and stored server-side, where browsers cannot read them back.
+How does it learn our severity rubric?
You write it into the worker's SKILL.md file, which is plain text you can open and edit. Changing a rule there changes every subsequent run, and the worker cites the rule it applied so you can see when a rule is producing bad calls.
+What about reports that arrive by email or Slack?
The Polaris Inbox catches Slack messages and turns them into prefilled task suggestions with bucket, lane, labels and owner already set. You approve the suggestion with one click and the triage worker picks it up like any other task.
Related
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
The incident ended and the writeup never started
The timeline assembled from the channel and the deploy history, with the gaps left honest.
Ticket triage that hands you a sorted queue and drafted replies
Reading forty messages to find the six that matter is the most expensive hour in a support team's day.
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 Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
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.
Acceptance criteria
Written before the work, checkable after it, and binary either way.