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 a menudo celebran la velocidad mientras ignoran la disciplina.
Eso funciona hasta que el software empieza a afectar a flujos de trabajo importantes.
En nuestro caso, utilizamos 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 se mantuvo gobernado desde los requisitos hasta la validación en producción.
Esa diferencia es lo que hizo que el resultado fuera útil.
Empiece con evidencia, no con entusiasmo
No empezamos con una instrucción de creación abierta. 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 estuvo precedida por la construcción del Sistema de Diseño y su fijación con Guardrails en Claude Design antes de enviar el prototipo inicial a Claude Code. Trataremos eso en otra publicación.
Eso creó tres versiones contrapuestas 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 conciliació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 estaban en la lógica subyacente. Ese es un estado habitual en el software en crecimiento, y es precisamente por eso que la gobernanza importa. Si se construye sobre suposiciones no verificadas, la IA solo acelera el riesgo.
Ceetrix impuso una cadena de entrega
Ceetrix impuso un camino estructurado:
PRD → Diseño → Tareas → Pruebas
Esto impidió que el equipo saltara directamente de la idea al código. Todo requisito tenía que convertirse en un diseño explícito. Todo diseño tenía que generar tareas concretas. Toda 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 grandes modelos de lenguaje son excelentes produciendo respuestas plausibles. La plausibilidad es útil, pero no es evidencia. Esto se suma a las salvaguardas de nuestro CLAUDE.md y hooks.
Un flujo de trabajo gobernado reduce la brecha entre ambas.
La primera versión 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 un software del que se espera que respalde decisiones operativas serias. El trabajo, por tanto, implicó sustituir las suposiciones estáticas por datos de referencia en vivo, anotaciones visibles y una lógica de reserva más segura.
Esto trataba de algo más que la 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, 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 tratarse como completa solo por la generación de código.
La validación reveló un problema de seguridad activo
Durante la validación de la versión, descubrimos que una ruta pública de Ajustes 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 tanto, requería una contención inmediata.
Se corrigieron los datos relevantes, 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 más laxos podrían pasar por alto por completo.
La lección no fue que la IA "hiciera seguridad" de forma independiente.
La lección fue que un flujo de trabajo trazable y basado en evidencia dificultó que el problema permaneciera oculto.
La segunda historia reforzó el comportamiento de Ajustes
Una segunda historia de producción se centró en la gestión de Ajustes y preferencias. Las opciones seleccionadas se aplicaron correctamente, las preferencias se guardaron 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 rara vez genera titulares llamativos, pero mejora sustancialmente la fiabilidad.
Ese es el punto más amplio. La calidad seria del software a menudo mejora mediante ganancias acumulativas de integridad, en lugar de funciones espectaculares.
El límite de control importó tanto como el código
A lo largo de 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 permanecer separadas. El desarrollo de producto asistido por IA debería seguir la misma regla.
Conclusión
Al final de la sesión, habíamos entregado mejoras significativas, ajustado el comportamiento operativo, descubierto y resuelto un problema en producción, y hecho avanzar el MVP más amplio a través de una ruta estructurada más clara.
Pero el resultado más importante fue conceptual.
La IA no sustituyó la gobernanza de producto.
Hizo posible una gobernanza de producto disciplinada 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 dónde usted exige evidencia antes de confiar en lo que se ha hecho. ¿Está gobernando hoy la entrega de su producto? Descubra Ceetrix.
Le mantendré informado a medida que avancemos.