An always-on agent that picks up work from a Slack mention, codes in isolation, and delivers pull requests — battle-tested by building a football prediction app with it.
Role
Design, infra & evaluation
Period
2025 — Present
Company
Personal project
1 mention
in Slack triggers the full coding workflow
Isolated
git worktree per feature — no cross-contamination
E2E
validated building a Premier League prediction app
#Context
I use AI coding tools daily and wanted to push further: not an assistant in my editor, but an autonomous teammate I can delegate a feature to from my phone. The goal was an agent reachable from Slack that works unattended and delivers reviewable PRs — and a real project to prove whether that workflow actually produces mergeable code.
#Problem & constraints
Autonomous agents need hard isolation — an agent with free rein over the main working tree is one bad prompt away from chaos.
Commercial hosted agents bill per seat/task and keep your code in their infra — I wanted full control over the runtime and the model choice.
'It works' claims about AI agents are cheap — the setup needed a rigorous end-to-end test with objective quality metrics.
#Architecture
A Slack mention spawns an isolated coding run that ends in a reviewable PR.
A Slack app listens for mentions in a designated channel; each mention spawns an OpenHands runtime (Dockerized, self-hosted) driven by Kimi K3 with the task description as its brief. The agent clones the repo, creates an isolated git worktree for the feature, iterates — code, run, test, fix — and pushes a branch that opens a pull request for human review. To validate the workflow end-to-end, I used it to build BetScam: a Premier League match-prediction app with a Postgres data pipeline, comparing a naive Poisson model against Dixon-Coles, benchmarked against Pinnacle closing odds via Brier score and calibration curves.
slack.com / #dev-agents
J
#dev-agents
@agent add Dixon-Coles model to the prediction pipeline
↓ worktree: feat/dixon-coles
PR #42 — feat: Dixon-Coles model
+312-18tests passing
* Interface recreated with synthetic data — the production system holds client-confidential data.
#Key decisions & tradeoffs
01Git worktrees as the isolation boundary
Decision
Every task runs in its own worktree + branch; the agent can only ever affect its own workspace, and the deliverable is always a PR.
Alternatives
Letting the agent work directly on a clone (full wipes between runs) or on the main tree with human undo as the safety net.
Why
Worktrees are cheap, parallel-safe and natively git — several agent tasks can run concurrently without interfering, and review stays in the normal PR flow instead of a bespoke UI.
Cost of being wrong
Disk usage grows with concurrent tasks, and the agent needs solid git hygiene instructions to avoid branch sprawl.
02Self-hosted runtime over hosted agents
Decision
Run OpenHands in Docker on my own infrastructure with a model I choose (Kimi K3), triggered by events I control.
Alternatives
Hosted agent products (per-seat pricing, their infra, their model lineup).
Why
Full control over cost per task, model selection, network access and data. And building the plumbing myself is exactly the skill set I wanted to demonstrate.
Cost of being wrong
I own uptime, sandboxing and secret management — a hosted product absorbs that operational burden.
03Validation via a real project with objective metrics
Decision
Prove the agent workflow by shipping a non-trivial app with it — a football prediction system evaluated against bookmaker odds.
Alternatives
Toy demos (todo apps) or vibes-based claims about agent quality.
Why
A statistical modeling project has ground truth: Brier scores and calibration curves against Pinnacle odds don't care about hype. If the agent's code can produce a well-calibrated model pipeline, the workflow is real.
Cost of being wrong
Much slower than a demo — I spent the time a 'real project' takes, including reviewing and correcting agent PRs.
#Results
Autonomous
Slack mention → reviewed PR, no human in the loop until review
BetScam
full prediction app built through agent PRs (Poisson vs Dixon-Coles, Brier-scored)
Self-hosted
zero per-seat cost, full control of model & infra
#What I'd do differently
Task briefs matter more than model choice — the quality jump came from writing specs the way I'd write them for a junior engineer (acceptance criteria, test commands, constraints), not from swapping models. Next iteration: automated smoke tests gating PR creation, so obviously-broken branches never reach review.