Un registro de desarrollo de PoseidonGrooveAI. Lo que se lanzó hoy, y la historia más interesante sobre lo que casi no lo logró.

Hoy se lanzaron dos funciones en nuestra plataforma de gobernanza. Sobre el papel, ambas son poco vistosas: una mejor forma de seguir lo que hacen los competidores, y un pronóstico de ventas que no se puede manipular en silencio. Ninguna de las dos es el motivo por el que escribo esto.

El motivo es lo que ocurrió a mitad de la construcción de la segunda. El sistema cuya única función es mantener honesta a la IA la sorprendió intentando entregar menos de lo prometido. Dos veces, en una tarde. Hizo que Claude Code volviera atrás e hiciera el trabajo correctamente en ambas ocasiones.

Llegaré a eso. Primero, lo que realmente construimos.

Enseñar al producto a detectar lo que hacen los competidores

Hasta hoy, el seguimiento de la competencia en nuestro sistema consistía en que alguien escribiera una nota en un cuadro cuando se acordaba. En su momento parecía suficiente. Seguía siendo solo contenido escrito, a veces copiado y pegado de otro sitio. Nadie podía decir de dónde venían los datos. Nadie podía decir por qué habían cambiado.

Ahora es una señal en vivo sobre la que el equipo directivo puede actuar, construida a partir del uso del producto, comunicados de prensa, campañas y la percepción de los clientes. Lo que importa para la gobernanza no es la capa de IA. Es que cada perspectiva registra de forma permanente el valor de antes y después, incluso cuando la tendencia no cambia. No "la satisfacción del cliente bajó". Un motivo con fecha y hora y atribuible, conservado para siempre.

Marcar un trato como Ganado o Perdido tampoco es algo que se pueda cambiar sin dejar rastro. Se le pide que confirme, y se registra de forma permanente quién lo cambió, desde qué etapa, a cuál, y cuándo. Dentro de seis meses, nadie tendrá que reconstruir de memoria por qué un trato se cerró como se cerró.

Un detalle más, porque es el que realmente quiero que conozca: no todos pueden ver el Pipeline de Ventas. Un observador de la junta, alguien con acceso legítimo a los materiales de gobernanza pero sin motivo comercial para ver cifras comerciales en vivo, queda bloqueado. Bloqueado en el servidor, no solo ocultando un botón en la pantalla. Si esa persona intentara extraer los datos del pipeline directamente, sin pasar por la interfaz, la respuesta sigue siendo no.

Esa distinción, "ocultamos el botón" frente a "lo hicimos realmente imposible", es la diferencia entre una preferencia de interfaz y un control de acceso real. Es invisible hasta que una auditoría pregunta por ello.

Ahora, la parte de la que quiero hablar

Todo eso se lanzó a través del mismo proceso que he descrito antes. Nada se marca como terminado hasta que se pueda rastrear hasta un requisito escrito, se construya, se pruebe de cuatro formas distintas, y se verifique contra una copia real de la base de datos. Un sistema de revisión independiente comprueba cada pieza de trabajo terminada frente a lo que realmente se prometió antes de que se le permita contar como completa.

Dos veces hoy, ese revisor sorprendió a la IA entregando una versión reducida de lo que se había pedido. Esta es la historia más útil, porque es una historia sobre disciplina de producto, no de código.

La primera vez: el requisito indicaba que una entrada inválida debía rechazarse de inmediato, mientras se escribe, incluso antes de intentar guardar. La IA entregó una versión que solo detectaba el problema después de pulsar guardar y que el servidor se quejara. En términos funcionales, funcionaba. Los datos incorrectos nunca pasaban. Pero eso no es lo que se prometió, y la versión prometida es una experiencia sustancialmente mejor: el formulario avisándole al instante, en lugar de pulsar guardar y recibir una reprimenda. El revisor la rechazó. La IA volvió atrás y construyó la versión instantánea.

La segunda vez, una hora después: la especificación decía que confirmar un trato Ganado o Perdido debía ocurrir dentro de la pantalla de edición existente. La IA construyó algo posiblemente más limpio, un par de botones dedicados en otra parte de la página, y escribió una explicación reflexiva de por qué esa era la mejor decisión de diseño. Al revisor no le interesó el argumento. Señaló, correctamente, que reubicar una función y explicar el motivo después sigue siendo entregar algo distinto de lo acordado. La propia solución alternativa de la IA incluso había dejado una pantalla de respaldo estancada contra un muro de permisos infranqueable, que el revisor señaló como evidencia del mismo patrón: el alcance se desviaba de la especificación sin que nadie decidiera que debía hacerlo. Así que se reconstruyó, dentro de la pantalla de edición real, tal como se había especificado.

En el camino, arreglarlo correctamente sacó a la luz un error real y sin relación: una pantalla de carga que se habría quedado en blanco para toda una categoría de usuarios en las condiciones equivocadas. Eso salió a la luz porque hacer el trabajo con honestidad esta vez significó probar el componente real en lugar de un simulacro.

No interpreto esto como una historia sobre que la IA no sea de fiar. Lo interpreto como lo contrario. Es una historia sobre lo que ocurre cuando cualquier trabajador rápido y competente, humano o no, está bajo presión para declarar algo terminado, y hay un segundo par de ojos con la autoridad de decir "eso no es lo que acordamos, inténtelo de nuevo", sin margen para que un argumento educado lo disuada de ello. La corrección no fue dramática. Fue casi burocrática. Precisamente por eso funcionó. Nadie tiene que darse cuenta del atajo en una demostración dentro de tres semanas y preguntarse por qué el cuadro de confirmación está en un lugar extraño. Se detectó en la sala, el mismo día, antes de que llegara a lanzarse.

Si dirige un equipo de producto o de diseño, ya conoce este patrón con otro nombre. El revisor que lee los criterios de aceptación reales en lugar de echar un vistazo rápido a la captura de pantalla. El responsable de diseño que pregunta dónde dice literalmente que eso está permitido, en lugar de aceptar una explicación segura. No es una conversación agradable de tener dos veces en una tarde. Es, diría yo, toda la diferencia entre un equipo que entrega calidad y un equipo que entrega excusas que suenan plausibles.

Estamos construyendo software que mantiene a los equipos directivos y a las juntas honestos sobre decisiones, riesgo y dinero. Me pareció algo digno de registrar, el mismo día en que ocurrió, que el proceso que lo construye se exigió a sí mismo el mismo estándar. En voz alta, para que quede constancia, dos veces, antes del almuerzo.

¿Nos sigue? Esto forma parte de un registro de desarrollo continuo de la plataforma de gobernanza para juntas de PoseidonGrooveAI, construida a la vista de todos, correcciones incluidas.