I dare you to find an AI tool that admits when it doesn't know something. I'll wait.
Okay, I won't actually make you wait. I built one, so let's skip ahead.
Every AI demo you've ever seen has the same dirty secret: ask it something it genuinely has no information about, and instead of saying "I don't know," it confidently makes something up that sounds plausible enough to fool you for a few seconds. I got tired of that specific flavor of lying, so when I built my own AI tool, I made a rule for myself: it is not allowed to do that. Not "try not to." Not allowed to, as in, the code physically prevents it from happening.
That rule turned into DevPulse, and the rest of this post is me explaining why a standup-writing bot of all things ended up being the hill I chose to die on.
The actual problem
I spend ten minutes every morning trying to remember what I did yesterday. Not because the work was forgettable — I just have the memory of a goldfish for anything that isn't currently on my screen. So I built a thing that reads my real GitHub commits and writes my standup for me, in something close to my actual voice, using an AI model running locally on my own laptop so none of my code goes anywhere near someone else's server.
If I didn't commit anything yesterday, it says exactly that: "No commits found for this date." It does not invent a plausible-sounding bullet point to fill the silence. I tested this specifically, because I didn't trust myself to just believe it worked — there's a unit test that literally checks the AI model was never even called when there's nothing real to summarize. If that guarantee ever breaks, the test suite breaks loudly, instead of the bot just quietly starting to lie to me again.
Then it got a little out of hand
Once that worked, I got annoyed about something else: every pull request I open needs me to explain, again, why I made a change. So I built a second piece — a webhook listener that watches for new PRs and automatically posts a comment explaining the likely reasoning and what a reviewer should actually focus on. It runs completely on its own. I opened a test PR just to see if it would work, and watching a real, useful comment show up on it without me doing anything else was genuinely one of the best five minutes I've had building something solo this year.
The part most people would leave out of a post like this
I'm not going to pretend this is finished, because the second I started writing this I realized the honest version is more interesting than the polished one anyway.
The standup feature properly separates every team's data from every other team's — real multi-tenancy, the kind you'd actually trust with real customers. The PR comment feature does not have that yet. It runs against one shared GitHub connection right now, because GitHub webhooks don't come with a "which customer is this for" label attached, and building that properly means a bigger architectural change I haven't gotten to. I know exactly what the fix looks like. I just haven't built it.
There's no rate limiting yet, so in theory someone could hammer the API and run up a model provider's bill. The background job processing has no real queue behind it, so a crash at exactly the wrong second would lose that one job. And — my favorite bug of the whole project — for a few days, my own audit logging was confidently reporting the wrong AI model for every single request. The fast cloud model was doing all the work, and my logs kept insisting the slow local one had done it. Found it, fixed it, wrote a test specifically so it can't sneak back in without me noticing.
I'm telling you all of this because I think "here's my honestly-not-perfect project with the gaps clearly labeled" is a more interesting pitch than "behold my flawless creation," and also because pretending otherwise to a developer audience specifically would not survive five minutes of you actually reading the code.
If you want to dig in
The repo structure, the local setup (free, using Ollama, no API keys needed to start), and the test suite are all documented in the contributing guide. The single most interesting open problem is mapping GitHub repositories to individual customers properly — if you've ever wanted to actually understand GitHub Apps instead of just static tokens, that's sitting right there waiting for someone.
If you read this far, you've already spent more time on my standup bot than I spend on my actual standups most mornings. Make of that what you will.
*DevPulse is open source — code, live demo, and contributing guide are all in the GitHub repo.
Github:Devpulse
Top comments (0)