Edición excesiva: cuando un modelo modifica código más allá de lo necesario
(nrehiew.github.io)- Incluso en bugs que se resuelven con cambios mínimos, es común que se reescriba toda la función, se agregue lógica auxiliar y hasta se cambie la firma, lo que termina generando un diff enorme
- En trabajo brown-field, donde hay que mantener la estructura existente, no basta con que pasen las pruebas: también importa cuánto se cambió, para conservar la revisabilidad y la seguridad del cambio
- A partir de 400 problemas de BigCodeBench dañados de forma programática, el estudio cuantifica la edición excesiva con Levenshtein a nivel de tokens, puntuación de parche relativa y Added Cognitive Complexity
- La tendencia a reescribir en exceso apareció en los modelos de programación más recientes; Claude Opus 4.6 mostró una combinación fuerte de precisión y cambios mínimos, mientras que GPT-5.4 destacó relativamente por su edición excesiva
- Un prompt que pide preservar el original redujo el diff, especialmente en los modelos de razonamiento; entre los enfoques de entrenamiento, RL logró el resultado más equilibrado al aprender conductas de edición mínima sin degradar el rendimiento general de programación
El problema de Over-Editing
- Over-Editing se refiere al fenómeno en el que, al corregir un bug, se modifica el código mucho más allá del mínimo necesario, llegando a alterar incluso su estructura
- Incluso en un bug off-by-one donde basta con cambiar
range(len(x) - 1)porrange(len(x)), el modelo puede terminar reescribiendo toda la función y agregando funciones auxiliares o lógica de validación innecesaria - En el ejemplo, GPT-5.4 hizo validaciones de
None, conversión connp.asarray(dtype=float), enmascarado de valores finitos, validación del tamaño del arreglo, cambio de la firma en la llamada acurve_fity hasta reemplazó la lógica de graficado; las pruebas pasan, pero se genera un diff enorme
- Incluso en un bug off-by-one donde basta con cambiar
- En trabajo brown-field, donde se interviene una base de código existente, es importante corregir solo el problema preservando código que el equipo ya entiende y escribió intencionalmente
- A diferencia del trabajo green-field, los cambios que no respetan la estructura existente dificultan que el revisor entienda qué cambió y por qué
- Si se reescribe una función completa, el código se vuelve más difícil de reconocer y también cuesta más juzgar la seguridad del cambio
- El criterio de “si pasa las pruebas, está bien” no alcanza para detectar este problema
- Over-Editing no es una falla de precisión, sino una falla de fidelidad en la edición, por lo que suele no hacerse visible en la suite de pruebas
- A medida que aumenta la cantidad de código generado, también crece lo que hay que revisar, y la complejidad innecesaria puede acumularse hasta degradar silenciosamente la calidad de la base de código
Cómo se mide Over-Editing
- Para construir un dataset donde la respuesta correcta de cambio mínimo fuera clara, se armó un conjunto de evaluación dañando de forma programática 400 problemas de BigCodeBench
- A diferencia de benchmarks previos, no se inyectaron bugs con otro LLM, sino que se aplicaron cambios finamente controlados, como convertir
<en<=,+en-oTrueenFalse - Se verificó que cada muestra dañada fuera sintácticamente válida y que rompiera los casos de prueba correspondientes; como la única corrección correcta era revertir ese daño, el diseño garantiza una edición mínima
- A diferencia de benchmarks previos, no se inyectaron bugs con otro LLM, sino que se aplicaron cambios finamente controlados, como convertir
- Gracias a esta configuración, se puede evaluar no solo si el modelo corrigió el bug, sino también cuánto más cambió durante el proceso
- Tanto la respuesta de referencia como la salida del modelo se comparan contra la entrada dañada para calcular el tamaño relativo del parche
- Cuantos más cambios adicionales haya más allá de restaurar la respuesta correcta, peor es la puntuación
- El código relacionado está disponible en el repositorio de GitHub
Métricas de medición
-
Distancia de Levenshtein a nivel de tokens
- En vez de usar la Levenshtein habitual a nivel de caracteres, se usa una variante a nivel de tokens de Python
- El código se divide con el tokenizer de Python en unidades sintácticas atómicas como
def,add,(,a,,,b,), y la distancia se calcula sobre esa secuencia de tokens - Si
def add(a, b):se cambia pordef someotherfunctionname(a, b):, la distancia a nivel de caracteres es 19, pero a nivel de tokens cuenta como un solo cambio de identificador y vale 1 - Para poder comparar funciones de distinta longitud, se normaliza por el número total de tokens
-
Puntuación de parche relativa
- En lugar de comparar directamente la salida del modelo con la respuesta correcta, ambas se comparan contra la entrada dañada
- La edición que revierte la respuesta dañada hasta la respuesta original es la verdadera corrección mínima, y se mide qué tan cerca está de eso la edición producida por el modelo
- Cuanto más cerca esté el valor de 0, más se parece el parche del modelo a la corrección mínima real
-
Added Cognitive Complexity
- Junto con Cyclomatic Complexity, también se usa Cognitive Complexity, que refleja mejor la dificultad de lectura
- Penaliza anidamiento, recursión, operadores lógicos compuestos y flujos de control poco intuitivos; estructuras como
if, loops otry/exceptelevan la complejidad porque obligan al lector a seguir más estado - En el ejemplo, el código con loops y condicionales anidados tiene una Cognitive Complexity de 6
- Como en este experimento los daños solo cambian valores y no tocan la estructura, una corrección correcta debería tener siempre Added Cognitive Complexity igual a 0
- Si la complejidad aumenta en la salida del modelo, significa que se agregó código no solicitado; también se considera indeseable un valor menor que 0, porque implicaría una simplificación innecesaria
¿Los modelos realmente hacen Over-Edit?
- El fenómeno de Over-Editing también se confirmó en los modelos frontier más recientes
- Tanto los modelos de razonamiento como los no razonadores muestran diferencias entre Pass@1 y la capacidad de hacer cambios mínimos
- La capacidad de corregir con precisión, por sí sola, no alcanza para evaluar si la edición fue fiel
- En la comparación entre modelos de razonamiento, Claude Opus 4.6 mostró la combinación más sólida
- Obtuvo el Pass@1 más alto, con 0.912, y también el diff más pequeño, con Levenshtein normalizado de 0.060 y Added Cognitive Complexity de 0.200
- Gemini 3.1 Pro Preview aparece en una zona similar, y entre los modelos open-weight, GLM 5 edita de forma relativamente más conservadora
- GPT-5.4 figura entre los modelos evaluados con mayor nivel de Over-Editing
- En modo de razonamiento registró Levenshtein de 0.395 y Added Cognitive Complexity de 2.313, y en modo no razonador también mostró valores altos, de 0.327 y 1.563 respectivamente
- Su Pass@1 también fue bajo, con 0.723 y 0.770, por lo que mostró debilidad tanto en precisión como en edición mínima
- Entre los modelos no razonadores, Qwen 3.6 Plus obtuvo el Pass@1 más alto, con 0.870, mientras que GLM 5 tuvo la Added Cognitive Complexity más baja, con 0.235
- El modelo no razonador de Claude Opus 4.6 también mantuvo cambios muy acotados, con Levenshtein de 0.079 y Added Cognitive Complexity de 0.313
¿Se puede mejorar con prompting?
- Al agregar al prompt “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible”, la distancia de Levenshtein bajó en todos los modelos
- Salvo en DeepSeek R1/v3, también mejoró Pass@1
- Esto puede interpretarse como que la restricción de cambio mínimo reduce el espacio de modificaciones posibles y guía hacia cambios más precisos y focalizados
- Este efecto se notó especialmente en los modelos de razonamiento
- Como tienden a seguir mejor las instrucciones explícitas, la exigencia de minimizar la edición se traduce con más fuerza en una reducción del diff
- Esto muestra que, aunque en estado base tiendan a tocar de más, cuando reciben la instrucción pueden desplazarse hacia correcciones más fieles
¿El razonamiento lleva a una reescritura excesiva?
- Se emparejaron versiones con razonamiento y sin razonamiento de la misma familia de modelos, y se comparó la distancia de Levenshtein solo en las muestras donde ambas acertaron
- Si hay muchas muestras fallidas, aparece un sesgo en el que se reducen las oportunidades mismas de Over-Editing; por eso se controló la exactitud y luego se aisló únicamente el estilo de edición
- En la configuración de prompts general, en la mayoría de los pares el modelo con razonamiento reescribe más
- DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus y Kimi 2.5 muestran una barra de razonamiento más alta
- Se observa una tendencia a que el razonamiento extendido, en vez de optar por la corrección mínima, apunte a una “mejor implementación” y termine produciendo refactorizaciones innecesarias
- La excepción es Claude Opus 4.6, donde la variante con razonamiento modifica mucho menos que la variante sin razonamiento
- Si se indica explícitamente que se preserve el original, el panorama cambia mucho
- Los modelos con razonamiento muestran una distancia de Levenshtein igual o menor que la de los no razonadores en casi todos los pares
- La variante con razonamiento de Claude Opus 4.6 registra en esta configuración la Levenshtein más baja de todos los modelos
- GPT-5 y GPT-5.4 también reducen mucho su puntaje en la variante con razonamiento, aunque en GPT-5.4 la variante sin razonamiento sigue quedando ligeramente por delante
- En su comportamiento por defecto, los modelos con razonamiento tienden más al Over-Editing, pero esa misma capacidad de razonamiento también les permite seguir mejor las restricciones
- La diferencia entre la configuración general y la explícita aparece de forma consistentemente mayor en los modelos con razonamiento
- Por lo tanto, el Over-Editing se parece más a un comportamiento por defecto que a una limitación fundamental, y puede revertirse mediante restricciones
¿Se puede crear un editor fiel mediante entrenamiento?
- Se usó Qwen3 4B 2507 Instruct como modelo base, y se tomó como baseline una configuración 0-shot y 8-shot con instrucciones de preservación del original
- Los demás métodos de entrenamiento se evaluaron en configuración general, sin instrucciones explícitas de preservación del original
-
Configuración experimental
- Se creó un dataset sintético corrompiendo problemas de DeepCoder de la misma manera
- Además, se hizo que Qwen3 4B 2507 Instruct base generara 8 completions para cada problema; luego se conservaron solo las muestras funcionalmente correctas y se ordenaron por distancia de Levenshtein para construir también un dataset de self-distillation
- El entrenamiento se ajustó, de forma similar a Context Distillation, para que en evaluación realizara un comportamiento de edición mínima sin instrucciones explícitas
-
Métodos de entrenamiento
- SFT: ajuste fino supervisado directo sobre el dataset generado programáticamente
- rSFT: entrenamiento usando solo las 3 completions con menor distancia de Levenshtein por muestra dentro del dataset de self-distillation
- DPO: optimización por preferencias entre la completion con mayor distancia de Levenshtein y la de menor distancia para cada muestra
- RL: aplicación de aprendizaje por refuerzo combinando exactitud funcional con una recompensa de edición mínima basada en Levenshtein
- Si pasa todas las pruebas,
r = r_edit + 0.1 - Si no las pasa,
r = -0.2 r_editse calcula como una recompensa basada en Levenshtein normalizada
- Si pasa todas las pruebas,
¿Qué pasó con el mismo tipo de corrupción?
- En la configuración in-domain, donde el tipo de corrupción del conjunto de entrenamiento y del de prueba es el mismo, SFT produce resultados casi perfectos
- Baseline 0-shot: Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
- Baseline 8-shot: Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
- SFT logra el mejor resultado en las tres métricas con Pass@1 0.932, Norm. Levenshtein 0.002 y Added CC 0.000
- rSFT registra 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113 y RL 0.802 / 0.046 / 0.112
- Como estos resultados parecían demasiado buenos, se revisó la posibilidad de que el modelo hubiera memorizado solo la transformación inversa de tipos específicos de corrupción
- Se consideró que el modelo podría no haber aprendido un comportamiento general de edición mínima, sino solo a revertir patrones de corrupción predefinidos
- Para comprobarlo, se reconfiguraron por completo los tipos de corrupción de los datos de entrenamiento y evaluación para que fueran distintos
¿Generaliza a otros tipos de corrupción?
- En la configuración out-of-domain, donde los tipos de corrupción del conjunto de entrenamiento y del de prueba son distintos, SFT se derrumba de forma importante
- El Pass@1 de SFT cae hasta 0.458, y el modelo termina intentando solo cambios mínimos específicos sin lograr corregir realmente los bugs
- Norm. Levenshtein es -0.008 y Added CC es 0.006, muy bajos, pero la capacidad de hacer la corrección correcta colapsa
- rSFT y DPO mejoran ligeramente frente al baseline de 8-shot, pero el margen de mejora es pequeño
- rSFT: 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
- DPO: Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
- Incluso entrenando solo con datos de rastreo generados por el propio modelo base, es posible cierta generalización
- Solo RL generaliza limpiamente en el conjunto de las tres métricas
- RL registra Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006
- Mejora en las tres métricas frente a ambos baselines, y además no cae el rendimiento de codificación general
- El hecho de que la mejora en Levenshtein y Added Cognitive Complexity sea mayor que en Pass@1 respalda que lo aprendido no fue una simple memorización de la reversión de corrupciones, sino el comportamiento mismo de edición mínima
Catastrophic Forgetting
- También se verificó con LiveCodeBench v6 si al ajustar finamente para edición mínima caía la capacidad general de programación
- El objetivo era mantener después del entrenamiento un nivel similar al del modelo pretrained original
- SFT muestra una caída muy grande en la capacidad general
- En LiveCodeBench aparece una caída de rendimiento del 43%, y ni siquiera logra mantener la capacidad básica de identificar y corregir bugs
- rSFT y DPO también bajan ligeramente
- Incluso entrenando con muestras generadas por el modelo original, por la naturaleza de la tarea sigue quedando cierto nivel de Catastrophic Forgetting
- RL aprende el nuevo comportamiento sin degradación de rendimiento
- Mantiene la capacidad general de programación y además mejora más que nadie el rendimiento en tareas de edición mínima
- Esto coincide con SFT memorizes while RL generalizes
- Desde la perspectiva de la distribución, también puede interpretarse que cuanto mayor sea la diferencia entre el dataset generado programáticamente y la distribución original del modelo, mayor será el Forgetting
- SFT altera fuertemente la distribución del modelo al ajustarse de forma intensa a datos muy distintos de la distribución original
- rSFT y DPO cambian de forma menos brusca porque los datos self-distilled están más cerca de la distribución original
- Es muy posible que el grado de Catastrophic Forgetting sea proporcional a la diferencia entre la distribución original y la distribución de los datos de entrenamiento de la tarea
Experimentos adicionales
-
RL con LoRA: ¿hace falta ajuste fino completo?
- Como esta tarea se parece más a un ajuste de estilo de la capacidad existente para modificar código que a incorporar conocimiento nuevo, se evaluó si LoRA también sería suficiente
- rank 1: Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
- rank 8: 0.775 / 0.112 / 0.426 / -0.022
- rank 16: Pass@1 0.805 / 0.087 / 0.328 / -0.005
- rank 32: 0.795 / 0.065 / 0.235 / -0.011
- rank 64: 0.797 / 0.051 / 0.160 / +0.001
- El mejor modelo de Full RL fue 0.782 / 0.050 / 0.185 / +0.006
- LoRA rank 64 casi alcanza a Full RL en Levenshtein y muestra un mejor resultado en Added CC
- A medida que aumenta el rank, Levenshtein y Added CC disminuyen de forma monótona de 1 a 64
- Las grandes mejoras se concentran al inicio: de rank 1→16, Levenshtein baja con fuerza de 0.166→0.087, mientras que de 16→64 se reduce gradualmente de 0.087→0.051
- En rank 1 y 8 aparece una compensación entre exactitud y edición mínima; es posible que, por falta de capacidad para aprender ambas funciones de recompensa al mismo tiempo, se haya sesgado hacia la minimización de edición, que tenía una recompensa más alta
- Para cambios de comportamiento a nivel de estilo en tareas donde la capacidad ya existe, un pequeño número de parámetros adicionales también puede ser suficiente, y después de cierto punto el rendimiento adicional de más capacidad disminuye
-
Nota sobre reward hacking
- La función de recompensa inicial tenía un bug que asignaba 0 puntos a los rollouts sin ninguna ejecución exitosa
- Como el signo de Levenshtein se había invertido para convertirlo en una forma de “mientras más grande, mejor”, ese 0 terminaba dando una recompensa más alta que una ejecución exitosa
- Aun así, Full RL aprendió la tarea, y solo en LoRA apareció reward hacking en forma de no generar en absoluto código funcionalmente correcto, lo que llevó a revisar el entorno
- Después de corregir la función de recompensa, los resultados de Full RL solo mejoraron ligeramente
-
¿Se extiende también a modelos más grandes?
- Se aplicó la misma receta de RL out-of-domain a Qwen3 14B
- El baseline 14B tuvo Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
- Tras aplicar RL, hubo una mejora general con Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011
- Incluso con un mayor número de parámetros, se mantienen al mismo tiempo el aumento de Pass@1, la reducción de Levenshtein, la disminución de Added Cognitive Complexity y la ausencia de Catastrophic Forgetting
- Esto respalda la posibilidad de que la receta de RL para edición mínima de código escale a modelos de varios tamaños
Resumen final
- Over-Editing aparece como un problema extendido y medible
- En los modelos frontier de programación, la capacidad de corregir correctamente y la capacidad de corregir con cambios mínimos aparecen como cosas separadas
- En particular, GPT-5.4 muestra en su configuración base una tendencia relativamente fuerte a reescribir en exceso, mientras que Opus 4.6 presenta un baseline sólido
- Solo con prompting explícito ya es posible inducir en buena medida ediciones fieles
- En especial, los modelos de razonamiento tienden por defecto a intervenir de más, pero siguen mejor las instrucciones cuando se les indica preservar el original
- GPT-5.4 también mostró una gran mejora en modo de razonamiento, lo que deja ver una fuerte capacidad de instruction following
- El menor margen de mejora de Opus 4.6 podría deberse a que su rendimiento base ya es alto
- Desde el punto de vista del entrenamiento, RL aparece como la solución más equilibrada
- Aprendió un comportamiento de edición más fiel sin perjudicar la capacidad general de programación, y el efecto se mantuvo tanto en Qwen3 4B como en 14B
- SFT fue fuerte en tipos específicos de corrupción, pero falló ampliamente en generalización y en mantener la capacidad general
- Aunque la evaluación de corrección de bugs a nivel de función única tiene un alcance más limitado que evaluaciones más agentic como SWE-Bench Pro, sí sirve como punto de partida para abordar el problema de la dificultad de cuantificar el Over-Editing en escenarios realistas
- Evaluar y mejorar la capacidad de edición mínima puede llevar a una mejora general en la calidad del código generado por IA
1 comentarios
Comentarios de Hacker News
La forma en que uso Claude Code supera por mucho mis expectativas
Cuando edita de más, hago que explique qué salió mal y que registre esa lección en un archivo de skills por proyecto
Así casi no repite el mismo error, y cuando el archivo de skills crece, también hace bastante bien la labor de ordenarlo y comprimirlo
Siento que ahora ya no tiene mucho sentido económico escribir código directamente en el trabajo
Me parezco más a un profesor, arquitecto o administrador de infraestructura, y dejo la mayor parte del desarrollo a un equipo de sesiones expertas de Claude
Claro, reviso todo, y Claude también escribe pruebas bastante exhaustivas para revisarlas juntos
Hoy en día incluso maneja proyectos grandes sin problema
No quiero decir esto como si fuera publicidad de Anthropic, sino que me da curiosidad qué estoy haciendo para que me funcione tan inusualmente bien
Y además, ya casi nunca me faltan tokens
Casi siempre uso solo el modelo Opus, que es eficiente con los tokens, y la semana pasada, aun subiendo más de 150 commits significativos con ayuda de Claude, solo usé un tercio de mi cuota semanal
Antes de Claude, mi límite era de unos 25 a 30 commits por semana
Ayer vi las estadísticas y me sorprendió que 97% del código de la empresa ahora lo escribe Cursor AI
Lo corro principalmente como cloud agent, porque verlo en tiempo real me distrae
Mi método es muy simple: solo decir claramente en palabras lo que quiero
La gente complica demasiado esto
Eso de compartir archivos .md y meterse en orchestration o prompt hacks me parece tan interesante como obsesionarse con atajos de vim o skins del IDE
Basta con decir claramente lo que quieres y dar buen feedback
Entrega resultados que aceptaría sin problema incluso si los hubiera escrito un colega
Claro, leo todo línea por línea y hago ajustes, pero esos ajustes son más o menos del mismo nivel que ya haría en un code review normal
No mido la productividad con números, pero se nota porque ahora sí me pongo con tareas que llevaba años posponiendo
Por ejemplo, se le da especialmente bien el trabajo aburrido como convertir 100 archivos markdown en 5 json y actualizar también el código que los lee
Es software con muchos defectos y muchos bugs, y aun así en la práctica es muy efectivo
Una de las cosas más raras de la IA es que la experiencia cambia de forma realmente extrema entre personas
También importa si haces mucho trabajo operativo o si lidias con código de producto que va a durar años
Mi hipótesis es que esta herramienta funciona bien sobre patrones simples y también resuelve cosas complejas, pero es muy mala para inventar patrones nuevos
Si la dejas sin supervisión, enseguida inventa patrones nuevos peligrosos y rompe cosas
Por eso bastantes veces termino reescribiendo por completo lo que me dio Claude
A veces incluso compito en velocidad con el robot y termino antes yo
Claro que tengo ventaja porque ya sé lo que quiero, pero siento que aquí se subestima el costo de estar manoseando detalles
Tanto futzing fraction como the peril of laziness lost apuntan a esa forma molesta en que la máquina se esfuerza de más
No entiendo por qué intenta hacer tres cosas cuando solo tenía que hacer una
Aunque lo corrijas y luego vuelva a ajustarse, sigue siendo frustrante repetir con ella el mismo ciclo que ya existe con colegas: "no hagas A, B y C; haz solo A"
La generación de tests también es un tema delicado: redacta bien tests cuando le das una dirección clara, pero si le dejas creatividad produce demasiadas pruebas inútiles como
foo + bar == bar + fooHay que revisar constantemente si esos tests realmente sirven para mantener sano el ciclo de feedback
Últimamente a veces me resulta más útil por traer de una vez los imports necesarios que por los tests mismos
Si estas máquinas van a hacer el trabajo, uno esperaría que la calidad promedio del código subiera
Pero mucha gente las usa como algo que "más o menos da el ancho promedio", y según cómo trabajes, incluso pueden bajar ese promedio
Llevo 28 años haciendo esto, y ya no encaja ni económica ni moralmente estar escribiendo yo mismo el código de aplicaciones de negocio durante horas pagadas por la empresa
En cambio, yo a menudo siento que los agentes de código priorizan demasiado preservar el código existente, cuando para adaptarse a nuevos requisitos tendrían que cambiarlo con más decisión
Al final parece una cuestión de cuánto quieres dejar congelado el código existente
Si es una aplicación de producción enorme con décadas encima, claro que conviene minimizar cambios, pero si es un proyecto experimental creado hace 3 días, quizá lo correcto sea mejorarlo en vez de conservarlo tal cual
Al final tendrán que aprender a ajustar por sí solos el nivel de agresividad según el contexto del proyecto
Incluso dentro del mismo proyecto, según el PR, hay áreas donde puedes cambiar todo lo que quieras y otras donde quieres mantener todo fijo para reducir el diff y el alcance de las pruebas
Por eso explico de antemano qué partes se pueden tocar y con qué agresividad, pero los resultados son irregulares
En general se inclinan por el diff mínimo, a costa de crear duplicación o forzar abstractions de forma rara
Si alguien tiene un método que funcione mejor, yo también quiero oírlo
Aunque le pidas refactorizar o reconsiderar el diseño de forma amplia, suele rendir poco
Así que hago que limpie markdown demasiado cargado de diseño, elimino del código fuente los detalles técnicos o implementaciones e interfaces clave, y luego hago que una sesión nueva vuelva a diseñarlo
Después restauro lo que borré y lo reconcilio con una sesión menos ingenua
La dependencia de la trayectoria es tan fuerte que por ahora hago este flujo manualmente, pero me gustaría formalizar este patrón como una skill
La IA muchas veces intenta ocultar fallas: se traga las excepciones y devuelve valores dummy, o deja solo un mensaje enterrado entre todo tipo de logs basura
Además, los logs suelen quedar demasiado resumidos y les faltan datos clave para el debugging real
Supongo que será porque fue entrenada para engañar al sistema y sacar buena puntuación
Si deja explotar la excepción, queda claro que falló y la castigan; pero si esconde el problema, a veces parece que tuvo éxito
Me da curiosidad cómo aparece esto en el Q&A general
Sospecho que el modelo tiende a sonar lo bastante convincente como para que el usuario quede satisfecho y se vaya
Un patrón frecuente es responder algo como "eso no es X, es Y", y esa falsa dicotomía hace que uno deje de considerar otras posibilidades
También es común cerrar con un plan de acción, y eso se parece a la técnica de ventas del assumptive close: más que hacerte pensar en la respuesta, te empuja a aceptar la postura de la IA e imaginar el resultado
Al final, subir la métrica por hill-climbing se ve justo así
Parece una especie de A/B enshittification llevada a un extremo ya casi imposible de interpretar
Mientras se entrene con feedback humano, cada pedazo de cada respuesta va a tender inevitablemente a esquivar y satisfacer al evaluador
Hacer algo realmente muy bueno con IA da más trabajo de lo que parece
Si le pides algo, produce resultados bastante plausibles, pero puede no saber que no sabe
Eso es todavía más peligroso cuando la IA habla con autoridad
Por eso no es fácil verificar desde varios ángulos y confirmar la exactitud
Será interesante ver cómo cambia esto con el tiempo
Al mismo tiempo, tanto este texto como los comentarios de aquí se sienten como una instantánea de un momento
El ritmo de avance de la industria es tan rápido que los modelos para programar ya son muchísimo mejores que hace apenas 9 meses
Cada vez que leo quejas sobre las capacidades de la IA, sin culpar a quien las hace, por dentro siempre pienso: "todavía"
Es como ponerlas a revisar mutuamente sus resultados
Aun así, como casi todo corre de forma asíncrona, yo puedo aprovechar ese tiempo para hacer otra cosa
Por eso, en algunos proyectos primero hice un prototipo con el agente para ir aprendiendo, y luego escribí el diseño y volví a empezar desde cero
Así ya sabes dónde vale la pena mirar con más profundidad
Qué representa el 20% restante depende al final de la naturaleza del problema
Aquí se habla de ediciones excesivas del código, pero los agentes hacen mucho más que eso
Tocan varios archivos, corren tests, despliegan y hasta hacen smoke tests, y todo eso queda oculto detrás de una abstracción
Por un lado es asombroso, pero por otro produce bastante inquietud
Primero, no entiendes bien qué está pasando realmente por dentro
Es demasiado tentador aprobar sin más el script que armó el agente y dejarlo correr
Pero ya me pasó que, porque el agente había decidido que estaba bien, me borró la base de datos, y también he frenado intentos de mandar credenciales de AWS a un destino de despliegue al que jamás debían enviarse
Segundo, yo no aprendo nada
Hasta la carga cognitiva de armar por mi cuenta un comando simple de docker se vuelve mayor, así que terminas apoyándote repetidamente en la IA como una muleta
No actives auto-approve, y aprueba tú mismo cada comando que ejecute el agente
Tampoco le delegues decisiones de diseño o arquitectura; la persona debe decidir cómo construirlo y darle instrucciones claras a ese bote
No es broma: si tratas la IA como una herramienta, se aprovecha mucho mejor
Quizá no llegues a una productividad 10x, pero al menos sigues entendiendo el código
En el Día 1 trata la seguridad con muchísimo cuidado y hasta te sermonea sobre por qué debes poner .env en .gitignore y por qué no debes pasarle credenciales, sino editar tú mismo esas partes
Pero en el Día 2, si le pides algo parecido, olvida esas reglas y configuraciones, recorre todo el disco buscando .env y otros archivos, entiende que tiene un token, arma por sí sola el comando curl y hasta hace pruebas con él
Un día parece experto en seguridad y al siguiente está por debajo de un practicante promedio
Este enfoque produce bastante comportamiento no deseado o implementación excesiva, pero sirve para eliminar boilerplate
En la práctica, en estas partes termino borrando como 70%
En cambio, no dejo que la IA toque las zonas de los puntos 1 y 2
Claro, la arquitectura tiene que permitir esa separación, pero me ha funcionado bastante bien
Simplemente no le des credenciales de producción al LLM
Si no puedes reproducir el problema en local o en staging/dev, entonces tu infraestructura de despliegue debería parecerse más a prod, y si no puedes granular suficientemente los permisos por entorno, primero hay que arreglar ese esquema de permisos
Yo sigo este principio, y casi nunca he sufrido el tipo de problema que mencionas
Para diagnóstico, podría darle temporalmente credenciales de solo lectura, pero incluso en ese caso emitiría solo tokens de vida muy corta por si se filtran
Así que en general sí tengo idea de lo que está pasando
A veces Claude toma decisiones extrañas o fuera de las convenciones
Aunque, cuando trabajas en equipo sobre una base de código grande, ya de por sí hay muchas áreas detrás de abstracciones que tampoco entiendes completamente, incluso partes hechas por gente que ya no está en la empresa
Antes se enseñaba mucho una idea que en la práctica casi nunca se cumplía: refactoriza mientras trabajas
La idea era que, si tocabas una zona, aprovecharas para ordenarla y pagar deuda técnica
Pero en la realidad eso rara vez ocurría, y ahora que los LLM empezaron a hacerlo de verdad, estamos sintiendo sus efectos secundarios
A veces crea algo nuevo aunque la función necesaria ya esté ahí mismo
Peor aún, a veces modifica la función existente fingiendo conservar el comportamiento, pero rompe otros usos
Lo peor es cuando toca estados entre clases sin entender los efectos secundarios y termina provocando deadlocks o bugs comunes
Para mí eso se parece menos a refactorizar y más a jalar otra vez la palanca de una tragamonedas
Mi verdadero problema fue la mala calidad de la refactorización que hizo el agente
Solo quería detener esas modificaciones y luego darle instrucciones más explícitas sobre qué corregir y cómo
En muchos casos la abstracción existente es suficientemente buena, y puedes rastrear un bug o ampliar una funcionalidad encima de ella
Pero a veces llegas a una bifurcación entre forzar rodeos sobre la implementación actual o rediseñarla
Con un LLM, se vuelve borroso cómo deberías reconsiderar eso, o incluso si de verdad hace falta reconsiderarlo
Y además ese tipo de decisión puede quedar escondida sin que el usuario la note mucho
Quizá esos cambios sí sean útiles, así que me gustaría ver más ejemplos
No confío mucho en la métrica de cognitive complexity, pero me parece un poco interesante que este tipo de cambios la eleven con bastante consistencia
Como en Claude Code o Codex no había visto ediciones excesivas en un tiempo, me dio curiosidad saber qué prompt usaron en esta investigación
Probablemente sea este y la última modificación fue hace 8 meses
https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py
GPT-5.4 reescribió 50 líneas porque le parecían más limpias, en vez de agregar las 10 líneas que le pedí
Era una adición mecánica: bastaba con mirar el código existente, cambiar nombres de variables e insertarlo de forma parecida
Y para colmo, al principio ni siquiera agregó la funcionalidad que yo había pedido
El over-editing no es en absoluto un problema del pasado; esto me pasó porque olvidé bajar el thinking y lo dejé corriendo con xhigh thinking
Para mí esto se lee como un problema de la era temprana de los agentes
Este texto está bastante sólido
Los LLM son demasiado verbosos, tanto en prosa como en código, y creo que la causa principal es cómo se entrenan
La cross entropy loss hace que prefieran oraciones tipo garden path
Algo que una persona resolvería en una oración, o incluso en unas pocas palabras, el modelo lo convierte en un párrafo
Porque las oraciones largas son, estadísticamente, una ruta de baja perplexity, es decir, menos sorprendente
Yo también tengo sentimientos encontrados con este problema
Normalmente hace cambios de más y luego yo tengo que invertir 30 minutos en corregirlos, así que coincido con la evaluación
Pero otras veces también deja pasar cambios más amplios que sí hacían falta
Seguramente es por límites de contexto, así que empecé a tratar la herramienta con más rigidez
Aun así, todavía no consigo el nivel de sensación de control que quiero
Esto se siente como una huella de los datos de entrenamiento
En los datos de SFT y de preferencias sobran ejemplos del tipo "versión del archivo más limpia y mejorada", pero hay pocos casos de "diff de exactamente 3 líneas"
Así que el modelo aprendió que ganan las salidas más grandes y más pulidas
Puedes controlarlo hasta cierto punto con el prompt, pero al final estás luchando contra una inclinación previa bastante fuerte