Cómo entender un repo que no escribiste

Pediste una función. Tu agente la escribió, la subió y pasó a la siguiente. Para el viernes hay cuarenta commits en tu repo, y no sabrías decir qué partes de tu producto tocaron.

Eso ya es lo normal. Los agentes suben cambios más rápido de lo que nadie alcanza a leer. La buena noticia: no necesitas leer el código para entender tu producto. Necesitas saber dónde mirar.

Empieza por la forma, no por los archivos

Una lista de archivos casi no dice nada. utils.ts, index.tsx, route.ts: todos los proyectos los tienen. Lo que quieres es la forma de tu producto, y todos los productos tienen la misma si los lees de izquierda a derecha.

1. Quién entra. Visitantes que no han entrado con su cuenta, personas con cuenta, otros programas que llaman a tu API y tareas que corren solas a su hora.
2. Qué hace el producto. Las pantallas que ve la gente, las acciones detrás de los botones, las piezas que comparten varias partes.
3. Qué guarda y a quién llama. Tus datos, tabla por tabla, y los servicios con los que habla: pagos, correo, IA, almacenamiento.

En cuanto ves esas tres columnas, muchas preguntas se responden solas. ¿Quién puede llegar al pago? ¿Qué escribe en la tabla de usuarios? ¿Qué pasa si se cae el servicio de correo?

Después mira qué cambió

La forma te dice qué tienes. La siguiente pregunta es qué se movió. No «qué archivos cambiaron», sino «qué partes de mi producto cambiaron esta semana, y quién las cambió».

Esa es la pregunta para después de una semana movida con tus agentes. Te dice qué probar antes de publicar y qué preguntarle a tu agente.

Después mira qué vale la pena arreglar

Hay cosas que hoy no rompen nada pero mañana duelen: pruebas que fallan, código con mucho movimiento que ninguna prueba cubre, archivos que ya nada usa, paquetes que instalaste y nunca importas, archivos tan grandes que cambiar una línea obliga a leer miles.

No tienes que encontrarlos tú. Tienes que saber que existen y dárselos a tu agente con los archivos correctos.

Antes de pedir un cambio

Un hábito más vale la pena. Antes de pedirle a tu agente que cambie algo, mira con qué se conecta esa parte. Un cambio pequeño en la parte que maneja el dinero puede llegar a muchos sitios. Si sabes a cuáles, puedes decirle a tu agente qué no debe romper, y sabes qué probar después.

Cómo ayuda SeeRepo

SeeRepo lee tu repo de GitHub y lo dibuja como ese mapa de izquierda a derecha: quién entra, tu producto, sus datos y servicios, con cables entre las partes. Cada parte puede ser un módulo propio, y entras con doble clic. Mira Módulos y partes.

• Una ficha para cada parte. Haz clic en una parte para leer qué hace en palabras simples, de qué recibe y a qué envía, si las pruebas la cubren y quién la hizo, personas y agentes. Mira La ficha de una parte.
• Qué cambió esta semana. Una parte que cambió en los últimos 7 días brilla en ámbar, y el filtro puede enseñarte solo lo que cambió tu agente. Mira Calor y cambios recientes y la guía Mira qué cambiaron tus agentes esta semana.
• La actividad. En Trayectoria, una gráfica de toda su vida: toca un día y ves qué pasó.
• Qué vale la pena arreglar. Salud enumera las tareas, la más seria primero, y cada una trae un prompt que copias y pegas en tu agente. Mira Salud y Dale a tu agente lo que vale la pena arreglar.
• Hasta dónde llega un cambio. La ficha de una parte te dice con qué se conecta antes de pedir el cambio. Mira Mira hasta dónde llega un cambio antes de pedirlo.
• Un mapa que puedes compartir. Enciende el mapa público y cualquiera con el enlace ve cómo funciona tu producto y cómo está hecho. Nunca el código.

El código se lee para dibujar el mapa y no se guarda. SeeRepo solo lee: nunca escribe en tu repo.

No tienes que convertirte en alguien que lee código. Tienes que conocer tu producto tan bien como lo conocen tus agentes. Un mapa te lleva casi todo el camino.