Dos cosas que los agentes de código con LLM todavía hacen mal

• Los agentes de código con LLM no logran realizar de forma natural tareas de mover código, como copiar y pegar
• Al refactorizar código, es difícil garantizar la consistencia debido a una forma de escribir código basada en la memoria
• Casi no hacen preguntas durante el proceso de resolución de problemas y se mantienen en intentos basados en conjeturas
• Los desarrolladores humanos aclaran el problema haciendo preguntas cuando hay ambigüedad, pero los LLM repiten intentos hasta chocar contra una pared
• Por estas características, se percibe a los agentes LLM no como reemplazo de desarrolladores humanos, sino como pasantes con demasiada confianza

---

Principales limitaciones de los agentes de código con LLM

Últimamente se ha intentado usar LLM como herramientas de ayuda para programar, pero todavía hay aspectos que a los desarrolladores humanos les resultan extraños. Este artículo explica con claridad dos razones que hacen especialmente incómodos a los agentes de código con LLM

1. Lo extraño de su forma de mover código y refactorizar

• Los LLM no realizan la acción real de 'copiar y pegar'
  • Por ejemplo, si se les pide refactorizar un archivo grande en archivos pequeños, el LLM 'recuerda' parte de los bloques de código, usa el comando delete en el archivo original y al mismo tiempo escribe en el archivo nuevo el código 'recordado' con el comando write
  • No usan herramientas de 'cut' o 'paste'; todas las modificaciones se reconstruyen desde la memoria
  • Cuando un desarrollador humano mueve código, usa 'copiar y pegar' y así tiene confianza en que el código coincide exactamente, pero el LLM no garantiza eso
  • Hasta ahora, solo Codex ha mostrado en parte intentos de imitar la acción humana de 'copiar y pegar' usando comandos sed o awk, pero no es perfecto

2. Un enfoque de resolución de problemas sin preguntas

• El proceso de resolución de problemas de los LLM también es muy distinto al de los humanos
  • Los LLM casi no hacen preguntas e intentan resolver el problema basándose en numerosas suposiciones
  • Los desarrolladores humanos siempre confirman la situación haciendo preguntas cuando hay cambios grandes o escenarios poco claros, bajo la idea de que 'no hay preguntas malas'
  • En cambio, los LLM tienden a seguir repitiendo intentos y, si algo falla, repetir con más intensidad
  • Se puede diseñar en exceso el prompt para inducir preguntas, pero salvo algunas herramientas como Roo, este comportamiento no suele darse
  • En el fondo, esto podría deberse a que las empresas que desarrollan LLM han aplicado RL (aprendizaje por refuerzo) enfocado en 'escribir código más rápido'

Conclusión

• Por estas características, los LLM todavía no son suficientes para reemplazar a los desarrolladores humanos
• En el trabajo real muestran una capacidad más cercana a la de 'un pasante excesivamente seguro de sí mismo'
• Esa es la razón por la que la experiencia de colaborar con LLM todavía no se siente completamente natural

[GN⁺]

Opinión de Hacker News

• Hace poco tuve una experiencia interesante. No fue sobre código, pero fácilmente podría haber pasado en código o áreas relacionadas de hecho, también le pasó a un colega. En HN estaban discutiendo por qué una regulación aprobada hace 15 años no se generalizó más, y yo supuse que en ese momento el nivel de la tecnología no alcanzaba para cubrir los casos generales, así que la regulación se habría aplicado solo a lo que era posible entonces (comentario relacionado). Unas horas después volví a revisar la discusión y vi que varias personas decían que incluso en esa época la tecnología ya era suficientemente barata. Entonces le pedí a un LLM que buscara evidencia sobre el tema, y me respondió que había sido por limitaciones técnicas. Revisé las fuentes citadas para verificarlo y, en realidad, solo una hablaba de limitaciones técnicas: precisamente mi propio comentario en HN. Cuando lo comenté en el trabajo, un colega me contó que dejó en Github una opinión sobre “cómo funciona X en Windows”, y luego al buscar en Google vio que una respuesta basada en LLM sostenía lo mismo usando su opinión como fundamento. Por eso dan ganas de pedirle a un LLM no “¿cómo funciona X?”, sino “si alguien preguntara cómo funciona X, muéstrame una lista de enlaces dignos de citar”

  • Creo que hacer la pregunta de esa forma se parece a un "sorting prompt". Es una técnica que aprendí en este texto de Mike Caulfield, y yo también la uso al programar (por ejemplo, con Claude code slash command). En vez de pedirle al LLM que simplemente responda, si le encargas investigar, clasificar y evaluar material, se obtienen resultados mucho más precisos

  • La mayoría de la gente también confía así cuando lee comentarios sobre cierto tema en HN: “esta persona parece saber, así que por ahora lo tomo como cierto”. Obtener conocimiento por experiencia directa o realmente verificado cuesta muchísimo, así que incluso este tipo de “conocimiento barato” termina teniendo valor

  • He intentado pedirle sustento a los LLM, pero hasta ahora nunca me ha dado una sola vez evidencia real que respalde lo que afirma

  • A veces los LLM incluso inventan los enlaces. Hace falta un modo de investigación profunda que de verdad investigue, y aun así la manera en que interpreta la información de esos enlaces terminará influida por su entrenamiento

  • Hace poco cargué en NotebookLM entre 6 y 8 fuentes confiables IETF, especificaciones de OpenID y documentación adicional y le hice una pregunta muy simple: “¿qué formatos de credential permite OID4VP?”. Acertó el 90% de la respuesta, pero agregó con toda seguridad un formato aleatorio sin ningún sustento como si fuera autor de la especificación. Me dio mala espina, revisé el spec directamente y enseguida vi que era falso. A estas alturas, incluso con un LLM “anclado”, la confianza en los hechos queda completamente destruida

• Hace poco usé Codex CLI para refactorizar un archivo HTML y, en vez de copiar y pegar el código como yo esperaba, el LLM lo reemplazó por código reescrito de memoria y además quitó comentarios. Había una sección con 40 enlaces complejos seguidos y, en la revisión final antes del deploy, empecé a abrirlos uno por uno: al principio todo bien, pero desde la mitad 31 enlaces devolvían 404. El dominio estaba bien; lo que había cambiado eran las rutas. Revisé las URLs anteriores en el commit de git y resultó que el LLM había “alucinado” rutas que ni existían. Este tipo de error sutil y silencioso es realmente peligroso. Hay que tener muchísimo cuidado

  • Me parece que el último punto es muy importante. Por culpa de estos “errores muy sutiles y silenciosos”, aunque un LLM haga el trabajo tan bien como un humano o mejor, no se lo puede tratar del mismo modo. En particular, el code review ha sido tradicionalmente una capa importante para prevenir problemas, pero si cambia el tipo de errores que hay que revisar, el método tradicional de revisión deja de ser eficiente. Antes, cuando se movía mucho código, se podía asumir que el bloque se había trasladado tal cual y concentrarse más en el nivel alto; en una refactorización con LLM, en cambio, el código “movido” puede ser en realidad código "nuevo" resumido o reconstruido, así que hay que mirar cada carácter. Por eso creo que conviene agregar una sección de “uso de AI” en la descripción del Pull Request, para dejar pistas sobre dónde y cómo se usó y así saber qué áreas revisar con más atención

  • A mí me pasa seguido algo parecido cuando hago preguntas de código o de investigación. El LLM empieza bien, pero después de la enésima iteración empieza a inventar cosas por su cuenta. Antes de un viaje le pedí a Gemini una lista actualizada de cervecerías, y metió tranquilamente lugares ya cerrados o que habían operado solo temporalmente. Luego le pedí que agregara enlaces de horarios y quitara los lugares cerrados; solo corrigió la primera parte de la lista, mientras que en la segunda hizo cambios sin relación o directamente no borró los lugares cerrados. Y aun así respondía cada vez con total seguridad diciendo que había investigado todo perfectamente

  • No es sobre código, pero una vez le pedí a un LLM que revisara solo ortografía y gramática de un aviso de evento. Me devolvió una versión ligeramente editada, pero cambió discretamente la fecha un día más tarde. Por suerte me di cuenta y lo corregí, pero me quedó la lección de que no hay que confiar ciegamente ni siquiera en tareas muy simples. Aunque el prompt sea una sola oración fácil y clara, los LLM a veces hacen cosas sorprendentes, pero otras veces fallan de forma inesperada incluso en lo más básico

  • Hace 5 minutos también le pedí a Claude que solo agregara sentencias de debug al código, y terminó cambiando en silencio una expresión regular. En un diff fue fácil verlo, pero en cambios grandes de verdad es muy fácil que se escape

  • Haber vuelto a revisar los 40 enlaces justo antes del deploy fue una buena decisión. Pero sí me sorprende un poco que, después de que Codex terminara, lo hayan subido a master sin hacer git diff

• Estoy de acuerdo con lo que sostiene el post. Aun así, creo que el problema más grande es que el agente solo ve una parte muy pequeña del repositorio. Como no conoce funciones helper que ya existen, vuelve a crear lo mismo una y otra vez. En desarrollo de UI, como no puede comparar la estructura completa de la interfaz, repite código inconsistente. Al final, una persona tiene que darle bien el contexto correcto: “usa las helpers de este archivo”, “hazlo como esta implementación”, “lee este documento sí o sí”, etc. Si le das directamente el contexto adecuado, se puede aumentar muchísimo la utilidad del agente. Y otro problema más es que en monorepos grandes se le da muy mal explorar la estructura de carpetas; por ejemplo, de verdad falla muchísimo incluso en algo como ejecutar npm test desde un subdirectorio

  • Es exactamente el mismo problema que tengo yo. Hace poco revisé unas 200 líneas de código para una función nueva implementada con Cursor, y en realidad muy poco de eso hacía falta. Encontrar funciones que ya existen en una librería utility es tan tedioso que uno lo deja pasar. Hace 5 años este tipo de revisión tenía mucho de onboarding junior, así que era importante señalar esas cosas, pero hoy siento que herramientas como Cursor solo aumentan el volumen de código, mientras que el propio developer muchas veces sí conoce la estructura pero, por políticas de la empresa, termina produciendo código así a propósito, y eso baja la productividad

  • Ejecutar comandos como npm test desde subcarpetas siempre fue un problema. En un repo dividido entre frontend Vite/React y backend .NET, si fallaba un comando npm, entraba en pánico y repetía varias veces sin resolver nada, generando troubleshooting innecesario. Una vez hasta escribí instrucciones en CLAUDE.md para que siempre verificara primero el directorio actual, pero igual seguía olvidando la ruta de forma aleatoria. Así que agregué aliases que funcionan desde cualquier directorio, como run-dev server restart y run-dev client npm install, y puse los comandos puros como dotnet/npm en una lista prohibida, obligando a la AI a consultar la documentación del proyecto y usar los aliases. Ese método fue relativamente estable, pero llegar a eso costó bastante tiempo, esfuerzo y estrés

  • Me gustaría que un modelo de gran contexto se usara con tool calls. Gemini chat puede ingerir un repositorio completo de github. ¿Qué tal una herramienta “not-invented-here” que, antes de escribir una función nueva, verifique si ya existe algo equivalente en el codebase? Aunque primero habría que ver si alguien no construyó ya algo así

  • Por eso hacen falta documentos como claude.md. Si queremos que siga nuestras propias reglas, documentarlas es indispensable

  • En realidad, este tipo de situación es muy común cuando un ingeniero senior trabaja en el día a día con colegas

• Coincido totalmente con la parte citada en el artículo. Estoy de acuerdo en que los LLM no pueden reemplazar a developers de alto nivel. Cualquiera en su sano juicio sabe que decir eso hoy no tiene sentido. Pero sí creo que ya están reemplazando a developers de desempeño bajo o medio. Por ejemplo, en nuestra organización había 3 personas egresadas de un bootcamp de 6 meses, a quienes contratamos porque en ese momento era demasiado difícil conseguir buenos developers. Pero en la práctica sufrían incluso con tareas realmente muy simples, y yo tenía que arreglar todo su código en cada review. Después, las herramientas de AI mejoraron exponencialmente y superaron el rendimiento de esas personas. Al final despidieron a 2, y la otra renunció por su cuenta. Últimamente casi ya no contratamos developers junior, y definitivamente no volveríamos a contratar gente salida de bootcamp. A mi alrededor pasa algo parecido, y quizá por eso la propia industria de los bootcamps está desapareciendo. No sé si en el futuro la AI podrá reemplazar incluso a los buenos developers, pero viendo los datos actuales, está claro que mejora a una velocidad enorme. Las opiniones negativas ignoran la realidad. En los inicios de Estados Unidos, el 90% de la población trabajaba en agricultura; hoy es apenas el 2%. Sin embargo, la producción y diversidad de alimentos aumentó muchísimo. Todo eso fue resultado del progreso tecnológico. Creo que algo similar podría repetirse rápido en la industria del desarrollo

  • Claro, la tecnología aumentó la producción de alimentos, pero también es cierto que la calidad nutricional bajó y la toxicidad aumentó

  • Me da curiosidad qué crees que impidió que la gente salida de bootcamp creciera profesionalmente

• La lección más importante es que, sin una cantidad considerable de instrucciones y supervisión, los LLM son muy frágiles incluso en tareas bastante simples. En mi proyecto pequeño 2.5K líneas les pedí refactorizar un parser, y el plan sonaba razonable. Le puse checkpoints paso a paso y lo fui guiando secuencialmente, pero cada vez que preguntaba “¿ya se eliminó la estructura anterior?” o “¿ya se reemplazó por la nueva?”, la respuesta era “no, sigue ahí”. El 80% de los tests falló, y aunque le indiqué direcciones de arreglo muy concretas, en una tarea abstracta como “refactorizar” seguía tropezando siempre con el mismo problema. Al final, si no le escribía instrucciones súper detalladas del tipo “esta clase cambia esto”, no funcionaba. A ese nivel ya no se le puede asignar trabajo de manera independiente, y el sentido mismo de usar LLM se reduce mucho

  • Mi experiencia es un poco distinta. Un parser de árboles de expresiones hecho en typescript (tinqerjs.org) lo completé en dos semanas part-time usando solo Codex+Claude, con 0 líneas escritas a mano, y además agregó cientos de tests incluidos duplicados. También hice un ORM, y usando LLM pude ahorrar por lo menos entre 4x y 10x de tiempo. Casi no necesité supervisión; creo que al final el resultado depende del objetivo de uso y de si el proceso está bien establecido. Los developers que ya dominan el uso de LLM también van construyendo workflows propios, y todos tienen en común el foco en tests, documentación y code review

  • El problema de “si la instrucción de refactor tiene que ser demasiado detallada, ya no vale la pena usarlo” hay que replantearlo como “si lo descompongo bien en pasos de alto nivel y doy instrucciones, voy mucho más rápido que haciéndolo yo solo”

  • De nuevo, esto conecta con lo que señala el artículo sobre que la AI no hace cut-paste sino borrado y regeneración. En la práctica es inevitable que el código vaya derivando un poco

  • Me da curiosidad qué modelo o herramienta usaste. Incluso con Cursor o Copilot me ha pasado seguido que en refactors pequeños igual hace falta supervisión constante

• Está claro que los LLM ayudan en algunas cosas. Por ejemplo, esta mañana corregí un bug en un parser de metadata PDF con ayuda de un LLM sin tener que profundizar a fondo en el spec de PDF. Pero en la mayoría de los casos el resultado es menos eficiente que hacerlo yo mismo. Antes intenté usar Codex Code para que escribiera unit tests; había preparado varios setups, pero se lo delegué porque me daba flojera hacer el mocking de datos. Lo intentó 8 veces, hubo que corregir a mano, y ni siquiera entendió que la entidad estaba obsolete y ya no se usaba en el servicio. El resultado fue decepcionante. Todavía no alcanza para reemplazar por completo a un developer, pero, igual que Stack Overflow en su momento, siento que sirve muy bien para exponer conocimiento y orientar hacia soluciones en temas poco familiares

  • Incluso hoy, creo que los LLM por sí solos todavía tienen bastante potencial. Pero la verdadera magia aparece al combinarlos con agentes de código. Si se cuenta con las herramientas adecuadas, integración e iteración con el modelo, hasta se puede implementar copy-paste, y la mayoría de las carencias actuales se pueden compensar con buen contexto, buenas instrucciones, validación iterativa y una arquitectura de agente sólida. Además, la experiencia mejora muchísimo con modelos rápidos, gran contexto y alta capacidad de concentración en las instrucciones. Y también creo que la habilidad humana para escribir prompts es muy importante. Al final se necesitan buenas capacidades de ingeniería de software, especialmente para asignar trabajo a otros developers, además de documentar instrucciones y buenas prácticas dentro del codebase con AGENTS.md o CLAUDE.md. En conclusión, el debate de “si la AI/LLM puede o no reemplazar developers” ya se volvió aburrido. La pregunta clave es más bien “¿qué puedo hacer yo por mi LLM?”

• No creo que sea sobreingeniería crear “prompts que lleven a hacer preguntas más claras”. Al contrario, diseñar el prompt para que “si no está claro, primero pregunta” me ha resultado muy efectivo. Un buen programador sabe si la especificación está transmitida por completo o si hace falta más clarification, y puede guiar a la AI para que haga de antemano las preguntas adicionales necesarias

  • Incluso se le puede indicar cuántas preguntas hacer. Cuando el tema es complejo, le pido de antemano 20 o 30 preguntas, y el resultado suele ser bastante satisfactorio. También es útil guardar ese QnA en un archivo aparte y reutilizarlo en la siguiente sesión o con otro agente

  • Gracias a eso, ya no escribo prompts como antes. Solo le tiro la idea y le digo “pregunta si hace falta”, y suele señalar muy bien puntos en los que yo ni había pensado

• Inspirado por lo del copy-paste del texto, agregué una herramienta de buffer para agentes en clippy una utilidad de macOS. clippy tiene un servidor MCP que interactúa con el portapapeles del sistema, pero esta vez convenía usar un buffer privado separado. Las funciones agregadas son buffer_copy copiar un rango específico de líneas de un archivo y guardarlo en el buffer privado, buffer_paste insertar o reemplazar en un archivo objetivo los bytes exactos guardados en el buffer, y buffer_list revisar el contenido del buffer. Por ejemplo, si el agente indica “copia las líneas 50 a 75 de auth.py”, el servidor hace directamente la entrada/salida del archivo y no hay generación de tokens ni alucinación alguna. Tampoco afecta el portapapeles del sistema. Antes también se podía copiar directamente al portapapeles el código generado por la AI. El propósito principal de clippy es mejorar pbcopy en macOS copiar el contenido real de archivos para luego pegar el archivo mismo en Slack o email desde la terminal. Quienes usen en macOS agentes compatibles con MCP como Claude pueden ver aquí. Se puede instalar con brew install neilberkman/clippy/clippy

• A muchos developers también les cuesta hacer buenas preguntas. Tienden a dar por sentadas y omitir muchas cosas. En 25 años de experiencia, más de la mitad de mis colegas tenían ese segundo defecto. Yo también fui así durante la mitad de mi carrera, así que me identifico aún más

  • Aun así, es natural que la gente quiera que la confiabilidad de los autos autónomos o de la AI sea superior a la de los humanos. El argumento de “los humanos tampoco pueden” no sirve de mucho para quienes tienen esa expectativa. Personalmente me parece una postura bastante comprensible

• Como dice el artículo, los LLM no hacen copy-paste o cut-paste; recuerdan el código, lo borran y lo vuelven a escribir, así que da la impresión de que siempre solo emiten nuevos comandos de escritura. En refactors, en realidad no hay tanto copy/paste literal, así que muchas veces lo resuelven más por recall basado en contexto. En trabajo real, tampoco está claro qué tan útil sería en sí el comando de copy/paste al menos en mis pruebas no cambió demasiado. Más bien, para partes repetitivas que consumen mucho contexto, me ha funcionado mejor usar herramientas como fastmod y pedirle a codex o claude que ayuden con “modifica esto en lote”. La forma en que enfrentan los problemas es distinta a la humana y a veces se siente rara, pero si se planifica bien y se conversa con suficiente detalle, el enfoque en sí puede cambiar bastante

  • Un IDE puede cambiar al instante firmas o nombres de funciones en varios archivos, pero cuando lo intenta un agente LLM a menudo tarda minutos y aun así no lo resuelve correctamente. Creo que la utilidad de un soporte real de copy/paste es evidente

  • El copy/paste ayuda mucho a reducir la explosión de contexto, porque el modelo no necesita recordar el contenido del bloque de código y puede acceder a él cada vez que haga falta