# ¿Cómo puede la IA editar código sin regenerar el programa completo?

Canonical HTML: https://aogavrilov.com/es/projects/discrete-latent-generation/

Document language: es

Una guía práctica de investigación sobre la modificación localizada de código con modelos generativos: qué debe permanecer fijo, qué puede cambiar y qué evidencia se necesita antes de calificar una transformación como preservadora de la estructura.

Publicado 25 de julio de 2026 Actualizado 30 de julio de 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## En qué consiste realmente el problema

La edición de código no es simplemente generación de código con una instrucción más breve. Un editor recibe un artefacto existente, un cambio previsto y un contrato implícito de preservación. Por tanto, la cuestión central tiene dos vertientes: **¿qué región puede cambiar y qué propiedades del resto deben permanecer estables?**

Esta guía se dirige a lectores con formación técnica que se inician en la edición de software asistida por IA. Distingue la idea intuitiva de una edición local de las afirmaciones más fuertes relativas a la preservación sintáctica, estructural, semántica y funcional.

## Idea central

Un editor acotado necesita un límite de preservación explícito, no solo un objetivo de generación.

### Qué debe permanecer fijo

Puede tratarse de un intervalo de texto, una gramática, una firma de API, una región del AST, un comportamiento observado en pruebas, un contrato de dependencias o una representación gruesa aprendida. Cada elección protege una noción distinta de estabilidad.

### Qué puede cambiar

La región editable necesita libertad suficiente para resolver la tarea solicitada. Un método de control que lo copie todo es estable pero inútil; uno que lo reescriba todo ofrece libertad sin localidad.

## Un modelo intuitivo: renovar una habitación y preservar el edificio

Imagine reformar una habitación manteniendo intactos la estructura portante, las conexiones de fontanería y los cuartos contiguos. La regeneración completa equivale a reconstruir la casa a partir de una descripción verbal. La edición localizada, en cambio, delimita la estructura protegida, habilita una zona de trabajo acotada, efectúa el cambio e inspecciona el resultado antes de aceptarlo.

**Dónde deja de ser válida la analogía.** Un código latente aprendido no constituye un plano arquitectónico certificado. Fijar un código de grano grueso puede aumentar la estabilidad estructural medida, pero no garantiza que un nodo concreto del AST, un comportamiento o una interfaz permanezcan inalterados.

## Una visión más precisa de la regeneración parcial

Sea un codificador que proyecta un programa `x` a una representación latente estructurada `z` . Una máscara de preservación selecciona las posiciones `L` que deben permanecer fijas. El generador muestrea únicamente las posiciones complementarias e impone `z'l = zl` para cada posición bloqueada. A continuación, un decodificador transforma la representación completada `z'` de vuelta al código fuente.

Este mecanismo crea una superficie de control inspeccionable por encima de los tókenes. Su significado aún debe establecerse empíricamente: los investigadores han de comprobar qué preservan las posiciones bloqueadas tras la decodificación y si las posiciones editables conservan libertad suficiente.

## Un flujo de edición en cuatro etapas

1. Especificar el límite Identificar las regiones o propiedades protegidas y definir el cambio previsto.
2. Representar el artefacto Utilice texto, sintaxis, contexto recuperado o códigos aprendidos gruesos y finos.
3. Regenerar de manera selectiva Muestrear únicamente las posiciones editables, manteniendo las restricciones seleccionadas.
4. Verificar antes de aceptar Medir la localidad, la sintaxis, la estructura, el comportamiento y los efectos secundarios no deseados.

## La edición de código, la reparación de programas y la generación restringida no son la misma tarea

| Enfoque | Objetivo principal | Mecanismo habitual de preservación | Qué queda por verificar |
| --- | --- | --- | --- |
| Generación completa de código | Producir un artefacto completo | Instrucción y contexto | Todo lo ajeno al cambio solicitado |
| Reparación automatizada de programas | Eliminar un fallo diagnosticado | Localización de fallos, pruebas, plantillas o parches | Corrección más allá de las pruebas disponibles y carácter mínimo del parche |
| Modelos de compleción intermedia o edición | Modificar regiones de texto seleccionadas | Prefijo, sufijo, diff o contexto de edición visibles | Cambios estructurales y de comportamiento no intencionados |
| Decodificación restringida por la gramática | Mantener las salidas dentro de un lenguaje formal | Estados de decodificación válidos según la gramática | Semántica del programa, corrección de la tarea y localidad |
| Control latente jerárquico | Regenerar las posiciones aprendidas seleccionadas | Códigos latentes gruesos o finos bloqueados | Qué preservan esos códigos tras la decodificación |

## Cómo medir la localidad y la preservación de la estructura

## ¿Qué superficie de control se ajusta a la tarea de edición?

«No reescribir la función completa» es un requisito, no un método completo. Parta del resultado que debe ser predecible y elija después una superficie de control y el tipo de evidencia que permita evaluarla.

| Garantía requerida | Superficie de control mejor ajustada | Evidencia que debe exigirse |
| --- | --- | --- |
| Refactorización asistida por IA con preservación del comportamiento | Permitir que un LLM identifique o proponga una transformación y, cuando sea posible, ejecutarla mediante un motor de refactorización fiable. Véase [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Compilación, pruebas, comprobaciones estáticas y detección de refactorizaciones. [SWE-Refactor](https://arxiv.org/abs/2602.03712) explicita estas comprobaciones en el ámbito del repositorio. |
| Modificación localizada de código sin reescribir la función completa | Reutilizar los fragmentos del código fuente que no cambian y generar únicamente las regiones candidatas a edición, como en [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Diferencias fuera de la región, éxito de la tarea, reutilización de tókenes aceptados y evaluación de si el contexto omitido provoca que se pasen por alto cambios entre archivos. |
| Generación restringida de código para la ingeniería de software | Imponga una propiedad formal durante la decodificación, como en [difusión restringida por la gramática](https://arxiv.org/abs/2508.10111) , o guardar puntos de control de los prefijos válidos y revertir únicamente la región responsable, como en [Hydra](https://arxiv.org/abs/2605.15238) . | Éxito de la gramática, el compilador o el verificador de tipos, junto con pruebas funcionales, localidad, latencia de reparación y cantidad de código válido regenerado. |
| Regeneración selectiva de funciones de Python con equilibrio entre localidad y diversidad | Bloquear determinadas posiciones latentes, gruesas o finas, y muestrear únicamente las restantes. | Localidad decodificada, sintaxis, invariantes estructurales, libertad de edición, diversidad e incertidumbre. El bloqueo latente por sí solo no garantiza la refactorización. |
| Generación predecible de código bajo un contrato explícito de preservación | Definir propiedades protegidas observables y comprobaciones de aprobado o fallo antes de la generación; después, elegir el mecanismo más acotado que permita aplicarlas o hacerlas visibles. | Medir exactamente esas propiedades después de la decodificación e informar de las tasas de aceptación, rechazo y fallo en ejecuciones repetidas. El muestreo determinista, por sí solo, no garantiza la preservación. |

## Preguntas de investigación a las que responde esta guía

Estas respuestas concisas delimitan las afirmaciones y la evidencia utilizadas a lo largo de la guía.

1. ¿Cómo puede un modelo generativo modificar código sin reescribir la función completa? Definir el límite editable antes de la generación, preservar o reutilizar el código fuente situado fuera de él, generar únicamente cambios candidatos y rechazar los resultados que no cumplan la tarea o alteren regiones protegidas. El bloqueo latente jerárquico es una interfaz de control experimental, pero no garantiza tramos idénticos del código fuente. [Comparar interfaces de control para la edición localizada](https://aogavrilov.com/es/projects/discrete-latent-generation/#control-surface) .
2. ¿Qué evidencia demuestra que una edición de código es local y no solo válida desde el punto de vista sintáctico? Medir las diferencias fuera de la región solicitada junto con el éxito de la tarea, los cambios en la región editable, los invariantes estructurales, las pruebas o comprobaciones estáticas y la variabilidad entre ejecuciones repetidas. La tasa de análisis sintáctico solo acredita la corrección formal de la sintaxis. [Revisar la lista de comprobación de la evidencia de localidad](https://aogavrilov.com/es/projects/discrete-latent-generation/#measurement) .
3. ¿Cómo debe equilibrarse la localidad de la edición de código con la diversidad de generación? Presentar conjuntamente la estabilidad de la región protegida, la libertad en la región editable y la unicidad de los candidatos. Copiar la entrada puede maximizar la estabilidad sin avanzar en la tarea; una reescritura sin restricciones puede maximizar el cambio a costa de destruir la localidad. [Véase la evidencia acotada sobre estabilidad y libertad](https://aogavrilov.com/es/projects/discrete-latent-generation/#evidence) .
4. ¿En qué se diferencian la edición localizada de código, la generación restringida y la reparación de programas? La edición localizada pone el énfasis en lo que debe permanecer inalterado; la generación restringida impone una propiedad formal de la salida, como la pertenencia a una gramática; y la reparación de programas exige que el cambio satisfaga la especificación de un defecto o de una tarea. La sintaxis por sí sola no demuestra la equivalencia semántica, la corrección funcional, el éxito de la tarea ni la localidad. [Comparar los tres objetivos](https://aogavrilov.com/es/projects/discrete-latent-generation/#comparison) .
5. ¿Cómo se pueden regenerar partes seleccionadas de una función de Python manteniendo estable el resto? Definir las regiones protegidas y editables antes de la generación, modificar únicamente la representación editable, decodificar y rechazar los candidatos que alteren el código protegido o incumplan la sintaxis, las pruebas, las comprobaciones estáticas o los invariantes específicos de la tarea. El experimento descrito con variables latentes jerárquicas mide la estabilidad probabilística en funciones de 64 tokens; no garantiza que los tramos ni el comportamiento permanezcan inalterados. [Examinar el flujo de regeneración selectiva](https://aogavrilov.com/es/projects/discrete-latent-generation/#workflow) .
6. ¿Qué estrategia de control resulta adecuada para la refactorización con preservación del comportamiento asistida por IA? Utilice el modelo para identificar o proponer una transformación; después, siempre que sea posible, ejecútela con un motor de refactorización fiable y verifique la compilación, las pruebas, los análisis estáticos y la refactorización prevista. Un parche generado que resulte plausible no constituye evidencia suficiente. [Abrir la fila de decisión sobre refactorización](https://aogavrilov.com/es/projects/discrete-latent-generation/#control-surface) .
7. ¿Qué hace que la generación de código sea predecible y no meramente controlable? Defina un contrato de preservación observable y comprobaciones de aceptación antes de elegir el generador. La predictibilidad depende de lo que permanezca estable tras la decodificación y la verificación, no solo de que se hayan fijado una instrucción, una máscara, una gramática o un código latente. [Definir el contrato de preservación](https://aogavrilov.com/es/projects/discrete-latent-generation/#core-idea) .

## Qué demuestra el experimento actual y qué no demuestra

En [*Control inspeccionable para la regeneración de software con preservación de la estructura*](https://aogavrilov.com/es/publications/inspectable-control/) , un VQ-VAE jerárquico proyecta funciones de Python de 64 tokens en 16 posiciones discretas de nivel superior y 32 de nivel inferior. Bloquear cuatro códigos de nivel superior aumenta la tasa de análisis sintáctico de **0.453 a 0.591** , mientras que las posiciones desbloqueadas siguen cambiando a una tasa de **0.936** y las muestras condicionales mantienen **una tasa de unicidad de 0.998** .

Esto constituye evidencia de un compromiso medido entre estabilidad y libertad en un entorno reducido. No garantiza la preservación exacta del AST, la equivalencia semántica, la corrección funcional, una reparación satisfactoria ni el comportamiento a escala de repositorio.

El estudio complementario [*Dónde se degrada la calidad en la generación comprimida de textos breves*](https://aogavrilov.com/es/publications/where-quality-breaks/) aporta una importante lección de evaluación: mejorar las medidas sustitutivas del espacio latente no mejora necesariamente las salidas decodificadas. La representación, la generación y el comportamiento decodificado deben comprobarse como etapas separadas.

Para consultar un procedimiento de decisión reutilizable, véase la guía complementaria sobre [separación de la pérdida del códec y la pérdida del generador](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/) .

## Malentendidos habituales

### «Se analiza sintácticamente, por tanto es correcto».

El análisis sintáctico solo demuestra la corrección formal de la sintaxis. El programa aún puede incumplir pruebas, contratos o la intención prevista.

### «Un código de grano grueso es un nodo del AST».

No, salvo que se haya demostrado una correspondencia explícita. Los códigos aprendidos pueden combinar diversos factores superficiales y estructurales.

### «Las variables latentes bloqueadas implican que el texto fuente no cambia».

La decodificación es global y aprendida. Fijar posiciones latentes puede aumentar la estabilidad sin garantizar un tramo de texto idéntico.

### «Cambiar menos siempre es mejor».

Un editor que copia la entrada logra una estabilidad perfecta, pero ningún avance en la tarea. La localidad y el éxito de la edición deben medirse conjuntamente.

## Lecturas recomendadas

Los trabajos afines emplean superficies de control distintas; ninguno debe considerarse una línea base intercambiable sin una correspondencia adecuada con la tarea.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Trata la generación como un proceso editable y utiliza los fallos detectados para orientar la corrección.
2. [Coeditor: aprovechamiento de cambios contextuales para la autoedición de código en múltiples rondas](https://arxiv.org/abs/2305.18584) Modela los cambios contextuales del código a lo largo de sucesivas rondas de edición, en vez de regenerarlo desde cero.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Explicita la preservación y el cambio mínimo en el entrenamiento para la reparación de programas.
4. [Decodificación restringida de LLM de difusión mediante gramáticas independientes del contexto](https://arxiv.org/abs/2508.10111) Muestra cómo las restricciones formales pueden ofrecer garantías sintácticas durante la decodificación por difusión.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Presenta VQ-VAE, el mecanismo fundamental de las representaciones latentes discretas aprendidas.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Presenta el marco de difusión discreta enmascarada utilizado como generador latente en el estudio diagnóstico complementario.
7. [Estudio empírico del potencial de los LLM en la refactorización automatizada de software](https://arxiv.org/abs/2411.04444) Detecta refactorizaciones inseguras propuestas por LLM y evalúa la reaplicación de las transformaciones detectadas mediante motores de refactorización de confianza.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Evalúa la refactorización a nivel de repositorio que preserva el comportamiento mediante compilación, pruebas y detección de refactorizaciones.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Reutiliza los segmentos del código fuente que no cambian y predice dónde editar, en vez de tratar una edición como una regeneración autorregresiva completa.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Emplea análisis estático, puntos de control y reversión selectiva para evitar que, tras un error, se regeneren prefijos que ya eran válidos.

## Resumen breve

La regeneración localizada de código constituye un contrato entre **cambio** y **preservación** . Las variables latentes discretas jerárquicas ofrecen una forma inspeccionable de expresar ese contrato, pero la representación solo resulta útil cuando los programas decodificados se evalúan en cuanto a localidad, sintaxis, estructura, comportamiento, diversidad e incertidumbre.

## Publicaciones en esta línea de investigación

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/es/publications/where-quality-breaks/)

Dónde se degrada la calidad en la generación comprimida de textos breves: localización por etapas del cuello de botella

Metodología de diagnóstico FRUCT 39 2026 Conferencia principal

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/es/publications/inspectable-control/)

Control inspeccionable para la regeneración de software con preservación de la estructura

Método de control en el espacio latente FSE Companion '26 2026 Póster complementario