Código generado: evita que tu agente parchee la salida

Un archivo generado es una salida que un compilador o generador produce a partir de otros archivos. Si tu agente corrige esa salida directamente, el arreglo puede desaparecer al regenerarla. Antes de aceptar el cambio, identifica qué proceso escribe el archivo y dónde están las entradas que determinan su contenido.

El arreglo desaparece cuando reconstruyes el proyecto

Si una corrección desaparece después de reconstruir, comprueba quién escribe el archivo antes de pedir otro parche. Ese síntoma justifica investigar una posible edición sobre código generado, aunque por sí solo no demuestra la causa. Necesitas relacionar el archivo modificado con el proceso que lo vuelve a producir.

Supongamos que tu aplicación calcula mal un descuento y el agente modifica dist/pricing.js. En este escenario hipotético, la aplicación ejecuta ese archivo y la comprobación manual devuelve el importe esperado. Sin embargo, el código que sirve de entrada al compilador conserva el cálculo anterior. Si la siguiente compilación vuelve a producir ese archivo desde la entrada sin corregir, el resultado esperado es que reaparezca el fallo.

La relación es posible en TypeScript: según su referencia de configuración, outDir establece el directorio donde se emiten los archivos de salida. Eso permite comprobar si una ruta pertenece a la salida del compilador. El nombre dist, por sí solo, no prueba nada sobre tu repositorio.

Tu primera decisión consiste en separar dos preguntas: si el cambio corrige el comportamiento y si está aplicado en un lugar que conserva la corrección. Puedes tener una respuesta afirmativa a la primera y negativa a la segunda. Pide al agente que explique la procedencia del archivo antes de continuar editándolo.

La causa está en la relación entre entrada y salida

La corrección duradera debe quedar representada en las entradas del proceso que reconstruye el archivo. Esas entradas pueden ser código fuente, un contrato de API, una plantilla o la configuración del generador. Localizar esa relación te permite elegir dónde intervenir sin adivinar por la extensión del archivo.

OpenAPI Generator ofrece un ejemplo documentado: transforma un documento OpenAPI en un modelo interno y aplica plantillas para producir código. Su documentación de plantillas explica también cómo personalizar las plantillas existentes. Por tanto, ante una salida incorrecta, hay que distinguir entre un dato incorrecto del contrato y una transformación incorrecta de ese dato.

Supongamos que un cliente generado contiene un campo obligatorio que debería ser opcional. Si el contrato de entrada lo declara obligatorio por error, cambiar únicamente el cliente dejaría intacta la causa. Si el contrato ya expresa lo correcto, corresponde investigar cómo lo interpreta el generador. No conviene modificar el contrato para compensar un problema de transformación sin comprobar antes esa diferencia.

Para orientar al agente, pide una explicación con rutas concretas: qué archivo se consume, qué herramienta lo procesa y dónde escribe el resultado. Una respuesta como "parece autogenerado" solo establece una sospecha. Como criterio práctico propio, considera identificada la procedencia cuando puedes señalar tanto la entrada como la configuración o implementación que conecta esa entrada con la salida.

Confirma la procedencia sin borrar archivos a ciegas

Confirma primero la relación de generación mediante lectura; después, si hace falta, comprueba la reconstrucción. No necesitas empezar borrando directorios. Conserva los cambios existentes y examina el archivo afectado, la configuración del proyecto y la tarea que supuestamente lo produce.

Empieza por las cabeceras y comentarios del archivo. Un aviso de generación es una pista útil, pero sigue buscando el proceso concreto. Después localiza la ruta de salida en la configuración y comprueba qué entradas utiliza. Evita que el agente dé por terminada la investigación solo porque encuentre otro archivo con el mismo nombre.

En un proyecto TypeScript, los mapas de fuentes pueden ayudarte a recorrer esa relación. La opción sourceMap genera información que permite a depuradores y otras herramientas mostrar el TypeScript original mientras trabajan con el JavaScript emitido, según la documentación oficial. Úsala como evidencia adicional si el proyecto ya dispone de esos mapas.

Si necesitas regenerar, utiliza la tarea existente del repositorio después de leer qué ejecuta y sobre qué rutas escribe. Haz la comprobación en una copia de trabajo prescindible cuando pueda sobrescribir cambios que todavía necesitas. No inventes un comando basándote únicamente en el nombre de la carpeta.

Observa el contenido relevante antes y después: si el proceso reemplaza exactamente la corrección manual, tienes evidencia de que ese cambio no está representado en sus entradas. Si el archivo permanece igual, el diagnóstico sigue abierto. Puede que esa tarea no lo genere o que no hayas reconstruido la salida que estás examinando.

Decide dónde corregir según lo que hayas encontrado

Elige el archivo que debes editar a partir de la evidencia de generación. Evita trasladar el parche automáticamente al primer archivo parecido. La entrada puede estar bien y el problema encontrarse en una plantilla, en la configuración o en el código que consume el resultado.

Si el problema está en una plantilla de OpenAPI Generator, la documentación de personalización contempla sustituir plantillas y crear generadores personalizados. Que exista esa posibilidad no significa que debas construir uno nuevo. Busca primero el cambio más pequeño que exprese correctamente la transformación necesaria.

En el ejemplo hipotético del descuento, si confirmas que la fórmula procede de un archivo fuente concreto, la corrección debe quedar allí. Después reconstruye y comprueba el comportamiento sobre el resultado recién producido. La salida esperada es que la fórmula corregida aparezca sin tener que volver a editarla a mano.

No exijas que todos los archivos resultantes sean idénticos byte a byte para resolver esta pregunta. El objetivo de este diagnóstico es determinar si la generación conserva la corrección funcional. Si aparecen otras diferencias, investiga su origen por separado antes de aceptarlas.

Plantilla para encargar el diagnóstico al agente

Pide una explicación verificable de la procedencia antes de autorizar otra corrección sobre el archivo sospechoso. La siguiente plantilla limita esa primera tarea a investigar. Sustituye los campos entre corchetes y pégala en la conversación del agente que está trabajando en el repositorio.

Investiga la procedencia de [ruta del archivo] antes de modificarlo.

Síntoma observado: [qué falla y cuándo reaparece].
Cambio propuesto o realizado: [qué contenido se ha modificado].
Tarea tras la que reaparece: [tarea conocida o desconocida].

Identifica qué proceso escribe este archivo, qué entradas utiliza y dónde configura la salida. Aporta rutas y fragmentos del repositorio que respalden cada relación. Si no puedes demostrarla, indica que la procedencia sigue sin confirmar.

Separa el archivo donde se observa el fallo del archivo donde propones corregir su causa. Explica cómo volverías a generar el resultado y cómo comprobarías que conserva la corrección.

En esta tarea, limita las acciones a lectura. No borres salidas, no regeneres y no cambies archivos.

La respuesta útil debe permitirte tomar una decisión concreta: corregir una entrada, investigar una transformación o descartar esta hipótesis. Si el agente devuelve únicamente una lista de carpetas que suelen contener código generado, falta evidencia del repositorio. Devuélvele la tarea señalando la relación que todavía no ha demostrado.

Esta plantilla propone un límite para la investigación inicial, no una política permanente de permisos. Cuando tengas identificadas las rutas y entiendas los efectos de regenerar, puedes encargar el cambio correspondiente con ese alcance concreto.

Cuándo sí puede editarse un archivo generado

No apliques una prohibición general basada en la extensión o en el origen inicial del archivo. La pregunta relevante es si existe un proceso que deba seguir reconstruyéndolo y cuál es el flujo de mantenimiento previsto. Un archivo creado automáticamente puede pasar después a mantenerse como código propio.

Tampoco todos los archivos .d.ts son salidas que debas evitar. La documentación de declaraciones de TypeScript enseña a escribirlos manualmente, por ejemplo para describir una biblioteca. Si el repositorio mantiene esas declaraciones a mano, editarlas puede ser precisamente la intervención correcta. Comprueba su procedencia antes de buscar una fuente que quizá no existe.

Como criterio práctico propio, distingue también entre una modificación temporal para explorar una hipótesis y el arreglo que vas a entregar. En una copia prescindible, cambiar una salida puede ayudarte a formular una hipótesis sobre el comportamiento deseado. Esa exploración no demuestra que el cambio vaya a sobrevivir a la reconstrucción ni sustituye la corrección en el origen.

Si no tienes acceso a las entradas o al generador, este procedimiento no basta para resolver el fallo. Deja explícita esa limitación y decide con quien mantiene el componente cómo conservar cualquier adaptación. Antes de aceptar el parche, exige una respuesta concreta a esta pregunta: ¿qué volverá a producir esta corrección cuando el archivo se reconstruya?