Engineering
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.
What the worker does
Engineering teams use Polaris AI workers for the coordination layer around the code: bug triage, sprint preparation, review queue management, postmortem assembly and documentation drift. A worker reads GitHub, Linear, Slack and Google Calendar, then posts proposed labels, queues, timelines or draft pages as comments on tasks. Merging, closing issues and deciding what a contributing factor was remain human actions.
- Jobs covered
- 5
- Usual connections
- GitHub, Linear, Slack
- Never automated
- The merge
Where engineering time actually goes
The interesting problem is not the ticket. It is the forty minutes before the ticket, spent working out whether the bug is a duplicate, whether the reporter is on a version from March, and which of the six open pull requests is blocking the release.
None of that is engineering. It is reading, matching and listing, done by the person with the most expensive hour in the room because they are the only one who knows the codebase well enough to do it quickly.
The five jobs
Sprint planning
A pre-meeting brief: carry-over issues with their age, issues with no estimate, work assigned to people who are on leave that week, and what is blocked on another team.
Bug triage
Every new issue checked for near-duplicates, version currency and repro completeness, with a proposed label set posted as a comment. Nothing is closed by the machine.
Code review workflow
A morning queue of open pull requests sorted by age, showing who is blocking each one, which have failing checks, and which touch code with no test changes.
Incident postmortems
A timeline assembled from the incident channel and deploy history, with the gaps marked unknown rather than guessed at.
Technical documentation
A monthly pass comparing documented behaviour against the current code, listing statements that are no longer true with file references.
What a machine can and cannot tell
The line is not intelligence. It is whether the answer exists in a system the worker can read.
Readable, so the worker does it
- Which issues look like duplicates of each other
- How long a pull request has been open, and who has not reviewed it
- Which deploys happened during the incident window
- Which config keys the docs mention that no longer exist
- Who is on leave during next sprint
Judgement, so a person does it
- Whether a bug is severity one or severity three for your users
- Whether the pull request is a good idea
- What the contributing factor really was
- What the team can commit to this sprint
- Whether the fix is worth the regression risk
Brief, connections, delivery
| Job | The brief | Connections | What arrives |
|---|---|---|---|
| Sprint planning | Assemble the pre-planning brief every Thursday | Linear, GitHub, Google Calendar | A comment with carry-over, unestimated and blocked work |
| Bug triage | Triage new issues against the rubric in your skill file | GitHub, Linear, Slack | One comment per issue with proposed labels and duplicates |
| Review workflow | Post the review queue each morning | GitHub, Slack | An ordered queue naming who each PR is waiting on |
| Postmortems | Build the timeline when an incident task is assigned | Slack, GitHub, Notion | A timeline draft with gaps marked unknown |
| Documentation | Check documented behaviour against the code monthly | GitHub, Notion, Google Drive | A list of false statements with file references |
The economics of handing over the assembly
Numbers from how Polaris meters work, not from a case study. Polaris is in free public beta and has no customer results to quote.
$0
For the workspace
Unlimited people, tasks, workstreams and docs
$2
Per human-hour delivered
Estimated by an open formula, itemised per job
8h
Cap on a single session
Sessions are clamped between five minutes and eight hours
The five engineering use cases
The two hours before planning that nobody schedules
Carry-over, gaps and blockers assembled the day before, so the meeting is about commitment.
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.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
Questions people ask
+Is this a coding agent?
No. Polaris workers handle the coordination work around a codebase: triage, queues, timelines and documentation drift. Teams that want a coding agent keep the one they use and give Polaris the jobs that currently sit in nobody's calendar.
+How is this different from running Claude Code locally?
A local agent stops when the laptop closes, cannot be assigned work by a teammate, and leaves no shared record. In Polaris a cloud machine claims each job from a queue, works while you are away, and posts the result where the whole team can read it.
+Does the worker need write access to our repository?
Not for any of these five jobs. Each one is a read of repository state that gets reported back as a comment on a Polaris task. Connections are authorised once, org-wide, and stored server-side where browsers cannot read them back.
+What happens if the worker misreads an issue?
Its output is a proposal on a comment, so a wrong label suggestion costs a glance rather than a cleanup. Rejecting the delivery and saying why in a reply is how the correction gets carried into the next run.
Related
What an AI worker actually does, department by department
Twelve functions, sixty recurring jobs, and the exact tool connection each one needs.
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
One analyst, thirty requests, and an AI worker in between
Five jobs that stand between a data team and the analysis they were hired to do.
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.
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.
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.
Turning a single-player agent into a team member
The change is not a better prompt. It is putting the worker in the same table as the people.