Enseñar a una IA a autogobernarse, para que pudiera construir software que gobierne juntas.

O: lo que ocurrió cuando dejamos a Claude Code suelto en nuestro producto de gobernanza de juntas, y le hicimos demostrar su trabajo en cada uno de los pasos.

Aquí hay un problema del que casi nadie habla hasta que les afecta: la mayoría de las empresas pequeñas y medianas gestionan la gobernanza de su junta a base de impresiones. Una resolución se "aprueba" en una reunión, alguien edita un campo de estado en una hoja de cálculo de Pendiente a Aprobada, y seis meses después, cuando el abogado de un inversor pregunta quién realmente dio su 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 desplazarse por antiguos 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 solucionar. Y los últimos dos días nos dieron un caso de estudio extraño, y bastante encantador, sobre cómo lo estamos construyendo. Porque no solo escribimos software de gobernanza. Sin querer, ejecutamos 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, por la "programación por impresiones": describe lo que quiere, escribe código, usted lo revisa por encima, lo publica, y espera lo mejor.

Nosotros no hacemos eso. En cambio, todo pasa por una plataforma de gobernanza de producto llamada Ceetrix, descrita mejor como un gestor de proyectos extremadamente estricto que se ha leído todos los libros 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 de trabajo específicas se divide eso (las tareas) y, fundamentalmente, qué pruebas demuestran que cada pieza realmente funciona. No le permite marcar nada como hecho a menos que toda esa cadena se remonte claramente a un requisito real. No se permiten impresiones.

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 honestas 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 entregamos 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 completo de administración para invitar a compañeros de equipo, asignar roles y, de forma importante, gestionar la realidad de que las personas se marchan. Cuando alguien que era responsable de varios riesgos o acciones abiertas se va, el software no deja huérfano su trabajo sin más. Obliga a alguien a reasignarlo explícitamente. Un detalle pequeño. El tipo de detalle pequeño que, si se omite, se convierte en "espera, ¿de quién era esto?" tres meses después.

Hoy: enseñar al software a realmente exigir cuentas a una junta

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

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

• Una resolución ahora pasa por etapas reales, Borrador, En Revisión, Aprobada, Rechazada, y solo puede avanzar de la manera en que lo haría una votación real.
• Llegar a Aprobada requiere que dos personas distintas den su visto bueno, específicamente el presidente de la junta y el fundador, no la misma persona con dos sombreros distintos. 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 obliga a ambos a firmar de nuevo. No se puede editar una resolución después de que alguien ya la haya aprobado esperando que no se note.
• Una vez que algo está Aprobado, se vuelve permanente. No se puede editar. No se puede eliminar. La única forma de cambiar de opinión es reemplazarla formalmente, lo cual crea una nueva resolución en borrador, visiblemente vinculada a la que sustituye, con un registro con marca de tiempo de exactamente quién hizo eso y por qué. Es la diferencia entre reescribir silenciosamente la historia y tachar algo con tinta donde todos aún pueden leer lo que decía antes.
• Las resoluciones ahora pueden vincularse a los riesgos, acciones y decisiones reales con los que se relacionan, de modo que una resolución nunca flota aislada, desconectada de la realidad que se suponía que debía abordar.

Nada de esto es llamativo. Todo ello es exactamente lo que marca la diferencia entre "tenemos actas de junta" y "tenemos un registro de gobernanza en el que un auditor real, un adquirente o el abogado de un inversor podrían confiar durante la debida diligencia."

Cómo se construyó realmente

Antes de que nada de esto tocara datos reales, se probó de cuatro formas distintas: si la lógica subyacente funciona de forma aislada, si funciona cuando realmente se comunica con una base de datos, si funciona de la manera en que lo experimentaría una persona haciendo clic en la pantalla, y si toda la historia, borrador, enviar, aprobar, aprobar de nuevo, reemplazar, funciona de principio a fin como una secuencia continua. Después, antes de declararlo 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 punto en el que Claude Code podría haber tomado una acción irreversible, se detuvo y preguntó primero. Antes de confirmar el código. Antes de subirlo a cualquier lugar. Antes de tocar la base de datos de producción. Antes de desplegarlo en vivo. No porque no pudiera hacer técnicamente esas cosas sin supervisión, sino porque ese es el verdadero objetivo de todo el ejercicio: una IA que avanzará con gusto rápidamente hasta el momento en que una acción no se pueda deshacer, y entonces le devuelve el bolígrafo a usted.

En un momento dado, la aplicación de 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 le hace un nudo en el estómago. Resultó no ser nada: un fallo de red puntual. Se reintentó treinta segundos después y se completó sin problemas. Lo menciono porque refleja bien el conjunto de la construcción. Esto no es magia, y tampoco es frágil. Es simplemente software, siendo cuidadoso.

Por qué esto es todo el sentido

Hay una verdadera ironía en construir software de gobernanza, una herramienta cuyo trabajo completo es forzar que las decisiones se tomen con cuidado, quedando registradas, siendo reversibles solo mediante un proceso formal visible, usando un proceso de desarrollo que se aplica exactamente eso a sí mismo. Cada requisito trazado hasta un diseño. Cada diseño trazado 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, sin importar quién o qué lo esté haciendo, aumenta en el momento en que uno se niega a permitir que "terminado" signifique algo menos que "aquí está la prueba." Eso era cierto antes de que la IA pudiera escribir código. Nos sentíamos orgullosos 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 funcionalidad que permite a los usuarios de varios países usar la plataforma en su propio idioma y moneda. También les contaré cómo va eso.

Following along? Esto forma parte de un registro de construcción en curso de la plataforma de gobernanza de PoseidonGrooveAI's, construida de forma abierta, errores incluidos.