Serie de 3 partes｜ Tiempo estimado de lectura: 10 minutos

Un día, le pedí a una IA que "leyera" un libro de 685 páginas y lo hiciera "utilizable".

『Software Engineering at Google: Lessons Learned from Programming Over Time』. Una obra de referencia que recopila el conocimiento acumulado durante décadas por decenas de miles de ingenieros de Google, quienes han mantenido más de 2.000 millones de líneas de código.

Extraer la esencia del libro, crear un memo de apalancamiento y una matriz de acciones: todo eso estaba dentro de las fortalezas de la IA. Pero lo verdaderamente interesante vino después. Al seguir lanzándole preguntas a la IA, surgió un framework propio que trascendía los límites del libro.

Este artículo sigue ese proceso: cómo fue evolucionando el framework a través del "sparring" con la IA.

El punto de partida: la "trampa" de una gran obra

『Software Engineering at Google』 es un libro extraordinario. Pero parte de ciertas premisas.

Decenas de miles de ingenieros. Más de 200 millones de líneas de código. Sistemas que funcionan durante décadas. Es decir, la escala que asume este libro es extremadamente grande.

Si una startup o un equipo pequeño intenta aplicar las reglas de este libro tal cual, quedará aplastado bajo el peso de procesos excesivos. Pero descartarlo con un "nosotros no somos Google, así que no nos aplica" sería desperdiciar un conocimiento demasiado valioso.

Además, en 2026, las premisas son muy distintas a las de 2020, cuando se publicó el libro. Me refiero a la proliferación del desarrollo impulsado por IA. La revisión de código, la generación de tests, el refactoring: muchas de las prácticas que aborda el libro en sus partes 3 y 4 están cambiando de raíz con el auge de la IA.

Así que le lancé a la IA la primera pregunta.

«Si el desarrollo impulsado por IA se generaliza, ¿no cambiaría significativamente el contenido de este libro, especialmente las partes 3 y 4?»

El primer giro: la idea de los "perfiles"

La respuesta de la IA fue, como era de esperar, una clasificación entre "áreas que cambiarán" y "áreas que no cambiarán". La IA se encargaría de la primera revisión de código, la generación de tests sería su punto fuerte, la documentación se generaría automáticamente… pero las decisiones de arquitectura, las consideraciones éticas y las negociaciones entre equipos seguirían siendo difíciles para la IA.

Un análisis no del todo malo. Pero seguía pensando dentro del marco del libro. Así que lancé la siguiente pregunta.

«Este libro asume una escala de decenas de miles de ingenieros, pero si también asumimos el desarrollo impulsado por IA, ¿no sería posible que organizaciones pequeñas hicieran un desarrollo de "sacar algo funcional rápido" usando monorepo y desarrollo basado en trunk?»

La IA respondió que sí, y desarrolló la idea de que el monorepo + desarrollo basado en trunk es válido incluso para equipos pequeños. Pero ahí me di cuenta de algo: se estaba intentando aplicar las mismas reglas a todos los sistemas. Exigir la misma cobertura de tests a un prototipo MVP y a un sistema de pagos no tiene ningún sentido.

«En lugar de tener un único plan de ejecución, ¿no se podrían preparar distintos planes: uno para aplicar a todo, otro para sistemas con requisitos estrictos de seguridad, otro para sistemas a gran escala, otro para sistemas pequeños… y así crear un entorno de formación de talento que cubra las áreas donde la IA flaquea?»

De esta pregunta nació una estructura de 3 capas.

La estructura de 3 capas: el esqueleto del framework

Capa 1: Base común (aplicable a todos los sistemas · no negociable)

Pocas reglas, pero absolutas.

La base técnica y cultural que se aplica independientemente del tipo de sistema: monorepo, desarrollo basado en trunk, CI/CD impulsado por IA, etc. Las reglas de esta capa no son algo que se "decide cumplir o no": están incorporadas desde el principio.

Capa 2: Perfiles (operación según las características del sistema)

Institucionalizar la idea de que "no existe una solución universal".

Perfil Prioridad máxima Dependencia de IA Cobertura de tests
A: Pequeña escala / Alta velocidad Velocidad Máxima 60%
B: Sistema a gran escala Consistencia Media 80%
C: Seguridad estricta Seguridad Limitada 80% + pentesting
D: Misión crítica Mantenibilidad Mínima 80% + revisión múltiple

El equipo que construye un MVP se mueve rápido con el perfil A; el equipo que gestiona el sistema de pagos usa el perfil C con un revisor de seguridad dedicado. Un diseño donde distintos perfiles coexisten dentro de la misma organización.

Capa 3: Entorno de formación de talento

Un sistema para que los humanos sigan desarrollando sus capacidades en las 5 áreas donde la IA flaquea: decisiones de arquitectura, detección de amenazas desconocidas, juicios de valor ante trade-offs, negociación entre equipos y toma de decisiones inmediata ante incidentes.

Sin embargo, el diseño de esta tercera capa sería el que más evolucionaría a lo largo del sparring.

El segundo giro: el redescubrimiento del "sparring"

Mientras debatíamos el entorno de formación de la capa 3, la IA presentó "las 5 áreas que solo los humanos pueden asumir". La clasificación en sí era correcta. Pero me di cuenta de una premisa implícita.

Se estaba cayendo en una dicotomía de "la IA no puede → el humano lo hace solo".

«Incluso en las áreas donde la IA flaquea, ¿no sería útil hacer sparring con la IA para ampliar el pensamiento, en lugar de que el humano lo haga todo solo?»

Esta pregunta cambió la orientación de todo el framework.

¿Qué es el sparring? No es pedirle a la IA que escriba código ni que te dé respuestas. Es usar la IA como interlocutor para estructurar tu propio pensamiento, generar contraargumentos y descubrir perspectivas que se te estaban escapando.

Por ejemplo, cuando dudas sobre una decisión de diseño de arquitectura, le pides: "Construye los 3 contraargumentos más sólidos para no elegir esta opción". En el threat modeling, haces sparring con: "Piensa en 3 variantes que evolucionen mi vector de ataque X". En el pre-mortem de gestión de incidentes, le pides que liste "los 5 escenarios más probables en los que este sistema falla a las 3 de la mañana".

No pedirle respuestas a la IA, sino pedirle que amplíe las preguntas.

Al incorporar esta idea, la capa 3 pasó de ser "un espacio donde los humanos se entrenan solos" a "un espacio donde los humanos amplían su pensamiento a través del sparring con la IA".

El tercer giro: los logs de sparring como "activo"

Si el sparring es valioso, sus logs deberían poder analizarse. Aquí fui un paso más allá.

«Si hacemos obligatorio entregar los logs de sparring y damos feedback sobre ellos, ¿no sería mejor que los mentores incluyeran tanto a la IA como a humanos? Y si además la IA analizara los logs para detectar personalidad, aptitudes y compatibilidades, ¿no podríamos usarlo para mejorar los planes de desarrollo de talento y optimizar la composición de los equipos?»

La IA respondió con cautela: es útil, pero se necesitan límites éticos. El análisis de personalidad podría derivar en discriminación, existe el riesgo de vulnerar la privacidad, y si el sparring se siente como algo "vigilado", la seguridad psicológica se desmorona.

Todo correcto. Pero fui un paso más allá.

«Aunque el principio es prohibir su uso directo en evaluaciones, ¿no podría considerarse la calidad de las preguntas en el sparring como el criterio de evaluación más importante dentro del entorno de formación?»

Era una pregunta que daba la vuelta a la premisa de la IA. Transformar la medida de seguridad de "no usar los logs de sparring en evaluaciones" en "la calidad de las preguntas en el sparring es el criterio de evaluación más importante".

"No medir lo más importante no es porque no tengamos la técnica para medirlo, sino porque no tenemos el valor de medirlo."

El cuarto giro: proteger la privacidad con "estructura"

Usar la calidad de las preguntas del sparring en las evaluaciones. Pero también proteger la seguridad psicológica. ¿Cómo satisfacer simultáneamente estos dos requisitos aparentemente contradictorios?

«En cuanto a los logs de sparring, ¿no podríamos crear un sistema donde solo la IA tenga acceso a todo excepto a lo que el mentor va a revisar, y donde ningún humano —ni siquiera los de mayor rango— pueda ver los logs, sino únicamente el informe de análisis de la IA? Así, la organización que lo implemente tendría una estructura que la obliga a respetar esos límites éticos de verdad.»

De esta pregunta nació una arquitectura de privacidad con 3 capas de datos.

Capa Acceso Contenido
Capa 1: Log en bruto Solo el propio usuario y la IA Registro completo del sparring. Ni el CEO ni el CTO pueden verlo
Capa 2: Objeto de mentoring Solo el mentor elegido por el usuario Con límite de tiempo. Expira automáticamente a las 2 semanas
Capa 3: Informe de análisis de IA Usuario → Mentor → Manager Solo puntuaciones y tendencias. No incluye el contenido concreto de las preguntas

Lo decisivo es que esto no es una "política", sino un "mecanismo". No es una regla que diga "ni el CEO verá los logs en bruto", sino una estructura donde "aunque el CEO quisiera verlos, están cifrados y el permiso de acceso simplemente no existe".

Protegido no por confianza, sino por arquitectura.

La cadena de preguntas hasta aquí

Repasemos el recorrido desde la primera pregunta hasta este punto.

«¿No cambiarían las partes 3 y 4 del libro con el desarrollo impulsado por IA?»
  ↓ Ante la respuesta de la IA
«¿No podría una organización pequeña usar también monorepo + trunk-based?»
  ↓ Dando la vuelta a la premisa de la respuesta de la IA
«En lugar de aplicar lo mismo a todos los sistemas, ¿no se resuelven las trampas dividiendo en perfiles?»
  ↓ Atacando la dicotomía "el humano lo asume solo" de la IA
«Incluso en áreas donde la IA flaquea, ¿no se puede ampliar el pensamiento con sparring?»
  ↓ Si vamos a sistematizar el sparring
«¿Qué tal incluir a la IA como mentor y usar los logs para el desarrollo?»
  ↓ Dando la vuelta a la premisa de "prohibición de evaluación" de la IA
«¿No debería ser la calidad de las preguntas el criterio de evaluación más importante?»
  ↓ Para compatibilizarlo con la seguridad psicológica
«Si protegemos los logs en bruto con estructura, ¿no podría la organización mantener esos límites éticos de verdad?»

Cada pregunta apunta con precisión a la "premisa" de la respuesta de la IA y conduce a una estructura superior. Esto en sí mismo es un ejemplo real de sparring.

Avance del próximo episodio

En la primera parte, seguimos el proceso desde el análisis del libro hasta el nacimiento del esqueleto del framework (estructura de 3 capas + arquitectura de privacidad).

Sin embargo, este framework todavía tenía dos defectos graves.

En la segunda parte, explicaremos los dos "puntos ciegos estructurales" descubiertos durante el sparring con la IA —Working Backwards (retroceder desde el objetivo) y el margen para la exploración— y el framework final (v2) que los integra.

«La racionalidad llevada al extremo mata lo que no puede nacer de la racionalidad.»

El significado de estas palabras quedará claro en la segunda parte.

Continúa en la segunda parte: «La formación sin objetivos no es más que un juego: Working Backwards y el margen para la exploración» →