GitHub and AI agents
GitHub holds everything that got done, and none of it is written for the person asking when it will be ready. An agent reads the repository and puts it in words you can say to a client or to your board: what shipped, what is stuck, and what you'll be asked about first.
What an agent does in GitHub
- Assembles what actually shipped this week: merged pull requests, closed issues, tagged releases.
- Surfaces the pull requests that have sat without review past a limit you set.
- Keeps the thread between a client's question and the issue behind it: where it stands, and what happened to it last.
- Drafts release notes from the real commits and tags, separating what a user will notice from what only the team will.
- Brings you the issues opened by people outside the team, instead of leaving them to sit unread.
Processes that run themselves
A playbook isn't a button — it's a process with a condition that starts it. In GitHub that condition usually comes from the repository itself: a pull request with no review, a release tag, an issue from someone outside the team.
A pull request stalls without review
A pull request has been open past the limit you set and still has no review
- Separate real waiting from drafts and from the ones with no reviewer assigned
- Describe in one paragraph, without code, what it changes and who it touches
- Nudge the assigned reviewer where they actually read messages
- Put the longest-standing one in front of you as the thing holding up delivery
A release, described in words
A release tag is pushed to the repository
- Collect the commits and closed issues between the previous tag and this one
- Split them into what a customer will notice and what only the team will
- Hand you a draft of the release notes — the wording and the promises stay yours
- Flag the items that need an answer from a developer rather than a guess
Something arrives from outside
An issue is opened by someone who isn't on your team
- Check whether it duplicates something already open
- Assemble a short card: who filed it, what they want, what it affects
- Bring it to you — it assigns no owner and promises no date
Where the agent stops
- It doesn't write, review or merge code: that is engineering's call and engineering's accountability.
- It reports what the repository shows, and won't read quality or effort off a commit count.
- It doesn't touch access, secrets or branch protection — none of that is configured by conversation.
- When something will be done comes from the people doing it, not from an agent extrapolating a commit graph.
FAQ
Do I need to read code to follow this?
No. The agent describes changes as outcomes: what now works, what got fixed, who it affects. The link to the original pull request or issue stays next to it, for when you want to put it in front of a developer.
Will the agent change anything in the repository?
By default it only reads. If you allow it, it can leave a comment or a label — never code, branches or history. Reviewing and merging stay with the team.
Doesn't this turn into surveillance of the developers?
We deliberately don't build «who committed how much» reports: the number says nothing about the work, and any team learns to feed it within a month. The agent shows the state of the work, not a ranking of people.
What does it take to connect a private repository?
Read access is granted by the repository owner or an org admin — their decision, not ours. After that the setup is a conversation: you name the repositories, and the limits past which something counts as stalled.
Where this shows up
Walkthroughs where seeing what development is actually doing is part of the process.