Gideon Code — El ciclo de desarrollo completo, orquestado
Un sistema que recorre el ciclo completo de desarrollo: requerimientos, arquitectura, base de datos, especificación, implementación con tests, verificación y archivo. Con 2,935 casos de test.
Restricciones
- Cada fase del desarrollo pierde el contexto al pasar a la siguiente, y lo que se pierde nunca se recupera.
- Un asistente sin límites escribe mucho y no verifica nada; el trabajo parece avanzar y no avanza.
- Las decisiones de arquitectura no quedan escritas y a los tres meses nadie recuerda por qué se eligió algo.
- Hay decisiones que no puede tomar un sistema solo: el stack, el esquema de datos y el tamaño de un cambio.
- El trabajo real no cabe en una sola herramienta: hay terminal, chat de equipo, revisión de código y panel.
El problema
El problema
El desarrollo de software no falla en el código. Falla en las juntas: el requerimiento se entiende a medias, la arquitectura se decide en un chat, el esquema de datos se improvisa y la especificación vive en la cabeza de alguien que se va de vacaciones.
Cuando el trabajo pasa de una fase a la siguiente, el contexto se pierde. Y lo que se pierde no se recupera: se reconstruye a base de suposiciones, y cada suposición se vuelve deuda.
Gideon Code es un sistema que recorre ese ciclo completo y obliga a que cada fase deje algo escrito antes de pasar a la siguiente.
Las dieciséis fases
- 01 Diseño · cuatro fases Requerimientos con historias y criterios de aceptación → arquitectura y modelo de dominio → recomendación de stack con alternativas → esquema de datos, relaciones, migraciones y diagrama.
- 02 Especificación · siete fases Propuesta → especificación con lenguaje normativo → diseño técnico → tareas con estimación → implementación con tests → verificación contra la especificación → archivo del cambio cerrado.
- 03 Interfaz · cinco fases Análisis de referencias y preferencias → confirmación de las preferencias por el humano → selección automática de imágenes e iconos → generación de componentes en paralelo → integración.
Del requerimiento al archivo, sin saltarse escalones
Los tres momentos en que se detiene
Un sistema que pregunta todo el tiempo es un formulario. Uno que nunca pregunta es un peligro. Gideon Code pausa exactamente en tres puntos:
- El stack Propone opciones con sus compensaciones y espera. Cambiar de stack después cuesta meses.
- El esquema de datos Muestra el diseño completo antes de escribir la primera migración.
- El tamaño del cambio Si estima que un cambio es demasiado grande, se detiene y pide estrategia de entrega.
Tres decisiones caras de revertir · todo lo demás avanza solo
La calidad, contada
- 2,935 Casos de test que verifican el sistema.
- 16 Fases en cascada con artefactos propios.
- 53 Comandos que cubren el ciclo y la operación diaria.
- 4 Motores de base de datos soportados en el diseño.
Un sistema que orquesta desarrollo tiene que estar probado, o se contradice
Casi tres mil casos de test no son una cifra decorativa: son la única razón por la que se pueden cambiar dieciséis fases sin romper las que ya funcionaban. Un sistema que exige tests en las fases que orquesta, y no se prueba a sí mismo, es una contradicción.
Vive donde ya trabaja el equipo
- Chat de equipo Reporta avance y recibe comandos desde Telegram y Slack.
- Revisión de código Revisa pull requests en GitHub sin salir del flujo.
- Panel web Estado del trabajo, fases y decisiones en una vista.
- Memoria de decisiones Grafo de conocimiento consultable: por qué se eligió cada cosa.
Mismo sistema para orquestar el ciclo y para el día a día
Y ordena lo que todavía no existe
Antes de construir hay una etapa de ideación que no vive en un chat: se generan variantes de una idea con ángulos distintos, se registran como entidades relacionadas, y dos ideas se pueden conjugar en una nueva. El resultado es un árbol consultable que sobrevive a la conversación donde nació.
Suena a juego y es lo contrario: la mayoría de las decisiones malas se toman porque solo se evaluó una opción. Esta etapa obliga a tener cinco antes de elegir.
Por qué esto también prueba el lado de desarrollo
Este sistema no es un producto que se vende y se olvida: es la herramienta con la que trabajo todos los días. Ahí está el ciclo completo de un desarrollador senior, hecho explícito y ejecutable — desde leer un requerimiento hasta archivar un cambio verificado.
Si algo demuestra que sé construir software, no es decirlo. Es haber construido la máquina que obliga a hacerlo bien.
Sobre el equipo
Gideon Code es mío: lo fundé y lo dirijo dentro de Alean. Es una herramienta interna del equipo, no un producto público, así que no tiene sitio ni repositorio abierto. La arquitectura, las fases, los gates y el modelo de datos son diseño mío; la implementación se hace con revisión por Pull Requests.
Decisiones
- 01
La cascada es obligatoria, no una sugerencia
Cada fase produce artefactos que alimentan la siguiente, y ninguna empieza sin lo que dejó la anterior. El requerimiento genera historias y criterios de aceptación; esos generan arquitectura y modelo de dominio; eso genera el esquema de datos; el esquema genera la especificación; la especificación genera las tareas; las tareas se implementan y se verifican contra el documento original.
DescartadoEncadenar prompts sueltos. Cada uno arranca de cero, nadie recuerda qué se decidió, y a la cuarta fase el sistema está construyendo algo que nadie pidió.
- 02
Tres decisiones se detienen a pedir permiso
El sistema pausa y pregunta en tres puntos: antes de fijar el stack, antes de pasar al diseño de datos, y cuando estima que un cambio supera un umbral de tamaño razonable. Son las tres decisiones caras de revertir. Lo demás avanza solo.
DescartadoAprobación humana en cada paso. Convierte el sistema en un formulario largo que nadie lee, y el humano empieza a aprobar sin mirar — que es peor que no preguntar.
- 03
La calidad no se declara, se cuenta
El sistema se verifica a sí mismo con casi tres mil casos de test. No es un número decorativo: es la única forma de cambiar dieciséis fases sin romper las que ya funcionaban. Un sistema que orquesta desarrollo y no se prueba a sí mismo es una contradicción.
- 04
La base de datos se diseña, no se improvisa
El diseño de datos es una fase con entregables: esquema, relaciones, migraciones y diagrama. Y soporta cuatro motores distintos, porque la decisión de motor es del proyecto, no de la herramienta.
- 05
El sistema vive donde ya trabaja el equipo
No es una terminal aislada. Reporta a Telegram y a Slack, revisa pull requests en GitHub, expone un panel web con el estado del trabajo y guarda las decisiones en un grafo de conocimiento para que las fases siguientes las consulten. El mismo sistema que orquesta el ciclo atiende el día a día.
- 06
También ordena lo que todavía no existe
Antes de construir hay una etapa de ideación: se generan variantes de una idea con ángulos distintos, se registran como entidades relacionadas y se pueden conjugar dos ideas en una nueva. No es una lluvia de ideas en un chat; queda un árbol consultable que sobrevive a la conversación.
Resultado
- Dieciséis fases en cascada que cubren del requerimiento al archivo del cambio, con artefactos verificables en cada una.
- Tres gates humanos en las decisiones caras de revertir — stack, esquema de datos y tamaño de cambio.
- 2,935 casos de test que sostienen el sistema mientras evoluciona.
- Diseño de base de datos con entregables y soporte para cuatro motores distintos.
- Integración con Telegram, Slack, revisión de pull requests en GitHub, panel web de estado y un grafo de conocimiento de decisiones.