Cómo gestionar la gobernanza de IA para evitar la deuda técnica

¿Te vas a mirar el correo mientras la IA reescribe tu código… y luego vuelves a casa de locos?

Tiempo estimado de lectura: 6 min

Poca gente lo dice en voz alta: dejar que un agente “lo corra y volvemos” es exactamente la forma más rápida de cavar una trampa de deuda técnica. Sales cinco minutos. Vuelves y el LLM te dejó un “decision” que grita: eso es una locura. No lo hagas.

Esto no es un problema de postureo. Es práctico. Es urgente.

Resumen rápido (lectores con prisa)

Un agente que ejecuta cambios sin gobernanza introduce decisiones sin autoría en el repo. Necesitas un mecanismo externo que intercepte commits, extraiga decisiones y requiera aprobación, convirtiéndolas en artefactos versionables y auditable—eso reduce deuda técnica y mejora trazabilidad.

1) Lo que pasa cuando “lo dejamos correr”

Un agente se queda ejecutando tareas. Encuentra ambigüedades. Encuentra dependencias rotas. Para avanzar, toma atajos. Guarda esos atajos en su chat. Tú haces commit y pum: el código llega a la rama, los tests pasan y la intención se evapora.

Resultado: hacks documentados en conversaciones privadas, no en el repo. Atajos que nadie planeó. Deuda técnica que aparece al lado del despliegue.

2) Por qué esto es peor que un bug cualquiera

Un bug puedes rastrearlo. Una decisión sin autoría es un agujero negro. Nadie recuerda por qué cambó la fórmula de impuestos a las 3 AM. Nadie puede auditar la razón. Y cuando el problema explota en producción, el “blame” no sirve: no hay decisión firmada, solo un commit huérfano y un chat que nadie va a revisar.

3) La solución no es prohibir la IA. Es gobernarla.

No más fe ciega. No más prompts que funcionan en beta pero rompen en prod. Necesitamos que cada decisión que importe deje rastro formal. Que sea un artefacto. Que sea buscable. Que tenga autoría y timestamp. Que puedas preguntar: “¿por qué esto existe?” y obtener una respuesta concreta.

4) Plum: la plomada que obliga a decidir en serio

Imagina una herramienta que corre al lado de Git y te fuerza a responder. No genera código por ti. No es una skill adentro del LLM. Es un checkpoint.

Básicos del flujo

• plum init → crea .plum y .plumignore, añade hooks.
• Cambias código con un agente.
• Intentas git commit. Plum compara diffs y scans de traces.
• Si hay decisiones, el commit falla hasta que apruebes, edites o rechaces.
• Si apruebas, plum actualiza la spec (Markdown) y agrega una entrada .jsonl con: pregunta, decisión, autor, branch y timestamps.

¿La ventaja? Cuando vuelvas del mail, no te encuentras sorpresas sin contexto. Te encuentras una decisión con nombre y apellido.

5) No puede ser una “skill” del agente —y punto

Una skill dentro del LLM es una sugerencia. Las sugerencias se ignoran. La gobernanza debe estar fuera. Tiene que poder bloquear commits, integrarse en CI y ser determinista. Si es opcional, no sirve.

6) ¿Qué hay dentro del .jsonl y por qué importa?

Ese archivo no es solo logs. Es la historia de la intención del proyecto. Cada entrada contiene:

• El dilema técnico.
• La decisión tomada.
• Quién aprobó.
• Si fue propuesto por el LLM o por un humano.
• Vínculo a la diff/PR.
• Marcas de tiempo.

Eso convierte la intención en dato: indexable, auditable, útil para auditorías y forensics.

7) Problemas reales —sin romanticismos

• Deduping de decisiones es fuzzy. Detectar “la misma decisión” entre conversaciones distintas no es trivial. Requiere heurísticas y ajuste repo-específico.
• Rollbacks automáticos: si rechazas la decisión, idealmente el sistema revierte el cambio o pide al agente rehacerlo. Hoy eso es work-in-progress.
• Ruido: si cada hotfix dispara cinco decisiones, la herramienta es odiada. Necesitas umbrales configurables.
• Specs crecen como malas hierbas. Hay que shardearlas en requerimientos atómicos, y sí: un LLM puede ayudar a fragmentarlas, pero diseña el flujo.

8) Umbrales: sensibilidad y contexto

La clave práctica es permitir tolerancias dinámicas:

• Modo strict: todo pasa por aprobación (fintech, salud).
• Modo sane: decisiones no críticas se agrupan y se presentan en lote.
• Modo fast-lane: “dangerously approve all” para prototipos.
• Filtros por carpeta: core = strict; ui-experiments = lenient.

Hazlo configurable por módulo y por rama. No es capricho: es supervivencia.

9) Integración con DSPy y el determinismo

Cuando puedas validar con código, hazlo. Usa parsers, tests y reglas. Donde necesites LLMs (p.ej. parse semántico del spec), estructura las llamadas con DSPy: inputs y outputs tipados. Menos alucinaciones, más predictibilidad. Enrutamiento por velocidad: dedupe puede ir a modelos OSS rápidos; parsing pesado a modelos más potentes.

10) ¿Qué debería cambiar en GitHub?

Markdown no es solo texto. Debe ser ciudadano de primera clase. Tu spec tiene que ser operable, con vínculos directos a decisiones, código y tests. Visualizar esa malla en GitHub (decisiones ↔ requisitos ↔ tests ↔ diffs) debería ser trivial. Imagina abrir un diff de markdown y ver “este requisito cambia X líneas de código” con enlaces directos. Eso es la próxima generación de repositorios.

11) Cultura y proceso: lo que no puedes automatizar

No automatices la cultura. Exige que cada PR responda:

• ¿Qué decisión justificó este cambio?
• ¿Qué requirement se actualiza?
• ¿Qué test cubre el cambio?

Haz que la herramienta extraiga esos metadatos y los convierta en entradas .jsonl. Convierte la disciplina en hábito.

12) Checklist mínimo para empezar hoy (15–30 minutos)

1. Versiona tu spec en Markdown en la raíz del repo.
2. Asegura tests automatizados (si eres Python, Pytest; si no, prepara adapter).
3. pip install plum-dev
4. plum init → apunta specs.md y carpeta de tests.
5. Añade .plumignore (README, docs, assets).
6. Configura umbrales: prod = strict; feature branches = lenient.
7. Prueba: haz un cambio via agente, intenta commit, observa el fail y aprueba la decisión.
8. Ejecuta plum sync -> revisa gaps spec↔tests↔code.

13) Si no lo haces: la factura llegará

Velocidad hoy = caos mañana. Cuando explote algo crítico a las 2 AM, nadie sabrá por qué la regla cambió. El time-to-fix se multiplicará. La deuda técnica se vuelve refractorable, y cada refactor cuesta más que el ahorro inicial de haber delegado.

14) Beneficios reales (sí, más allá del miedo)

• Auditoría real para compliance.
• Onboarding más rápido: nuevos devs leen el árbol de decisiones.
• Menos debates eternos en PRs: la intención está documentada.
• Productividad con control: velocidad sin descontrol.

15) Cierre y acción concreta

No es sexy. Es necesario. Instala la plomada. Prueba en una rama. No por postureo: por supervivencia técnica.

Quiero ayudarte a empezar ya. ¿Quieres que te mande:

• el template de .jsonl listo para copiar,
• el flujo de PR + configuración de CI que bloquea merges hasta sync exitoso,
• y un checklist de integración de Plum en 15 minutos?

Respóndeme “Mándame el template” y te lo doy ahora mismo.
Y mientras lo instalas, recuerda esto: velocidad sin plomada es solo una forma elegante de cavar tu propia trampa.

Esto no acaba aquí.

Si quieres profundizar en prácticas de gobernanza y automatización que encajan con este enfoque, revisa Dominicode Labs para recursos y experimentos relacionados.

FAQ

• ¿Qué hace exactamente Plum cuando detecta una decisión?
• ¿Plum bloquea commits automáticamente?
• ¿Cómo se almacena la autoría y los timestamps?
• ¿Cómo evito que la herramienta genere ruido?
• ¿Se puede integrar Plum en CI/CD?
• ¿Qué contiene una entrada .jsonl?
• ¿Qué pasa si rechazo una decisión detectada?
• ¿Cómo empezar en 15 minutos?

¿Qué hace exactamente Plum cuando detecta una decisión?

Intercepta el commit, extrae decisiones desde los traces del agente y falla el commit hasta que alguien apruebe, edite o rechace la decisión.

¿Plum bloquea commits automáticamente?

Sí: si detecta decisiones relevantes, el commit falla hasta que se resuelva la aprobación o edición de esa decisión.

¿Cómo se almacena la autoría y los timestamps?

Se agregan entradas .jsonl con campos como pregunta, decisión, autor, branch y timestamps; además la spec en Markdown se actualiza para reflejar la decisión.

¿Cómo evito que la herramienta genere ruido?

Configura umbrales y filtros por carpeta, agrupa decisiones no críticas en lotes y ajusta sensibilidad por rama o módulo.

¿Se puede integrar Plum en CI/CD?

Sí. La gobernanza debe integrarse en CI para ser efectiva; Plum puede bloquear merges hasta que el sync y las aprobaciones sean exitosas.

¿Qué contiene una entrada .jsonl?

Cada entrada incluye el dilema técnico, la decisión, quién aprobó, si fue propuesto por LLM o humano, vínculo a la diff/PR y marcas de tiempo.

¿Qué pasa si rechazo una decisión detectada?

Idealmente el sistema revierte el cambio o solicita al agente rehacerlo; hoy ese comportamiento es work-in-progress y depende de la configuración del repositorio.

¿Cómo empezar en 15 minutos?

Versiona la spec en Markdown, asegura tests automatizados, instala plum-dev, ejecuta plum init, configura .plumignore y umbrales, y prueba el flujo con un cambio vía agente.