DEV GENIUS·

DEV Genius · por BotSmith

Un dev de IA en tu equipo, con disciplina de ingeniería.

Toma una idea, pregunta lo que no está claro, y entrega Pull Requests con spec, tests y QA en vivo — de la idea al merge, con revisión humana siempre.

preguntas al equipoapplycola de QATICKETDISEÑOPULL REQUESTCODE REVIEWQAMERGE

El flujo ágil estándar, del refinement al merge — y se adapta al proceso y a las fases de tu equipo.

Al menos 3 veces más rápido, del caso al merge.

< USD 3 de API de Claude por tarea implementada.

Qué es DEV Genius

DEV Genius es un agente que orquestás desde Slack sobre sandboxes aislados en la nube, con los repositorios de tu proyecto ya clonados y un ambiente completo listo para ejecutar y probar código real.

No es autocompletado de código: es un flujo de delivery completo. Analiza la tarea, redacta la spec, escribe el código con tests, abre los Pull Requests y deja un ambiente de QA navegable para probar el cambio antes de mergear.

Corre sobre tu infraestructura y tus credenciales, nunca al revés: tus llaves, tus datos, tu infraestructura.

Se integra con tu stack

  • Slack
  • ClickUp
  • Jira
  • GitHub
  • GitLab
  • Vercel

Slack como sala de control y tu tracker como fuente de verdad: el pipeline se adapta al proceso y a las fases de tu equipo, no al revés.

Cómo funciona

El ciclo completo va de la idea al merge, y cada fase queda visible en un hilo de Slack: nada avanza sin que el equipo lo vea.

DEFINE

De la idea al ticket

La IA investiga el código y la documentación viva del sistema y redacta el ticket completo en el tracker del equipo: contexto, alcance y criterios de aceptación. Pensado para producto, sin saber de código.

  1. Contás la idea en un hilo de Slack

    Alguien de producto abre un hilo y cuenta qué necesita, sin comandos ni jerga técnica.

  2. Investigación sobre el sistema real

    La IA revisa el código y la documentación del proyecto antes de proponer nada; si ya existe un ticket parecido en el backlog, lo avisa con el link.

  3. Preguntas de negocio, no técnicas

    Las dudas vuelven numeradas al hilo, solo sobre alcance y reglas de negocio. Se responden y se vuelve a analizar hasta que no quedan preguntas.

  4. Historias y criterios de aceptación

    Si la idea es grande, se granula en historias coordinadas; cada una queda con su alcance y sus criterios de aceptación, lista para tomar.

PREGUNTA

Nada avanza a ciegas

Antes de escribir una sola línea, las dudas técnicas llegan a los devs y las de negocio al equipo de producto, siempre por Slack.

  1. Dudas técnicas a los devs

    Lo que no está claro sobre el código o la arquitectura se pregunta en el hilo, directo a los devs del equipo.

  2. Dudas de negocio a producto

    Lo que depende de una decisión de producto se etiqueta al equipo correspondiente, también en el hilo.

  3. El plan se aprueba antes de construir

    Nada arranca a codear hasta que las dudas están resueltas y el plan de trabajo queda aprobado.

IMPLEMENTA

Spec, tests, código

En un sandbox aislado en la nube, la spec va antes que el código y los checks del proyecto son la puerta de calidad.

  1. Sandbox aislado en la nube

    Se aprovisiona un entorno efímero con los repositorios del proyecto, listo para ejecutar y probar código real.

  2. Spec antes que código

    Propuesta, diseño y plan de tareas se redactan y aprueban antes de escribir una sola línea.

  3. TDD tarea por tarea

    Cada tarea del plan se implementa con tests primero, código después.

  4. Los checks del proyecto son la puerta

    Linters, pre-commit y CI existentes deciden si el cambio pasa, no el criterio del agente.

VERIFICA Y ENTREGA

PRs, QA y merge

La entrega queda lista para revisar y probar, y el conocimiento del proyecto se actualiza solo al cerrar.

  1. Un PR por repositorio

    Con tests incluidos y una descripción lista para revisar.

  2. Ambiente de QA navegable

    Cada entrega levanta su propio ambiente efímero con una URL para probar el cambio en vivo.

  3. Code review humano

    Un dev revisa y aprueba, o pide ajustes, antes de que nada llegue a la rama principal.

  4. Merge y aprendizaje

    Al mergear, la documentación viva del proyecto se actualiza sola, dejando la siguiente tarea con menos dudas.

vía paralela

Cargas grandes

No es una fase más del ciclo: es una vía aparte para epics, cargas que agrupan semanas de trabajo en una serie de tickets coordinados.

  1. Descomposición en una serie de tickets

    La carga grande se parte en tickets chicos, verificables y con dependencias explícitas entre sí.

  2. Ejecución subtarea por subtarea

    El agente avanza una subtarea a la vez, sin esperar intervención manual entre una y la siguiente.

  3. Evaluador independiente

    Cada subtarea se revisa contra sus criterios de aceptación antes de integrarse a la rama de la carga.

  4. CI en verde como puerta

    Nada se integra sin los checks del proyecto en verde; lo que falla se difiere o frena la carga según la política definida.

Capacidades

El conocimiento no se pierde, se acumula

Cada tarea entregada deja el conocimiento del proyecto más completo, y ese conocimiento hace que la siguiente tarea empiece con menos dudas. Nadie documenta a mano.

workspace-specs

El corpus de specs

Un repositorio de especificaciones reconstruido por ingeniería inversa del código y el historial real del proyecto, que se alimenta solo: cada entrega produce su delta de specs como subproducto y, al mergear, un proceso automático lo valida, lo archiva y lo integra al corpus.

Ese corpus se clona en cada sandbox nuevo. La IA lo investiga antes de preguntar, así sus dudas llegan aterrizadas y sus propuestas se apoyan en la historia real de decisiones del proyecto.

grafo de conocimiento

El segundo cerebro

Sobre el corpus se mantiene un grafo de conocimiento navegable, con una nota por concepto del producto enlazada a sus specs y lecciones relacionadas. Se regenera solo con cada entrega.

Ese grafo es útil para el onboarding de gente nueva y para que la propia IA descubra conexiones que una búsqueda de texto no encuentra.

Principios y seguridad

  • Spec antes que código

    Ninguna feature se construye sin propuesta, diseño y plan aprobados. El proceso vive en el orquestador, no en el criterio del modelo.

  • TDD y puertas de calidad

    Tests primero, y los linters, type-checkers y suites del proyecto tienen que pasar antes de entregar.

  • Aislamiento real

    El agente corre en un sandbox en la nube, nunca en las máquinas del equipo; se destruye al terminar la tarea.

  • Humanos al mando

    Un dev revisa y aprueba cada Pull Request; el agente nunca hace merge solo.

Quién está detrás

Saúl Hernández, fundador de BotSmith

Saúl Hernández

Agentic Engineer, fundador de BotSmith SpA

15 años construyendo software — de pasante en Caracas a Dev Lead en Recorrido.cl.

El último año dejé de usar IA para programar más rápido y construí un sistema donde la IA programa y el pipeline garantiza la calidad.

DEV Genius es el resultado, y hoy opera en producción.

Preguntas frecuentes

Tu backlog es más largo que tu capacidad. Cambiemos eso.

Agenda una llamada de Discovery: revisamos el flujo actual de tu equipo y definimos juntos el piloto.

Agenda un Discovery