- Los fallos de los agentes de programación se sienten más irritantes que un simple error de herramienta, porque la UX conversacional crea la sensación de estar trabajando con una persona
- El agente responde que es un asistente de IA sin emociones, pero por su tono amistoso, los elogios y las objeciones suaves, da la impresión de ser un colega
- Cuando el mismo error se repite, aunque siga con disculpas, actualizaciones de memoria y promesas de “no volver a hacerlo”, puede que no logre salir de una trayectoria probabilística
- Con colegas humanos reprimimos la expresión de la ira, pero con un agente podemos enojarnos libremente, así que la frustración no se disipa y se vuelve más nítida
- Una posible solución sería reducir las actitudes que lo hacen parecer humano y usar un tono más clínico y robótico, aunque la interfaz conversacional en sí funciona bien en muchos aspectos
La frustración que crea la UX conversacional
- Un agente de programación es una máquina que genera parches de forma probabilística, así que puede producir tanto buenos como malos resultados, pero los malos pueden sentirse mucho más irritantes que el simple fallo de una herramienta
- La clave está en que la UX conversacional crea la sensación de interactuar con una persona y activa en el usuario respuestas sociales y emocionales ante errores repetidos
- Si se le pregunta directamente, el agente responde que es un asistente de IA sin emociones ni experiencia subjetiva, pero en la interacción real usa un tono amistoso y relajado, elogia al usuario y maneja las objeciones con suavidad
- Aunque racionalmente el usuario sabe que está leyendo un “bloque de texto con alta probabilidad”, la forma en que actúa la herramienta crea la sensación de trabajar con un colega útil, y esa sensación se mantiene hasta que aparece un problema
- Cuando el mismo error se repite, el usuario lo señala, el agente se disculpa y, si se le vuelve a señalar, actualiza la memoria y promete “no volver a hacerlo”
- Aun así, como la herramienta sigue la ruta con mayor probabilidad, hay casos en los que ni siquiera con HARD RULES logra salir de una conducta problemática
Una herramienta que parece humana pero no asume responsabilidad
- Si un colega humano repitiera el mismo error, habría razones para sentirse molesto, pero enojarse con un algoritmo parece absurdo
- Sin embargo, como el agente de programación actúa como un colega, el usuario activa los mismos circuitos emocionales, y los errores repetidos pueden sentirse como la irresponsabilidad real de un compañero de trabajo
- Con colegas humanos, la limitación de “no quiero convertirme en una persona horrible” reprime la expresión de la ira, pero con un agente uno siente que puede enojarse libremente
- Ese desahogo no produce alivio, y el usuario solo siente con más claridad la frustración de que nada de lo que haga o diga tiene un efecto real
- Claude Code, cuando recibe correcciones, últimamente a veces repasa dónde se equivocó y qué debería haber hecho, pero ese análisis posterior no da pistas útiles sobre cómo cambiar las instrucciones y puede leerse como relleno molesto
- Una solución más radical podría ser abandonar la intención de parecer humano y hacer que el agente hable de forma clínica y robótica, para reducir la ilusión de que el usuario está interactuando con una persona
- Como la inteligencia de los LLM surge de mecanismos orientados a “actuar como humanos”, es natural que la interfaz conversacional se haya establecido como modo predeterminado, y en muchos aspectos funciona bien
- En términos prácticos, los usuarios tendrían que entrenarse para no caer en la ilusión de que están hablando con un ser humano, pero no resulta atractivo un futuro en el que haga falta esa defensa para usar herramientas de trabajo
1 comentarios
Comentarios de Hacker News
En la mayoría de los casos de uso de IA que se están imponiendo al público, un chatbot conversacional no es la herramienta adecuada, y al final la experiencia solo puede resultar frustrante.
Cuando Copilot era básicamente un IntelliSense muy inteligente, era excelente. Ahora, con este método en el que hay que pensar y escribir prompts, no veo en qué ha mejorado frente a la forma anterior, que tomaba el código alrededor como contexto y rellenaba los huecos. Una herramienta bien integrada siempre es mejor que un chatbot añadido encima, y en traducción pasa igual: Firefox tiene un botón que traduce directamente el texto o la página, mientras que con los LLM más recientes hay que pedírselo a un chatbot, así que en realidad es un retroceso.
Entiendo que las empresas de IA quieran crear una sola herramienta y vendérsela a todo el mundo, pero al final eso equivale a fabricar una navaja suiza. Puede hacer de todo, pero para apretar un tornillo no va a superar a un destornillador bien hecho. Para reducir la frustración, no hay que poner herramientas no deterministas detrás de un cuadro de texto, sino construir herramientas reales.
Uso Mistral sobre todo, y Codestral es pésimo para conversar, pero es de lo mejor para el “autocompletado mágico”, y también funciona bien para generación puntual con prompt+contexto, como redactar logs de commit. Document.AI es casi inutilizable como interfaz conversacional, pero si lo conectas como reemplazo de OCR o en un pipeline de indexación semántica de documentos, rinde bastante bien.
Así que parece que lo que falta no es tanto el modelo como la interfaz. Por ejemplo, estaría bien un fork o wrapper de zsh/bash con un modelo entrenado para interacción por línea de comandos. En vez de
git commit --fixup=..., uno podría decir “haz un fixup del commit donde corregí el nombre completo” o “convierte some.mov a mp4 sin audio con ffmpeg, manteniendo la calidad y la relación de aspecto”, y que lo transforme en un comando, te lo muestre y luego lo ejecute según una política de permitir/rechazar/lista blanca/lista negra.Lo mismo con traducción, borradores de correo y lectura de documentos: debería funcionar no como conversación, sino como botón, atajo de teclado o autocompletado con tab. Creo que la empresa que resuelva bien esto en el IDE ganará la competencia de herramientas de IA para programar, y que Zed mostrara el botón “git conflict found, resolve with AI” parece un paso en la dirección correcta, aunque haya abierto un hilo de conversación.
Hago bastante trabajo solo con el agente y revisión de PR en la web, sin editor, y solo abro
code .de vez en cuando cuando hace falta. Si lo practicas con un proyecto personal sin presión, como si fuera un juego, se vuelve menos frustrante con el tiempo. Se parece a aprender a esquiar o a jugar boliche.Insultar al modelo me ha funcionado bastante bien para hacer que vuelva a pensar y corrija errores. Me pasó algo parecido con Codex, Claude, Qwen y Gemma/Gemini en general.
No sé si el modelo lo interpreta como una señal de que “debe concentrarse con más rigor”, o si el proveedor detecta la frustración del usuario y redirige a un modelo más inteligente. Cuando repite el mismo error, insultarlo muchas veces hace que salga del atasco y tome el camino correcto; o quizá simplemente sea catarsis.
Muestra que ser “grosero” o “muy grosero” mejora la exactitud del resultado; es sospechoso, pero una lectura divertida. Los prompts de la tabla 1, arriba de la página 3, son especialmente buenos, y seguro probaron otros que no incluyeron en el paper.
Ayer mismo, Opus insistía en culpar a la API porque supuestamente faltaba cierto campo, y aunque le mostré el JSON y los logs, seguía repitiendo que “habrá sido un problema temporal”. Me enojé, metí todo tipo de insultos en una sola frase y la siguiente solución fue la correcta; antes de eso se había equivocado de forma parecida unas diez veces. Estos casos son cada vez menos frecuentes, pero igual era una situación que habría debido resolver yo directamente, y antes de entrar no se puede saber hasta qué punto el modelo va a obsesionarse con una causa absurda. Llegó a la respuesta tras unos 11 prompts en un contexto de 1 millón con Opus 4.7 xhigh después de
/clear.greppara analizar con qué frecuencia pasa.La naturaleza conversacional de los LLM tiende a arrastrar a la gente hacia caminos de conversación improductivos.
Decir “no hagas X” sirve tanto como decirle a un bebé que llora que no llore. Así como entendemos de forma natural que, si un bebé llora, hay que resolver una incomodidad como hambre o el pañal, cuando un LLM falla lo veo como una señal de que hay un problema en la arquitectura y estructura del código.
Un desarrollador con experiencia suele detectar patrones que violan DRY o KISS y puede resolver el problema organizando mejor la encapsulación. Con el código generado por LLM pasa lo mismo: para mejorar el resultado hace falta ese mismo tipo de refactorización, y solo con pedir entre una generación y otra que “refactorice limpiamente”, la mantenibilidad mejora mucho.
También hay un texto anterior que aborda con más profundidad los efectos psicológicos y sociales de este tema: https://medium.com/@livestock.dev/we-were-promised-liberatio...
El problema no es que actúe como humano, sino que actúe de manera impredecible. Lo frustrante es no poder definir el rango de lo que se puede esperar.
El problema mayor es que la frustración genera estrés, y eso es malo para la salud y crea un entorno de trabajo hostil. Entiendo la idea de que las herramientas de IA pueden ayudar más de lo que hacen sufrir, pero no quiero trabajar en un entorno laboral doloroso y hostil. Mi salud y mi dignidad no son negociables, aunque por eso tenga que dejar pasar muchos trabajos.
Por la misma razón tampoco trabajo con Windows. Eso también me cierra muchas oportunidades, pero prefiero preservar mi dignidad y mi cordura.
Los LLM tampoco están todavía en un nivel que me sirva. Lo que necesito es un LLM que diga: “Para, creo que ahora mismo estás haciendo algo mal, así que explícame qué intentas hacer”. En cambio, siento que la generación actual de LLM está diseñada para hacerme enojar.
Si yo actúo como maestro, el modelo actúa como discípulo; si yo actúo como discípulo, el modelo intenta enseñarme. Así que el objetivo es llevar esta conversación al lenguaje de expertos que discuten con razón y lenguaje. Siento que gana el prompt académico.
Basta con imaginar a una maestra de guardería que cuida niños o a un camionero que transporta comida diciendo que “la frustración genera estrés y un entorno de trabajo hostil, así que es mala para la salud”.
El problema que siempre veo es que, cuando haces una propuesta, la IA pasa por un bucle de razonamiento, llega a una conclusión exactamente equivocada y luego empieza a vomitar tokens con una solución ajustada a esa conclusión.
Preferiría que dijera más seguido: “No estoy seguro de entender lo que quieres decir, aclárame esta parte”. Me hace falta algo así como un control deslizante de confianza para regular su propia seguridad.
Por ejemplo, en TDD, si haces que el mismo modelo escriba tanto las pruebas como el código, casi siempre decide primero la solución y luego escribe a regañadientes pruebas que encajen con ella. Por eso doy instrucciones de usar subagentes, pero faltan muchísimo herramientas para entender qué contexto se transmite entre el agente y el subagente.
Lo que mejor me ha funcionado es hacer que un hilo escriba solo las pruebas. No puede leer el código, o solo puede leer el directorio de tests o una parte de él. Luego, otro hilo en un contexto nuevo ejecuta las pruebas, confirma que fallen y, en el momento en que pasan, detiene la implementación y no le permite modificar las pruebas. Después, otro contexto nuevo hace refactor siguiendo una skill estricta de refactorización. Da mucho trabajo y, de forma irónica, las skills escritas por el agente son bastante malas, así que hace falta mucho trabajo manual, pero la recompensa vale la pena.
Creo que el problema de UX está en otra parte. Es muy posible que muchos usuarios no sepan que la ventana de contexto del agente es limitada y que se aplica compresión inteligente de forma continua para que parezca infinita. Pero eso implica que el agente necesariamente tiene que olvidar parte de las cosas.
Como resultado, los usuarios siguen reutilizando la misma sesión de coding o la misma sesión de chat. Si la tarea no tiene relación, es mejor empezar de nuevo.
Normalmente trabajo con sesiones de menos de 300 mil tokens, en Opus 4.7 xhigh, y hay huecos en el world model o zonas con cierto condicionamiento muy fuerte; por más fuertes y explícitas que pongas las reglas en el system prompt, algo se filtra. Incluso en una sesión nueva, si tropieza con uno de esos puntos, entra en un ciclo del que es difícil salir, y soltar alguna grosería ayuda un poco.
Trabajar con LLM sirve para mejorar la capacidad de comunicación. Comunicarse de forma efectiva es una de las habilidades más difíciles, y está presente en casi todo lo que hacen los humanos.
En principio, me parece mejor verlo como un fallo de comunicación de mi parte que culpar a un LLM tonto. Al final, la única parte que realmente puedo cambiar soy yo. Por eso no creo que sea una cuestión formal de si la IA debe o no comportarse como un humano.
Se supone que el agente está entrenado para funcionar mejor incluso con sintaxis poco clara o ambigua y con mala estructura, pero la calidad cambia de forma notable si le hablas en inglés claro y estructurado y le das suficiente contexto de la tarea. Para mí eso sale natural porque me gusta escribir y explicar, pero para algunas personas parecía casi una barrera imposible de superar. Creo que esta capacidad de comunicación y escritura va a ser un factor enorme para separar a quienes tienen y no tienen ventaja mientras cambia la “ingeniería” de software.
Además, parte del valor de un agente de coding está en que no tengas que detallar absolutamente todo a la perfección. Si tengo que darle al LLM cada detalle de implementación, entonces mejor escribo yo mismo el código. Obviamente no espero algo del nivel de “hazme una app increíble que genere dinero”, pero sí espero cierto grado de inteligencia para encontrar las piezas que faltan.
La habilidad que todavía tengo y que los LLM aún no han reemplazado es la de hacer buenas preguntas
Es la capacidad de reformular la pregunta original para confirmar si entendí bien, preguntar suficiente “por qué” hasta entender desde dónde parte la otra persona y hacer preguntas abiertas que generen insight. En cambio, los LLM suelen adivinar mal el contexto de una pregunta, responder basándose en esa suposición y luego no pueden soltar la premisa que ellos mismos inventaron
Normalmente no quiero que la IA me haga preguntas. Prefiero que suponga razonablemente lo que no especifiqué, porque si hubiera querido especificarlo, lo habría hecho. Por eso a veces le digo explícitamente que no haga preguntas y que asuma de forma razonable las partes insuficientemente especificadas. Claro, cuando sí quiero preguntas de aclaración, basta con decirlo. Si prefieres ese estilo, puedes ponerlo en el prompt o hacer que una skill o una extensión en una herramienta de programación flexible como pi la empuje en esa dirección más exploratoria
En vez de crear herramientas, estamos creando servicios. Esto no se limita a la IA; está pasando en todas partes
Las herramientas no resuelven un problema por completo de una sola vez, pero te permiten avanzar en pasos pequeños, y esos pasos son predecibles y consistentes. Los servicios intentan resolver el problema de una vez, pero su solución solo es buena cuando el usuario encaja en un patrón predefinido. Si no encaja, no sirve, y tampoco hay pasos pequeños que puedas ir combinando hasta llegar a lo que necesitas. Las herramientas dan gusto usarlas
Una herramienta es una extensión de mí, pone nuevas capacidades al alcance de mi voluntad, y la muevo y la uso como si fuera parte de mi cuerpo. En cambio, un servicio es algo al que le pides que haga una tarea y te devuelve un resultado terminado