This is a submission for Weekend Challenge: Passion Edition
While talking about AI workflow automation, someone asked me a simple question:
“Are...
For further actions, you may consider blocking this person and/or reporting abuse
I actually built something similar a while ago, though it was meant for bug-patches. It monitors the log-sink. If an error hits a threshold, or based on context is considered a high-risk, it is flagged for patching. Then it spins up Claude API to patch it, generate unit tests and run realtime testing via a docker container, if it can verify it's a clean patch, it creates a PR and sends a message to the telegram group via the bot for dev's to review. But Slack is probably more 'industry standard', good job!
Thank you that's cool, you could use telegram as well by installing the channel using
npm i hexabot-channel-telegram: npmjs.com/package/hexabot-channel-...Are you still using the project you built ?
My boss shelved the project... Despite it working flawlessly. Shows you what happens when you take your own time to build something useful, but all they want is a simple blazor dev...
I'm sorry to hear that 🙏
Not the end of the world, I keep what I learned, so in the future I might just release it as open-source. But for that, I'd need to get a different job first. I mean people dont really trust the AI providers with mission critical work, but a draft for a patch, with a clean description of what caused it and how it was remedied, is something that can save ALOT of time.
I agree 100% with your statement and attitude. Keep up the good work!
Question on the sandbox lifecycle, since "each Slack thread receives a cloned copy of the target repo" is the detail I keep turning over. If someone opens a thread on Monday, gets pulled into a meeting, and replies on Thursday, is that sandbox still sitting there with a three-day-old clone? A fix planned against stale main is the kind of thing that looks perfect in the PR body and then conflicts on merge or, worse, quietly reverts something. Do you re-pull on each turn, or is the thread expected to be short-lived enough that it never comes up? The intent classification getting its own stage instead of being folded into one big prompt is the part I'd steal, by the way.
To address this, we could update the AGENTS.md file in order to add this instruction, re-pull from main and rebase.
Now, as for the thread + sandbox lifetime, the channel source configuration allows to set the TTL (24h by default if I'm not mistaken)
Thank you for your feedback and you are more than welcome to contribute to the project. 🙏
The three-way split (Feature / Bug / Question) is the smartest design decision here. Most AI coding tools treat everything as a one-shot generation — you describe, it produces. But bugs are fundamentally different from features: a bug fix without understanding the root cause is just a new bug with better PR formatting. The "investigate first, wait for approval" gate on Bug type is exactly the kind of human-in-the-loop that keeps AI from confidently making things worse.
Curious about the sandbox isolation — are you running separate containers per request, or does the agent keep state across a conversation thread? The state question is the one that always bites me: if the agent inspects the repo for Bug A, then gets asked about Feature B in the same thread, does it carry context from A that might bias B?
Thanks, yes state is kept per thread, so it's one container per thread.
As for the context, it's stored in memory which has a scope that you configure either as global, per workflow, per thread or per workflow run.
Exactly — the per-thread state is the right call for a PR workflow. Global context would bleed between sessions, and per-workflow would lose continuity if you restart mid-task.
For memory scope, I'd add: per-thread scope means you get isolation without losing conversation context within that thread. Perfect for the three-way split approach — Feature/Bug/Question each stay clean in their own thread context.
The Slack-to-PR pattern is powerful, but the review boundary matters. Chat is a great place to capture intent; it is a risky place to hide execution details. I would want every PR to carry the original request, assumptions, changed files, verification output, and the exact places where the agent was uncertain.
Thank you for sharing such an excellent post. I really enjoyed reading it.
I’m a Python Full-Stack Engineer with over 10 years of experience designing and building scalable software solutions for clients across a variety of industries. Along the way, I’ve learned that successful projects depend not only on strong technical execution but also on creating real business value.
With my recent contract completed, I’m exploring new opportunities to collaborate with professionals who value innovation, practical problem-solving, and long-term partnerships. I enjoy discussing ideas that combine technical excellence with sound business strategy, creating outcomes that benefit everyone involved.
I believe every connection has the potential to become something meaningful. If you're interested in exchanging ideas, exploring opportunities, or simply connecting with someone who enjoys building impactful technology, I'd be happy to hear from you.
Wishing you success in your future endeavors, and I look forward to connecting.
If you allow me, let's discuss about collaboration and income
Let's connect on LinkedIn
Thanks for reaching out.
Linkedin is too public. I can't share my ideas in public.
How about gmail?
The bug workflow is a strong boundary: investigate in read-only mode, then require approval before mutation. I would also make the proposed diff, test results, and exact tools used part of the Slack thread, so the human review has an auditable handoff rather than just a PR link.
Congrats, this is a genuinely nice build, and dogfooding it on Hexabot itself is the right kind of proof. One thing worth watching as it grows: the moment approval gates differ per request type (bugs wait, features don't, questions are read-only), the intent classifier becomes a security boundary, not just UX routing. A bug misclassified as a feature silently skips the human approval step. I'd give that classifier its own tiny eval set with adversarial phrasings, because the rest of the pipeline inherits whatever it decides.
Exactly, many thanks! 🙏
The intent split is the smart part, but I'd push on the Bug path specifically. "Investigate first, then wait for approval before applying a fix" assumes the bot correctly reproduced the bug before it proposes anything — and reproduction is exactly where agents quietly cheat. In an isolated sandbox with a freshly cloned repo, the agent often can't actually trigger the reported failure (no prod data, no real config, no timing), so it "investigates," finds a plausible-looking cause, and hands you a fix for a bug it never saw fail. The green tests it writes then encode its own theory, not the actual defect.
The approval gate protects you from bad diffs, but it doesn't protect you from confident wrong diagnoses — a reviewer skimming an AI-authored PR at 4pm is going to rubber-stamp a clean-looking fix with passing tests. I'd make the Bug path refuse to propose a fix until it has a failing test that reproduces the reported behavior, and surface that red test in the thread first. If it can't write one, that's the honest answer, and it's more useful than a PR.
Slack is a natural command surface for agents, but it needs strong boundaries. The useful pattern is not just opening PRs from chat, it is preserving intent: who asked, what files were in scope, what was changed, what tests ran, and what still needs human review.
the bit about distinguishing feature vs bug vs query before acting — that's the decision most agents skip and then it bites you.
we built something similar for internal tooling. the failure mode: when the agent misclassifies a bug fix as a feature, it introduces scope creep in the branch (refactors adjacent code, adds unrelated tests). totally reasonable for a feature, footgun for a hotfix going out in 20 minutes.
ended up adding a Slack confirmation step: "treating this as a bug fix, limiting scope to X, continue?" one extra round trip but saved us from a few 2am reversions.
how are you handling cases where PR scope ends up larger than expected?
When the scope is larger than expected, we could add a condition right after the plan to assess whether there is a need to breakdown the work. The only limit I see currently is hitting the AI coding agent quota. The project is still fresh, I think there room to enhancing it.
Thank you for your feedback!
Interesting project! I didn't know we could build something like that and integrate it with Slack.