AI workers for Developer Tools apps
Give an AI worker a repository, or your error monitoring, without giving it the organisation. Scope is per repository, error monitoring is granted tool by tool, and the ability to change anything is always a separate grant.
- GitHub
Morning repository briefings, pull requests that have gone quiet, and release notes…
- Sentry
AI workers for Sentry read your errors so a person does not have to watch the inbox: they…
What is an AI worker for Developer Tools?
An AI worker for developer tools is a scoped connection to a source control platform that can read repositories, issues and pull requests, and where allowed write to them, under rules set outside the model. Scope is granted per repository rather than per organisation, so one project can be in play while the rest of the estate is not. An error monitoring service that connects through its own server adds the issues, events and stack traces behind production failures; it is granted tool by tool and acts as the account that connected.
What these workers do
Triage what came in
A worker reads new issues, works out what they actually are, and flags the ones that are urgent.
Explain what changed
A worker summarises what moved in a repository for people who do not read diffs.
Answer questions about the code
A worker finds where something is implemented instead of interrupting the person who wrote it.
Triage production errors
A worker reads the errors that are new, spiking or back after a fix, reads the stack traces behind the worst ones, and hands the team a short brief with the links.
How an AI worker runs in your Developer Tools apps
Source control is where a broad token does the most damage, because the access usually spans every project a company has.
Grant repositories individually. An organisation-wide grant is rarely what the job needs and is exactly what an accident would use.
Reading is enough for a surprising amount of work. Triaging issues, summarising changes and answering questions about the codebase need no write access at all.
Where writing is granted, opening a pull request is the safe shape. It leaves a human in the loop by construction rather than by policy.
Error monitoring is read-first too. A worker that reads the issues that are new or back after a fix, with their events and stack traces, can write the morning triage brief with no write tool at all. Commenting on, assigning or resolving an issue is visible to the whole team, so grant those tools only to a worker whose instructions say what it may change.
Developer Tools questions, answered.
Can I limit it to one repository?
Yes. Repositories are allowed individually, so an organisation-wide grant is never required. Source control is where a broad token does the most damage, because the access usually spans every project a company has, including the ones with credentials or customer data somewhere in their history. Granting the repositories the job concerns keeps the rest of the estate out of reach.
Can it push code?
Writing is a separate permission from reading, and many teams limit workers to opening pull requests so a human still reviews. That shape keeps a person in the loop by construction rather than by policy, since nothing reaches a default branch without someone approving it. The write grant covers the same repositories as the read grant or fewer, never more.
Does it see private repositories?
Only the ones you allow. Anything not granted is not visible to the worker, private or public, and the grant does not widen because the connected account's own access does. That distinction matters when a person's membership changes, since a worker keeps exactly the repositories it was given rather than inheriting whatever they gained.
Is there a record of what it read?
Yes. Reads and writes are logged, so access can be reconstructed after the fact. Each entry names the worker and the repository involved, which is the part source control platforms rarely make clear when a single machine account does all the work. A question later about what a worker looked at becomes a lookup rather than an investigation.
Can it read our error tracking?
Yes, through the error monitoring service's own connection, which is granted tool by tool and acts as the account that connected. Reading issues, events and stack traces changes nothing. Commenting on, assigning or resolving an issue is a separate tool and is visible to the whole team, so it belongs on a worker whose instructions say what it may change.