Todo el trabajo

Agente de coding con IA autoalojado activado desde Slack

Un agente siempre activo que toma trabajo desde una mención en Slack, programa en aislamiento y entrega pull requests — probado en batalla construyendo una app de predicción de fútbol con él.

Rol
Diseño, infraestructura y evaluación
Período
2025 — Actualidad
Empresa
Proyecto personal

1 mention

en Slack dispara el flujo de coding completo

Isolated

worktree de git por feature — sin contaminación cruzada

E2E

validado construyendo una app de predicción de Premier League

#Contexto

Uso herramientas de coding con IA a diario y quería ir más allá: no un asistente en mi editor, sino un compañero autónomo al que pueda delegar una feature desde mi celular. El objetivo era un agente accesible desde Slack que trabaje sin supervisión y entregue PRs revisables — y un proyecto real para probar si ese flujo realmente produce código mergeable.

#Problema y restricciones

  • Los agentes autónomos necesitan aislamiento duro — un agente con libertad sobre el árbol de trabajo principal está a un mal prompt del caos.
  • Los agentes hospedados comerciales cobran por asiento/tarea y mantienen tu código en su infraestructura — yo quería control total sobre el runtime y la elección del modelo.
  • Las afirmaciones de 'funciona' sobre agentes de IA son baratas — el montaje necesitaba una prueba de punta a punta rigurosa con métricas objetivas de calidad.

#Arquitectura

Slack mention#dev-agentsOpenHandsDocker · Kimi K3Git worktreeisolated per featurePull requesthuman reviewRun & testiterate
Una mención en Slack levanta una ejecución de coding aislada que termina en un PR revisable.

Una app de Slack escucha menciones en un canal designado; cada mención levanta un runtime de OpenHands (en Docker, autoalojado) dirigido por Kimi K3 con la descripción de la tarea como brief. El agente clona el repo, crea un worktree de git aislado para la feature, itera — código, ejecución, tests, corrección — y empuja una rama que abre un pull request para revisión humana. Para validar el flujo de punta a punta, lo usé para construir BetScam: una app de predicción de partidos de Premier League con pipeline de datos en Postgres, comparando un modelo Poisson naive contra Dixon-Coles, evaluados contra las odds de cierre de Pinnacle vía Brier score y curvas de calibración.

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

* Interfaz recreada con datos sintéticos — el sistema productivo contiene datos confidenciales de clientes.

#Decisiones clave y tradeoffs

01Git worktrees como frontera de aislamiento

Decisión
Cada tarea corre en su propio worktree + rama; el agente solo puede afectar su propio workspace, y el entregable es siempre un PR.
Alternativas
Dejar al agente trabajar directamente en un clon (borrado total entre ejecuciones) o en el árbol principal con deshacer manual como red de seguridad.
Por qué
Los worktrees son baratos, seguros en paralelo y nativamente git — varias tareas del agente pueden correr en paralelo sin interferirse, y la revisión permanece en el flujo normal de PRs en vez de una UI a medida.
Costo de equivocarse
El uso de disco crece con tareas concurrentes, y el agente necesita instrucciones sólidas de higiene git para evitar proliferación de ramas.

02Runtime autoalojado sobre agentes hospedados

Decisión
Correr OpenHands en Docker en mi propia infraestructura con un modelo que elijo (Kimi K3), activado por eventos que controlo.
Alternativas
Productos hospedados de agentes (precio por asiento, su infraestructura, su catálogo de modelos).
Por qué
Control total sobre el costo por tarea, selección de modelo, acceso de red y datos. Y construir la plomería yo mismo es exactamente el conjunto de habilidades que quería demostrar.
Costo de equivocarse
Soy dueño del uptime, el sandboxing y la gestión de secretos — un producto hospedado absorbe esa carga operativa.

03Validación con un proyecto real y métricas objetivas

Decisión
Probar el flujo del agente entregando con él una app no trivial — un sistema de predicción de fútbol evaluado contra odds de casas de apuestas.
Alternativas
Demos de juguete (apps de tareas) o afirmaciones basadas en sensaciones sobre la calidad del agente.
Por qué
Un proyecto de modelado estadístico tiene verdad de terreno: los Brier scores y las curvas de calibración contra las odds de Pinnacle no se impresionan con hype. Si el código del agente produce un pipeline de modelo bien calibrado, el flujo es real.
Costo de equivocarse
Mucho más lento que una demo — invertí el tiempo que toma un 'proyecto real', incluyendo revisar y corregir los PRs del agente.

#Resultados

Autonomous

mención en Slack → PR revisado, sin humanos hasta la revisión

BetScam

app de predicción completa construida vía PRs del agente (Poisson vs Dixon-Coles, evaluada con Brier)

Self-hosted

cero costo por asiento, control total de modelo e infra

#Qué haría diferente

Los briefs de tarea importan más que la elección del modelo — el salto de calidad vino de escribir especificaciones como se las escribiría a un ingeniero junior (criterios de aceptación, comandos de test, restricciones), no de cambiar de modelo. Siguiente iteración: smoke tests automáticos que bloqueen la creación del PR, para que ramas obviamente rotas nunca lleguen a revisión.

#Stack

OpenHandsKimi K3Slack APIDockerGit worktreesPostgreSQLPythonSelf-hosted