Por qué la IA basada en agentes no es una buena compañera para programar en pareja

• Los agentes LLM escriben código mucho más rápido que los humanos, por lo que la experiencia de programación en pareja puede incluso empeorar
• La automatización excesivamente rápida hace que la persona no pueda seguir el ritmo y que con frecuencia pierda el contexto del trabajo
• Este fenómeno es similar a la sensación de exclusión al hacer pairing con desarrolladores muy experimentados, y termina debilitando el control de calidad y la comunicación
• Como solución, se propone colaborar principalmente mediante revisiones de código asíncronas y cambiar a un flujo de trabajo centrado en el control de calidad y la comunicación, reduciendo la velocidad del pairing con IA
• También hace falta diseñar agentes de IA para que, como los humanos, “se detengan y conversen, y se enfoquen menos en la confianza y más en la duda y la verificación”

---

Problemas de los agentes LLM y la programación en pareja

• Los agentes de IA (por ejemplo, Copilot Agent) escriben código mucho más rápido que la velocidad de pensamiento humana
• Como resultado, el código se acumula antes de que la persona pueda seguirlo, y esto provoca que se pierda el contexto y disminuya la concentración en la tarea
• Cuando el agente pide ayuda en una situación problemática, la persona termina asumiendo el papel de “arreglar las consecuencias” sin haber entendido bien lo que pasó, lo que aumenta la carga de ordenar código que avanzó en una dirección equivocada
• Al final, se vuelve difícil mantener el control de calidad, la comunicación y la dirección correcta

• La experiencia de hacer pairing con el mejor agente de IA recuerda malos recuerdos de hacer pairing en el pasado con programadores humanos excepcionales
  • La pareja de programación teclea en silencio a una velocidad excesiva, haciendo imposible seguir el código
  • Tras agotar por completo la energía mental, uno empieza a desconectarse gradualmente del trabajo
  • Cuando la otra parte se atasca y pide ayuda, surge la experiencia incómoda de no poder entender la situación
  • Durante el proceso, se generan implementaciones que van en una dirección distinta al objetivo, y la carga de corregirlas dentro del plazo termina recayendo en uno

The path forward: soluciones prácticas

• 1. Colaboración asíncrona

  • Igual que cuando en la programación en pareja con otra persona una de las partes toma la iniciativa, es más efectivo que la IA escriba código de forma independiente y luego se revise mediante un Pull Request
  • Al aprovechar flujos de trabajo asíncronos como GitHub Coding Agent, la persona puede concentrarse en la revisión y el control de calidad

• 2. Pairing “por turnos” reduciendo la velocidad

  • En lugar del “Agent Mode” de la IA, usar un enfoque paso a paso como Edit/Ask Mode
  • Como en el ping-pong pairing (una parte propone y la otra aprueba), la persona regula el ritmo aceptando y revisando directamente los cambios propuestos por la IA
  • Es preferible no usar la IA solo para resolver problemas o depurar, sino integrarla en un flujo de trabajo consistente

Ideas para hacer más humano el pairing con agentes

• Permitir que la persona ajuste directamente la velocidad de salida del código (líneas/min, palabras/min)
• Una función para pausar temporalmente al agente, de modo que la persona pueda hacer preguntas o cuestionar la dirección
• Ofrecer primitivas de UI vinculadas al progreso del trabajo, yendo más allá de la UI tradicional de chatbot (por ejemplo, fijar la sesión actual a un issue específico de GitHub, una lista de tareas integrada, etc.)
• Diseñar al agente para que se detenga y converse con más frecuencia: confirmar “por qué se hace esto”, pedir consejo, revisar la dirección, etc., para crear un ambiente de colaboración más humano
• Incorporar soporte avanzado de chat por voz para que la persona pueda mantener la vista en el código y comunicarse con la IA por voz

• Si se aplican estas funciones, en lugar del pairing actual con agentes, rápido y unilateral, sería posible una verdadera experiencia de colaboración conjunta entre humanos y agentes

Conclusión

• En este momento estamos viendo al mismo tiempo las limitaciones y el potencial de la programación en pareja basada en agentes de IA
• La programación en pareja con agentes de IA puede ser más efectiva cuando se diseña, como la colaboración humana, en torno a la comunicación, la calidad y la verificación, en vez de priorizar solo la velocidad
• Un enfoque de “ir despacio, conversar, verificar y compartir el contexto” mejora la calidad del pairing con IA

[panarch]

> 1. Colaboración asincrónica
> Como cuando una persona lleva la iniciativa en programación en pareja con otra persona, es más efectivo que la IA escriba código de forma independiente y luego lo revise mediante un Pull Request.

He estado usando Codex durante varios días y, más que el formato de agente, coincido con esto. Ahora que puedo ejecutar trabajo en varios proyectos al mismo tiempo, de verdad se siente como trabajar con varios desarrolladores junior.
Al poder usar la IA de forma asincrónica, puedo asignarle varias tareas a la vez en distintos proyectos, e incluso varias dentro de un mismo proyecto, y realmente se percibe una productividad de 3 a 10 veces o más en términos aritméticos.

[GN⁺]

Opiniones de Hacker News

• Siento que este texto explica exactamente por qué dejé de usar la IA de esta manera tan rápido. Cuando quiero construir algo, normalmente ya tengo más o menos decidido el <i>cómo</i>, pero muchas veces la forma en que la IA realmente lo hace no coincide con lo que quiero. Y cuando la IA genera 2,000 líneas de código de una sola vez, en realidad termina dándome más trabajo. Tengo que decirle cosas como: "Primero quítame todos estos comentarios, hay el doble de explicación innecesaria para un código simple. No abstraigas X de esta forma, yo quiero esto..."; y cuando le doy feedback, de pronto esas 2,000 líneas cambian bruscamente a 700 y se vuelve dificilísimo seguirle el rastro. Tampoco me gusta que el codebase termine convertido en una colección de scripts que no conozco bien y además todos hechos de maneras distintas. Necesito una IA cuyo estilo y forma de pensar se parezcan a los míos, pero eso es precisamente lo difícil. Trabajar con IA se siente como trabajar con alguien sin experiencia en su primer día. Personalmente, más que un problema de exceso de confianza de la herramienta, creo que esto dejó más expuesto el proceso de diseño. Idealmente, primero debería haber un paso donde me muestre un diseño del tipo: "Estoy pensando este enfoque y voy a manejar estas funciones, clases y estado de esta manera"; si eso me convence, entonces pasamos a la implementación.

  • Igual que con un ingeniero humano, quiero enfatizar que primero una sesión de planeación es realmente importante. Antes de escribir código, primero discutir y negociar los detalles. Yo a propósito hago la primera pregunta lo más vaga posible para ver si sale alguna recomendación inesperada, y luego voy entrando gradualmente en más detalle. Cuando ya estoy suficientemente satisfecho, le pido al LLM que cree dos documentos: initialprompt.txt y TODO.md. En initialprompt.txt va un resumen del proyecto, una instrucción para leer TODO.md y la orden de ir marcando cada etapa a medida que se complete. Gracias a eso, el LLM entiende tanto el objetivo general como las tareas específicas, y más adelante, cuando la conversación se corta por límites de contexto y hay que reiniciar, puede recordarse rápido de qué estaba haciendo.

  • Siento que resume exactamente mi experiencia. Solo me ha salido bien con código escrito por IA cuando lo único que importaba era el resultado y yo casi no tenía conocimiento del dominio. Cuando tengo una opinión fuerte sobre qué significa un resultado “bueno”, casi siempre termino frustrado y abandonando el proyecto. Con la función architect de roo code, primero organicé el enfoque, y luego al implementar el código real en code mode fue mitad alegría y mitad frustración. La lección importante es empezar siempre tareas nuevas; no seguir conversaciones largas. Yo normalmente divido bien los problemas y voy verificando resultados, pero con los LLM tendí a aventarles todo el espacio del problema de una sola vez y fallé. Probé muchas veces para encontrar mi propia manera, y hoy mismo agregué una feature a una app en 30 minutos. Si la hubiera implementado yo, realmente me habría tomado días. Y si en mi registro puse solo 30 minutos fue porque sabía exactamente qué quería y no me interesaba el proceso. Esa experiencia me llevó a concluir que, por todas esas razones, es imposible dejarle a la IA código que después tendrá que usar otra persona.

  • Al final solo me dejó agotado y con resultados insatisfactorios. Se lo digo a cualquiera que tenga esta misma inquietud. En mi caso, solo he quedado satisfecho con agentic coding cuando se trata de scripts de corto plazo donde no me importa mucho la calidad del código, o funciones hoja que de verdad no afectan nada en ninguna parte.

  • El workflow que recomienda Anthropic en la guía de uso de Claude Code sí vale la pena. La idea central es: “primero haz que lea el código, luego que haga un plan de cambios, y al final que ejecute”. Así puedes revisar y corregir el plan antes de que la IA escriba una sola línea. Si al usar un agente ves que se mueve de una forma distinta a la que quieres —por ejemplo, si se pone a programar directo sin diseño previo—, simplemente pídele: "hazlo diferente".

  • Eso de generar 2,000 líneas de código de una sola vez suena a que quizá le están metiendo un prompt para que haga Skyrim completo en un SNES. Me imagino la escena de irse a comer, volver y enojarse porque te hizo un Fallout con solo combate cuerpo a cuerpo y estilo de PS1.

• Siempre que un post llega a la portada de HN, me da miedo leer los comentarios y ver qué tan idiota soy, o si la gente va a hacer comentarios agresivos para destrozar mi dignidad. Pero a veces, si atino muy bien al título, nadie lee realmente mi texto y cada quien se pone a hablar de lo suyo, y así me salvo de esos ataques.

  • Me parece una observación divertida pero realista. Veo patrones parecidos muy seguido en otros textos también. De todos modos, disfruto este tipo de discusiones por sí mismas, así que me resultan entretenidas.

  • El post estuvo bueno. Se sintió como una especie de “cómo disfrutar el pair programming con IA”. Me pareció útil, así que gracias.

• Cuando usé agentes LLM por primera vez, esperaba comunicación bidireccional, un pair programming realmente colaborativo. Pero en la práctica me encontré con un compañero que quiere resolverlo absolutamente todo a su manera. Si yo intentaba corregir un poco algo, se rompía el contexto del código que había escrito la IA y la experiencia se volvía todavía más incómoda. Lo que quiero es una colaboración real: yo hago un poco, la IA hace un poco, y vamos alternando el trabajo.

  • ¿Lo has vuelto a intentar recientemente? Mi experiencia ha sido distinta. Yo modifico el código generado por la IA y luego le digo que vuelva a leer el archivo. Normalmente reacciona con algo como “veo que hubo cambios en el archivo”. Si la IA cambia el código, yo corro pruebas y le doy feedback, y así vamos iterando. Esto me ha funcionado bien con Zed y Claude Sonnet.

  • La forma en que yo lo uso normalmente es recibir primero la propuesta de la IA y luego refactorizarla o volver a indicarle cosas con prompts si hace falta. Este enfoque tiene el efecto de inflar artificialmente la tasa de aceptación (accept rate), y de hecho esas estadísticas luego pueden servirles a las empresas de IA para decir que “la IA escribe código muy bueno”. En realidad, muchas veces también ha sido más bien un “bah, ya lo arreglo yo mismo”.

  • A mí normalmente me funciona poner algo como: “primero solo discutamos. No modifiques código”. Así logro el tipo de conversación que quiero. Después de suficiente ida y vuelta, al final le digo: “aplícalo”.

  • Si quieres una forma específica de colaboración, te recomendaría pedírsela explícitamente al LLM. Conviene tener preparados algunos documentos de prompt que puedas reutilizar en cada conversación.

  • Últimamente mantener el contexto ya no me resulta tan difícil, así que tampoco tengo problemas con cambios de código. Yo solo lo uso en Ask mode (más de preguntas y respuestas que de comandos), y en Claude Code uso Opus, mientras que en Cursor uso o3 max. Evito a propósito el agent mode porque, como en el post original, siento que mientras más tiempo pasa menos beneficio obtengo. Casi no uso tab completion, y entre 80% y 90% del código sugerido lo modifico y lo tecleo yo mismo. Gracias a eso puedo seguir escribiendo a 170 wpm. Como la velocidad de salida de Opus y o3 max es limitada, tampoco se vuelve pesado leerlos; al principio era demasiado rápido y costaba, pero uno se adapta pronto. Mi opinión personal es que, si GitHub Copilot es toda tu experiencia con LLM, eso apenas es una experiencia de motel.

• El pair programming tampoco sirve para todas las situaciones. De hecho, en muchos casos puede no ser adecuado. Como ya mencioné en otro lado, el problema de las sugerencias de autocompletado del LLM es que te rompen el flujo de concentración al programar: tienes que detenerte constantemente para leer, revisar y aceptar o rechazar cosas, y eso destroza por completo el flow. A mí me costó muchísimo intentar meter autocompletado con IA en mi workflow.

  • Pienso igual. La solución es usar tanto un IDE dedicado sin IA como Cursor/VS Code, e ir alternando entre ambos. El verdadero enfoque total o trabajo profundo no es posible mientras estás conversando con un chatbot.

  • Hace poco compré una laptop nueva e instalé de nuevo mi IDE. Después de unas horas programando sentía que algo estaba “raro”. Resultó que se me había olvidado iniciar sesión en GitHub Copilot, así que estaba trabajando sin IA. Sentí que estaba escribiendo código de una forma mucho más activa porque no tenía que esperar el autocompletado. Cursor en particular interrumpe demasiado el flujo, así que funciones como “predecir la siguiente posición del cursor” me parecen completamente innecesarias. De aquí en adelante pienso dejar Copilot apagado y usar herramientas estilo agente como aider solo para boilerplate o trabajo repetitivo.

  • Las funciones de autocompletado o sugerencias de código con IA son lo peor, especialmente si trabajas con lenguajes fuertemente tipados. La mayoría de las veces están 80% correctas, pero el autocompletado del IDE está casi al 100%. El enfoque de agentes de IA es mejor porque 1) no interrumpe constantemente tu hilo de pensamiento y 2) puede compilar y correr pruebas por su cuenta, corregir lo que esté mal y luego devolverte código correcto.

  • A mí, en cambio, me encanta el autocompletado. Tengo que usar Go y hay muchísimo boilerplate; muchas veces no es algo que se resuelva agregando una librería, así que escribirlo a mano suele ser más rápido. Para ese tipo de código tedioso, mis manos son más rápidas que la IA, por eso el autocompletado sí me ayuda mucho. Las sugerencias de una sola línea las leo al instante, y si una sugerencia larga se parece a lo que iba a escribir, la dejo pasar sin problema. Con la repetición, ya hasta agarras intuición de qué va a predecir la IA. No diría que sea una mejora de productividad enorme, pero sí acelera claramente cosas aburridas como mensajes de log o loops for. Creo que solo ayuda cuando leer me resulta mucho más rápido que teclearlo yo mismo.

  • El pair programming no siempre es lo indicado, pero en la mayoría de las situaciones sí puede ser muy útil. Cuando no funciona, generalmente es porque una de las dos personas —o ambas— no se involucran de verdad en el proceso, porque alguna de las dos se pone en plan de “eso no se hace”, o porque intentan seguir los principios del pair programming con demasiado rigor.

• Mi postura es un poco compleja. Llevo al menos un mes, en la empresa, usando activamente varias herramientas LLM para aprender a sacarles el máximo provecho. Si lo mides por líneas de código, sí soy claramente más productivo. Pero no puedo decir que en conjunto sea más productivo. En muchas tareas terminadas aparecen comportamientos raros difíciles de explicar, o a veces toca partes no relacionadas y al final tengo que revertirlas. Las pruebas generadas automáticamente por la IA al principio se ven razonables, pero cuando las evalúas con otros indicadores como cobertura, sus carencias se vuelven obvias. Para llegar al resultado que realmente quiero, a veces siento que tengo que deshacer varios pasos y retroceder. No es una ganancia ni aprendizaje: es una experiencia de retroceso total. Una vez incluso me agregó a escondidas 50 mil líneas de imports innecesarios en módulos que ni siquiera estaban dentro del alcance original del cambio. En otra ocasión, aunque le había dejado claras las reglas, destruyó toda la estructura orientada a objetos e implementó todo con puros if/else. El problema es que los resultados cambian demasiado según la situación; incluso con la misma tarea, a veces lo hace perfecto y otras veces destroza todo. He probado muchas formas de pedirle las tareas y de guiarlo, pero incluso para trabajos parecidos se comporta de maneras demasiado distintas, así que revisar todos los cambios siempre es doloroso. Incluso cuando el código está casi bien, si le pido que corrija solo una parte específica, el trabajo completo se descarrila. En mi experiencia, funciona para escribir herramientas pequeñas, pero en codebases medianos o grandes es difícil esperar resultados consistentes.

• Los agentes LLM hablan demasiado y siempre actúan como si su forma fuera la correcta. No son concisos, y explican larguísimo cosas que cabrían en una sola línea. Hasta en cambios mínimos meten comentarios larguísimos. Se sienten como si quisieran enseñarme y salieran con algo excesivo, demasiado cargado.

  • Algunos comportamientos que la gente odia ("salidas demasiado largas, comentarios excesivos, etc.") podrían ser efectos secundarios de cómo se diseñó el LLM para mejorar la eficiencia en otros aspectos. Las salidas largas tienden a correlacionarse con código no perezoso y mejores puntajes en benchmarks de rendimiento. El exceso de comentarios también puede reforzar el contexto local, mejorar la calidad del código siguiente y reducir errores.

  • Ayer probé sonnet 4 y se pasó 15 minutos probando y refactorizando una tarea donde solo quería cambiar una sola configuración. Al final terminó modificando 40 archivos sin necesidad. También insistía en ejecutar un depurador que ni existe y en abrir continuamente páginas web que requieren autenticación. De verdad se siente lejísimos de ser algo perfecto.

• En mi experiencia, el problema no es que sea rápido sino, al contrario, que es demasiado lento. La velocidad queda en un punto ambiguo y por eso es peor. Si fuera más rápido, podría seguir el código en tiempo real mientras trabaja. Si fuera más lento, podría ponerme a hacer otra cosa y volver después. Pero la realidad es que termina las cosas en intervalos de 50 segundos a varios minutos, así que no alcanzo a concentrarme en otra tarea. Creo que sería mejor iterar más rápido en unidades más pequeñas. Al final, sería preferible un nivel de autonomía más parecido a una revisión humana, por ejemplo trabajo independiente como revisar un merge request (PR). El loop actual (dar una tarea, esperar 1 a 3 minutos, ver el resultado, dar feedback y repetir) personalmente me parece el peor caso posible.

  • Esto me hace pensar en la caricatura de The Oatmeal sobre “internet lento vs. no tener internet”.

  • Consejo ingenioso: si se te dispersa la atención, pon una pecera de 30 L en el escritorio. Es ideal para quedarse viendo al vacío.

• Como desarrollador, casi no uso IA; solo de vez en cuando uso un chatbot para preguntas no relacionadas con proyectos. Me da curiosidad si la usan también en proyectos de clientes o solo en proyectos personales (pet projects). Si la usan para clientes, me gustaría preguntar si incluyen en el contrato el hecho de que el código se envía a una IA. La mayoría de los clientes tienen NDA o acuerdos de no divulgación externa, y algunos incluso han puesto cláusulas que prohíben usar IA. Me pregunto si alguien se ha topado con clientes que sí acepten herramientas de programación con IA como excepción.

  • Yo casi solo la uso dentro del trabajo y eso porque la empresa tiene lineamientos claros sobre el uso de IA. En la práctica ni siquiera siento que me ahorre tanto tiempo, así que no pagaría por usarla en mis proyectos personales. En proyectos propios, me importa más la diversión de construirlo yo mismo que el resultado, así que disfruto más hacerlo directamente que ponerme a trabajar con prompts.

  • También hay casos donde el cliente pide activamente que se use IA. Esperan mejor calidad y desarrollo más rápido (al final, buscando reducir costos), aunque muchas veces la realidad termina siendo muy distinta de esa expectativa, pero eso ya es otro tema.

  • Con OpenAI/Anthropic solo comparto código que sería lo suficientemente público como para pegarlo sin problema en un buscador web.

  • Yo no comparto nada. Ni siquiera proyectos internos; compartir código hacia afuera solo lo hago cobrando. Además, manejo datos personales, así que el riesgo legal de que el código quede expuesto a empresas de EE. UU. es demasiado grande.

• Por fin alguien señaló exactamente esto. La IA tiene demasiada confianza en el diseño, pero en la implementación detallada avanza por su cuenta sin consultar. Incluso con APIs mockeadas muchas veces rompe la estructura y obliga a rehacer trabajo. Me gustaría que el comportamiento del LLM fuera más colaborativo, que si le faltan detalles pregunte de inmediato. No puedo meter toda la información en el prompt inicial, y los prompts adicionales rompen el contexto y el hilo mental del diseño original. No sé si lo estoy usando mal, pero quiero aprender una mejor manera. Me gustaría que el LLM mejorara hacia una dinámica donde reciba feedback de manera gradual y lo incorpore. También me pregunto si agregar o actualizar contexto en sí mismo es un problema difícil, pero sigo con ganas de aprender.

  • Hoy en día la mayoría de los tech stacks soportan sesiones de “diseño/planeación”, así que probablemente valga la pena probar primero eso. Un workflow que me funciona bien, con modelos grandes o pequeños, es empezar con una conversación tipo: “Con base en @file, @docs, @examples, quiero trabajar en _ dentro de @path consultando @module_requirements.md; antes de implementar de verdad, discutamos todo lo necesario”. Se discute de ida y vuelta hasta que todos estén de acuerdo, y luego eso puede guardarse en un .md o pasarse de una vez a un “ahora sí, hazlo”. Si registras el workflow en archivos .rules, .md o snippets del IDE, puedes reutilizarlo de forma repetible en cada tarea nueva. También hay que tener presente que los LLM recientes necesitan muchísimo más contexto, así que conviene probar flujos distintos según el codebase (según el proyecto), porque eso cambia mucho los resultados.

  • También siento que, mientras más información les das, más se confunden. Supongo que debe haber alguna forma de superarlo. Son muy buenos extrayendo fragmentos pequeñísimos de información, pero me da lástima que toda la industria esté tan enfocada solo en modelos tipo chatbot. Me pregunto cómo sería si nunca hubiéramos seguido desarrollando teclado, mouse, GUI o pantallas táctiles.

• El estilo colaborativo de usar la IA como asistente es justamente la forma correcta de aprovecharla, y la moda de enfocarse en que “la IA escriba el código directamente” me parece más bien un ejemplo de que la industria del software va en la dirección equivocada. Yo nunca le dejo la escritura del código a la IA. La uso para que critique el código que escribí o para ayudarme a diseñar estrategias de arquitectura a gran escala. Es como usarla de consultor estratégico: si estructuras bien el contexto para el LLM, puedes sacar guías realmente excelentes. El protagonista siempre soy yo: yo entiendo, yo ejecuto, y mi principio es no darle nunca a la IA una responsabilidad mayor que la de consejera. Pienso en la IA como un “idiot savant” y creo que hay que tratarla con cuidado.