GitKord: Pull Requests Deserve Better Than Another Notification
I wanted to keep up with everything happening across my GitHub repositories without turning Discord into another notification feed. So I built something that treats a pull request in the age of AI like what it actually is: an ongoing conversation.
Imagine you’re working across three projects. One has a few developers pushing changes, another has an agent opening pull requests, and the third has a teammate waiting on a review before they can merge their work.
You open Discord.
There are 14 new messages. A branch was updated. Someone requested a review. Another commit was pushed. A workflow failed. A pull request was merged. Somewhere in that stream, a coworker mentioned you, but you missed it while trying to reconstruct a conversation from earlier in the week.
You start scrolling.
Which PR was that commit for? Did someone already address the failing check? Was that review request withdrawn, or is it still waiting? You remember seeing something about it earlier, but now you’re looking through messages trying to reconstruct what happened. On top of that, you want to know whether open pull requests deserve five minutes of attention, a proper review session, or a closer look because an agent generated most of it.
None of these events are particularly unusual. They’re a part of the job every engineer deals with. The information is technically there. You’re just doing all the work to make sense of it.
And that’s the problem.
We have plenty of ways to generate notifications. We don’t have enough ways to make them useful.
I wanted something different. Not another integration that forwards GitHub events into Discord, but one that makes the pull request itself the place where its activity lives.
So I built GitKord.
GitKord is an open-source Discord bot that gives every pull request a live, continuously updated message and its own discussion thread. Instead of posting another notification every time something happens, it keeps the original message up to date and records the activity in one place.
The goal is simple: keep developers, contributors, bots, and agents on the same page without making everyone read through another notification feed all within the same, portable communication platform.
Table of Contents
- The notification problem
- Why pull requests?
- The pull request in the age of AI
- One message, one thread
- Making Discord a first-class integration
- A little engineering behind the scenes
- What’s next?
- Give GitKord a try
The notification problem
Discord has been part of my everyday life for years. I use it for assignments, gaming, socializing, and building communities. It’s also where I naturally gravitate when coordinating work with other people.
So when I wanted a way to follow GitHub activity, bringing it into Discord seemed like an obvious choice. I didn’t need, nor have, an enterprise-sized engineering organization to get a reasonable developer experience.
I tried a few different approaches. There were Discord webhook integrations, tools like GitTrack, and other GitHub-to-Discord solutions. Some had been discontinued, some felt dated, and others required more setup than I wanted to deal with. More importantly, most followed the same pattern: something happened on GitHub, a message was sent to Discord, and that was the end of it.
Fire and forget.
That sounds reasonable until you’re following multiple repositories. A single pull request can generate quite a bit of activity, and every event becomes another message competing for attention. You can configure filters, limit notifications, and carefully organize channels, but you’re still left with the underlying problem: each event is treated as a separate piece of information rather than part of a larger story.
Even if you manage to keep track of every message, there’s another cost. You constantly switch context between Discord and GitHub to understand what’s happening. The notification tells you something changed, but rarely gives you a convenient place to understand the change, discuss it, and follow what happens next.
Discord already has the tools to do better. Messages can be edited. Users can be mentioned. Threads can be created and maintained. Yet many integrations barely scratch the surface of those capabilities.
I didn’t want to build another notification forwarder. I wanted to make the integration feel native to the platform.
Why pull requests?
A pull request is more than a change waiting to be merged.
Working at AWS forced me to think about facilitating this ceremony at scale for builders. It’s where we explain what we’ve changed, why we’ve changed it, and how we think it should work. It’s where reviewers challenge decisions, contributors respond to feedback, and everyone eventually agrees that the change is ready to ship.
In other words, decisions happen around pull requests.
That makes them a much better unit of collaboration than individual GitHub events.
Think about the lifecycle of a typical PR. Someone opens it, pushes a few commits, requests a review, receives feedback, makes adjustments, and eventually gets approval. Perhaps a CI check fails along the way. Perhaps an agent opens the PR and a developer takes over to review the implementation.
These aren’t unrelated notifications. They’re connected events in the lifecycle of one piece of work.
I wanted GitKord to preserve that connection.
If something changes, the PR should reflect it. If someone needs to understand what happened, they should have somewhere to look. And if someone wants to discuss the change, they shouldn’t have to dig through an unrelated channel conversation to find the context.
The pull request becomes the anchor. Everything else builds around it.
The pull request in the age of AI
There’s a growing conversation about whether the traditional pull request can keep up with AI-generated code.
In February 2026, former GitHub CEO Thomas Dohmke announced Entire, a new developer platform built around human-agent collaboration. The announcement included a pointed observation: our manual software production process, from issues and repositories to pull requests and deployment, wasn’t designed for the era of AI agents.
That’s a fair criticism. Agents can generate changes faster than people can reasonably read and validate them. The bottleneck is moving from producing code to understanding and verifying it.
Burak Dede makes a related argument in The Pull Request is Dead: Surviving the AI Code Avalanche. He describes the resulting backlog of unverified changes as verification debt: implementation moves faster than the human review process can keep up. His proposed direction includes stronger automated verification and agent-driven review workflows, with humans focusing more on intent, constraints, and oversight.
I don’t think that means the pull request should simply disappear.
I do think the way we use it needs to evolve. Agents may very well take over the line-by-line review of generated syntax, eventually freeing us more time for evaluating specifications, constraints, test results, architectural decisions, and the behavior we actually intend to ship.
But the responsibility for accepting a change doesn’t belong to the agent that produced it. It belongs to the people and teams deciding to use that output and accept the risks that come with it. AI isn’t a substitute for understanding what we’re asking it to build or deciding whether the result is safe to ship.
That’s why I still believe in a human-in-the-loop process, even if the mechanics of that process change. We need visibility into what agents are doing, what they’re proposing, what has been verified, and what still needs a decision.
CI/CD provides one important part of that picture. Automated checks can tell us whether a build passed, tests failed, or a workflow needs attention. But those checks aren’t the same as deciding whether a proposed change is the right one. That decision belongs to the builders in design war rooms.
The pull request can remain the anchor for that decision, even if the review process around it becomes more automated.
GitKord isn’t trying to reinvent that process. I wanted to make the existing workflow easier to follow.
One message, one thread
This is the central design decision behind GitKord.
Get Kevin Lizarazu’s stories in your inbox
Join Medium for free to get updates from this writer.
When a pull request is opened in a subscribed repository, GitKord creates a Discord message containing its important details: title, author, branch, target branch, reviewer status, and other relevant information.
As the PR changes, GitKord edits that same message.
A new commit? Update the message. A reviewer approves? Update the status. Changes are requested? Reflect that too. When the PR is merged or closed, its final state is shown without posting yet another notification.
The message becomes a current snapshot of the pull request rather than a collection of historical notifications.
🟢 Open → Review → 🟣 Merged
But a live message only solves half the problem. It tells you where things stand, not necessarily how they got there.
That’s why every PR also gets its own thread.
The thread is where GitKord records relevant activity as GitHub reports it: commits, reviews, status changes, and other supported events. It also gives contributors a dedicated place to discuss the change without taking over the main channel.
The distinction matters. The main channel stays focused on the current state of the work, while the thread provides the history and conversation behind it. A quick glance at a PR update preserves costly context switches, helping reviewers decide whether it needs five minutes, a longer review, or not attention from you just yet.
This also means the integration can do more than passively report activity. GitKord supports requesting and withdrawing reviews directly from Discord using /assign and /unassign.
Once accounts are linked, you can identify reviewers using their Discord mentions or GitHub usernames. The request is still validated against GitHub permissions, so Discord doesn’t become a shortcut around repository access.
It’s a small but important distinction: the integration shouldn’t just tell you what happened. It should help you do something about it, even on the go.
Making Discord a first-class integration
I didn’t want GitKord to be another webhook that someone has to configure for every repository.
GitKord uses a GitHub App. You install it once, select the repositories it can access, and GitHub sends the relevant events to GitKord. There’s no need to create and maintain a separate webhook for every repository.
On the Discord side, GitKord uses native messages, edits, threads, mentions, and slash commands. That means the integration feels like part of the server rather than an external notification feed.
There’s also account linking. Running /link starts GitHub's Device Authorization Flow. GitKord provides a verification code and a GitHub URL; you enter the code on GitHub and authorize the app there. GitKord can then associate your Discord account with your verified GitHub identity.
No need to manually claim a GitHub username in Discord.
The broader idea is simplicity. You shouldn’t need to be particularly technically savvy to get useful GitHub updates in your Discord server. Install the app, invite the bot, subscribe to a repository, and you’re ready to go.
A little engineering behind the scenes
GitKord is built in Rust, with an asynchronous backend that receives GitHub events, verifies their signatures, and processes them before updating Discord.
I wanted the system to be more than a quick webhook handler. Events should be processed reliably, failures should be visible, and the service should be understandable when something goes wrong.
A few pieces make that possible:
- RabbitMQ handles asynchronous event processing through a message queue.
- PostgreSQL stores the application data, including subscriptions and account links.
- Loki, Prometheus, and Grafana provide logging, metrics, and dashboards for understanding the service’s behavior.
- Railway hosts the application and supporting services.
I’m not going to turn this into an infrastructure walkthrough. The important part is that these tools give GitKord a foundation for processing events, tracking state, and diagnosing problems as usage grows.
I also think it’s worth emphasizing that building a useful developer integration shouldn’t require building an entire platform team around it. Working at AWS gave me an appreciation for the engineering that goes into reliable internal tooling. Building GitKord has been an opportunity to apply some of those ideas to a much smaller product.
Good tooling shouldn’t be reserved for organizations with dedicated teams to build it.
What’s next?
GitKord currently focuses on the pull request lifecycle, but there’s more to explore.
I’d like to make it easier to understand the wider development workflow without losing the simplicity that motivated the project in the first place.
Some areas I’m interested in:
- CI/CD visibility: Surface workflow runs, build results, and failed checks alongside the pull requests they belong to.
- More Git providers: Explore support for other hosting platforms so teams aren’t limited to GitHub.
- AI-powered summaries: Help developers catch up on changes, discussions, and agent activity without having to reconstruct the entire history themselves.
These are areas I’m exploring, not release promises. I want to understand which workflows developers actually need before deciding what belongs in GitKord.
I’d also love to hear how people are working with newer development patterns. How should GitKord fit into workflows like stacked pull requests? Should updates be connected across a stack? Should each PR remain independent while still making the broader change easier to follow? What other modern workflows are becoming difficult to track in Discord?
Those are the kinds of questions I’d like to work through with people actually using the product.
Give GitKord a try
GitKord started with a pretty simple frustration: I wanted to follow the work happening across my repositories without turning Discord into another notification feed.
I still think the pull request is a useful place to organize that work. The way we produce code is changing quickly, but teams still need to communicate intent, understand changes, review risk, and take responsibility for what ships.
I hope GitKord can make some of that easier, especially for smaller teams, independent developers, and open-source communities that don’t have the resources to build and maintain their own integrations.
If that sounds useful, give it a try:
- Website and documentation
- GitHub repository
- Add GitKord to Discord
- Install the GitHub App
- Join the Discord community
It’s still growing, and I’d genuinely appreciate feedback, bug reports, and ideas for where it should go next.
Thanks for reading, and happy shipping.
Less noise. More context. More time shipping. 🚀
