English

Borra tu andamiaje por una tarea

Tienes un archivo de reglas, algunas plantillas, una carpeta de skills escritas con cuidado. Va una pregunta incómoda: ¿cuándo revisaste por última vez si algo de eso todavía ayuda? No si existe, ni si está ordenado, sino si quitarlo cambiaría el resultado.

Los montajes son fósiles

El andamiaje se acumula. Agregas una regla porque el agente se equivocó, una plantilla porque una tarea se repitió, una skill porque un flujo pareció digno de codificar. Cada adición tuvo sentido ese día. Casi ninguna se vuelve a revisar.

El resultado es un montaje moldeado por problemas que tuviste hace meses, contra modelos que ya no se comportan igual. Y a diferencia del código, esta deuda se cobra de forma continua: un archivo de reglas siempre cargado cuesta contexto en cada sesión sin importar si la tarea lo necesita, y los archivos largos reducen de forma medible qué tan confiablemente se siguen las instrucciones.

Así que el andamiaje viejo no es neutral. Está pagando renta y, pasado cierto tamaño, desplazando activamente a las reglas que sí te importan.

El experimento

Hay una forma directa de averiguarlo, y toma una tarea:

• Elige una tarea real, no de juguete, algo representativo de tu trabajo.
• Córrela como siempre: archivo de reglas completo, memoria, plantillas, skills.
• Mueve todo eso a otra carpeta para que no se cargue.
• Corre la misma tarea otra vez desde una descripción simple de lo que quieres.
• Compara los dos resultados con honestidad.

La comparación es el punto, y deberías esperar un veredicto dividido y no una victoria limpia. Parte del andamiaje se va a ganar su lugar con claridad, y lo conservarás con confianza real en vez de por suposición. Parte va a resultar que responde una pregunta que ya nadie hace, y podrás borrarla sin la sensación de que quizá la necesites.

Qué suele sobrevivir y qué no

Predecir el resultado sirve menos que correrlo, pero hay un patrón en lo que aguanta.

Suele sobrevivir: los hechos no descubribles. Este directorio se genera, nunca lo edites a mano. Las pruebas necesitan estas dos variables de entorno primero. Este servicio está obsoleto, usa aquel. Nada en el código revela esto, así que se ganan su lugar permanente.

Seguido no sobrevive: las convenciones que el código ya anuncia. Si cada archivo del proyecto usa un patrón, una regla que enuncia ese patrón es contexto gastado en decirle al agente algo que puede ver mirando. Estructuras de carpetas, listas de dependencias y panoramas de arquitectura caen en el mismo saco, que es justo lo que el chequeo integrado ataca cuando propone recortes.

Hay un camino intermedio que conviene conocer antes de borrar: el material que solo importa a veces no tiene que ser todo o nada. Las reglas con alcance por ruta se cargan solo cuando el agente toca archivos que coinciden, y el cuerpo de una skill se carga solo al usarse. Moverlo ahí lo mantiene disponible a costo casi nulo.

Hazlo hábito, no evento único

Esto funciona como práctica recurrente porque el terreno se sigue moviendo. Una regla que era estructural hace un año puede ser redundante hoy, y nunca lo vas a notar con el uso normal, porque el uso normal jamás quita la variable.

Una cadencia razonable es una vez por trimestre, o cuando notes que tu montaje creció mucho. Cuesta una tarea duplicada y es la única señal honesta disponible.

Para llevar

El andamiaje no es gratis solo porque ya lo construiste. Corre una tarea real con todo apartado, compara, y conserva lo que se gana su lugar. Lo que sobreviva lo vas a confiar de verdad; lo que no, te estaba costando contexto en cada sesión.