Ceetrix y Claude Code nos ayudaron a avanzar rápidamente. El verdadero logro fue hacer que esa velocidad fuera fiable.
Divulgación: Ceetrix es una plataforma creada por un amigo cercano mío, antiguo empleado de Google, Director de Producto experimentado y experto en IA agéntica.
Las historias de programación con IA suelen celebrar la velocidad ignorando la disciplina.
Eso funciona hasta que el software empieza a afectar flujos de trabajo que importan.
En nuestro caso, usamos Claude Code y Ceetrix para hacer avanzar un producto B2B serio en una sola noche. Pero el resultado importante no fue simplemente que el código se generara rápidamente. Fue que el trabajo permaneció gobernado desde los requisitos hasta la validación en producción.
Esa diferencia es lo que hizo útil el resultado.
Empiece con evidencia, no con entusiasmo
No empezamos con un prompt de construcción abierto. Empezamos con un Documento de Requisitos de Producto estructurado y un análisis de brechas independiente basado en una aplicación existente.
La etapa de Requisitos de Producto también fue precedida por la construcción del Sistema de Diseño y su fijación con Guardrails en Claude Design antes de llevar el prototipo inicial a Claude Code. Cubriremos eso en otra publicación.
Eso creó tres versiones competidoras de la verdad.
El PRD describía el comportamiento previsto. El prototipo sugería el comportamiento actual. El repositorio revelaba el comportamiento real.
Solo uno de ellos podía tratarse como autoritativo.
Así que el primer paso no fue la implementación. Fue la reconciliación.
Varias áreas del producto eran más sólidas de lo esperado. Otras parecían más completas en la interfaz de lo que eran en la lógica subyacente. Ese es un estado común en el software en crecimiento, y es precisamente por eso que la gobernanza importa. Si construye sobre supuestos no probados, la IA solo acelera el riesgo.
Ceetrix impuso una cadena de entrega
Ceetrix impuso una ruta estructurada:
PRD → Diseño → Tareas → Pruebas
Esto impidió que el equipo saltara directamente de la idea al código. Cada requisito tenía que convertirse en un diseño explícito. Cada diseño tenía que generar tareas concretas. Cada tarea tenía que estar respaldada por pruebas y validación.
Eso cambió el papel del agente de IA.
En lugar de actuar como un improvisador rápido, se convirtió en un colaborador que operaba dentro de un sistema trazable. Eso importa porque los modelos de lenguaje de gran tamaño son excelentes produciendo respuestas plausibles. La plausibilidad es útil, pero no es evidencia. Esto se suma a las barreras de seguridad de nuestro CLAUDE.md y los hooks.
Un flujo de trabajo gobernado reduce la brecha entre ambos.
El primer lanzamiento se centró en la integridad operativa
La primera historia de producción elegida fue el manejo de divisas. Nos centramos primero en la forma en que la aplicación gestionaba la lógica de divisas y elegimos una integración de API para validar los cambios de divisas frente a 30 divisas.
La aplicación existente dependía de valores codificados de forma fija, lo cual es aceptable en un prototipo pero no en software del que se espera que respalde decisiones operativas serias. El trabajo, por tanto, implicó sustituir supuestos estáticos por datos de referencia en vivo, anotaciones visibles y una lógica de reserva más segura.
Esto era algo más que corrección técnica.
Si un sistema convierte un número, debe hacerlo visible. Si utiliza una tasa de referencia, debe indicarlo. Si recurre a una alternativa de reserva, ese comportamiento debe ser explícito. Una buena gobernanza significa que el sistema es honesto sobre su propia lógica.
La historia se implementó, se probó y se validó en un entorno real, en lugar de considerarse completa únicamente en virtud de la generación de código.
La validación expuso un problema de seguridad en producción
Durante la validación de la versión, descubrimos que una ruta de ajustes de cara al público exponía más información de la prevista. Tras un examen más detallado, el problema parecía implicar un patrón de valores sensibles y, por lo tanto, requería contención inmediata.
Se corrigieron los datos correspondientes, se restringió la ruta expuesta y se mejoraron las salvaguardas circundantes para que fuera menos probable que se repitiera el mismo tipo de problema. El episodio demostró algo importante sobre la entrega gobernada. Cuando los equipos validan cuidadosamente frente al comportamiento real, salen a la luz problemas que flujos de trabajo más rápidos pero menos rigurosos podrían pasar por alto por completo.
La lección no fue que la IA "se encargara de la seguridad" de forma independiente.
La lección fue que un flujo de trabajo trazable y basado en evidencias dificultó que el problema permaneciera oculto.
La segunda historia reforzó el comportamiento de los ajustes
Una segunda historia de producción se centró en la gestión de los ajustes y las preferencias. Las opciones seleccionadas se aplicaron correctamente, las preferencias se conservaron de forma más fiable y los cambios importantes pasaron a ser auditables. También se corrigieron problemas de comportamiento menores como parte de la validación de extremo a extremo.
Este tipo de trabajo raramente genera titulares llamativos, pero mejora sustancialmente la fiabilidad.
Ese es el argumento más amplio. La calidad seria del software a menudo mejora mediante ganancias acumulativas de integridad, en lugar de mediante funciones espectaculares.
El límite de control importó tanto como el código
Durante toda la sesión, el agente de IA pudo analizar, diseñar, implementar, probar y explicar. Pero no cruzó límites irreversibles sin aprobación.
- Antes de confirmar los cambios, se detuvo
- Antes de desplegar, se detuvo
- Antes de tocar datos con forma de producción, se detuvo
Eso no es ineficiencia. Es un modelo de control funcional.
En cualquier entorno operativo serio, la capacidad y la autoridad deben mantenerse separadas. El desarrollo de productos asistido por IA debe seguir la misma regla.
Conclusión
Al final de la sesión, habíamos implementado mejoras significativas, ajustado el comportamiento operativo, detectado y resuelto un problema en producción, y avanzado en el MVP más amplio mediante una vía estructurada más clara.
Pero el resultado más importante fue conceptual.
La IA no sustituyó la gobernanza del producto.
Hizo posible una gobernanza disciplinada del producto a una velocidad mucho mayor.
Esa es una historia mucho más duradera que otro ejemplo de código generado rápidamente.
La pregunta para la entrega asistida por IA ya no es si un modelo puede construir. Es si su proceso genera suficiente evidencia para confiar en lo que se construye. Es donde usted exige evidencia antes de confiar en lo que han hecho. ¿Está gobernando hoy la entrega de su producto? Consulte Ceetrix.
Le mantendré informado a medida que avancemos.