Serie de 3 entregas | Tiempo estimado de lectura: 12 minutos

En la primera entrega expliqué el esqueleto del framework; en la segunda, el Working Backwards y el margen para la exploración. En esta tercera entrega, traduzco todo ese framework a archivos y prompts que realmente funcionan. Y al final, reflexiono sobre qué ha sido en realidad esta serie de artículos.

Implementación con CLAUDE.md en Claude Code

Claude Code tiene un archivo llamado CLAUDE.md. Se carga automáticamente al inicio de cada sesión y sirve para transmitirle a la IA las reglas, convenciones y arquitectura del proyecto.

Este framework se implementa como CLAUDE.md con la siguiente estructura.

/
├── CLAUDE.md                        # Base común (compartida por todos los perfiles)
├── .claude/profiles/
│   ├── PROFILE_A.md                 # Pequeña escala, alta velocidad
│   ├── PROFILE_B.md                 # Sistemas a gran escala
│   ├── PROFILE_C.md                 # Seguridad estricta
│   └── PROFILE_D.md                 # Misión crítica
└── apps/<app-name>/CLAUDE.md        # Cada app especifica su perfil

CLAUDE.md raíz: la base común

En el CLAUDE.md raíz solo van las reglas que aplican a todo, independientemente del perfil. La clave es mantenerlo corto. La ventana de contexto de Claude Code es finita.

Qué incluir: descripción de la estructura del proyecto, lista de comandos, convenciones de mensajes de commit, reglas no negociables (la regla Beyoncé, la pirámide de tests, el "shift left"), flujo de trabajo para decisiones de diseño, principios de Working Backwards, recomendaciones sobre el margen de exploración.

Qué no incluir: reglas de linter y formateador (se aplican forzosamente en CI), reglas específicas de cada perfil (se delegan a sus respectivos archivos), explicaciones largas.

Perfil A: la velocidad es lo que manda

El núcleo del Perfil A es "velocidad > perfección".

# Perfil A: Pequeña escala, alta velocidad

## Prioridad máxima: velocidad
- Code review: solo revisión primaria por IA. Los humanos solo intervienen en cambios de arquitectura
- Cobertura de tests: 60% (se acepta un nivel bajo)
- Principio YAGNI estricto. No construir lo que no se necesita ahora

Lo más importante es dejar por escrito de antemano los criterios de promoción. Si un sistema que empezó en el Perfil A crece y no hay forma de decidir "cuándo subir al Perfil B", acabarás operando un sistema grande con una cobertura de tests baja para siempre.

Perfil C: la seguridad está por encima de todo

La filosofía de diseño del Perfil C es la defensa en profundidad. La IA es una capa de defensa, no la última.

# Perfil C: Seguridad estricta

## Rol de la IA (deliberadamente limitado)

### Lo que se le delega a la IA
- Detección automática de patrones de vulnerabilidad conocidos (OWASP Top 10, etc.)
- Monitoreo de CVE en dependencias

### Lo que NO se le delega a la IA
- Descubrimiento de nuevos vectores de ataque → el humano amplía mediante sesiones de brainstorming
- Decisiones de diseño en autenticación y cifrado → el humano diseña, la IA solo asiste en la revisión

Lo que más destaca en el Perfil C es el flujo de trabajo para el modelado de amenazas. Tras enumerar amenazas con el análisis STRIDE, se amplía con la IA mediante sesiones de brainstorming: "Dame 5 vectores de ataque que podría estar pasando por alto en este diseño". Es un buen ejemplo de combinar la capacidad analítica humana con la exhaustividad de la IA.

Perfil D: no cambiar puede ser la decisión correcta

El Perfil D es el más conservador y, a la vez, el más singular.

# Perfil D: Misión crítica

## La particularidad de este perfil
- La carga de la prueba para justificar un cambio recae sobre quien lo propone
- "No toques lo que funciona" puede ser una decisión legítima
- Se recomienda firmemente que los PRs tengan menos de 200 líneas
- Despliegues prohibidos desde el viernes por la tarde hasta el lunes por la mañana

Mientras los demás perfiles apoyan "escribir buen código rápido", el Perfil D institucionaliza "el coraje de no cambiar nada". En sistemas como infraestructura o bases de datos, donde si algo se rompe todo se detiene, "no hacer nada" es en la práctica la mejor decisión posible.

Los canary releases también empiezan desde el 1%, con al menos una hora de monitoreo entre cada etapa. Se confirman 24 horas de funcionamiento estable en staging antes de pasar a producción. Un mundo donde la cautela supera a la velocidad.

Diseño de prompts para generar informes de análisis con IA

Para activar la tercera capa del framework (entorno de desarrollo de talento), se necesitan prompts que analicen los logs de las sesiones de brainstorming. Los diseñé en 4 etapas.

Prompt 1: análisis de sesión única (feedback inmediato)

Se introduce el log de una sesión de brainstorming y devuelve una puntuación en 5 dimensiones (del 1 al 5), sugerencias de mejora (máximo 3) y puntos fuertes (máximo 2) en formato JSON.

Lo más importante aquí son las instrucciones de privacidad.

【CUMPLIMIENTO ABSOLUTO】
La salida NO debe contener:
- Las preguntas concretas formuladas durante la sesión
- Nombres de proyectos, tecnologías, equipos o personas
- Fragmentos de código específicos o mensajes de error

Los hallazgos deben describirse de forma abstracta.
  ✗ "Planteó preguntas con descomposición estructural sobre la gestión de estado en React"
  ✓ "Planteó preguntas con descomposición por capas sobre la gestión de estado en el framework"

Con estas instrucciones, resulta imposible reconstruir el contenido concreto del log original a partir del informe de análisis de la IA.

Prompt 2: análisis trimestral (reconocimiento de patrones)

Se introduce la serie temporal de puntuaciones de varias sesiones y se visualiza la trayectoria de crecimiento y sus patrones. En la v2 se añadió aquí una verificación de alineación con objetivos.

Al generar las "acciones recomendadas", en lugar de simplemente cubrir los puntos débiles del score, se contrasta con los objetivos de carrera declarados por la persona y se prioriza el refuerzo de la dimensión que más contribuye a alcanzarlos.

Prompt 3: agregación de equipo (para managers)

Agrega los informes trimestrales anonimizados y analiza el perfil de 5 dimensiones del equipo en su conjunto, la diversidad de estilos de pensamiento y los gaps entre perfiles. La salida se genera de forma que sea imposible identificar a ningún individuo.

Prompt 4: auditoría de sesgos (ejecución trimestral)

Verifica la equidad del propio modelo de análisis de IA. Divide las puntuaciones de todos los miembros por género, nacionalidad, edad y antigüedad en la empresa, y comprueba si existen diferencias estadísticamente significativas.

Lo importante es que "hay diferencia" no equivale a "hay un problema". La correlación entre antigüedad y puntuación es razonable. Pero si existe correlación entre género y puntuación, eso es una señal de alerta que debe hacernos sospechar de un sesgo en el modelo.

Visión general del flujo de datos

Log bruto de la sesión (solo la persona + IA)
  ↓ Prompt 1
Puntuación de sesión única (solo la persona)
  ↓ Acumulación trimestral
  ↓ Prompt 2
Informe trimestral (persona → mentor → manager)
  ↓ Anonimización
  ↓ Prompt 3
Tendencias del equipo (manager)
  ↓ Etiquetado de atributos
  ↓ Prompt 4
Auditoría de sesgos (responsable de auditoría)

En cada etapa aumenta el nivel de abstracción, y el contenido del log bruto nunca se filtra a las capas superiores. Esta es la implementación técnica de la arquitectura de privacidad.

Hoja de ruta de implementación: lo más importante es no pasarse

Si después de leer todo esto sientes que "es imposible hacer todo esto de golpe", esa es la reacción correcta. El propio framework advierte contra la inversión inicial excesiva.

Fase Duración Qué hacer Qué NO hacer
Fase 1 1–2 semanas Monorepo + trunk-based + revisión primaria por IA. Empezar a operar con el Perfil A Introducir los perfiles B/C/D, cambiar el sistema de evaluación
Fase 2 2–4 semanas Automatización de tests, introducción gradual de los perfiles B/C/D Montar la infraestructura de análisis de logs de brainstorming
Fase 3 Continua Base de logs de brainstorming + evaluación en 6 dimensiones + arquitectura de privacidad Intentar completar todo de una sola vez
Fase 4 Continua Días de brainstorming en hackathon, brainstorming en parejas entre perfiles cruzados "Obligar" a explorar

Si aún no has alcanzado el PMF, con la Fase 1 es suficiente. Monta el monorepo y el desarrollo trunk-based, y pon a rodar la revisión primaria por IA. Solo con eso, la base de desarrollo mejora de forma drástica.

La "construcción de una cultura de exploración" de la Fase 4 llega al final, pero desde la Fase 1 ya hay que empezar a transmitir el mensaje de que "la exploración es bienvenida". Las estructuras formales se pueden crear después. El ambiente hay que crearlo desde el principio.

Este artículo en sí mismo es un ejemplo real de brainstorming

A lo largo de estas 3 entregas hemos seguido el proceso por el que un framework nació de sesiones de brainstorming con IA. Para terminar, quiero reflexionar sobre ese proceso en sí.

Lo que generó la cadena de preguntas

La pregunta inicial era algo sencillo: "¿Cambiará el desarrollo impulsado por IA las partes 3 y 4 de este libro?". A partir de ahí, tras una cadena de 7 preguntas, se completó un framework integral de 3 capas y 2 ejes.

Lo importante es que la IA no diseñó todo.

La IA devolvió respuestas lógicas y coherentes en cada ocasión. Pero quien descubrió los supuestos implícitos enterrados en esas respuestas y condujo hacia una estructura superior fue el ser humano que lanzaba las preguntas.

  • Cuando la IA dijo "el humano se encarga solo", se corrigió a "se puede ampliar con brainstorming"
  • Cuando la IA tomó la postura segura de "no usar en evaluaciones", se revirtió a "debería ser el ítem de evaluación más importante"
  • Cuando la IA dijo "mantener la ética con voluntad", se rediseñó a "hacer que sea imposible romperla estructuralmente"

La calidad de la pregunta determina la calidad de la respuesta. Es exactamente el principio que predica este mismo framework.

Los 3 patrones de brainstorming

Los patrones de brainstorming extraídos de esta sesión se convirtieron en guías dentro de la "colección de patrones de brainstorming" del framework.

El patrón de escalera lógica. Tras recibir la conclusión de una respuesta de la IA, uno se pregunta: "Tomando esta conclusión como punto de partida, ¿cuál es la pregunta aún más profunda?". El punto de llegada anterior se convierte en el punto de partida siguiente, y las preguntas forman una escalera continua.

El patrón de visibilización de supuestos. Se pregunta: "¿Qué está asumiendo implícitamente esta respuesta?" y "¿Qué pasaría si eliminamos ese supuesto?". La IA tiene dificultades para ser consciente de los supuestos de sus propias respuestas. Hacerlos visibles es tarea de quien pregunta.

El patrón del abogado del diablo. Se le pide a la IA: "Construye los 3 argumentos más poderosos en contra de elegir esta opción". Se usa a la IA como el mejor contraargumentador posible frente a las propias decisiones.

Lo que el brainstorming no genera

Pero al mismo tiempo, hay cosas que el brainstorming no generó.

La perspectiva del Working Backwards no surgió del brainstorming en sí, sino de una autocrítica al resultado del diseño del framework. La idea del margen de exploración surgió de contemplar el framework racional en su conjunto y preguntarse "¿qué le falta?".

El brainstorming expande el pensamiento, pero la capacidad de cuestionar el propio marco del pensamiento está fuera del brainstorming. El hecho de que el propio framework concluya con "este framework en sí mismo también debe ser objeto de brainstorming" viene precisamente de esta conciencia.

Cierre: seguir preguntando

"La ingeniería de software es la programación integrada a lo largo del tiempo"
  — Titus Winters, Google

La ingeniería de software en la era de la IA es
"la práctica en la que humanos e IA colaboran para seguir refinando la calidad de sus preguntas",
y al mismo tiempo "la práctica de cultivar, fuera de las preguntas, aquello que las preguntas no pueden medir".

Una obra maestra de 685 páginas se transformó, a través del brainstorming con IA, en un framework ejecutable. Y ese mismo framework dice: "Sométete a ti mismo a brainstorming con IA cada trimestre".

Es decir, este framework no tiene "versión final". Mientras se sigan haciendo preguntas, seguirá evolucionando.

Eso es, creo yo, la esencia de la ingeniería de software en la era impulsada por IA.

El contenido de esta serie es en sí mismo "un ejemplo real de cómo construir un framework mediante brainstorming con IA". En tu propio proyecto, empieza por lanzar una sola pregunta: "¿Cuál es el mayor punto débil de este diseño?" — de ahí parte todo.