Enseñar a una IA a gobernarse a sí misma, para que pudiera construir software que gobierne juntas.

O: qué ocurrió cuando dejamos a Claude Code suelto en nuestro producto de gobernanza de juntas directivas, y le hicimos demostrar su trabajo en cada paso.

He aquí un problema del que casi nadie habla hasta que les afecta: la mayoría de las empresas pequeñas y medianas gestionan su gobernanza de juntas directivas a base de intuición. Una resolución se "aprueba" en una reunión, alguien edita un campo de estado en una hoja de cálculo de Pendiente a Aprobado, y seis meses después, cuando el abogado de un inversor pregunta quién dio realmente el visto bueno a esto, y cuándo, y si algo cambió entre la votación y la versión final, la respuesta honesta es un encogimiento de hombros y un vistazo a viejos hilos de correo electrónico. He visto esta misma escena repetirse más de una vez.

Ese es el problema que estamos construyendo software para resolver. Y los últimos dos días nos dieron un caso de estudio extraño, y bastante gratificante, sobre cómo lo estamos construyendo. Porque no solo escribimos software de gobernanza. Sin querer, llevamos a cabo un experimento sobre cómo gobernar el proceso que escribe software de gobernanza.

El reparto de personajes

Estamos construyendo sobre Claude Code, el agente de codificación de IA de Anthropic, el tipo de herramienta que se ha ganado una reputación, justa, en su mayor parte, de "vibe coding": usted describe lo que quiere, escribe código, usted lo revisa por encima, lo lanza, y espera lo mejor.

Nosotros no hacemos eso. En cambio, todo pasa por una plataforma de gobernanza de producto llamada Ceetrix, que se describe mejor como un gestor de proyectos extremadamente estricto que se ha leído todos los libros de texto de derecho contractual y se niega a dejar que nadie salga de la sala. Antes de que se escriba una sola línea de código, Ceetrix exige: qué problema estamos resolviendo (el PRD), cómo exactamente lo resolveremos (el diseño), en qué piezas específicas de trabajo se divide eso (las tareas) y, de manera crítica, qué pruebas demuestran que cada pieza realmente funciona. No permite marcar nada como terminado a menos que toda esa cadena se remonte con claridad a un requisito real. No se permiten intuiciones.

Así que Claude Code no puede improvisar por su cuenta. Puede construir, pero solo contra una especificación que no puede reinterpretar en silencio, y tiene que mostrar su trabajo: resultados de pruebas reales, evidencia real, retrospectivas reales de "esto es lo que haría diferente la próxima vez", antes de que algo se declare terminado.

Ayer: poco glamuroso, y necesario

Ayer publicamos dos piezas que nunca ganarán un premio de diseño, pero que toda empresa real necesita: una pantalla de ajustes donde el equipo puede elegir qué modelo de IA impulsa las distintas partes del producto, y un sistema de administración completo para invitar a compañeros de equipo, asignar roles y, de manera importante, gestionar la realidad de que la gente se va. Cuando alguien que era responsable de varios riesgos o acciones abiertas se marcha, el software no deja simplemente su trabajo huérfano. Obliga a que alguien lo reasigne explícitamente. Un detalle pequeño. El tipo de detalle pequeño que, si se pasa por alto, se convierte en un "espera, ¿de quién era esto?" tres meses después.

Hoy: enseñar al software a exigir cuentas de verdad a una junta directiva

La pieza central de hoy fue la funcionalidad que le da al producto entero sus dientes: las resoluciones de la junta, las decisiones formales y oficiales que toma una junta directiva. Ayer, en nuestro propio producto, una resolución era solo un campo de estado que cualquier persona que hubiera iniciado sesión podía editar. Aprobada, pendiente, lo que se escribiera. Hoy, se convirtió en algo más parecido a lo que una resolución realmente es en el mundo real: una decisión con peso.

Esto es lo que cambió, en términos sencillos:

• Una resolución ahora avanza por etapas reales, Borrador, En Revisión, Aprobada, Rechazada, y solo puede avanzar de la forma en que lo haría una votación real.
• Llegar a Aprobada requiere que dos personas distintas den su visto bueno, concretamente el presidente de la junta y el fundador, no la misma persona con dos sombreros. A esto lo llamamos segregación de funciones. Si algo sobre la resolución, su redacción, su responsable, su fecha de decisión, cambia aunque sea ligeramente entre la primera firma y la segunda, el sistema lo detecta y hace que ambos vuelvan a firmar. No se puede editar una resolución después de que alguien ya la haya aprobado con la esperanza de que no se note.
• Una vez que algo está Aprobado, se vuelve permanente. No se puede editar. No se puede eliminar. La única manera de cambiar de opinión es sustituirlo formalmente, lo que crea un nuevo borrador de resolución, visiblemente vinculado a aquel al que reemplaza, con un registro con marca de tiempo de quién hizo eso exactamente y por qué. Es la diferencia entre reescribir la historia en silencio y tachar algo con tinta, de manera que todos puedan seguir leyendo lo que decía antes.
• Ahora las Resoluciones pueden vincularse a los riesgos, acciones y decisiones reales con los que se relacionan, de modo que una resolución nunca queda flotando de forma aislada, desconectada de la realidad que se suponía que debía abordar.

Nada de esto es vistoso. Todo ello es exactamente lo que marca la diferencia entre «tenemos actas de la junta» y «tenemos un registro de gobernanza en el que un auditor, un comprador o el abogado de un inversor podrían confiar realmente durante la due diligence».

Cómo se construyó en realidad

Antes de que nada de esto tocara datos reales, se probó de cuatro maneras distintas: si la lógica subyacente funciona de forma aislada, si funciona cuando realmente se comunica con una base de datos, si funciona tal como lo experimentaría una persona haciendo clic en la pantalla, y si toda la historia (borrador, envío, aprobación, segunda aprobación, sustitución) funciona de principio a fin como una secuencia continua. Después, antes de darlo por terminado, se puso a prueba contra una copia real y temporal de la base de datos real, con sesiones de inicio de sesión reales, haciendo clic a través del flujo de trabajo real. No una simulación.

En cada uno de los puntos en los que Claude Code podría haber realizado una acción irreversible, se detuvo y preguntó primero. Antes de confirmar el código. Antes de subirlo a ningún sitio. Antes de tocar la base de datos de producción. Antes de desplegarlo en producción. No porque no pudiera técnicamente hacer esas cosas sin supervisión, sino porque ese es precisamente el objetivo de todo el ejercicio: una IA que avanza a gran velocidad sin problema hasta el momento en que una acción ya no se puede deshacer, y entonces le devuelve el bolígrafo a usted.

En un momento dado, al aplicar la actualización de la base de datos a producción, falló con un críptico error de autorización del proveedor de la nube, del tipo de mensaje que por un segundo hace que se le encoja el estómago. Resultó no ser nada: un fallo puntual de red. Se volvió a intentar treinta segundos después y se completó sin problemas. Lo menciono porque es un reflejo justo de toda la construcción. Esto no es magia, pero tampoco es frágil. Es simplemente software, actuando con cuidado.

Por qué esto es precisamente el objetivo

Hay una verdadera ironía en construir software de gobernanza, una herramienta cuyo trabajo consiste enteramente en obligar a que las decisiones se tomen con cuidado, quedando registradas, y siendo reversibles solo mediante un proceso formal visible, utilizando un proceso de desarrollo que se aplica exactamente eso a sí mismo. Cada requisito rastreado hasta un diseño. Cada diseño rastreado hasta tareas reales. Cada tarea cerrada con resultados de pruebas reales y una nota honesta sobre qué mejorar la próxima vez. Cada acción arriesgada y difícil de deshacer, detenida a la espera de un sí humano.

Hay una lección ahí que no tiene nada que ver específicamente con la IA. La calidad del trabajo, sea quien sea o lo que sea quien lo realice, mejora en el momento en que uno se niega a que «terminado» signifique algo menos que «aquí está la prueba». Eso ya era cierto antes de que la IA pudiera escribir código. Nos enorgullecíamos de esta disciplina en cada empresa que he ayudado a fundar o de la que he formado parte. Sigue siendo cierto ahora que la IA puede escribir el código. La herramienta ha cambiado. La disciplina no, y no debería hacerlo.

Mañana empezamos con la internacionalización: la función que permite a los usuarios de varios países utilizar la plataforma en su propio idioma y moneda. También les contaré cómo va eso.

¿Nos está siguiendo? Esto forma parte de un registro de construcción continuo de la plataforma de gobernanza de PoseidonGrooveAI, construida a la vista de todos, errores incluidos.