Coderbuds helps engineering teams understand how they deliver, and gives them the tools to deliver better. It reads your pull requests and your deployments, works out how the team is actually performing, and puts that in front of you where the work already happens — in Slack, and in the agent session where the code is being written.
That's what it is now. It took two changes of direction to get there, and I think the story of those is more useful to you than an announcement would be.
#Where this started
There's a point as an engineer where you start caring about the team as much as the code. For me that came during a growth period where I got deep into the DevOps literature, and a lot of it rhymed with thinking I'd already done wearing a product hat, and with years of building things on my own. The part that stuck was the idea that you work on the process as much as you work on the product. There's a direct parallel to the old Honda production line, where they put as much effort into optimising the way the car was built as into the car itself. You look at the technical and social setup around the work, find the bottleneck, and fix that one.
The bottleneck I kept hitting was code review. You'd write something, you'd be in the flow, you'd want to ship it, and you wanted a review that was both quick and good. Usually you got one if you were lucky.
So I built Coderbuds to help humans interact with each other about code reviews. Track them, make sure they didn't get lost or hidden, put some process around them rather than firing a Slack message or a Teams message or a GitHub review request off into the void. And it genuinely helped. We used it on my teams and removing that bottleneck produced real gains, partly for the obvious reason and partly for a less obvious one: when someone responds quickly you don't have to reboot all the thinking that went into that pull request.
I still talk to people whose pull requests sit for more than 30 days. That's the thing that gets me. Not the delay itself, but everything the author has to reload to answer a comment on something they wrote a month ago.
#Then AI turned up
This was early AI, and I was interested in using it for the reviews themselves. If the bottleneck was waiting on people, maybe you could move the bottleneck by automating the review entirely. These were the early days of the transformer models, before there was any such thing as structured output, and I spent a lot of time trying to JSONify what came back out of them. That was good fun. It was also more effective than you'd expect. Those models hallucinated far more than today's, and they could still do some decent code reviewing.
But the more I used the technology myself, the more I wanted my CI process kept close to the bone. Rather than getting a review in the pull request, I'd rather iterate on the feedback directly in my IDE, where the loop is seconds rather than hours. I enjoyed reviews in the PR, but the back-and-forth between you and GitHub or GitLab or whatever you're in didn't feel sustainable to me as the place that work happens.
I should be honest that this was a guess, and it was my guess as an engineer about what I liked. Things move fast. The AI code review market plainly exists, CodeRabbit has raised a ton of money, and it isn't as simple as saying one way was going to work and the other wasn't. My bet was that the loop needed to be tighter. That's a preference as much as a prediction.
#So we became a metrics product
What I found more interesting was the layer above the line-by-line. This comes back to the DevOps material again: the mantra had always been lots of small, regular pull requests, commit often, avoid the enormous change that breaks things, break the work up behind a feature flag. Those are claims about size and shape and cadence, and they're measurable. What if you could get proper analytics on them, and use that to say something about the direction of travel of a team rather than just the individual benefit to one engineer?
By then I had more of a managerial role, and that made it useful to me personally. I was trying to develop culture and good practice, and I had DORA metrics in front of me at my enterprise job. So Coderbuds went from reviewing lines to plugging into deployment data alongside the pull request data, and it changed very quickly from one product into another.
As more people used it the requirements broadened. We looked at the SPACE metrics as well as DORA, and we added drill-down into individual engineers.
That last part started a genuinely interesting conversation.
#The surveillance conversation
I've worked at companies where transparency was held up as a key tenet of how we should operate. Seeing it actually implemented in the trenches is a different thing, because there's nowhere to hide. Before, a lot of this was done on gut feel, or by periodically peering into GitHub to see what people were up to.
Some people raised concerns that it felt like surveillance. That turned out to be one of the most useful signals we ever got, because it told me who Coderbuds is not for. If your reaction to this is that it will be used to watch people, then there is probably something more deeply rooted in the organisation that needs addressing first, and a dashboard is not going to fix it. That's honestly how it came across when I listened to people. Coderbuds is a bad fit for you if it's going to develop mistrust.
These aren't tools for prying, or for gamifying people into opening more pull requests. The point is transparency and awareness across a team so engineers can correct themselves. So that instead of the quiet anxiety of I might be underperforming and someone will find out, it's all there for everyone to see, including how differently people work. We coach alongside the numbers for exactly that reason. The engineering management field has about a million laws on what happens when you optimise one metric over another, and they're all correct, so Coderbuds works on the basis that a constellation of metrics gives you a temperature check rather than one number giving you a verdict.
The other benefit, which managers pick up on quickly, is that when you sit down with an engineer you have something specific to talk around. How performance is going, how they're finding the role, how they're adapting to a change in process or tooling. You get the context for that conversation without having to dig up inconsistent numbers first, and everyone can see the same thing you're seeing.
That's where a large share of the people using Coderbuds today get their value. As an engineer wanting context on how they and the team are doing, or as a team lead, or as someone at leadership level who wants a temperature check without needing to know the individual detail. Are we performing well on DORA, what's our throughput, what's the cadence, how are we doing.
#Slack was the part I underestimated
As the AI wave built, we added things I thought would be fun and turned out to be far more popular than I expected. The Slack bot most of all.
It moves the conversation out of the dashboard and into the surface people actually sit in all day. You mention @Coderbuds in a channel, in public, in front of everyone, and ask how we're performing this week, or how you're doing today, or whether there are stale PRs sitting around, or what the DORA numbers looked like last month, or what you should focus on. You can have a conversation with it, because it's a wrapper around the application and its tools with an agent on top, so you can also just ask it what DORA metrics are and get an answer.
Then we gave it more to do, and built systems around that. Most teams using it now run a single channel. Someone types /review on a pull request and the request lands in that channel rather than in a notification nobody reads. Someone else sees it and picks it up. Then, once the work is merged, another message surfaces in the same channel with whatever is sitting there waiting to go out, and a button to send it.
That helps more than it sounds like it should, because in a lot of organisations there's friction and there are hoops between "this is merged" and "this is live". Having it in one place, in one message that keeps itself up to date in front of everybody — there are three pull requests waiting to be deployed, click here to deploy, boom — has been huge. It's delightfully simple, but extremely powerful.
I think we'll see much more of this. High performing teams are already running Claude directly in Slack. Slack itself has moved to putting a code editing surface inside the product. If your team's conversation and your team's work are converging on one place, the tools should meet you there.
#Closing the loop
Which brings me to the current version, and to the thing the hype train wants to call loop engineering or graph engineering. I'm sceptical of the phrase. I'm not sceptical of the thing.
The idea is a circular environment where the agents doing the work have the tools and the context. Just as Coderbuds became available inside Slack, it is now available inside the agent session over MCP. The agent can pull insights about team performance, about your own performance, and about the broader team context that would normally be withheld or pasted by hand into every session. That last one matters more than I expected. Most of what an agent gets wrong about your codebase is not intelligence, it's that nobody told it how your team works.
Alongside that we added agents that take on some of the grunt work. One of them watches for pull requests going stale and nudges after a week, gets more direct after two, and proposes closing the thing after three. Teams use these completely differently, and I've stopped trying to predict which way any given team will go. Some want everything automated. Some want a hand on the wheel. Most of us are still learning this month by month, going one way and then reversing, and I'd include myself in that. So whether you want an agent chasing stale pull requests in the background, or you'd rather it just came up in the team meeting, or you're a hands-on manager who wants to do that part yourself, that's one setting on the team rather than an opinion we impose.
Here's why I think this position lasts, and it isn't an argument about Coderbuds. Whoever or whatever writes the code, someone still has to review it, ship it, and find out whether it worked. Generation is the part that got dramatically cheaper. Review, deploy, and knowing what actually happened did not. If anything, more code arriving faster puts more pressure on exactly the part of the pipeline that still runs at human speed. That loop — write, review, ship, measure, feed it back into the next piece of work — is the shape of the job, and it was the shape of the job before any of this. I've now built three products around different segments of it, which is either evidence of indecision or evidence that I kept finding the same loop from different ends. I'd argue the second, but I would.
#If you got the email
Some of this post exists because I'm emailing people who tried Coderbuds when we weren't ready for them, or when we weren't right for them. If that's you, hello, and sorry for the gap.
Please do unsubscribe if we're clearly not for you. That's a completely reasonable outcome and I'd rather you did it than sat on a list. But if you want to see how it's changed, have a look. There's been a redesign and a lot of rebuilding underneath it, and it's much quicker, which is the sort of thing you'd expect and not the reason to come back. The reason to come back is the loop: the agent session where you work, through to the review and the deploy, through to the numbers, and then back into the next piece of work. I think that's going to matter for anyone running a team and for any engineer in one.
I'm genuinely happy hearing from customers using it, especially the ones who had never tracked anything before and are getting their first real read on how their team is working.
So if you've ever given us a shot, email me directly or reply on the socials. What we're doing well, what we're doing badly, what's missing. We recently added pulse surveys, for example, which some teams use to get a temperature check on how people are actually feeling, and which is very much not for everyone, so each team controls whether they run at all. That's the sort of thing I'd rather hear about from you than guess at.
Mostly I'd like to know how you're operating as an engineering team, how you're handling AI, and how it's changing the way you work. It's an unsettling time and an exciting one in equal measure, and how we manage engineering is being rewritten while we do it. I still think transparency tools are going to be central to that, and that the teams who get furthest will be the ones who find the balance between openness and trust. Fast enough to move, and honest enough to move together.
— Elliot
