Los copilotos de IA ya no bastan; necesitamos HUDs de IA

• La crítica de Mark Weiser a la metáfora del "copiloto" de IA, planteada en 1992, sigue vigente hoy
• Weiser defendía una interfaz que se integre de forma natural en la experiencia del usuario, no un "asistente"
• El concepto de HUD (Head-Up Display) de los aviones modernos muestra bien esta filosofía
• Varios ejemplos revelan el valor de una UI estilo HUD que amplía la percepción del usuario, en lugar de automatización o interfaces de agentes
• Los copilotos funcionan bien para tareas cotidianas, pero en situaciones creativas o no estructuradas, un HUD potencia mucho más las capacidades humanas

---

La crítica de Mark Weiser al copiloto en 1992

• En 1992, Mark Weiser planteó críticas a la idea de comparar la IA con un "copiloto" en un evento del MIT Media Lab sobre "agentes de interfaz"
• En ese momento ya se discutían problemas que siguen vigentes hoy, como el reconocimiento de contexto y la automatización
• En lugar del "copiloto" (una IA que actúa como apoyo del piloto, casi como un humano virtual), Weiser defendía un sistema que permitiera al usuario percibir la información de forma natural
• Su ideal era el de una "computadora invisible", un entorno que funcionara como una extensión natural del cuerpo del usuario

El HUD (Head-Up Display) y la filosofía de Weiser

• El HUD (Head-Up Display) de los aviones modernos superpone información clave, como el horizonte o la altitud, sobre una pantalla transparente, para ofrecerla de manera natural dentro del campo visual del piloto
• A diferencia de un copiloto, el HUD no requiere conversación y amplía de forma natural la capacidad de percepción
• Esta idea de HUD encaja con la usabilidad que proponía Weiser

Cómo se materializa un HUD en el software

• El corrector ortográfico no funciona hablando como un "colaborador de IA", sino subrayando automáticamente en rojo los errores tipográficos
• Este tipo de información inmediata y visual es un ejemplo de HUD que crea un nuevo sentido para el usuario
• Una UI de depuración personalizada impulsada por IA también puede visualizar de forma intuitiva el comportamiento de un programa, para que el usuario detecte y entienda directamente los problemas
• Este enfoque se distingue de la automatización tradicional o las interfaces de "asistente virtual", y amplía de forma directa los sentidos humanos

Los trade-offs entre HUD y copiloto

• El autor aclara que no sostiene que un HUD siempre sea mejor que un copiloto; cada enfoque tiene ventajas y desventajas
• Para tareas rutinarias y predecibles (por ejemplo, volar en línea recta), el enfoque de copiloto es eficiente
• Para problemas no estructurados y creativos (por ejemplo, comprender una situación durante un aterrizaje de emergencia), una herramienta que apoye la cognición humana, como un HUD, puede ser muy poderosa
• Quienes diseñan IA también deben considerar interfaces que se alejen del "asistente" y apunten a ampliar los sentidos humanos, como los HUD

Conclusión

• En el diseño de la IA del futuro, hace falta reconocer el valor y los trade-offs tanto del enfoque de copiloto como del enfoque HUD
• La automatización común puede dejarse a un asistente virtual, pero si se buscan resultados superiores, una de las estrategias más poderosas puede ser ofrecerle al experto humano una "nueva superpotencia", como lo haría un HUD

[GN⁺]

Opiniones en Hacker News

• Me da mucha curiosidad si sería útil poder activar un mapa de calor que muestre qué tan sorprendente le resulta cada token de un archivo fuente al modelo. Los tokens en rojo tendrían mayor probabilidad de ser errores, malos nombres o comentarios incorrectos.
  • A veces el código impredecible se debe a un algoritmo novedoso, pero incluso en esos casos hace mucha falta una mejor documentación. Si agregas explicaciones adecuadas al código, eso en sí mismo lo vuelve menos sorprendente. Es decir, se puede estructurar ciertas partes del código fuente para que no resulten sorprendentes, y quizá eso sea una buena práctica de ingeniería. Gracias a los LLM, todos han empezado a prestar atención a la importancia de una buena documentación. Hace aún más falta si quieres que no solo otras personas, sino también una IA, puedan leer y entender el sistema.
  • Me parece una idea realmente genial. A la inversa, también sería muy útil si las sugerencias de la IA vinieran con un mapa de calor por nivel de confianza.
  • Me gustaría que el editor tuviera una función así. También serviría para verificar si la escritura es demasiado predecible o trillada. Calcular la perplexity tampoco es difícil, así que solo habría que integrarlo en la UI del editor.
  • Interesante. A menudo siento que no hemos aprovechado lo suficiente los “frutos al alcance de la mano” que surgieron desde el furor inicial de los LLM. Esta es justamente una de esas ideas.
  • Me parece una idea verdaderamente fantástica.
• Hace como 10 años Bret Victor dijo que minimizar el retraso de retroalimentación era un principio de vida. Decía que los ciclos rápidos de iteración no solo mejoran la forma de programar, sino que también contribuyen a obtener ideas creativas. Mostró programas de ejemplo variados para presentar alternativas, y el caso del HUD mencionado por el OP también se parece mucho a su demo de “retroceder en el tiempo para entender el código”. Video relacionado
• Me gustó esta idea, así que pensé en cómo podría aplicarse al proceso de programación en general. Imaginemos esto: mientras escribes código, un LLM genera pruebas y el IDE las ejecuta en tiempo real. En cada pulsación se corren de 10 a 100 pruebas en <1ms, y los resultados se muestran de forma discreta. Las pruebas aparecen en un panel separado junto al código, y si la última ejecución pasó o falló se distingue con puntos rojos o verdes. Solo con ver qué pruebas existen o no, y cuál es su estado, ya puedes entender desde “afuera” qué hace el código que estás escribiendo. Si crees que hace falta una prueba que el LLM no está escribiendo, eso puede ser señal de que el prompt está mal o de que el código no coincide con la intención. La propiedad de tiempo real ayuda mucho a pulir el código. Si quisieras hacerlo como TDD tradicional, el usuario también podría escribir las pruebas y el LLM escribir el código para hacerlas pasar.
  • Es mucho mejor que la persona escriba primero las pruebas y que el LLM genere el código. Porque las pruebas son la “verdad” y la “intención” del código. Si renuncias al control de definir entradas y salidas, el desarrollador deja de estar en el asiento del conductor.
  • En una base de código seria de C++ esto es inviable. Solo los tiempos de compilación ya lo hacen imposible, y además es difícil que el LLM adivine pruebas si no escribe todo el código. Por ejemplo, si estás creando una nueva estructura de datos, ¿cómo se supondría que el LLM lo sepa?
  • No me parece buena idea que un LLM genere pruebas mientras escribes código y que el IDE las ejecute cada vez. Las pruebas son código que garantiza invariantes, así que no conviene que un LLM las ande tocando libremente. Las pruebas solo deberían cambiar cuando el usuario las modifica explícitamente, y deberían cambiar solo ellas. Bajo esas restricciones, esto ya es un flujo de trabajo cotidiano. Como el modo watch de los frameworks de pruebas de JavaScript. Es un flujo que los desarrolladores ya vienen usando desde hace 10 años.
  • ¿No harían falta también pruebas para verificar que las pruebas estén bien escritas? Si no, el LLM simplemente podría hacerlas pasar aunque las pruebas mismas estén mal. O incluso podría escribir código solo para engañar al sistema. Al final, el mejor setup será uno en el que el LLM y el humano puedan cruzar libremente sus fronteras respectivas. Es mucho más productivo y streamlined escribir solo los requisitos claros y dejar que la IA maneje la mayor parte de ambos lados.
  • Ejecutar toda la suite de pruebas con cada entrada tiene un ROI demasiado bajo. La mayoría de las pulsaciones ocurren cuando el programa aún está “incompleto”, así que hay que decidir con más inteligencia cuándo correr las pruebas para lograr un equilibrio razonable.
• Al final, todo se reduce a la pregunta: “¿Cuál es la interfaz ideal para que los humanos manejen información digital?”. Cada día absorbemos más información, y por culpa de la IA esa cantidad no va a reducirse, sino a aumentar. Si además resume información compleja y especializada, como logs de errores, se abre un nuevo camino para que personas que antes no podían accedan a esa información. Entonces, ¿cómo deberíamos manejar toda esta información de forma eficiente? Hoy tenemos todo tipo de interfaces, sitios, dashboards, correos y chats, pero dudo que dentro de 10 años sigan haciendo falta todos. Si pudiera recibir toda la información en una sola interfaz de chat, ¿realmente necesitaría entrar a los sitios? Que la IA construya sitios web, apps y web UI por nosotros ya empieza a sentirse un poco... redundante.
  • Un sitio web era precisamente una forma de recibir información “oficial” desde una fuente confiable, como una empresa o Wikipedia. Esa confiabilidad era tan poderosa que por eso se trabajó tanto en la “line of death”, el ícono del candado, las defensas contra phishing y la mitigación de ataques con homoglifos. Todo se movía bajo la suposición de que ese sitio contenía información oficial y confiable. En un mundo donde todos dependen de los LLM sin espíritu crítico, realmente se vuelve confuso qué significa “confianza”. Aunque el LLM normalmente acierte, ¿de verdad podrías confiar en él también en momentos cruciales?
  • Los diseñadores de cazas de sexta generación se están topando exactamente con el mismo problema. La cabina es la interfaz entre la aeronave y el piloto, pero su papel se reduce cada vez más. Cuando llegue la séptima generación, no está claro si el humano seguirá teniendo un rol valioso. (Aun así, podría seguir siendo necesario por razones como el derecho internacional o la gestión del riesgo tipo Skynet). Probablemente las interfaces en todos los ámbitos evolucionen así. La complejidad irá disminuyendo, y el humano solo tendrá que explicar al sistema lo que quiere en conceptos de alto nivel. No necesariamente en lenguaje natural; si hace falta una especificación precisa, también podría ser una interfaz hecha para eso.
  • Como todas las personas son distintas, no habría que generalizar las interfaces, sino personalizarlas dinámicamente al momento.
  • No creo que el smartphone sea realmente perfecto ni que se esté aprovechando prácticamente al máximo. Aun así, es lo que más me gusta.
• Creo que una función donde la IA genere visualizaciones complejas en tiempo real sería realmente útil. Por ejemplo, al depurar un memory leak en una ruta específica del código, la IA podría visualizar las asignaciones y liberaciones de memoria en esa ruta para ayudar a detectar el problema. Parece que se viene una era en la que la IA cree directamente herramientas de visualización adecuadas para cada problema particular. Un talk reciente de Jonathan Blow en LambdaConf conecta exactamente con esta idea. Mostró herramientas que visualizan programas de distintas maneras para encontrar problemas potenciales. Creo que la IA podría construir muy bien herramientas así. Ver video completo
• Quiero ver de inmediato en un HUD los cambios conectados con los TODO items de Claude Code. No quiero comentarios inline, porque con el tiempo se acumulan y el LLM no los organiza bien.
• Una de las razones más importantes por las que los HUD todavía no se han masificado es la limitación de los medios de visualización actuales. Los monitores y dispositivos móviles no son buenos para ofrecer información periférica y no intrusiva. Cuando un agente de IA corrige bugs o resuelve tareas complejas, el tiempo de espera por el resultado es ambiguo. Es demasiado corto como para ponerse a hacer otra cosa, pero también se siente raro quedarse mirando la pantalla todo el tiempo. Con un HUD podrías tener un loop de retroalimentación mucho más corto. Podrías ver de reojo lo que hace la IA e intervenir al instante, o simplemente seguir con otra cosa. Lo importante es que, en vez de elegir entre atención total o desentenderte por completo, puedas decidir en cada momento cuánto intervenir dentro de una conciencia ambiental. Por eso creo que VR/AR podría ser la killer app clave de los AI HUD. Gracias a la computación espacial, podrías recibir ayuda de la IA sin apartar la vista de una pantalla 2D. Este enfoque también sería especialmente útil en tareas físicas como cocinar o reparar una bicicleta.
  • Yo hago algo parecido conectando un monitor ultrawide con la pantalla de la laptop. Mientras me concentro en un juego u otra tarea, dejo a Claude abierto en una ventana de tmux en una esquina y reviso de inmediato cuando aparece el siguiente paso o algún cambio importante.
• Creo que una interfaz de programación estilo HUD es básicamente AREPL. Va bien para depuración, pero siento que una ventana de chat o un Q&A inline sirven para una gama mucho más amplia de usos. En general estoy de acuerdo con la lógica de buscar interfaces alternativas al chat, pero en la práctica el chat ya es una interfaz abrumadoramente dominante en smartphones. El HUD parece más apropiado para un HUD real, como unos lentes AR.
• Creo que también son posibles modelos de IA que operen de manera autónoma durante mucho tiempo en segundo plano y que hagan “push” de información cuando sea necesario. Sería un enfoque donde detectan inteligentemente el contexto, filtran, resumen y entregan el contenido, e incluso recomiendan cosas si hace falta. En especial, en entornos de negocio donde hay que monitorear a muchos clientes en 100 situaciones distintas, eso sería mucho más natural.
  • En realidad, lo más difícil es definir el contexto y recopilar los datos relevantes. El problema de que un sistema autónomo haga eso en sí ya quedó resuelto técnicamente hace mucho tiempo.
• Estoy de acuerdo con la afirmación de que “si vamos a diseñar en serio para la IA, hay que pensar en formas que expandan el interior humano más allá de un simple copiloto”. De hecho, el auto-complete ya cumple en parte ese rol. Claro que también puedes conversar con un LLM, pero también puedes darle instrucciones simples o usar autocompletado. Lo que el autor parece querer enfatizar, aunque sea de pasada, es que la IA debería trabajar a nuestro lado, mirando en la misma dirección que nosotros. No un copiloto tipo “humano virtual” que se sienta enfrente de la mesa a discutir, sino un colaborador real que haga de inmediato lo que le pedimos.
  • Soy el autor. Sí, la UI de autocompletado de GitHub Copilot es en verdad un buen ejemplo de HUD (irónicamente). El autocompletado con tab se integra como si fuera una parte del cerebro. Pero últimamente el entorno de programación se está moviendo hacia agentes de chat. Vale la pena imaginar cómo sería una UI de “autocompletado con tab” en un nivel de abstracción más alto. Podría convertirse en una forma de diseñar código realmente directa, sin quedar atrapados en detalles secundarios.