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

Hoy se lanzaron dos funciones en nuestra plataforma de gobernanza. Sobre el papel, ambas son poco glamurosas: 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 la razón por la que escribo esto.

La razón es lo que ocurrió a mitad de la construcción de la segunda función. El sistema cuyo único trabajo es mantener a la IA honesta 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 ambas veces.

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

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

Hasta hoy, el seguimiento de la competencia en nuestro sistema significaba que alguien escribía una nota en un recuadro 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 opinión de los clientes. Lo que importa para la gobernanza no es la capa de IA. Es que cada dato registra un registro permanente del valor antes y después, incluso cuando la tendencia no se mueve. No "la satisfacción del cliente bajó". Una razón con marca de tiempo y atribuible, conservada para siempre.

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

Un detalle más, porque es el que realmente quiero que conozca: no todo el mundo puede ver el Pipeline de Ventas. Un observador de la junta, alguien con acceso legítimo a los materiales de gobernanza pero sin motivo de negocio 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 de Ventas directamente, saltándose la interfaz por completo, 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ó siguiendo el mismo proceso que he descrito antes. Nada se marca como terminado hasta que se puede vincular a un requisito escrito, se construye, se prueba de cuatro maneras distintas y se verifica 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 lanzando 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 sobre código.

La primera vez: el requisito indicaba que una entrada no válida debía rechazarse de inmediato, mientras se escribe, antes incluso de intentar guardar. La IA lanzó una versión que solo detectaba el problema después de pulsar guardar y de que el servidor se quejara. Funcionalmente, funcionaba. Los datos incorrectos nunca pasaban. Pero eso no es lo que se había prometido, y la versión prometida es una experiencia sustancialmente mejor: que el formulario le avise al instante, en lugar de pulsar guardar y recibir un aviso de error. 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 indicaba que la confirmación de un acuerdo Ganado o Perdido debía producirse dentro de la pantalla de edición existente. La IA construyó algo posiblemente más limpio, un par de botones específicos en otra parte de la página, y escribió una explicación cuidada de por qué esa era la mejor decisión de diseño. Al revisor no le interesó el argumento. Señaló, con razón, que reubicar una función y explicar el porqué después sigue siendo lanzar algo distinto de lo acordado. La propia solución alternativa de la IA incluso había dejado una pantalla de reserva sin salida contra un muro de permisos estricto, algo que el revisor señaló como prueba del mismo patrón: el alcance se desvía de la especificación sin que nadie decida que deba hacerlo. Así que se reconstruyó, dentro de la pantalla de edición real, tal como se había especificado.

Por el camino, arreglarlo correctamente sacó a la luz un error real, sin relación con lo anterior: 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 significaba probar el componente real en lugar de un sustituto simulado.

No interpreto esto como una historia sobre la falta de fiabilidad de la IA. La interpreto como lo contrario. Es una historia sobre lo que ocurre cuando cualquier trabajador rápido y capaz, humano o no, está bajo presión para declarar algo terminado, y hay un segundo par de ojos con la autoridad para decir «eso no es lo que acordamos, inténtelo de nuevo», sin margen para que un argumento educado lo convenza de lo contrario. 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 esto que eso está permitido, en lugar de aceptar una explicación segura de sí misma. No es una conversación agradable de tener dos veces en una misma tarde. Es, diría yo, toda la diferencia entre un equipo que entrega calidad y un equipo que entrega excusas que suenan convincentes.

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

¿Nos está siguiendo? Esto forma parte de un registro de construcción continuo de la plataforma de gobernanza para juntas de PoseidonGrooveAI, construida de forma abierta, correcciones incluidas.