Desarrollar Hub con IA: SDD, harness, agentes y SoftOS
La implementación de Hub no fue solo un ejercicio de producto. Fue una prueba real de cómo usar IA para construir software sin caer en el deporte extremo de “pídale algo al chat y rece”. Menos magia. Más método.
De caos técnico a ejecución gobernada
No se trató de desarrollar más rápido. Se trató de desarrollar con más control.
Hub nació como una experiencia para estudiantes, pero su construcción tocó muchas superficies: autenticación, permisos, datos académicos, eventos, beneficios, integraciones, frontend, backend, staging y despliegue.
En un producto así, un error visible en pantalla puede venir de cualquier parte: una migración pendiente, un contrato de API incompleto, una configuración de ambiente o un deploy que no publicó el build correcto. Ahí fue donde la metodología importó más que la velocidad.
Antes: IA como asistente suelto
- Errores dispersos y difíciles de clasificar.
- Cambios rápidos, pero con riesgo de abrir más frentes.
- Validaciones dependientes de intuición o revisión manual.
- Confusión entre “funciona local”, “pasó CI” y “está desplegado”.
Después: IA dentro de un sistema
- Specs como contratos de intención.
- Agentes con rol, alcance y límites claros.
- Harness para validar con evidencia repetible.
- SoftOS como capa de orquestación del proceso.
Hub fue el caso perfecto para probar una idea incómodamente necesaria.
La IA puede escribir código rápido. Eso ya lo sabemos. La pregunta más interesante es otra: ¿puede ayudar a construir software de manera confiable cuando el producto tiene múltiples capas, dependencias reales y usuarios esperando que todo funcione?
Para Hub, la respuesta no estuvo en usar IA como una especie de desarrollador fantasma que “resuelve todo”. La respuesta estuvo en usarla dentro de un flujo disciplinado: definir, ejecutar, verificar, desplegar y cerrar.
Ese flujo fue posible gracias a SoftOS, un sistema diseñado para coordinar trabajo de software con IA a partir de specs, repositorios, agentes, comandos, validaciones y evidencia.
- Intención
- Alcance
- Evidencia
- Validación
- Deploy
- Criterio humano
La IA no fue útil porque “hacía código”. Fue útil porque trabajó dentro de carriles.
SDD: cuando las specs dejan de ser decoración.
La base del proceso fue SDD, o Spec-Driven Development. En este enfoque, una spec no es un documento bonito para dejar olvidado en una carpeta. Es un contrato de intención.
Una buena spec define qué se va a construir, qué queda fuera, qué superficies se pueden tocar, qué comportamiento se espera y qué evidencia demuestra que el trabajo está completo.
Para Hub esto fue clave, porque no todo síntoma necesitaba una nueva spec. No todo error justificaba rediseñar el sistema. Muchas veces la decisión correcta fue más aburrida, pero más madura: usar una spec existente, cerrar un gap específico y no expandir el alcance porque sí.
Lo que evitó SDD
Que cada bug se convirtiera en una excusa para tocar medio sistema. Ese tipo de entusiasmo técnico suena heroico hasta que rompe producción.
Lo que permitió SDD
Foco, trazabilidad y control de cambios. En resumen: que la IA no improvisara, sino que trabajara con mapa.
Cuatro piezas que hicieron la diferencia.
El valor no estuvo en una herramienta aislada. Estuvo en la combinación entre dirección, estructura, evidencia y criterio.
SDD: dirección antes de ejecución
Las specs definieron intención, alcance, comportamiento esperado y evidencia de cierre. La IA trabajó mejor porque no estaba adivinando.
SoftOS: estructura para coordinar
SoftOS conectó specs, repos, agentes, comandos y validaciones. Hizo visible qué estaba local, remoto, desplegado o realmente validado.
Harness: evidencia, no fe
El harness permitió ejecutar, observar y validar el sistema de forma repetible. Nada de “debería funcionar”. Aquí tocaba demostrar.
Agentes: rol y límites
Los agentes funcionaron mejor cuando no eran una IA genérica haciendo de todo, sino piezas con responsabilidades claras dentro del flujo.
SoftOS: el sistema operativo del desarrollo con IA.
SoftOS funcionó como la capa que organizó el trabajo para que cada cambio tuviera intención, límites, validación y evidencia. No reemplazó al equipo. No reemplazó el criterio técnico. Y esa es precisamente la gracia.
Lo que hizo fue estructurar la ejecución para que el proceso no dependiera de memoria, intuición o conversaciones dispersas. En proyectos reales, esa diferencia pesa. Mucho.
SoftOS ayudó a responder preguntas que normalmente se vuelven ruido: qué spec aplica, qué repo está involucrado, qué runtime debe usarse, qué comandos validan el cambio, qué gates deben pasar, qué evidencia falta y si algo está listo localmente, remoto, desplegado o validado por un usuario.
“Listo en código” no es lo mismo que “listo en CI”. Y “desplegado” tampoco significa “validado”.
Duro, pero necesario. La realidad técnica no se arregla con optimismo.Harness: el puente entre intención y evidencia.
Uno de los elementos más valiosos del proceso fue el uso de harness. En sencillo: un harness es el conjunto de herramientas que permite ejecutar, validar y observar el sistema de forma repetible.
En Hub no bastaba con que un agente dijera “esto debería funcionar”. Tenía que correr comandos, revisar resultados, consultar workflows, validar endpoints y producir evidencia.
Eso cambió la relación con la IA. Ya no se trataba de confiar ciegamente en una respuesta. Se trataba de darle herramientas para demostrar su trabajo.
La spec define el comportamiento esperado
Antes de tocar código, se aclara qué debe pasar, qué no debe pasar y cómo se sabrá que el cambio está completo.
El agente implementa dentro del marco
La IA ejecuta o corrige, pero no inventa el alcance. Trabaja sobre una superficie concreta y con límites visibles.
El harness valida
Se corren comandos, gates, CI, deploy o smoke tests según corresponda. La evidencia pesa más que la sensación.
La evidencia decide el cierre
Un cambio solo se considera cerrado cuando hay pruebas suficientes para sostenerlo. Sin evidencia, sigue abierto. Triste, pero justo.
Agentes: IA con rol, no IA genérica.
Otro aprendizaje fuerte fue que los agentes funcionan mejor cuando tienen rol y límites. Durante Hub, la IA no actuó como una única entidad haciendo todo. Hubo una lógica de orquestación.
Un agente podía analizar. Otro podía ejecutar un cambio puntual. Otro podía validar evidencia. Y el orquestador mantenía la visión general del proyecto.
Esa figura fue clave porque su responsabilidad no era escribir cada línea de código, sino mantener el estado real: qué está cerrado, qué está parcialmente cerrado, qué falta, qué no debe tocarse, qué evidencia existe y qué riesgo sigue abierto.
El valor de los agentes no estuvo en reemplazar al desarrollador, sino en aumentar la capacidad de ejecución bajo supervisión. La IA podía avanzar rápido, sí, pero dentro de carriles definidos. Que es muy distinto a soltarla en el repo con café y fe.
De incertidumbre a sistema.
Al inicio, Hub tenía síntomas dispersos: errores de autenticación, problemas posteriores al login, endpoints que no respondían como se esperaba, integraciones incompletas, diferencias entre entornos y fallos de despliegue.
Sin metodología, eso habría sido una secuencia de parches. Con SoftOS, el proceso fue más ordenado: se identificaron los frentes, se ubicaron specs existentes, se separaron gaps, se asignó cada gap a una superficie, se generaron prompts específicos para agentes, se ejecutaron validaciones, se verificó deploy y se distinguió lo cerrado de lo pendiente.
La IA fue útil porque podía moverse entre contexto, código, logs y evidencia. Pero SoftOS fue lo que le dio estructura.
No fue usar IA. Fue usar IA dentro de un sistema de ingeniería.
Qué cambió en calidad.
SoftOS elevó la calidad principalmente por disciplina. No permitió que el proyecto dependiera solo de confianza. Cada cierre necesitaba evidencia.
Eso redujo cambios innecesarios, bajó el riesgo de regresión, separó mejor producto e infraestructura, alineó las pruebas con el comportamiento real y aclaró algo que en desarrollo suele confundirse demasiado: qué está listo y qué simplemente “parece listo”.
Flujo débil
Aparece un error → se pide una solución → se aplica un cambio → se prueba superficialmente → todos cruzan los dedos.
Flujo gobernado
Aparece un error → se clasifica → se contrasta contra specs → se define ownership → se ejecuta con agente → se valida con harness → se confirma con evidencia.
El papel humano sigue siendo el centro.
Este modelo no elimina al humano. Al contrario: exige mejor criterio humano.
La persona define prioridades, valida decisiones de producto, autoriza cambios sensibles, interpreta riesgos y decide cuándo un resultado es aceptable. La IA acelera análisis y ejecución, pero el criterio de cierre sigue siendo humano.
En Hub, esa dirección humana fue esencial para aclarar qué error correspondía realmente al problema actual, cuándo una parte ya debía considerarse resuelta, qué gaps importaban para cerrar staging, cuándo no crear nuevas specs y qué debía validar manualmente un usuario test.
Qué aprendimos.
La principal lección fue simple: la IA no debe usarse como magia. Debe usarse como fuerza de ejecución dentro de un sistema.
SDD dio dirección. SoftOS dio estructura. Los harness dieron evidencia. Los agentes dieron velocidad. La orquestación dio criterio.
Juntos formaron un flujo donde era posible avanzar rápido sin perder control. Y ese punto es clave, porque el futuro del desarrollo con IA no será solo escribir más código en menos tiempo. Será construir sistemas donde la IA pueda operar con contexto, límites y verificación.
- SDD = dirección
- SoftOS = estructura
- Harness = evidencia
- Agentes = velocidad
- Orquestación = criterio
La IA acelera el desarrollo. SoftOS hace que esa aceleración sea gobernable.
La implementación de Hub mostró una forma más madura de trabajar con IA: no como un generador de código suelto, sino como parte de un proceso completo de ingeniería.
La velocidad sirve, pero solo cuando no se convierte en desorden. Y en producto real, desorden con deploy es básicamente una novela de terror con usuarios incluidos.
El verdadero aprendizaje de Hub no fue “la IA puede programar”. Fue este: la IA necesita sistema, evidencia y criterio.
En PLG EdTech Lab seguiremos compartiendo lo que estamos construyendo, rompiendo, corrigiendo y aprendiendo mientras convertimos tecnología educativa en producto real.
