En el texto anterior, comenté que las especificaciones empiezan a ganar espacio como fuente de la verdad.
Pero eso aún puede parecer abstracto.

En la práctica, esto empieza a aparecer en algo bastante simple: archivos que describen cómo tu equipo construye software.

Cosas como:

• README
• guías de código
• decisiones de arquitectura
• patrones de organización del sistema
• instrucciones sobre cómo contribuir

Y, más recientemente, esto también aparece en formatos como:

• constitutions
• system prompts
• skills y playbooks para agentes

Nombre y formato pueden variar.

Pero el rol es el mismo: dejar claro cómo trabaja el equipo.

Qué patrones seguimos aquí?
Cómo organizamos el código?
Qué tipo de decisiones privilegiamos?
Qué se considera un buen resultado?

Históricamente, mucho de esto no estaba escrito. Estas decisiones vivían en la cabeza de las personas.

El resultado era predecible: inconsistencia.

Cada persona implementaba de una forma. Cada parte del sistema evolucionaba con patrones ligeramente diferentes.
Y lo máximo que podíamos esperar era que, con buenas revisiones, el código convergiera. Sabemos que, en la práctica, rara vez quedaba realmente consistente.

Con IA, esto cambia.

Si haces explícito cómo tu equipo construye software, la probabilidad de que el código se genere siguiendo esos patrones aumenta mucho.
No porque la IA sea “mejor ingeniera”, sino porque dejaste claro qué esperas.

Antes, dependías de que cada persona interpretara correctamente esos patrones. Ahora, puedes aplicarlos con mucha más consistencia.

Y eso cambia el rol de estos archivos.

Dejan de ser documentación de apoyo y pasan a ser parte activa del proceso de desarrollo.

En la práctica, empiezan a funcionar como:

• referencia para el equipo
• input para la IA
• mecanismo de estandarización

Y aquí entran tres cambios importantes en el día a día:

• Estos archivos dejan de ser algo estático y pasan a evolucionar con frecuencia, idealmente varias veces por semana.
• Deben estar en el control de versiones, junto con el código, y ser utilizados por todo el equipo, no solo como documentación, sino como parte del flujo de trabajo.
• Cada vez que la IA genere algo que no salió como esperabas, en lugar de solo corregir el código, mejoras estos archivos. Con el tiempo, el sistema aprende cómo trabaja tu equipo.

Si en el texto anterior hablamos de que el foco sale del código, aquí queda claro hacia dónde va.

Los equipos que hagan esto bien no solo van a escribir menos código. Van a construir sistemas más consistentes.

Y esa diferencia empieza pequeña, pero se acumula rápido